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

[Swistheater]

No issues here....i rebooted multiple times as I'm tryin to use DoT with quad9...it's odd you're getting this issues.

I recommend doing a fresh reset on parent router, i was seeing constant disconnects with merlin -nodes until i did. The fresh reset probably makes merlin code play nice with merlin nodes, idk.

 

[Swistheater]

The long road to merlin nodes was a pain. I had to factory reset main and reconfigure from scratch to allow merlin nodes to play nicely (meaning not disconnecting frequently).

*update* Nodes survive reboots, I have not tested nodes without wired back-haul though.

 

[Magnus33]

The AC86 does, the AC68 did not.

In all likelihood its needs to be brought near the primary router and completely reset.
Then during setup you select the aimesh option which should allow it to connect to wireless.

Noticed aimesh is quite picky that way but once done it should do as its suppose to.

 

[Swistheater]

In all likelihood its needs to be brought near the primary router and completely reset.
Then during setup you select the aimesh option which should allow it to connect to wireless.

Noticed aimesh is quite picky that way but once done it should do as its suppose to.

let it be noted you may also need a good reset done to your primary router not just the nodes.

 

[RacerRon]

I don't know if it makes a difference but , on my node router all I did was a factory reset then added it as a node from main router. I never changed any setting on the node including initial setup. The main router did everything setup related on the node.

Is there any real reason or benefit to running Merlin on the node vs stock Asus ?

Sent from my Pixel using Tapatalk

 

[Swistheater]

I don't know if it makes a difference but , on my node router all I did was a factory reset then added it as a node from main router. I never changed any setting on the node including initial setup. The main router did everything setup related on the node.

Is there any real reason or benefit to running Merlin on the node vs stock Asus ?

Sent from my Pixel using Tapatalk

well if merlin is able to at some point fine tune or otherwise make better his setup with the included merlin nodes, those who are on stock nodes will not get the benefits from merlin nodes and would otherwise be missing out. Aside from testing, I think this is the only relevance.

 

[Swistheater]

I tested wifi from nodes, speed and performance seems on par with normal stock. No issues to report yet. I look forward to see where merlin takes this next.

 

[octopus]

Those of you use aimesh
What lan-ip range do you use?
Im using 192.168.12.1 and when I trying to connect my nod I se in log blocked adress 192.168.1.19 probably from aimesh nod. Maby I have to change that if I want them to connect.

Jul 13 16:17:41 rc_service: cfg_server 21418:notify_rc restart_obd_monitor
Jul 13 16:16:54 dnsmasq-dhcp[2679]: DHCPNAK(br0) 192.168.1.19 70:8b:cd:13:c2:58 wrong address

 

[RMerlin]

, it instead launches a small browser window, (in my case Chromium and Firefox), showing the login screen for the node.

This is how node update works. You must log into that node using that popup window, and then you will get a new page with a large Upload button.

The true question is will merlin nodes remain manual update only, or will there be some kind of hybrid method to allow it to check either merlin or stock (in mixed stock and merlin node setups)

New firmware availability check will remain automatic, and firmware upload will remain manual. I don't support automatic "live updates". Just like it has always been with Asuswrt-Merlin. Only nodes running the stock Asus firmware will be able to perform live updates.

 

[RMerlin]

Is there any real reason or benefit to running Merlin on the node vs stock Asus ?

Not really, beside maybe running some custom scripts on the nodes themselves, for instance to track connected clients and do "something" when a specific client connects to that node.

The fact it's supported is in large part because I had to fix a couple of issues related to routing and the web display of an Asuswrt-Merlin node that could have been erroneously joined. Since achieving actual support was just a few further steps ahead, I decided to go for it, so we can see if it's a viable feature or not. Remember, all of this current test project is still considered experimental. The gathered feedback will determine if it's a viable long-term feature or not, both as a router and as a node.

Personally, I recommend people stick to the original firmware for their nodes, so they can still get the benefit of live updates from Asus.

 

[heysoundude]

Personally, I recommend people stick to the original firmware for their nodes <snip>

...for the time being, until further notice.

This is moving along quite quickly and is exciting to watch. It'll no doubt be something quite formidable when it's a full release version.

 

[Swistheater]

Not really, beside maybe running some custom scripts on the nodes themselves, for instance to track connected clients and do "something" when a specific client connects to that node.

The fact it's supported is in large part because I had to fix a couple of issues related to routing and the web display of an Asuswrt-Merlin node that could have been erroneously joined. Since achieving actual support was just a few further steps ahead, I decided to go for it, so we can see if it's a viable feature or not. Remember, all of this current test project is still considered experimental. The gathered feedback will determine if it's a viable long-term feature or not, both as a router and as a node.

Personally, I recommend people stick to the original firmware for their nodes, so they can still get the benefit of live updates from Asus.

I don't mind the merlin node route as long as it can be sustainable like you said. I have always preferred manual update over, regular. If i have mixed node setup, will it still allow me to live up date my stock nodes that maybe in a mixed setup with merlin nodes?

 

[KnightRider]

AiMesh
Things in need of testing:

• Adding/removing a node
• Updating the firmware on one of your nodes. Try flashing a slightly older version, then make sure the Firmware Check option as well as the automatic firmware upgrade work properly, allowing you to be notified of new releases, and also reading the release notes posted by Asus.
• Validate that clients are able to connect to the separate nodes, and also that the nodes stay properly connected

For Wifi-specific issues, please take a look at the existing posts in the Official Asuswrt Forum here on SNBForums for troubleshooting steps. You may need to tinker with the Roaming Assistant setting, for instance.


