Release Asuswrt-Merlin 386.4 is now available

[dave14305]

This is what I get with nslookup on the ssh connection:

Server:    100.64.0.1
Address 1: 100.64.0.1
Name:      dns.msftncsi.com
Address 1: 131.107.255.255 dns.msftncsi.com
Address 2: fd3e:4f5a:5b81::1

It seems to be correct.

Try setting this debug flag and watching the system log for a while. You’re looking for messages like WAN Connection DNS probe succeeded/failed

nvram set dns_probe_debug=1

When you want to revert it, just run

nvram unset dns_probe_debug

 

[lukester01]

I really, really hope that network isn’t called “IOT”…!!

I would also suggest changing your channel width to 20 rather than 20/40 and changing the channel to 1, 6 or 11 rather than 3.

Thanks for the ups. I'll try those settings.

 

[WillyTP]

Hi
I've done a fresh install of latest 386.4 on AC86U (main router), with two AC68U as AiMesh nodes.

After this update, Guest Network 1 (the one I use to distribute a guest network all around the nodes) doesn't work anymore.
Clients doesn't get IP.

Is anybody else experiencing this? Any fix?
I've already done a hard reset of everything.

Best regards

 

[Khadanja]

These appear every 30 mins. What does it mean?

an 11 04:21:03 RT-AC68U-20E0 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jan 11 04:51:03 RT-AC68U-20E0 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jan 11 05:21:04 RT-AC68U-20E0 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jan 11 05:51:04 RT-AC68U-20E0 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jan 11 06:21:04 RT-AC68U-20E0 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jan 11 06:51:04 RT-AC68U-20E0 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jan 11 07:21:04 RT-AC68U-20E0 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jan 11 07:51:05 RT-AC68U-20E0 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
Jan 11 08:21:05 RT-AC68U-20E0 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2

 

[arewhy]

Two issues with 386.4. One is a continued issue from 386.3_2. My asus zenbook has no internet when connected to 2.4ghz. Only has internet on 5ghz. That is the continued problem from old firmware. The new issue is with NEST camera losing connection constantly on the 5Ghz. But also there is an issue with old 2.4ghz printer not working on 386.4. Reverting the 386.3_2 solved the problem with the printer. Windows said printer offline for printer with new firmware. Printer came back online (though it was connected via wifi) when I went back to the old firmware. So there is some issue with old 2.4 devices and the new firmware.

I had the same issue with my HP Envy 7645 which is connected to the 2.4ghz network. Windows said printer was offline. I could ping it from the router but could not ping it from my Windows clients. I was able to resolve by turning off IPV6 on the printer for both the WIFI and LAN. May not be applicable to you depending on whether you have IPV6 enabled on your router or not.

 

[RMerlin]

request to hide the PPTP password with "*****" if possible

My counter-request is for you to stop using PPTP. We're in 2022.

 

[RMerlin]

For some reason the file for the RT-AC68U on SorceForge.net when unzipped has the .trx labeled as "RT-AC86U_386.4_0_cferom_ubi.w" but the one from OneDrive is the correct "RT-AC68U_386.4_0.trx" in the zip file. Not sure if I am the only seeing this issue but maybe someone else can confirm it for me?

Look again, you are posting firmwares from two different device models.

 

[banger]

Using the 386.4 on main router and stock 45987 on mesh node as disconnects on node are a lot more abundant than with the stock on node. Both routers are AC68U

Seeing this in the log every 7 days

Jan 10 18:44:21 syslog: wlceventd_proc_event(491): eth1: Deauth_ind 60:45:CB:**, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-46
Jan 10 18:44:23 syslog: wlceventd_proc_event(527): eth1: Auth 60:45:CB:**, status: Successful (0), rssi:0
Jan 10 18:44:23 syslog: wlceventd_proc_event(556): eth1: Assoc 60:45:CB:**, status: Successful (0), rssi:0

60:45:CB:** is the mesh node but it also disconnects the 5ghz connection when eth1 the 2.4ghz disconnects. Not major but any ideas?

 

[Thalch]

If that was true then it would have been a bug in 386.2. Devices on the LAN are not supposed to be able to communicate with devices on an isolated guest network, and vice versa. YazFi was created in part to offer this ability.

Thanks for the hint, I did not know YazFi but with this extension I was able to manage my requirement.

 

[Sonyrolfy]

Unfortunately this does not work for me; less than 2 hours after adding this to my script the device got offline again and now I even had to manually reconnect on the device itself to get it online again.


Unfortunately this does not work for me; less than 2 hours after changing it, well: see above...

Thats a pitty, offcourse country, device or IOT's specific are different for each of us, the settings i adjusted helped me for now, but then again it can change over time. 2 extra settings i adjusted are DTM interval to 5 and becon interval to 150. Again its just a lucky shot to to have and to hold from this day forward, for better for worse,, etc etc

 

[GHammer]

I really, really hope that network isn’t called “IOT”…!!

I would also suggest changing your channel width to 20 rather than 20/40 and changing the channel to 1, 6 or 11 rather than 3.

Yeah, well. I think I'll do what works for me.
IoT is a perfect SSID. Why not?

 

[Krism]

My AX86 is running with the new update. Even guest wifi #1 (with access intranet disabled) is running fine and broadcasted to the other mesh nodes.

I can see the lease time is the default (24h), is there a way to change it for the dhcp range specific for the guest network?

 

[ColinTaylor]

I can see the lease time is the default (24h), is there a way to change it for the dhcp range specific for the guest network?

