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

[Mrk26]

No, this section wasn't on mine either.

 

[agilani]

rt-ac88u here

Router and wifi are working...but both webui and ssh access not wokring. Not getting anything from webui. SSH login appears to work, but i don't get a shell.

 

[Hawk]

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.

If it is regarding Protected Management Frames, Asus has hard coaded this setting in firmware to be Capable from 384.14 and onwards, you can't choose disable, however you can choose required.

 

[RMerlin]

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).

Hopefully I picked all the relevant changes. I kept some of the others because they were bug fixes related to other areas.

 

[RMerlin]

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 ...

Probably because the WRT54GL did not support Wifi 6?

 

[ollimoe]

Probably because the WRT54GL did not support Wifi 6?

Uuups got me [emoji2956]

 

[Mrk26]

If it is regarding Protected Management Frames, Asus has hard coaded this setting in firmware to be Capable from 384.14 and onwards, you can't choose disable, however you can choose required.

Doesn't matter if it set to capable or enable, cause bandwidth issue for android mobile phones. Apparently is possible to turn this off on latest Asus fw for rt-ax88u, but I didn't tried, 384.13 is nice and stable so can't be asked at the moment. Maybe I will have a go after new year.

 

[Xentrk]

384.14 is the first release I have had issues with on my RT-AC88U. After the update to 384.14 from 384.13, I too see the Internet status: Disconnected message. I did check that wanduck is running.

In trying to debug, I changed the Tools -> Other Settings -> Wan: Use local caching DNS server as system resolver (default: No) from Yes to No. Internet reconnected and my VPN clients were able to establish connection. But LAN clients can't access websites. I can ping IP addresses but can't resolve domain names using the nslookup command. I also see a yellow triangle with an explanation mark on my WiFi indicator on my Win 10 laptop. When I troubleshoot network problems, I get a proxy error:

I experimented with DNS settings and was unable to resolve the problem. WAN connectivity is established early in the boot process as two of the VPN clients is able to establish connectivity. But later in the process, internet connectivity is lost and the other VPN clients get hung in trying to connect.

I then did a factory reset and established WAN connection after performing the basic setup. I enabled jffs and ssh and rebooted. I then copied over /jffs and nvram settings using the updated nvram-save/restore-utlity I am working on. I experienced the same issues.

I did another factory reset and reconfigured my settings manually. I tested WAN access as I made updates along the way, each time with success. I took a backup of this config. The last step I did was to restore jffs partition. After a restore of jffs partition followed by a reboot, I experienced the same issues described above. When I reformat the jffs partition and rebooted, internet connectivity is restored.

At one point in my troubleshooting, I got the Internet connection working and the yellow explanation mark to go away. But I still could not access websites. I did another troubleshooting on the WiFi and get a message about DNS not being available.

Everything works again once I revert to 384.13.

 

[dave14305]

384.14 is the first release I have had issues with on my RT-AC88U. After the update to 384.14 from 384.13, I too see the Internet status: Disconnected message. I did check that wanduck is running.

In trying to debug, I changed the Tools -> Other Settings -> Wan: Use local caching DNS server as system resolver (default: No) from Yes to No. Internet reconnected and my VPN clients were able to establish connection. But LAN clients can't access websites. I can ping IP addresses but can't resolve domain names using the nslookup command. I also see a yellow triangle with an explanation mark on my WiFi indicator on my Win 10 laptop. When I troubleshoot network problems, I get a proxy error:
View attachment 20527

I experimented with DNS settings and was unable to resolve the problem. WAN connectivity is established early in the boot process as two of the VPN clients is able to establish connectivity. But later in the process, internet connectivity is lost and the other VPN clients get hung in trying to connect.

I then did a factory reset and established WAN connection after performing the basic setup. I enabled jffs and ssh and rebooted. I then copied over /jffs and nvram settings using the updated nvram-save/restore-utlity I am working on. I experienced the same issues.

I did another factory reset and reconfigured my settings manually. I tested WAN access as I made updates along the way, each time with success. I took a backup of this config. The last step I did was to restore jffs partition. After a restore of jffs partition followed by a reboot, I experienced the same issues described above. Once I reformatted jffs partition and rebooted, I have internet connectivity.

At one point in my troubleshooting, I got the Internet connection working and the yellow explanation mark to go away. But I still could not access websites. I did another troubleshooting on the WiFi and get a message about DNS not being available.
View attachment 20530