Dnsmasq with OpenSSL
Things in need of testing:

• Look for any random lookup failure.
• Look for any permanent/persisting lookup failure. Note down the website address that fails to resolve.
• Please test with different nameservers on your WAN page (or different DoT servers)
• Test with the existing DNSSec validation sites available, like https://rootcanary.org/test.html
• Keep an eye on memory usage for dnsmasq, look for any steady increase in memory usage over multiple days in case of a potential memory leak
• Keep an eye on system log for any dnsmasq error message, about "insecure/missing DS records" or anything else

General

• Check that your DHCP static reservations were properly converted to the new format, that the list shows normally on the DHCP page
• Make sure that editing/adding/removing DHCP static reservations still work properly
• IPSEC could also use some testing, as @themiron did some cleanup to the code, removing some of Asus's customizations that were no longer needed

When reporting any issue, please provide information about the router(s) model(s), the firmware versions on your AiMesh nodes, the DNS servers used (with or without DoT).

Hi Eric, currently own AC68U, running on 380.70 build in AP mode w/basic setup for 2.4/5 operating behind a DMZ interface on my main firewall. Is it recommended to still move up to 384 build? Does AiMesh work in AP mode, will I gain any benefits from the newer wireless drivers for 2.4/5? Any input is much appreciated. Thanks

 

[jerry6]

384.13 alpha2 running well no problems so far onmy rt 5300

 

[Swistheater]

Hi Eric, currently own AC68U, running on 380.70 build in AP mode w/basic setup for 2.4/5 operating behind a DMZ interface on my main firewall. Is it recommended to still move up to 384 build? Does AiMesh work in AP mode, will I gain any benefits from the newer wireless drivers for 2.4/5? Any input is much appreciated. Thanks

On stock you can use AIMESH-router in AP mode, i don't know if any one tested it with Merlins New Aimesh test branch though.

 

[Plompie]

Running the 384.13 alpha2 on my AC86U with two AC68U with stock firmware as nodes. Works perfect!! Thanks!
Only "issue" I noticed so far is that the WiFi Site survey doesn't seem to work, but consider that a very minor issue.

Will continue to test of the next days. I switched since I had some stability issues with the stock firmware but enjoyed the easy maintenance of the AiMesh (wired backhaul).

I know so far it's about getting this alpha stable but to broadcast the guest network also from the Nodes would be a neat feature!

 

[Swistheater]

Network Map seems to detect devices more accurately when using in combination with merlin-nodes versus stock nodes.

* my site survey is working fine, no issues here with it.

 

[skeal]

Now I got this AiMesh figured out it sure is nice!! I vote to keep it as feature if we can do so without to much trouble. Great work Eric!!

 

[SomeWhereOverTheRainBow]

Should I be impressed with the Root Canary results in the first post when I get the same results with DNSSEC via Stubby? Still feel there should be a choice of where DNSSEC is processed. View attachment 18578 ?

IMO if DoT is enabled it should be married to stubby DNSSEC, with the simple option of DNSSEC, no need to tell dnsmasq to validate unsigned replies.

dnsmasq.conf would say

dnssec
dnssec-check-unsigned=no

and stubby.yml would say

dnssec_return_status: GETDNS_EXTENSION_TRUE

and the unsigned reply option should simply be disabled in the gui and remain hidden with DoT turned on.

no need for complexities of DNSMASQ verifying when it would be easier upstream by stubby and then cached later.

No, there will always be an option to enable/disable the validation done by the router itself, as this adds an extra layer of security.

.......

Regarding https://rootcanary.org/test.html test behavior.
Browser tries to resolve secure.dNaNnN.rootcanary.net & bogus.dNaNnN.rootcanary.net domains.
After that, following happen:
1. If bogus.* was resolved - test concludes resolver doesn't validate answers (yellow)
2. If bogus.* was not resolved but secure.* was - test concludes resolver performs validation. (green)
3. If bogus.* was not resolved and secure.* was not too - test concludes resolver doesn;t support algo in general. (red)

So, if upstream DNS performs validation on its own (i.e cloudflare) - bogus.* requests will not be validated upstream and therefore will not be replied to dnsmasq, and in turn - to client too.
Therefore test will be unable to test dnsmasq against 1st case at all (dnsmasq / client have no bogus.* reply), instead it actually will be test of upstream DNS server.
With cases 2 / 3 cases still possible, result will likely be between "green" (upstream and dnsmasq passes secure.* and upstream or dnsmasq blocks bogus.*) or "red" (upstream doesn't support dnssec at all or strips dnssec records badly or dnsmasq is broken somehow).

That's why you have more green than dnsmasq supports.
In clean environment there should be following - RSA-MD5/DSA*/ECC GOST algos and GOST digest are not validated (yellow), no SERVFAIL (no red), all the rest are validated (green) .

dig +dnssec <domain> @router.ip

will give a bit more light for partucular domain.
If there'll be "ad" flag - it's validated.
If no "ad" flag - insecure, due validation is not possible.
In other case validation will be failed with SERVFAIL status w/o resolved data.


Easy to check - start traffic capture with wireshark (dhcp or dhcpv6 filter) and wait for issue reproduction.[/CODE]

 

[Stephen Harrington]

but to broadcast the guest network also from the Nodes would be a neat feature!

Various Asus engineers promised that feature at various times during the public beta cycles for the (stock) AIMesh firmware, and it has never eventuated after nearly 2 years, which may mean it was a lot harder to implement than they initially thought ... which is not to say Eric couldn’t outsmart them yet again and do it himself, just that it is definitely not trivial from what I can tell?