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

[RMerlin]

With DNSSEC enabled, I still can’t get to this site with the new 384.13 Alpha1.

sa.gov.au

Disable DNSSEC, & no problem getting to it.

Odd, it resolves properly for me. The domain also passed Verisign's DNSSEC validation test, so it shouldn't be a problem on their end.

 

[Gitsum]

Do you have any unusual configuration? I discovered the dnsmasq crash issues last night as my RT-AC88U was no longer able to add any nodes for instance, so it seems like a lot of things can interfere with AiMesh.

Also during the pairing, make sure the node is brought closer to the router (Asus mentions it should be within 3 meters).

I have guest wifi on both bands and using YazFi, conmon, and AMTM. Using a Pihole device for DNS server.
During pairing I had the units within a couple feet of each other.

 

[Swistheater]

Can any of the AiMesh testers try the firmware downgrade and upgrade capabilities of their nodes? Try flashing back the previous firmware, then test the Check button, as well as the link displaying release notes.

Regarding DNSSEC, this is similar to the odd behaviour I mentionned in the first post. In my case, DSA validation seem to be handled by my ISP's servers, so I get successful validation even tho DSA validation is currently disabled in dnsmasq. We'll see if @themiron can track anything there.

I went RISKY! I flashed all of my access points down to the lesser model stock firmware. ADD each as an AIMESH node. Then I hit the update button....

SUCCESS!

Edit ---- I paired all of mine via hard wire backhaul with no penalty issues.

I noticed better wireless speed (about the same speed as the Main router)
by switching my connection priority to Ethernet this is highly recommended especially if you have switches in between on your network for better compatibility.

(for those script-users)
So far, I have not noticed any issues with any scripts I am running on main router.

edit 2..
Everything appears stable after reboots (note it takes a couple of minutes for cpu to calm down, due to the script world)

 

[Swistheater]

I have guest wifi on both bands and using YazFi, conmon, and AMTM. Using a Pihole device for DNS server.
During pairing I had the units within a couple feet of each other.

I highly recommend in the pairing mode you only pair without scripts active, due to aimesh being designed to pair in "Normal" asus stock conditions.

also, sometimes nodes or router may have to be rebooted if pair fails, this is normal behavior.

 

[Kingp1n]

I have guest wifi on both bands and using YazFi, conmon, and AMTM. Using a Pihole device for DNS server.
During pairing I had the units within a couple feet of each other.

Are you trying to connect them wirelessly or wired ....tried connecting a lan cable from the main router to the wan port of the node and try to sync them...also some folks had luck syncing them thru the Asus app as well.

 

[Swistheater]

Are you trying to connect them wirelessly or wired ....tried connecting a lan cable from the main router to the wan port if the node and try to sync them...also some folks had luck syncing thru the Asus app as well.

Lan cable will definitely help, it allows for it to focus on better. originally, when aimesh first release, the lan cable pairing was horrible, with several version updates later it works very well.

 

[Olivier]

Hello @RMerlin,

I assume that the source code used for compiled the AX88 firmware is based on Version 3.0.0.4.384.5951 and not Version 3.0.0.4.384.6210, just?
Otherwise is running smoothly with AX88 & 2 nodes AC68. I'm going to conduct further testing.

Thanks a lot for this work!

 

[karma]

hmmm, the web UI on my main router became really slow/unusable even after multiple restarts.. in firefox I constantly see that it's performing TLS handshakes (i have https enabled)

I managed to flash the stock firmware and the web UI is working properly again.

 

[Swistheater]

hmmm, the web UI on my main router became really slow/unusable even after multiple restarts.. in firefox I constantly see that it's performing TLS handshakes (i have https enabled)

I managed to flash the stock firmware and the web UI is working properly again.

You need to make sure you clear all browser and dns cache on your computer when switch to merlin.

 

[Swistheater]

Hello @RMerlin,

I assume that the source code used for compiled the AX88 firmware is based on Version 3.0.0.4.384.5951 and not Version 3.0.0.4.384.6210, just?
Otherwise is running smoothly with AX88 & 2 nodes AC68. I'm going to conduct further testing.

Thanks a lot for this work!

Rmerlin is using latest for that line

 

[Olivier]

Rmerlin is using latest for that line
View attachment 18599

