Release Asuswrt-Merlin 386.7 is now available for all models

[ColinTaylor]

I've had the messages occasionally, when moving upstairs for example, sure, but never this hectic bouncing activity and noticeable disconnects. If I take the example of my TV: it has these loops of butt/disass/reass/with/deauth messages every 12 to 20 seconds over the course of hours. Starting seemingly random somewhere in the afternoon. Racking up hundreds of lines in the log and real connect/disconnect loops That can't be normal right? And just to add for your info: I'm not lugging my TV up and down the stairs every 12 to 20 seconds ;-)

They're not debug messages, they're just normal messages. This sort of repetitive behaviour is almost always a client issue. Sometimes it's caused by the device being in standby mode. Sometimes it's just a crappy device.

In your case it looks like the TV can't decide whether it's better to connect to the 2.4GHz AP or the 5GHz AP and is bouncing between the two. Perhaps because it has a marginal signal. I suggest you create different SSID's for each band and only allow the TV to connect to one of them. Alternatively you could create a guest wireless network for the TV to connect to.

 

[eibgrad]

I've had the messages occasionally, when moving upstairs for example, sure, but never this hectic bouncing activity and noticeable disconnects. If I take the example of my TV: it has these loops of butt/disass/reass/with/deauth messages every 12 to 20 seconds over the course of hours. Starting seemingly random somewhere in the afternoon. Racking up hundreds of lines in the log and real connect/disconnect loops That can't be normal right? And just to add for your info: I'm not lugging my TV up and down the stairs every 12 to 20 seconds ;-)

In my experience w/ wifi-enabled TVs, the wifi always seems particularly crappy. Just seems to come w/ the territory. It makes Chromecast-enabled TVs problematic as well. It's why I *only* use a wired connection for such devices, even if that means powerline adapters. I've found powerline to be ideal for such devices. They don't have to be great, just good enough to support the relatively low bandwidth requirements. Far more reliable and consistent in my experience than wireless.

Even MoCA would be better (if considerably more expensive than powerline).

Just too much dependence on wireless if you ask me, esp. for stationary devices.

P.S. Worst case? Get yourself a standalone wireless ethernet bridge and dump the built-in wireless.

 

[thecheapseats]

They're not debug messages, they're just normal messages. This sort of repetitive behaviour is almost always a client issue. Sometimes it's caused by the device being in standby mode. Sometimes it's just a crappy device.

In your case it looks like the TV can't decide whether it's better to connect to the 2.4GHz AP or the 5GHz AP and is bouncing between the two. Perhaps because it has a marginal signal. I suggest you create different SSID's for each band and only allow the TV to connect to one of them. Alternatively you could create a guest wireless network for the TV to connect to.

In my experience w/ wifi-enabled TVs, the wifi always seems particularly crappy. Just seems to come w/ the territory. It makes Chromecast-enabled TVs problematic as well. It's why I *only* use a wired connection for such devices, even if that means powerline adapters. I've found powerline to be ideal for such devices. They don't have to be great, just good enough to support the relatively low bandwidth requirements. Far more reliable and consistent in my experience than wireless.

Even MoCA would be better (if considerably more expensive than powerline).

Just too much dependence on wireless if you ask me, esp. for stationary devices.

P.S. Worst case? Get yourself a standalone wireless ethernet bridge and dump the built-in wireless.

both important tips and comments- as TVs, Bluray/4k players and Chromecasts - all notorious chatter boxes - are best disciplined with wired connections as well as network segregation if possible- certainly stops some of the nonsense... I enjoy the features they provide but hate ((in most cases) their wireless network behavior and promiscuous phoning home...

 

[underdose]

In my case, it is my PlayStation4 in stand-by mode that disassociates - associates the 2.4 GHz interface frequently at random intervals.

Aug  4 15:09:49 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:11:27 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:11:27 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:11:29 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:11:29 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 154F9199A1D1D472
Aug  4 15:11:29 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:13:07 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:13:07 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:13:10 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:13:10 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 9EA2FC8396444551
Aug  4 15:13:10 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:14:47 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:14:47 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:14:50 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:14:50 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 3252057F264D4957
Aug  4 15:14:50 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:18:08 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:18:08 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:18:11 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:18:11 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 5F75322667AA0632
Aug  4 15:18:11 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:19:49 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:19:49 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:19:51 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:19:51 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 2492FD9B9B19A740
Aug  4 15:19:51 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)

 

[5stringdeath]

In my case, it is my PlayStation4 in stand-by mode that disassociates - associates the 2.4 GHz interface frequently at random intervals.

