What's new

[Experimental] Asuswrt-Merlin 384.13 test - AiMesh/DNSSEC through OpenSSL

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
I may have have found a bug on the Wireless Log tab it is not displaying the IP address of the Nodes for both the 2.4 and 5GHZ bands, it displays as unknown.

This is normal. The nodes get their IP addresses on a different MAC address than those used by the wifi bridge. These bridge connections don't have any IP address allocated to them.

I'm not using logs from the Diversion or the Scribe. Observing the htop, the event log-async dnsmasq consuming 10% of memory, AC86U. I noticed that the wifi disconnect some devices.

dnsmasq is the DHCP server and DNS resolver of your router, it has nothing to do with Diversion or Scribe.
 
dnsmasq is the DHCP server and DNS resolver of your router, it has nothing to do with Diversion or Scribe.
I know. What you mention is that the generation of logs of these software also consume memory. --log-async of dnsmasq consumes 10% of memory here.
 
I know. What you mention is that the generation of logs of these software also consume memory. --log-async of dnsmasq consumes 10% of memory here.

--log-async merely tells dnsmasq to log asynchronously to syslog, to prevent deadlocks if you have actual query logging enabled (which people normally don't) and are generating a lot of entries. It has nothing to do with Scribe or Diversion, and it has no real impact on its memory usage either. The memory usage you see is mostly for its resolution cache.
 
That is because it is designed to pick preference to your main router, if you using a dual band less powerful router as your main and this as your node you are bound for issues in setup somewhere. Also you lose the benefit of having the 3rd band used as a wireless backhaul on the rt-ac5300 , instead it may simply appear disabled when it is a node.

I am using wired as the backhaul on all nodes. If using a tri-band router as a node when using a dual-band as main makes you lose that functionality of the extra band, it is definitely a detriment. The 88 isn't "less powerful", it just isn't tri-band. Unfortunately, I need the higher count ports on the main router due to my set up.

What I don't understand is why having the extra band would affect any of the other regular settings copying over to the node. Things like link aggregation or Bluetooth coexistence are unrelated to the extra band existing and should be copied to the node right?

That is too bad because aimesh was looking to have some promise with my setup. I doubt it is ideal but I have to ask...Is it possible to run a set up with AImesh enabled, a couple of mesh nodes active but the 5300 active as a normal AP? Why is the reason this wouldnt be ideal?
 
Yes. That’s what I did. I thought that was best to avoid complications.

Next playtime, when I go back to using Merlin on the node, I won’t do it that way.

As this is alpha testing I just thought I’d give it a go.

All is still good.

Update:

With reference to my post #338

As this downgrade to stock FW on the NODE went well and has been running problem free since I did it this morning, I have flashed the NODE back to Merlin 384.13 alpha2. No issues.

This time I simply went straight to the MASTER and selected Admin/Firmware/NODE and manual update from the Merlin .trx file. I did not remove the NODE or even reset the NODE after updating.

Again, all went as smooth as silk.

For me this is practically a release version, never mind a alpha. I think Eric should sub-contract to Apple and show them how it's done! lol.
 
Tl;dr
I am patiently waiting for RMerlin's beta :)

Due to Family home for summer break, I have been unable to test this alpha, yet following thread attentively. I am allowed to "test" RMerlin's betas, due to their stability.
 
So far it seems the integration of AiMesh is working properly. The only reported issues are typical AiMesh issues and not related to my firmware code.

OpenSSL-based DNSSEC validation seems to work well as well. While the validation behaviour seems a bit odd at times (where validation done upstream might be accepted regardless of dnsmasq), no odd issue seems to be occurring, so it should be safe to formally do the switch from Nettle to OpenSSL.
 
4+ days running alpha 2 on an RT-AC86U. Set up an RT-AC68P as a wireless mesh node on stock firmware. Setting up the node went smoothly. Devices didn't connect to the node at first - Per someone else's comment, I did change the connection priority for the node from "Auto" to "Ethernet" and it resolved, but that may have been coincidence. No other issues or errors, nothing unusual or new in the log. Great work as always!
 
I’ve been running the experimental builds alpha 1 & 2 on my RT-AC86U since they were released, I haven’t been testing AiMesh

OpenSSL-based DNSSEC validation has been working fine

e39d6826f6625567eb72a2e771ebc8d7.jpg


To be honest my router has been performing flawlessly


Sent from my iPad using Tapatalk
 
I’ve been running the experimental builds alpha 1 & 2 on my RT-AC86U since they were released, I haven’t been testing AiMesh

OpenSSL-based DNSSEC validation has been working fine

e39d6826f6625567eb72a2e771ebc8d7.jpg


To be honest my router has been performing flawlessly


Sent from my iPad using Tapatalk
What DNS provider were you using? Most seem to be going with Quad9 (which I believe to be because of the thread with the cloudlfare and Quad9 guys giving input). I'm using Cloudlfare and Quad9 and having no issues so far.
 
So far it seems the integration of AiMesh is working properly. The only reported issues are typical AiMesh issues and not related to my firmware code.

OpenSSL-based DNSSEC validation seems to work well as well. While the validation behaviour seems a bit odd at times (where validation done upstream might be accepted regardless of dnsmasq), no odd issue seems to be occurring, so it should be safe to formally do the switch from Nettle to OpenSSL.


Seeing no major issues on the AC86U :)
 