Everything works again once I revert to 384.13.

Are you using Stubby? Stubby is wrongly compiled against OpenSSL 1.0.2 for the mainline branch. It may cause some issues if you’re expecting TLS 1.3.

 

[Andy1932]

I realize I'm not providing much helpful information here, but I've run into an issue 3x with 384.14.
After approx. 3 days of uptime on my 86u, web pages become unresponsive(won't load at all). I can log into the router and everything looks normal -- nothing at all in the log. The only thing I notice is the cpu core status dancing all over the place, but both cores always adding up to 100% total.
After a reboot, all is good again.

Mem: 413712K used, 26708K free, 24K shrd, 104K buff, 3588K cached
CPU: 4.9% usr 4.7% sys 0.0% nic 43.8% idle 46.0% io 0.0% irq 0.4% sirq
Load average: 4.16 3.61 3.07 1/148 15268
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
18198 1 nobody D 46352 10.5 0 4.7 dnsmasq --log-async
1235 2 admin DW 0 0.0 1 1.0 [usb-storage]
1041 1037 nobody S 3316 0.7 1 0.5 lldpd -L /usr/sbin/lldpcli -I eth1,eth2,eth3,eth4,eth5,eth6,wds0.*.*,wds1.*.*,wds2.*.* -s RT-AC86U
1005 1 admin S 8376 1.9 0 0.4 networkmap --bootwait
27 2 admin SWN 0 0.0 0 0.4 [kswapd0]
853 1 admin S 3368 0.7 0 0.2 /sbin/syslogd -m 0 -S -O /tmp/syslog.log -s 256 -l 5
14915 931 admin S 2476 0.5 1 0.2 dropbear -p 192.168.1.1:22 -j -k
12672 1 admin S < 14580 3.3 1 0.1 dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/
903 1 admin S 8704 1.9 1 0.1 /sbin/wanduck
917 1 admin S 5324 1.2 1 0.1 protect_srv
15254 14916 admin R 3372 0.7 1 0.1 top
1061 1 admin S 52620 11.9 1 0.0 amas_lib
1395 1 nobody S 50552 11.4 0 0.0 pixelserv-tls 192.168.1.2
285 1 admin S 18504 4.1 1 0.0 /bin/swmdk
1043 1 admin S 12880 2.9 0 0.0 cfg_server
2020 1 admin S 11560 2.6 1 0.0 /usr/sbin/smbd -D -s /etc/smb.conf
1001 977 admin S 11460 2.6 0 0.0 vis-dcon
2012 1 admin S 11392 2.5 1 0.0 /usr/sbin/nmbd -D -s /etc/smb.conf
916 1 admin S 11036 2.5 1 0.0 nt_monitor
918 1 admin S 10752 2.4 0 0.0 /sbin/netool
1008 1 admin S 10436 2.3 1 0.0 mastiff
975 1 admin S 10320 2.3 1 0.0 httpd -i br0
1 0 admin S 9692 2.2 1 0.0 /sbin/init
1931 1 admin S 9536 2.1 1 0.0 wred -B
974 1 admin S 9092 2.0 1 0.0 httpds -s -i br0 -p 8443
932 1 admin S 8952 2.0 0 0.0 nt_center
1011 1 admin S 8708 1.9 0 0.0 pctime
983 1 admin S 8704 1.9 0 0.0 watchdog
1255 1 admin S 8704 1.9 1 0.0 usbled
2085 1 admin S 8704 1.9 1 0.0 bwdpi_wred_alive
984 1 admin S 8704 1.9 1 0.0 check_watchdog
1009 1 admin S 8704 1.9 0 0.0 bwdpi_check
2108 1 admin S 8704 1.9 0 0.0 disk_monitor
788 1 admin S 8704 1.9 1 0.0 console
933 18199 admin S 8704 1.9 0 0.0 dhcpc_lease arp-del f0:6e:0b:ac:1e:f1 192.168.1.141
939 1 admin S 8704 1.9 1 0.0 wpsaide
1256 1 admin S 7544 1.7 1 0.0 u2ec
3996 1 admin S 6472 1.4 1 0.0 /etc/openvpn/vpnserver1 --cd /etc/openvpn/server1 --config config.ovpn
4000 3996 admin S 6468 1.4 1 0.0 /etc/openvpn/vpnserver1 --cd /etc/openvpn/server1 --config config.ovpn
977 1 admin S 5316 1.2 0 0.0 vis-dcon
18199 18198 admin S 4908 1.1 0 0.0 dnsmasq --log-async
979 1 admin S 4708 1.0 1 0.0 vis-datacollector
1026 1 admin S 4636 1.0 0 0.0 nt_actMail
954 1 admin S 4544 1.0 0 0.0 /usr/sbin/wlceventd
982 1 admin S 4388 0.9 0 0.0 sysstate
941 1 admin S 4180 0.9 0 0.0 /usr/sbin/wlc_nt
990 1 admin S 4176 0.9 0 0.0 rstats
1271 1 admin S 3724 0.8 1 0.0 /usr/sbin/ntp -t -S /sbin/ntpd_synced -p pool.ntp.org
940 1 admin S 3432 0.7 0 0.0 nas
14916 14915 admin S 3372 0.7 1 0.0 -sh
967 1 admin S 3368 0.7 0 0.0 crond -l 9
855 1 admin S 3368 0.7 0 0.0 /sbin/klogd -c 5

 

[dev_null]

Maybe restart the UI?
service restart_httpd

 

[RMerlin]

People having the Internet disconnected issue, please report whether you ever messed with your bootloader or not.

 

[SheikhSheikha]

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

I am in the meantime on 384.15Alpha1 wich demonstrates the same lower signal levels. Tried your suggestion to replace the LAN host name, rebooted and ..... indeed all signal levels bumped up to the levels I had with 381.13! Thanks!

 

[RMerlin]

Here are the rules for Protected Management Frames:

• If the Authenticatoin Method is WAP3-Personal, the Protected Management Frames will be Required.
• If the Authenticatoin Method is WPA2/WAP3-Personal, the Protected Management Frames will be Capable.
• If the Wi-Fi Agile Multiband is enabled, the Protected Management Frames will must be enabled.(Capable or Required)

So if you have incompatible devices, you will have to disable Agile Multiband support. This is most likely due to rules from the Wi-Fi Alliance regarding this feature.

 

[Andy1932]

Maybe restart the UI?
service restart_httpd

Thanks, but the UI loads fine during this. Also, internet status shows as connected.

 

[Xentrk]

People having the Internet disconnected issue, please report whether you ever messed with your bootloader or not.

I never have tinkered with bootloader + I don't know how to modify.

 

[Mrk26]

Here are the rules for Protected Management Frames:

• If the Authenticatoin Method is WAP3-Personal, the Protected Management Frames will be Required.
• If the Authenticatoin Method is WPA2/WAP3-Personal, the Protected Management Frames will be Capable.
• If the Wi-Fi Agile Multiband is enabled, the Protected Management Frames will must be enabled.(Capable or Required)

So if you have incompatible devices, you will have to disable Agile Multiband support. This is most likely due to rules from the Wi-Fi Alliance regarding this feature.

If this setting will be in next stable release I will do that way, but wasn't in 384.14, also when PMF enabled I observe ping jumps on my pc even with QOS on, and pc wasn't affected with bandwidth issue like mobile phones.

 

[Xentrk]

Are you using Stubby? Stubby is wrongly compiled against OpenSSL 1.0.2 for the mainline branch. It may cause some issues if you’re expecting TLS 1.3.

I am using the DoT feature built into the firmware on the WAN page. I think in one of my tests I disabled DoT to see if it had an impact on the issue.

 

[ollimoe]

Here are the rules for Protected Management Frames:

• If the Authenticatoin Method is WAP3-Personal, the Protected Management Frames will be Required.
• If the Authenticatoin Method is WPA2/WAP3-Personal, the Protected Management Frames will be Capable.
• If the Wi-Fi Agile Multiband is enabled, the Protected Management Frames will must be enabled.(Capable or Required)

So if you have incompatible devices, you will have to disable Agile Multiband support. This is most likely due to rules from the Wi-Fi Alliance regarding this feature.

Thanks Merlin - but this would be only relevant if I had the option to disable Agile Multiband in 384.14 - which does not exist for me and others. Therefore the only option seems to either downgrade to 384.13 or to upgrade to 384.15-Alpha ...

 

[XIII]

Does Dropbear in this version (384.14) support ed25519 keys?

(I know older versions did not)