Aug  4 15:09:49 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:11:27 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:11:27 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:11:29 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:11:29 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 154F9199A1D1D472
Aug  4 15:11:29 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:13:07 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:13:07 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:13:10 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:13:10 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 9EA2FC8396444551
Aug  4 15:13:10 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:14:47 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:14:47 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:14:50 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:14:50 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 3252057F264D4957
Aug  4 15:14:50 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:18:08 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:18:08 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:18:11 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:18:11 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 5F75322667AA0632
Aug  4 15:18:11 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)
Aug  4 15:19:49 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:19:49 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: disassociated
Aug  4 15:19:51 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address IEEE 802.11: associated
Aug  4 15:19:51 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address RADIUS: starting accounting session 2492FD9B9B19A740
Aug  4 15:19:51 RT-AX58U hostapd: eth5: STA ps:4:client:mac:address WPA: pairwise key handshake completed (RSN)

But that's totally normal for a device that has a low power standby state. Keeping a radio active consumes electricity

 

[Morris]

But that's totally normal for a device that has a low power standby state. Keeping a radio active consumes electricity

Yep, and those messages consume log huggers emotions

 

[L&LD]

I would not be pursuing this firmware version any longer. 386.7_2 has been released in the meantime.

 

[banger]

I am not sure who looks after this bit of the firmware but few releases ago it worked now populated with zeros. Network rate for node.

 

[SomeWhereOverTheRainBow]

Yep, and those messages consume log huggers emotions

I agree, seems like a party of handshakes, associations, and disassociations. A.K.A. mesh parlor tricks.

 

[Lee MacMillan]

Updated to 386.7_2 today after 33 days on 386.7. Forgot to unmount my USB drive but it updated successfully with no apparent issues.

 

[jorhett]

seems like a party of handshakes, associations, and disassociations. A.K.A. mesh parlor tricks.

Speaking as a professional network engineer, that's the most succint yet accurate description of 802.11 I've ever seen

 

[RMerlin]

Heads up, this thread is going to be locked down soon.

 

[lepa71]

Is there a reason I get "hostapd: wl0.1: STA 84:72:07:71:f3:cd RADIUS: starting accounting session 1B2FA986CBDA6AA1"?
I'm not using RADIUS.

 

[ColinTaylor]

Is there a reason I get "hostapd: wl0.1: STA 84:72:07:71:f3:cd RADIUS: starting accounting session 1B2FA986CBDA6AA1"?
I'm not using RADIUS.

They're just normal messages. You don't need to be using a RADIUS server.

 

[dsring]

I posted about this issue once before...I noticed that I could not manually select a 5GHz control channel below 100. I did perform a hard factory reset of the router and both of my AI mesh nodes. After the reset, I was able to select any 5GHz channel. I then added the two XT8 AI mesh nodes to my system and now it is back to not being able select a 5GHz control channel below 100. It looks like the nodes are using Channel 36 as the 5GHz backhaul channel. My theory is that the newer Asus firmware will not allow you to select a channel that is being used as a wireless backhaul channel?? Maybe I am wrong.

 

[jorhett]

I noticed that I could not manually select a 5GHz control channel below 100

There isn't 160Mhz below 100. Unselect the checkbox and you'll see all the choices.

Do you really need that much bandwidth?

 

[visortgw]

There isn't 160Mhz below 100. Unselect the checkbox and you'll see all the choices.

Do you really need that much bandwidth?

That's not true, at least not in the USA. Channel 36 is the optimal 160 MHz channel.

The bandwidth makes a huge difference for wifi AiMesh connections -- I routinely see about a 3 Gbps bidirectional physical connection between GT-AX6000 primary router and RT-AX82U mesh node.

 

[gbernard]

Just as an aside, had a few strange inconsistencies since 386.5_2, on my RT-AX88U, did a default settings, reboot, etc then again after 15 mins etc entered in settings everytime, no real improvement.
I did the hard reset holding down the WPS, until power off, re-entered all settings, rebooted after 15 mins, and it has been rock steady and all previous strange little things have not happened for over a week now. Highly recommend the hard reset process.

 

[mister]

Dear all,
I've also recently noticed some odd behavior from my RT-AC86U and maybe someone else has noticed this as well or has a solution.

My DCHP network has the configuration 192.168.111.0/24 and there are 2 openvpn servers and openvpn 1, 4 and 5 active, each configured via the policies (VPN Director).

This also normally works without any problems. Now I recently had an internet outage and all connections were lost. At first I thought it was the VPN and I wanted to log in to my RT 86U with the IP using my cell phone via WLAN. But that didn't work. The IP address of my router was not found even though it was connected to the WIFI.

Under Status of Cell Phone I found that it was assigned a 10.XX.XX.XX IP address.

I was able to properly log into the router via LAN on the computer. A correct IP from the 192.168.111.0 range was assigned to the mobile phone according to the WebUI of the 86U.


I don't work with 10.XX.XX.XX. networks, only the OpenVPN clients have such a network when they are connected. But I find it strange why I suddenly have such an IP locally on my cell phone and can no longer access the router. Rebooting the RT-AC didn't help. By the way, it doesn't just affect a cell phone, but apparently all devices that are connected via WIFI.
LAN devices display the correct IP and can access the router's WEBUI.
Has anyone observed anything similar?

 

[RMerlin]

Locking this, as the release feedback has died down.

Remember, if you have a general issue, you should not be using these released thread to obtain support, but start a separate thread instead.