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

[vdemarco]

I just installed it, i don't have airmess turned on, but do have dnsec turned on (not OpenSSL-based DNSSec) and everything seems to be working great. been up for 5 days so far.

 

[RMerlin]

Not sure if it's due to DNS issues, Link DOWN/UP switching or something else in this Alpha release but one night ago the router lost all connections and today around 11.00 my AC86U stopped working again.

Those messages are specifically at the Ethernet level, and have nothing to do with protocols or network applications. Change your Ethernet cable.

 

[bbunge]

I just installed it, i don't have airmess turned on, but do have dnsec turned on (not OpenSSL-based DNSSec) and everything seems to be working great. been up for 5 days so far.

If you have 384.13a 1 or 2 and DNSSEC enabled in the gui then you are running OpenSSL validated DNSSEC. Just installed and up for 5 days does not compute either...

Sent from my SM-T380 using Tapatalk

 

[Neil62]

I have just installed the alpha 2 on the main router, all running great and completed a factory reset of all nodes and Main. No problem at all rejoining nodes. Nodes still using the original current ASUS firmware. The only thing I have noticed is that the main router RT-AC86U, is now constantly running at 80C rather than its previous 70C,even with both CPU's at idle, around 2-3% at different stages. Should that be of any concern?

 

[scjr]

The only thing I have noticed is that the main router RT-AC86U, is now constantly running at 80C rather than its previous 70C,even with both CPU's at idle, around 2-3% at different stages. Should that be of any concern?

See RMerlin’s post here. Maybe this change extends to your model as well?

https://www.snbforums.com/threads/e...ssec-through-openssl.57489/page-6#post-503865

 

[vdemarco]

If you have 384.13a 1 or 2 and DNSSEC enabled in the gui then you are running OpenSSL validated DNSSEC. Just installed and up for 5 days does not compute either...

Sent from my SM-T380 using Tapatalk

sure whatever. i dont have dns over ssh, dns is using the openssl library to validate the certificates that i understand.

 

[Neil62]

See RMerlin’s post here. Maybe this change extends to your model as well?

https://www.snbforums.com/threads/e...ssec-through-openssl.57489/page-6#post-503865

Thanks for the link, but it is referring to AX models, not sure it applies to the AC86U. On the current Merlin stock firmware the router runs at a constant 70C , give or take a degree or two, with this alpha 2 firmware its running at an additional 10C. Not sure on the long term effects would be on the router if any at all...

 

[MNoisy]

Still unable to get my main ac88 to not have disconnect issues whenever the 5300 is set up as a node.

My suspicion was confirmed that not all settings are duplicated to the mesh node of the 5300. This was confirmed by running some external tests to see that some items like aggregation and jumbo frames are not enabled/disabled to match the main router on the mesh node of my 5300 when i changed them and tested.

I don't know if this is due to the 5300 being triband instead of dual like my main 88 but now I am also curious if any of merlins settings are duplicated to the mesh node since not even the stock Asus ones don't seem to be.

I want to do a quick test to see if the link aggregation on the 5300 not being enabled might be affecting the 88 since it is connected to another switch with 802.3ad and another vlan. Maybe this is causing enough errors, loopbacks or similar to cause the 88 to drop all connections?

Is there a way to enable/disable link aggregation via ssh? I could only find the old commands for it before it was officially supported by ASUS.

Thank you!!

 

[Treadler]

Alpha 2 running Quad9 DoT + DNSSEC just fine.

I haven’t seen any operational ‘glitches’ at all with this set up.
Happy!

 

[SheikhSheikha]

Thanks @Merlin for trying to make iMesh work. So far so good.
A few things that I noticed:
Both with or without my vpn client at random moments all devices do no longer get wan access. When I stop the VPN client in some cases WAN access comes back but often I have to power off and reboot the router to get it all up and running until it happens again. .... I have a feeling that the DNS is the problem causer ...
I do not see anything in my log files though .

RT-AX88U runs at 96 degrees celsius. At random internet access is blocked. Happens both with the VPN client on or off. Waiting until internet access came back did not give a solution. Only a reboot would solve it for some time until it happens again. The nodes are connected by cable backbone (cables are good). Changing DNS: no solution. No log file entries giving any information that reflects the practical experience.
Switched off DNS SEC: same problem occurs. DOT: same problem occurs.
My 5 cents: something between router and nodes causes a "hang up" of the router to provide internet access.
For now reverted back to 318.12 and my original configuration - no more interrupted internet access ...

 

[FTC]

RT-AX88U runs at 96 degrees celsius. At random internet access is blocked. Happens both with the VPN client on or off. Waiting until internet access came back did not give a solution. Only a reboot would solve it for some time until it happens again. The nodes are connected by cable backbone (cables are good). Changing DNS: no solution. No log file entries giving any information that reflects the practical experience.
Switched off DNS SEC: same problem occurs. DOT: same problem occurs.
My 5 cents: something between router and nodes causes a "hang up" of the router to provide internet access.
For now reverted back to 318.12 and my original configuration - no more interrupted internet access ...

Hi, 96C is maybe too much to maintain stability and could be the cause of malfunctions. The silicon itself will resist maybe 100C or so, but you are too close and this *may* be causing problems. 384.13 is based on asus firmware that disables power management cpuwait in some platforms, including some of the rt-ax88s, so these routers running 384.13 will see temps 8-10C higher than running 384.12,