What DNS provider were you using? Most seem to be going with Quad9 (which I believe to be because of the thread with the cloudlfare and Quad9 guys giving input). I'm using Cloudlfare and Quad9 and having no issues so far.

I mainly use Quad9, I used Cloudflare to start with until as you mentioned the guys from Cloudflare and Quad9 gave us the opportunity to ask some questions. I do mix it up a bit and use Cloudflare, I’ve found they both perform very well for me


Sent from my iPad using Tapatalk
 
I’ve been running the experimental builds alpha 1 & 2 on my RT-AC86U since they were released, I haven’t been testing AiMesh

OpenSSL-based DNSSEC validation has been working fine

e39d6826f6625567eb72a2e771ebc8d7.jpg


To be honest my router has been performing flawlessly


Sent from my iPad using Tapatalk
Do you get the same test results with Cloudflare and Quad9?

Thanks.
 
Do you get the same test results with Cloudflare and Quad9?

Thanks.

Quad9

bee1ea68bbb5080d4f02a84959962622.jpg


Cloudflare

23378d5e9df2de937da69e3f74978bb1.jpg


Both were tested using google


Sent from my iPad using Tapatalk
 
Quad9

bee1ea68bbb5080d4f02a84959962622.jpg


Cloudflare

23378d5e9df2de937da69e3f74978bb1.jpg


Both were tested using google


Sent from my iPad using Tapatalk

I don't understand when you state both were tested using google?

I get the same as the above when using the very latest Edge Developers Chromium edition browser though. ;)
 
I ran the 13 A1 and 2 for several days without re-configuring the Stubby or DNSMASQ settings. As before I get much better results with Cloudflare and CleanBrowsing than Quad9 on DoT/DNSSEC. My ISP routes the anycast for Quad9 to resolvers 1,000 miles or more away while the Cloudflare goes to a data center less than 100 miles as the crow flies. The two RT-AC68U's I manage on Comcast work very well (384.12) on Quad9 with DoT/DNSSEC.
However, I seem to get better all around operation with enabling DNSSEC via Stubby. This does pose a problem getting DNS working after reboot as Stubby uses retrieved root keys.

Most users will do just fine using Merlin's DoT/DNSSEC GUI configuration.
 
I don't understand when you state both were tested using google?

I get the same as the above when using the very latest Edge Developers Chromium edition browser though. ;)

I use Edge as well with the same results, what I should of said was on this occasion the test were done using chrome


Sent from my iPad using Tapatalk
 
Hi I am using a a86u as main and gt-5300 as mesh node. With this alpha the 5300 node get's unresponisive after about 8 hours of runtime rebooting it fixes it. With stock firmware on the 5300 this doesn't happen.
 
I’ve been running the experimental builds alpha 1 & 2 on my RT-AC86U since they were released, I haven’t been testing AiMesh

OpenSSL-based DNSSEC validation has been working fine

e39d6826f6625567eb72a2e771ebc8d7.jpg


To be honest my router has been performing flawlessly

This is identical to what I see, I use Quad 9 and FF.


Sent from my iPad using Tapatalk
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top