You'd have to do it with a dnsmasq.postconf user script.

 

[Krism]

You'd have to do it with a dnsmasq.postconf user script.

Okay, but what is the exact command to do it? Dnsmasq has no dhcp-option to do it with

 

[Unisoft]

FYI. In todays firmware release from Asus for AX86U v3.0.0.4.386.46061 they have fixed a bunch of security related stuff and the IPv6 DDNS issue. Merlin may already be at work behind the scenes lol

 

[ColinTaylor]

My AX86 is running with the new update. Even guest wifi #1 (with access intranet disabled) is running fine and broadcasted to the other mesh nodes.

I can see the lease time is the default (24h), is there a way to change it for the dhcp range specific for the guest network?

Okay, but what is the exact command to do it? Dnsmasq has no dhcp-option to do it with

Only guest WiFi's #1 have their own DHCP range so they're the only one's you could change.

For example, to change the lease duration on 2.4GHz guest #1 to 60 minutes:

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh

sed -i "s/dhcp-range=br1.*/dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,60m/" "$CONFIG"

Check the contents of your router's dnsmasq.conf file beforehand to make sure it looks the same as mine.

 

[Jeffrey Young]

Okay, but what is the exact command to do it? Dnsmasq has no dhcp-option to do it with

The dnsmasq manual is here; https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

You will need to look for a entry such as dhcp-range=wl0.1,192.168.2.100,192.168.2.200,255.255.255.0,86400s and modify the last parameter (86400s).

EDIT: @ColinTaylor beat me to it I like his description better....

 

[PR3MIUM]

My counter-request is for you to stop using PPTP. We're in 2022.

just a quick shoot, so next gen. its removed

 

[plar036]

I bought a new ax56u and installed RT-AX56U_386.4_0 on it right after unboxing, but it started to crash randomly.
I don't use any extensions or scripts at the moment just "stock" merlin firmware.

I found another post with similar issue:
RT-AX56U crash using 386.4 alpha1 | SmallNetBuilder Forums (snbforums.com)

In the log files I can see nothing interesting.

First crash:
Jan 11 16:02:54 dnsmasq-dhcp[3768]: DHCPDISCOVER(br1) MAC
Jan 11 16:02:54 dnsmasq-dhcp[3768]: DHCPOFFER(br1) 192.168.101.61 MAC
Jan 11 16:02:54 dnsmasq-dhcp[3768]: DHCPREQUEST(br1) 192.168.101.61 MAC
Jan 11 16:02:54 dnsmasq-dhcp[3768]: DHCPACK(br1) 192.168.101.61 MAC
Jan 11 16:02:57 wlceventd: wlceventd_proc_event(486): wl0.1: Disassoc MAC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 11 16:02:57 wlceventd: wlceventd_proc_event(486): wl0.1: Disassoc MAC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 11 16:02:57 hostapd: wl0.1: STA MAC IEEE 802.11: disassociated
Jan 11 16:02:57 hostapd: wl0.1: STA MAC IEEE 802.11: disassociated
Jan 11 16:03:03 wlceventd: wlceventd_proc_event(505): wl0.1: Auth MAC, status: Successful (0)
Jan 11 16:03:03 hostapd: wl0.1: STA MAC IEEE 802.11: associated
Jan 11 16:03:03 wlceventd: wlceventd_proc_event(534): wl0.1: Assoc MAC, status: Successful (0)
Jan 11 16:03:03 hostapd: wl0.1: STA MAC RADIUS: starting accounting session ED855AF2D069FD44
Jan 11 16:03:03 hostapd: wl0.1: STA MAC WPA: pairwise key handshake completed (RSN)
May 5 07:05:02 syslogd started: BusyBox v1.25.1
May 5 07:05:02 kernel: klogd started: BusyBox v1.25.1 (2022-01-01 13:42:20 EST)
May 5 07:05:02 kernel: Booting Linux on physical CPU 0x0
May 5 07:05:02 kernel: Linux version 4.1.52 (merlin@ubuntu-dev) (gcc version 5.5.0 (Buildroot 2017.11.1) ) #1 SMP PREEMPT Sat Jan 1 13:48:33 EST 2022
May 5 07:05:02 kernel: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
May 5 07:05:02 kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
May 5 07:05:02 kernel: Machine model: Broadcom BCM947622

Second crash:
Jan 11 19:42:37 dnsmasq-dhcp[2590]: DHCPREQUEST(br0) 192.168.0.126 MAC
Jan 11 19:42:37 dnsmasq-dhcp[2590]: DHCPACK(br0) 192.168.0.126 MAC XXXXXXXX
Jan 11 19:42:45 kernel: br1: port 2(eth4.501) entered learning state
Jan 11 19:43:00 kernel: br1: topology change detected, propagating
Jan 11 19:43:00 kernel: br1: port 2(eth4.501) entered forwarding state
May 5 07:05:01 syslogd started: BusyBox v1.25.1
May 5 07:05:01 kernel: klogd started: BusyBox v1.25.1 (2022-01-01 13:42:20 EST)
May 5 07:05:01 kernel: Booting Linux on physical CPU 0x0
May 5 07:05:01 kernel: Linux version 4.1.52 (merlin@ubuntu-dev) (gc

Now I downgraded to an older version to see if it is a HW issue or not.

Did any one experienced the same?

 

[Gary_Dexter]

Yeah, well. I think I'll do what works for me.
IoT is a perfect SSID. Why not?

Because it’s an advertisement of what devices are using that Wi-Fi.