I suggest that you find a cooler place to put your router, or test to manually reenable cpuwait instruction by running the command : "pwr config --cpuwait on" from a ssh session. Note that ASUS has disabled cpuwait probably for a reason so this could cause side effects in your case (I have been running my router with cpuwait in 384.13 for a week without problems already). Then see if the temp decreases and if your router is more stable..

 

[Neil62]

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.

 

[sdmf74]

This may mesh ok. You can also adjust the transmit power down to reduce WiFi overlap. Or try a AiMesh wireless backhaul and more distance between the nodes.

OE

Yes this is one of the reasons (besides gaining aimesh capabilities) that I upgraded. This RH13 doesn't allow to adjust transmit power so turning down the power on my main router only made things worse.

My other concern is that with asus stock firmware roaming assist on the "access point" doesn't allow going greater than -70dbm, can anyone confirm if the firmware or Merlin's firmware for the 68u will allow setting it to -65,-60 etc?

Btw for those of you that are experiencing high temps you do not need to mount one of those fans to the back of your router, you can simply buy one of these arctic breeze adjustable usb fans and set it behind the router!
My 86u went from around 73c to 41c 49c & 48c on both bands & cpu and this fan requires little power from usb, about .18A at half fan speed or less which is where I set mine at and .38A at full speed.

 

[SomeWhereOverTheRainBow]

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.

View attachment 18665

i don't think there is anything that can be done about this.

 

[SomeWhereOverTheRainBow]

Still unable to get my main ac88 to not have disconnect issues whenever the 5300 is set up as a node.

My suspicion was confirmed that not all settings are duplicated to the mesh node of the 5300. This was confirmed by running some external tests to see that some items like aggregation and jumbo frames are not enabled/disabled to match the main router on the mesh node of my 5300 when i changed them and tested.

I don't know if this is due to the 5300 being triband instead of dual like my main 88 but now I am also curious if any of merlins settings are duplicated to the mesh node since not even the stock Asus ones don't seem to be.

I want to do a quick test to see if the link aggregation on the 5300 not being enabled might be affecting the 88 since it is connected to another switch with 802.3ad and another vlan. Maybe this is causing enough errors, loopbacks or similar to cause the 88 to drop all connections?

Is there a way to enable/disable link aggregation via ssh? I could only find the old commands for it before it was officially supported by ASUS.

Thank you!!

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.

 

[rgnldo]

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.

 

[SheikhSheikha]

Hi, 96C is maybe too much to maintain stability and could be the cause of malfunctions. The silicon itself will resist maybe 100C or so, but you are too close and this *may* be causing problems. 384.13 is based on asus firmware that disables power management cpuwait in some platforms, including some of the rt-ax88s, so these routers running 384.13 will see temps 8-10C higher than running 384.12,

I suggest that you find a cooler place to put your router, or test to manually reenable cpuwait instruction by running the command : "pwr config --cpuwait on" from a ssh session. Note that ASUS has disabled cpuwait probably for a reason so this could cause side effects in your case (I have been running my router with cpuwait in 384.13 for a week without problems already). Then see if the temp decreases and if your router is more stable..

Thank you for the suggestions but I already went through the pwr config excercise with no real improvement. My premises are air conditioned so the ambient temperature is not an issue, nor is an airflow. (My AX88U in router config is currently running 384.12 at 68 celsius with a vpn client and no cpuwait on actived) so 96 degrees on my AX88U was a bit too much with the 384alpha2).

 

[JemTheWire]

I have a working and stable AiMesh system with an AX88U as the MASTER running Merlin 384.13 alpha2 connected via Ethernet back-haul to a AC88U as a NODE running Merlin 384.13 alpha2. This has been stable now for days so I thought it was time to play. I wanted to test the downgrade facility withing the alph2 build.

I removed the AiMesh node via the AiMesh status page of the MASTER by clicking the '-' icon.

I now flashed the AC88U NODE with stock ASUS FW (v384.45717). I did this through the MASTER on the usual Admin/Firmware Update page. I was very careful to select the NODE!

Flashing went though without a hitch. The AC88U came back up after a reboot. As I was going from Merlin to Stock, I did a push (reset) button reset on the AC88U.

After the AC88U came back up, I returned to the master and started a search for any new AiMesh routers. My AC88U was found OK.

I changed the priority from AUTO to ETHERNET. All my connected devices showed up.

So in essence the downgrade was straightforward and trouble free.

 

[OzarkEdge]

I have a working and stable AiMesh system with an AX88U as the MASTER running Merlin 384.13 alpha2 connected via Ethernet back-haul to a AC88U as a NODE running Merlin 384.13 alpha2. This has been stable now for days so I thought it was time to play. I wanted to test the downgrade facility withing the alph2 build.

I removed the AiMesh node via the AiMesh status page of the MASTER by clicking the '-' icon.

I now flashed the AC88U NODE with stock ASUS FW (v384.45717). I did this through the MASTER on the usual Admin/Firmware Update page. I was very careful to select the NODE!

Flashing went though without a hitch. The AC88U came back up after a reboot. As I was going from Merlin to Stock, I did a push (reset) button reset on the AC88U.

After the AC88U came back up, I returned to the master and started a search for any new AiMesh routers. My AC88U was found OK.

I changed the priority from AUTO to ETHERNET. All my connected devices showed up.

So in essence the downgrade was straightforward and trouble free.

You appear to write that you removed the AiMesh node and then flashed its firmware from within the AiMesh router webUI... during which you pushed the node reset button. I'm amazed this all worked out ok!

Useful note... according to an AiMesh FAQ, removing a node from AiMesh automatically resets that node. I've been accepting this as true to save a step.

OE

 

[JemTheWire]

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.