[Release] Asuswrt-Merlin 384.14 (and 384.13_2) are now available

[skeal]

I can confirm the described behaviour on my AC86U - as soon as I enable PMF bandwidth is gone. Therefore I wanted to disable the same on the AX88U too, but as said not working under 384.14 - maybe there is a smart cheat to get it manually disabled?

Yeah disable this first

Wi-Fi Agile Multiband

and then disable protected management frames.

 

[ech]

Any status update on that testing?

Neither of the tests worked... any newer GPL/binary blobs applied on top of 384.13, or reverted from 384.14 result in the internet status disconnected, even though it's working.

It looks like in release/src/router/rc/services.c, the start_wanduck function is bailing out because of the newly-added ate_factory_mode() check.

And I suspect the traffic stats spike is a result of a new patch applied to release/src/router/rstats/rstats.c that was part of "Merge with GPL 384_81044 (from GT-AC2900)" (commit 679c8b597610ca0ab0e4265dbefbd3a2d0526fd2 in the git log).

 

[RMerlin]

It looks like in release/src/router/rc/services.c, the start_wanduck function is bailing out because of the newly-added ate_factory_mode() check.

The connectivity issue is indeed tied to wanduck. However I am unable to reproduce the issue, so I don't know if it fails to start, or if it crashes at run time - all I know is that people with the issue reported that the wanduck process was not running.

And I suspect the traffic stats spike is a result of a new patch applied to release/src/router/rstats/rstats.c that was part of "Merge with GPL 384_81044 (from GT-AC2900)" (commit 679c8b597610ca0ab0e4265dbefbd3a2d0526fd2 in the git log).

Worth a check. In the past, similar issues were actually within the Ethernet driver (the /proc/net/dev packet counts were flat out wrong), but it's possible that in this case it might be a rstats-related regression.

 

[RMerlin]

It looks like in release/src/router/rc/services.c, the start_wanduck function is bailing out because of the newly-added ate_factory_mode() check.

Try these if you have one of these two models: https://www.snbforums.com/threads/internet-status-disconnected.59830/page-2#post-536417

 

[bobo27]

I have to AC5300 routers. The 384.14 has a significant lower signal then the 384.13.
Both routers on 384.14 demonstrate both a lower signal strength. So I exclude the environment as moving back to 384.13 brings the signal strength back alive.

So apparently 384.14 has an influence on the signal strength. What it is I have no clue (obviously).

Hi, I had the same problem after upgrading from 384.13 to 384.14 on my AC-86U. Weaker WiFi signal on both bands and lower throughput (150 instead of 250 mbit/s). Tried reboot, changed the TX settings but didn’t work.
I just changed the host name in the LAN settings and now all is well. Don’t know how this is connected but it’s worth a try.


Sent from my iPhone using Tapatalk

 

[ollimoe]

Yeah disable this first

Wi-Fi Agile Multiband

and then disable protected management frames.

Thanks Skeal - before doing so is this something you'd recommend? Where to enter the code - command line? Can it be reversed?

 

[skeal]

Thanks Skeal - before doing so is this something you'd recommend? Where to enter the code - command line? Can it be reversed?

Essentially you are dumbing down parts of the wifi 6 upgrades. Which is ok as some people are having trouble with all the changes and their different devices. This is the only way I know of to turn off protected management frames. What should be concluded first is if protected management frames is actually the sole issue.

 

[ollimoe]

@ skeal - thanks for your lightning fast response - if PMF is the or one issue needs to be figured. Therefore the intent to isolate. So your code has to be injected via SSH I assume?

 

[skeal]

@ skeal - thanks for your lightning fast response - if PMF is the or one issue needs to be figured. Therefore the intent to isolate. So your code has to be injected via SSH I assume?

No not SSH, it's under the wifi settings main pages of 2.4 and 5 bands. Look above the channel frequency bandwidth setting, on the two respective pages. It is this way on my AX88U.

 

[ollimoe]

No not SSH, it's under the wifi settings main pages of 2.4 and 5 bands. Look above the channel frequency bandwidth setting, on the two respective pages. It is this way on my AX88U.

You mean the setting "802.11ax / Wi-Fi 6 mode" ? It is set to disabled for me on 2.4 and 5 - nevertheless still can't disable PMF

 

[ech]

Worth a check. In the past, similar issues were actually within the Ethernet driver (the /proc/net/dev packet counts were flat out wrong), but it's possible that in this case it might be a rstats-related regression.

I built a 384.14 branch with the rstats update mentioned before reverted (the whole thing, as I didn't want to bother trying to pick through it for what specifically caused the bug) and the traffic monitoring false spikes are gone now (12+ hours and about 40GB of data transferred and no problems with data spikes).

 

[skeal]

You mean the setting "802.11ax / Wi-Fi 6 mode" ? It is set to disabled for me on 2.4 and 5 - nevertheless still can't disable PMF

Here is the location for my AX88U

 

[skeal]

Here is the location for my AX88UView attachment 20515

Leave WIFI 6 alone and just disable the Wi-Fi Agile Multiband setting. Then disable PMF.

 

[ollimoe]

Here is the location for my AX88UView attachment 20515

Thanks again skeal. Interestingly enough I do not have this selector box / button

Could this be tied to regional version of the SW? As my profile states I am in EMEA/Germany ...

 

[skeal]

Thanks again skea. Interestingly enough I do not have this selector box / button

View attachment 20516

Could this be tied to regional version of the SW? As my profile states I am in EMEA/Germany ...

Ahhh I see. I'm running the 384.15 alpha 1 newest version available, that may be the difference here.

 

[maxbraketorque]

384.14_0 has been working well for several days on three AC86Us and one AC68U. However there are a few small things I've noticed with the naming of the local network. I have three networks, two of which are at remote sites and connected to my home network via OVPN. The home network is an AC86U while one remote network is controlled by another AC86U and the other remote network is controlled by the AC68U. The names I selected for the networks controlled by the AC86Us (both the home network and one remote network) are showing up on my syslog server that is in my home network, but the local network name selected for the AC68U is not showing up in the syslog server. Instead, it shows up as RT-AC68U-... Presumably this is an issue with the ASUS source code, but figured I'd mention it anyhow.

Another related issue is that selected local network names are automatically being suffixed by a hex code -XXXX-XX. I guess there is now way to stop this suffix from being added and that its due to the ASUS source code?

 

[MDM]

Thanks again skeal. Interestingly enough I do not have this selector box / button

View attachment 20516

Could this be tied to regional version of the SW? As my profile states I am in EMEA/Germany ...

Maybe you first have to enable "802.11ax / Wi-Fi 6 mode" for the setting to appear?

 

[L&LD]

@MDM I was just going to suggest that too (along with a reboot of the router too).

 

[Mrk26]

Thanks again skeal. Interestingly enough I do not have this selector box / button

View attachment 20516

Could this be tied to regional version of the SW? As my profile states I am in EMEA/Germany ...

I didn't have this option as well in 384.14 and before you ask I tried to disable nearly everything and still wasn't able to save "disable" option for PMF. Simply must be bug in fw, of course for rt-ax88u.

 

[ollimoe]

@MDM I was just going to suggest that too (along with a reboot of the router too).

I did try this multiple times, incl. reboot, factory reset and re-config from scratch - the selection box does not appear for me under 384.14. I assume skeal is correct assuming this is tied to the 38.15 Aplpha? Or do you see this selection option under 384.14 too?