Beta Asuswrt-Merlin 388.2 Beta is now available for Wifi 6 models

[RMerlin]

I am running with YazDHCP.

Something is causing your dnsmasq to crash (the watchdog will restart it). Remove that script to see if it's the cause.

During my time setting up & tweaking some ASUS AC-class routers, I've always seen only 2 dnsmasq processes running simultaneously

One has root privileges to handle binding to a privileged port (port 53), the other runs without privileges to handle the rest. Typical process separation to improve security, as not everything within dnsmasq needs to run with root privileges.

 

[aex.perez]

Well, I thought I had it figured out... After a HW reset of the router (AX88u) and the nodes (2x AX86s) and putting humpty dumpty (AX88) back to tgether again (with all the scripts), the problem reappeared. I got a little aggressive when putting it back together, and after a few runs and reboots stopped my testing. After loading it all up with the scripts & settings I was running before 388.2 beta (and getting ~+900Mbps in both directions) and still seeing similar CPU utilization metrics before/after (single digits average utilization). The problem reappeared (dropping to ~+450Mbps Up / +~650Mbps Down or worse and packet loss). Some script or combination of them (more likely) or the CPU utilization of a particular script or combination of them (more likely), or overall how CPU resources are used has changed in this release.

So now going back and adding one by one, ligher CPU/WAN use scripts to heaviest, one by one, and testing after a reboot and letting it settle. When it goes south going to try and play around to see if uninstalling it or another clears it up. I also need to revaluate what scripts or combination of them to run to maintan as close to constant results as I used to get, or run them all and adjust how I use/view Speedtest results to judge router/carrier performance and preferably without impact to Wired/WiFi performance/errors (dropped packets!).

So far so good with the results with just these running, Skynet, scMerlin, spdMerlin, YazDHCP and vnStat. Of the remaining ones, scribe is the most intense from my list, and with that I can fool around with the loglevels to see how much of an impact that is, if there is one.

 

[aex.perez]

Are all these posts really relevant to this thread?

Well, if CPU utilization is different under 388.2B vs every other 388.1 and 386, in that is results in packet errors or aothe anomalies like http timeout or unresponsive pages on the router, maybe...

 

[DJones]

Amtm and entware are are really only relevant to the firmware up to the point ssh functions. Packages causing issues with the routers performance or errors really should be left up to the package developers. And package developers really shouldn’t be working toward production updates for a beta firmware. Custom scripts are more or less up to you to debug unless it’s a kernel, driver module, or something prepackaged into the Merlin firmware.

Either way beta means their will be bugs.

 

[Kyjiep]

Hello all,

I have a RT-AX58U and since i installed the version 388.2 beta 1, the static values in arp table get deleted after i turn off the device in question.

I step up a static arp entry using the command's below, editing the services-start and rebooting the device, but a few moments after turning off the device the entry in the arp no longer shows [PERM] and it changes to something like "(xxx.xxx.xx.xxx) at [ether] on br0". The IP is there but there is no mac adress defined.

I also tried to run the command "arp -i br0 -s XXX.XXX.XX.XXX XX:XX:XX:XX:XX:XX" manually, the value shows the [PERM] indicating that its a static value, but a minute after i shutdown the device, the value changes again and shows the entry in arp without mac adress.
Already tried a factory reset, formating the JFFS partition and configuring all from scratch, but it still doesn't work.

Everything is the same as in previous working version 388.1.

Can someone please confirm this issue?

Script:
vi /jffs/scripts/services-start
#!/bin/sh
arp -i br0 -s XXX.XXX.XX.XXX XX:XX:XX:XX:XX:XX
chmod a+rx /jffs/scripts/services-start

Thanks all!

I also wrote about this on page 13. Apparently, few people use static entries in ARP, and no one here pays attention to this, except for us. This is a pretty serious bug.
Post in thread 'Asuswrt-Merlin 388.2 Beta is now available for Wifi 6 models' https://www.snbforums.com/threads/a...available-for-wifi-6-models.84139/post-830850

 

[oldgringo]

Your modem lost sync, or your ISP terminated the connection.


I'm not sure if this issue affects routers, since the fix is within AddBlockDNS(), and AFAIK DNS blocking only works on Win32.

I don't know but in the latest beta I cannot ping any OpenVPN client, in all previous versions I was able to do that. There is something different which I cannot see in the changelog. All clients are connected and functional, I can reach them via ssh but cannot ping any vpn instance. I had to go back to 388.1 where everything works just fine.

 

[Sundraw]

@RMerlin
Hi, I'm Italian, I'm a fan of your wonderful firmwares. Me and many other Italian users who have a 2.5\1 gigabit line with the gt ax 6000 router have an upload that goes below 300mb\s if the server latency exceeds 5ms. Today I found that with the latest asus beta firmware 9.0.0.6.102.4856, our upload always reaches the maximum speed. I've tried all the asus stable firmwares and all your firmwares but I always have the bottleneck on the upload. I ask you if you can understand what is in this latest beta firmware that unlocks the upload and if you can integrate it into your next firmware. For us Italian users it would be amazing to be able to continue using your wonderful firmware! Thank you.

 