Thanks a lot to point me in the right direction. I will check on GitHub next time Sorry I'm just a newbie with Asuswrt-Merlin.

 

[king006]

@RMerlin,

Good to read that you are now testing with Aimesh support I have been using it for some time with the 'normal' Merlin firmware and the node with stock firmware. So I turned aimesh on manually via SSH. Has a lot been adjusted by you in this build? In other words, does it make sense to change the 'release' Merlin to this 'alpha' build on the main router?

I ask for certainty, I assume that in this situation the node(s) must always use the stock firmware as otherwise you cannot perform an update/upgrade on the GUI?

 

[Blacklistedcard]

Loaded alpha onto my AC86U. Running fine. I did notice this in the logfile. First time seeing it.

Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 6
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 6
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 6

 

[octopus]

Just updated on top of 384.12 and working fine.
Uptime 0 days 0 hours 18 minute(s) 55 seconds

Thank you.
RMerlin

 

[Swistheater]

Loaded alpha onto my AC86U. Running fine. I did notice this in the logfile. First time seeing it.

Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 4
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 6
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 6
Jul 10 09:00:42 lldpd[878]: custom TLV op remove oui f8:32:e4 subtype 6

This is normal in system logs for aimesh and even for non aimesh even in stock, dont be concerned unless you start to have performance or function issues.

 

[RMerlin]

I have guest wifi on both bands and using YazFi, conmon, and AMTM. Using a Pihole device for DNS server.
During pairing I had the units within a couple feet of each other.

Dial back on the customisations in case one of them interferes.

hmmm, the web UI on my main router became really slow/unusable even after multiple restarts.. in firefox I constantly see that it's performing TLS handshakes (i have https enabled)

Known issue with Firefox, been like that for years. You need to either generate your own CA + certificate pair, or switch to a different browser. Also, sometimes deleting the saved certificate in Firefox's database can help.

In other words, does it make sense to change the 'release' Merlin to this 'alpha' build on the main router?

The goal of this test program is to gather as much test data as possible to determine if it can safely become an officially supported feature, so any extra testing could be useful.

I did notice this in the logfile. First time seeing it.

Those are related to the AiMesh pairing process from what I can understand.

 

[king006]

@RMerlin,

Thank you! I will test it with this firmware no problem.

 

[Magnus33]

Can any of the AiMesh testers try the firmware downgrade and upgrade capabilities of their nodes? Try flashing back the previous firmware, then test the Check button, as well as the link displaying release notes.

Regarding DNSSEC, this is similar to the odd behaviour I mentionned in the first post. In my case, DSA validation seem to be handled by my ISP's servers, so I get successful validation even tho DSA validation is currently disabled in dnsmasq. We'll see if @themiron can track anything there.

Downgraded my AC68U node to previous firmware without issue.

Did the firmware check on my primary AC86U and the firmware upgrade button showed (its placement a little wrong as its blending into the check button somewhat).

Upgrade proceeded as normal and the AC68U node upgraded correctly without issue.

One thing of not is the flashing yellow firmware upgrade icon doesn't quite clue into the upgrade tell you click on it and redo the check again.
Minor issue which has no effect on function.

As Eric mentioned the nodes need to be within three feet and make sure you go into operation mode and set the router to aimesh.
I had no problems with my AC68U connecting once this was done.

 

[Swistheater]

Dial back on the customisations in case one of them interferes.



Known issue with Firefox, been like that for years. You need to either generate your own CA + certificate pair, or switch to a different browser. Also, sometimes deleting the saved certificate in Firefox's database can help.



The goal of this test program is to gather as much test data as possible to determine if it can safely become an officially supported feature, so any extra testing could be useful.



Those are related to the AiMesh pairing process from what I can understand.

I know this is for Aimesh/dnssec , but there seems to be something I am noticing. I no longer see the ntp server options inside dnsmasq.conf when testing it. I noticed @themiron moved around the placement of this option in one of his commits , could this have broken the option to add the dhcp ntp option when local ntp server is enabled?


Edit: disabling and re-enabling fixed issue.

 

[themiron]

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.

I noticed @themiron moved around the placement of this option in one of his commits , could this have broken the option to add the dhcp ntp option when local ntp server is enabled?

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