[RMerlin]

@RMerlin
Hi, I'm Italian, I'm a fan of your wonderful firmwares. Me and many other Italian users who have a 2.5\1 gigabit line with the gt ax 6000 router have an upload that goes below 300mb\s if the server latency exceeds 5ms. Today I found that with the latest asus beta firmware 9.0.0.6.102.4856, our upload always reaches the maximum speed. I've tried all the asus stable firmwares and all your firmwares but I always have the bottleneck on the upload. I ask you if you can understand what is in this latest beta firmware that unlocks the upload and if you can integrate it into your next firmware. For us Italian users it would be amazing to be able to continue using your wonderful firmware! Thank you.

Check your settings, there are various users reaching higher than 1 Gbps with Asuwrt-Merlin without problem. My first guess is you are enabling something that disables NAT acceleration, which would cap the speed to around 400 Mbps.

 

[Sundraw]

Check your settings, there are various users reaching higher than 1 Gbps with Asuwrt-Merlin without problem. My first guess is you are enabling something that disables NAT acceleration, which would cap the speed to around 400 Mbps.

First of all thanks for your reply. We don't actually change any default settings, except the vlan id that is used to connect. I don't use Vpn, scripts of any kind and not even qos (which I've tried but it doesn't solve anything). I don't even use aiprotection or other features. It seems that the new beta firmware has something different for us Italian users. We were talking about it today on a well-known Italian forum where we all understood that the only solution seems to be this beta firmware. Can you please investigate? I don't like having a router without your firmware

 

[RMerlin]

Can you please investigate?

Nothing more I can do about that, sorry. This is an ISP-specific issue (if it really is an issue), therefore impossible for me to investigate.

 

[MilkyOneWay]

I also wrote about this on page 13. Apparently, few people use static entries in ARP, and no one here pays attention to this, except for us. This is a pretty serious bug.
Post in thread 'Asuswrt-Merlin 388.2 Beta is now available for Wifi 6 models' https://www.snbforums.com/threads/a...available-for-wifi-6-models.84139/post-830850

Thank you for your reply, lets hope that the problem doesn't occur on the final build.....
Otherwise i will have to use another method to use WOL from an external source like a vpn, but i was really trying to avoid that....

 

[DJones]

@RMerlin
Hi, I'm Italian, I'm a fan of your wonderful firmwares. Me and many other Italian users who have a 2.5\1 gigabit line with the gt ax 6000 router have an upload that goes below 300mb\s if the server latency exceeds 5ms. Today I found that with the latest asus beta firmware 9.0.0.6.102.4856, our upload always reaches the maximum speed. I've tried all the asus stable firmwares and all your firmwares but I always have the bottleneck on the upload. I ask you if you can understand what is in this latest beta firmware that unlocks the upload and if you can integrate it into your next firmware. For us Italian users it would be amazing to be able to continue using your wonderful firmware! Thank you.

I would suggest contacting your isp and see if they can check the line quality. Depending on the line type I assume fibre the drop in speed could be on their end.

I would also investigate if you’re experiencing bufferbloat which might effect your latency.

Bufferbloat and Internet Speed Test - Waveform

Is bufferbloat causing issues with your internet connection? Run this test to find out.

www.waveform.com

Well QoS like cake might help might reduce bufferbloat jitter and latency it comes at the cost of the loss of NAT acceleration. Using cake you might be able to improve your line stability however the flip side might mean a loss of some overall speed at the top end, but it might equalize upload and download if latency remains under 5ms.

Because you have a Asymmetrical line (d2.5/1u) instead of Symmetrical line (d2.5/2.5u) it could be that use of your download well your using upload could cripple one or the other when exceeding a equal symmetrical speed. But I’m not sure if that’s the case.

 

[tetar]

When 160 is enabled my wifi connections become slugish and I have slow responses. When turned off, everyrhing is speedy fast and stable

My proposition. Install firmware 386.5_2. and check stability and speed on 160MHz settings. I use fw 386.5_2. works great, fast and stable! Newer fw versions don't work properly with my Samsung S22Ultra.

My configuration: RT-AX86u <---backhaul 2.5GB--> RT-AX86u / 5Ghz + 160Mhz / ISP 1Gbps/300Mbps / WiFi 6 transfer (S22Ultra) 940Mbps/310Mbps

 

[MilkyOneWay]

I also wrote about this on page 13. Apparently, few people use static entries in ARP, and no one here pays attention to this, except for us. This is a pretty serious bug.
Post in thread 'Asuswrt-Merlin 388.2 Beta is now available for Wifi 6 models' https://www.snbforums.com/threads/a...available-for-wifi-6-models.84139/post-830850

I think i figured it out, in the process of updates to the firmware and reseting the router i think i forgot to disable the option Spanning-Tree Protocol, still not sure if its completly solved, but i made a quick test and it looks that with this disable the static entry stays configured.

Feel free to try.

 

[Martinski]

...
Some additional observations:
I only see one PID reporting the Fatal Signal
I usually get a few fatals, often spaced about by around 20 seconds (+/- 5 secs)
This might be interesting - in every case, the signal occurs right after the .hostnames file is read by YazDHCP. There are 77 host names.

Yeah, that's interesting. The YazDHCP event and the fatal signal crashes appear to have a temporal correlation, but without further data points, we can't yet say that there's causation. As @RMerlin suggested, you could try uninstalling YazDHCP temporarily to see if that has any effect on your situation. If the crashes continue to happen, at least you would have eliminated YazDHCP as the main culprit or a possible contributing factor.

 

[Martinski]

One has root privileges to handle binding to a privileged port (port 53), the other runs without privileges to handle the rest. Typical process separation to improve security, as not everything within dnsmasq needs to run with root privileges.

Yes, that's exactly what I've seen every time in ASUS routers: one "dnsmasq" process running with user ID "anybody" (non-root), and the other one running with user ID "*Admin*" which has root privileges. That's why seeing 6 "dnsmasq" processes running simultaneously, as @JGrana mentioned in his post, is surely a sign of some kind of trouble brewing under the surface.

P.S.
User ID "*Admin*" is just a placeholder for whatever custom string the router's WebGUI login user might have been set to (if not using the default "admin").

 

[kernol]

I believe sticking 160MHz wide channel in Asuswrt 386_46061 (and Asuswrt-Merlin 386.5_2) firmware for RT-AX86U (and other models) was actually a bug fixed in later firmware releases in order to better follow DFS channels use requirements. This change affects not only Asus routers, but anything else on the market using the same hardware and Broadcom drivers for it. This is not coming from Asus at all and totally unrelated to Asuswrt-Merlin.

Understood - but no matter what Merlinware version is released - its foundation is Asuswrt - so changes in the perceived behaviour of ones router under a beta or any released version of Merlinware will result in comments from the user base ... whether those changes are brought about directly by what @RMerlin does - or the underlying code it is based on. The distinction between the two matters little to an average "Joe" like me ... and clearly a LOT to the technical boffs like @RMerlin and yourself.

We remain indebted to your skills and fully enjoy the fruits of your labors and testing.

 

[Tech9]

What I can say so far - 388.2 beta is consistent with what I'm getting from 388_22525. With 388.1 there were differences between GPL used and Asuswrt releases. On my router with my test clients 388.1 didn't perform well. I test with some quirky clients in purpose. In my opinion and if possible RMerlin has to slow down a bit and work on stable GPL only released as official Asuswrt firmware. We test what Asus released first and go from there. If the base has an issue (like 386_49447) - we'll know. There is no point releasing Asuswrt-Merlin on top of this one. The one in my example created complaints (386.7) and drivers downgrade for some models (386.7_2) later. I was thinking my router is defective.

The community is updates hungry and applies too much pressure for no reason. When the things don't go well because of some beta stage GPL provided - RMerlin takes the hit. I see no issues in Asuswrt-Merlin release few weeks after official Asuswrt release. This time around 388.2 following good Asuswrt is the better way. Instead of telling folks with issues "use Asuswrt, it's newer" I can easily recommend "wait for the Asuswrt-Merlin release". Right now, based on what I see here and if Asuswrt-Merlin is needed - "load 388.2 beta, better than 388.1 and stable enough". RMerlin is under impression I steer people away from Asuswrt-Merlin. No, I personally like it and want it better. Also, more available options is not necessarily better for everyone. As usual my recommendations are not global, but per case depending on who's asking and what the needs are.

 

[Ripshod]

The community is updates hungry and applies too much pressure for no reason. When the things don't go well because of some beta stage GPL provided - RMerlin takes the hit. I see no issues in Asuswrt-Merlin release few weeks after official Asuswrt release. This time around 388.2 following good Asuswrt is the better way. Instead of telling folks with issues "use Asuswrt, it's newer" I can easily recommend "wait for the Asuswrt-Merlin release". Right now, based on what I see here and if Asuswrt-Merlin is needed - "load 388.2 beta, better than 388.1 and stable enough". RMerlin is under impression I steer people away from Asuswrt-Merlin. No, I personally like it and want it better. Also, more available options is not necessarily better for everyone. As usual my recommendations are not global, but per case depending on who's asking and what the needs are.

100%

 

[Damit1]

10 days for Beta and no issues observered here, hence, the most stable beta in months...
I believe the latest GPL has improved WIFI stabillity, maybe just an illustion, anyway- Im good with that

36/160MHZ dropped to 44/80Mhz when DFS was idle (just noticed today- it caused some IOT devices to connect-disconnect untill they just disoconnect) , had to change to Auto/160Mhz, which picked 44/160, manually changed to 44/160 which dropped back to 36/160 so I manually changed it to 36/160 again (like in the beginning), like a set- and re-set kind of thing, and for a few hours it looks fine,
Will keep looking in the next 48h when flights are back to operate, as there is a flight-route over my head- 6 days a week.