ASUS RT-AC86U firmware release 3.0.0.4.384.45149 12/05/2018

[Lotta Cox]

These Assoc Disassoc messages started appearing in the Merlin 384.9_alpha1-g67f9006e5 on my 86U.
There are e thousands of these entries. Roaming assistant is off. I have a lot of WiFi outlets and switches.
I saw these entries when I tried this Asus official FW. Went back to Merlin 384.8_2 and they were gone.
It seems to got into Merlin FW in the alpha.

 

[128bit]

I had that same, until I removed the
roaming assistant
Test it.

tell me more, k. i have the 86u and am unaware of this feature. aimesh is not used with my simple home config so yes, u've got my attention.

 

[128bit]

These Assoc Disassoc messages started appearing in the Merlin 384.9_alpha1-g67f9006e5 on my 86U.
There are e thousands of these entries. Roaming assistant is off. I have a lot of WiFi outlets and switches.
I saw these entries when I tried this Asus official FW. Went back to Merlin 384.8_3 and they were gone.
It seems to got into Merlin FW in the alpha.

your feedback is much appreciated. cause these asso/disasso logs are brand new for me since the last fw update. i've had the device for over a year.

. . . again, much appreciated.

 

[kew]

tell me more, k. i have the 86u and am unaware of this feature. aimesh is not used with my simple home config so yes, u've got my attention.

I do not use Aimesh.
You find it wireless-professional

 

[maxbraketorque]

These Assoc Disassoc messages started appearing in the Merlin 384.9_alpha1-g67f9006e5 on my 86U.
There are e thousands of these entries. Roaming assistant is off. I have a lot of WiFi outlets and switches.
I saw these entries when I tried this Asus official FW. Went back to Merlin 384.8_2 and they were gone.
It seems to got into Merlin FW in the alpha.

These assoc/disassoc actions have probably been happening all along with older firmwares but were not being written to the log file. I'm half wondering whether having this information written to the log is a debug option that ASUS forgot to disable in this latest firmware.

 

[LD500]

I am still having Homekit devices going NO RESPONSE with this latest firmware. The AiMesh data rate plunging to almost zero has been fixed but not the Homekit device drops.
Noticed online someone seems to have identified a bug that could be the cause:
https://rog.asus.com/forum/showthre...e-after-roaming-away-from-wireless-AiMesh-nod

I wonder if there's a way to turn off roaming between Asus AiMesh router/nodes for particular devices (identified by MAC or other methods).
Any ideas? It would be a good stop-gap fix until Asus makes additional fixes in future firmware versions

Thanks

 

[Fandroid]

The disassoc / assoc messages made me realize that the network adapter of my notebook had from none up to 10 of those entries per hour. Can this mean a faulty network adapter?

 

[Lotta Cox]

The disassoc / assoc messages made me realize that the network adapter of my notebook had from none up to 10 of those entries per hour. Can this mean a faulty network adapter?

No, it's not bad. There is some bug in the code. Or this spam was never logged whatever.
Anyone know what version these notifications started with official Asus firmware?
I had this 86U a year. I always had Merlin FW on it. I tried this official FW for the first time ever a few weeks ago and saw that spam in the log. Now, it has made to Merlin's FW.

 

[Fandroid]

It's odd because I have other devices on same band (2.4 GHz) that don't exhibit same behavior.

 

[Sanna1967]

Anyone know what version these notifications started with official Asus firmware?

disassoc / assoc
This one 384.45149 , this notification was not there in 32799 and before

 

[Lotta Cox]

disassoc / assoc
This one 384.45149 , this notification was not there in 32799 and before

@RMerlin any idea why these entries started appearing in the logs?

 

[SwampKracker]

@RMerlin any idea why these entries started appearing in the logs?

I suspect it is because Asus is finally allowing these messages to appear in the logs. The problem causing the messages has existed for most, if not all, of this new code branch that is AiMesh.

 

[universe83]

Buy the RT-AC86u 5 days ago and when turning on the router, IPv6 works correctly for a few minutes, then it does not work.?
When IPv6 works the routing table shows the default route (WAN IPv6 Gateway), when IPv6 stops working the line with the default route (WAN IPv6 Gateway) disappears.

All this happens in official firmware. versions: 3.0.0.4.384.45149, 3.0.0.4.384.32799, I do not know if in previous versions it happens.
Also try the latest version of Asus merlin and the same thing happens.

(Excuse my language, my native language is Spanish)

Update 1:
My internet connection is VDSL2 50mbps down / 10mbps up.
My configuration is as follows: ISP -> Modem Huawei HG659 (In bridge mode) -> Asus RT-AC86U.
My ISP is DualStack (IPv4/IPv6), IPv6 Connection Type: Native with DHCP-PD​

After 1 month of testing, now I know when the problem occurs, when turning on the router for 31 minutes the devices in my network can access IPv6 sites (https://ipv6.google.com), the router can never reach IPv6 sites (probe from router GUI -> Network tools -> Network analisys -> Ping to ipv6.google.com)
After 31 minutes default route (WAN IPv6 Gateway) disappears.

Contact asus support and after several emails and tests they said:
"We found that the default gateway was removed caused by timeout occurred, we need to check if the router get the extended time packet"

And they sent me a beta of a firmware with tcpdump enabled and the command: tcpdump -i eth0 -w /tmp/wan0.pcap -s 1500

I sent them the file with the data and then they said:
"According to the information you provide, Our Enginner think it cause by RFC 4861 (https://tools.ietf.org/html/rfc4861) Section 4.2 Router Advertisement Message Format A: A lifetime of 0 indicates that the router is not to default router and SHOULD NOT appear on the default router list "

They made some changes to the firmware and they sent it to me, now IPv6 works correctly all the time, the funny thing is that in System log-> IPv6, WAN IPv6 Address: Always is empty

I told them that IPv6 was now working correctly with the modified firmware and they said:
"We use some workaround to deal with IPv6 Packet in your environment, it seems the ISP you used, IPv6 action didn't similar to most of ISP (after analysis the packet you provided), so we use this method."

But they do not know when the patch will be in the official firmware because according to them it is a problem that only happens with my ISP, I think it happens in more ISPs but the users have not noticed, firstly because IPv6 is disabled by default, and in the second because many ISPs are just beginning the IPv6 deployment, my ISP in 1 year went from 4% to 25% of IPv6 deployment.

Looking in the forum I see similar issues to mine (I think i´m not alone):
https://www.snbforums.com/threads/wan-ipv6-gateway-problem-fix.54199/

 

[OzarkEdge]

After 1 month of testing, now I know when the problem occurs, when turning on the router for 31 minutes the devices in my network can access IPv6 sites (https://ipv6.google.com), the router can never reach IPv6 sites (probe from router GUI -> Network tools -> Network analisys -> Ping to ipv6.google.com)
After 31 minutes default route (WAN IPv6 Gateway) disappears.

Contact asus support and after several emails and tests they said:
"We found that the default gateway was removed caused by timeout occurred, we need to check if the router get the extended time packet"

And they sent me a beta of a firmware with tcpdump enabled and the command: tcpdump -i eth0 -w /tmp/wan0.pcap -s 1500

I sent them the file with the data and then they said:
"According to the information you provide, Our Enginner think it cause by RFC 4861 (https://tools.ietf.org/html/rfc4861) Section 4.2 Router Advertisement Message Format A: A lifetime of 0 indicates that the router is not to default router and SHOULD NOT appear on the default router list "

They made some changes to the firmware and they sent it to me, now IPv6 works correctly all the time, the funny thing is that in System log-> IPv6, WAN IPv6 Address: Always is empty

I told them that IPv6 was now working correctly with the modified firmware and they said:
"We use some workaround to deal with IPv6 Packet in your environment, it seems the ISP you used, IPv6 action didn't similar to most of ISP (after analysis the packet you provided), so we use this method."

But they do not know when the patch will be in the official firmware because according to them it is a problem that only happens with my ISP, I think it happens in more ISPs but the users have not noticed, firstly because IPv6 is disabled by default, and in the second because many ISPs are just beginning the IPv6 deployment, my ISP in 1 year went from 4% to 25% of IPv6 deployment.

Looking in the forum I see similar issues to mine (I think i´m not alone):
https://www.snbforums.com/threads/wan-ipv6-gateway-problem-fix.54199/

Good reason to not use IPv6 now... give it more time to mature and deploy?

OE

 

[128bit]

fascinating observation in tha last few minutes.

i just so happened to notice my la crosse weather station repeatedly toggling (on/off) the clock part of its display. so i signed-on to my 86u to see if there was any indication and sure enough, every time there was a blink, i got a asso/disso msg.

u guys are good!

 

[SeattleJJFish]

Yes. Please see this:

Dec 7 07:49:15 kernel: pgd = ffffffc00ae8b000
Dec 7 07:49:15 kernel: [00000000] *pgd=000000001253c003, *pud=000000001253c003, *pmd=000000000af31003, *pte=0000000000000000
Dec 7 07:49:15 kernel: CPU: 1 PID: 23051 Comm: dcd Tainted: P O 4.1.27 #2
Dec 7 07:49:15 kernel: Hardware name: Broadcom-v8A (DT)
Dec 7 07:49:15 kernel: task: ffffffc0170f54c0 ti: ffffffc00ae58000 task.ti: ffffffc00ae58000
Dec 7 07:49:15 kernel: PC is at 0xf7169f44
Dec 7 07:49:15 kernel: LR is at 0x1dc74
Dec 7 07:49:15 kernel: pc : [<00000000f7169f44>] lr : [<000000000001dc74>] pstate: 80070010
Dec 7 07:49:15 kernel: sp : 00000000fff85f28
Dec 7 07:49:15 kernel: x12: 000000000009ff10
Dec 7 07:49:15 kernel: x11: 00000000f63ff024 x10: 00000000000a0766
Dec 7 07:49:15 kernel: x9 : 0000000000000028 x8 : 00000000000a076c
Dec 7 07:49:15 kernel: x7 : 0000000000000028 x6 : 00000000f63ffd54
Dec 7 07:49:15 kernel: x5 : 0000000000000000 x4 : 00000000f63ffcf0
Dec 7 07:49:15 kernel: x3 : 00000000f63ffd7c x2 : 00000000ffffffff
Dec 7 07:49:15 kernel: x1 : 000000000007c674 x0 : 0000000000000000

CriticJay, I had this problem too. Since I didn't have time to rollback the router firmware - I get home at night and physical access to the router is in the kid's room - I played with settings until it went away - Under the advanced wireless network setup, I am running smart connect dual band, I had 'Protected Management Frames' set to capable. I disabled the feature, rebooted the router, and I haven't had the soft crashes. I also checked the 'AIProtection', QoS and other issues but the protected management frames seems the culprit.

 

[CriticJay]

CriticJay, I had this problem too. Since I didn't have time to rollback the router firmware - I get home at night and physical access to the router is in the kid's room - I played with settings until it went away - Under the advanced wireless network setup, I am running smart connect dual band, I had 'Protected Management Frames' set to capable. I disabled the feature, rebooted the router, and I haven't had the soft crashes. I also checked the 'AIProtection', QoS and other issues but the protected management frames seems the culprit.

Hi Seattle,

Thanks for the input, however I don't think that's causing the issue on my setup. I have never had that particular feature enabled, it's always been disabled.

 

[SeattleJJFish]

Hi Seattle,

Thanks for the input, however I don't think that's causing the issue on my setup. I have never had that particular feature enabled, it's always been disabled.

It started again today. After some more research, it seems to be related to a bad Broadcom driver. It seems like the 4.1.27 driver has repeated issues, even on this forum - May, Jul, Sept and Nov. - https://www.bing.com/search?q=tainted+4.1.27 -

There is a nice thread here on memory mgmt with the driver: https://www.linuxquestions.org/ques...e-to-handle-kernel-paging-request-4175618282/

So its unclear if rolling back is just not logging the bug. I initialized the modem and set it up today. It's been stable other than this log. I'm not thinking of rolling back at this time, since it certainly has happened before. it soft crashes about 2 times an hour on average.

Note I tried turning off ipv6, and I lost 1/2 of the router speed via speedtest and I couldn't figure out why so I left ipv6 on.

 

[RMerlin]

4.1.27 has nothing to do with drivers, it's simply the kernel version used by the firmware.

The "tainted" string simply indicates that the kernel contains non-GPL drivers.

 

[bluepoint]

The disassoc / assoc messages made me realize that the network adapter of my notebook had from none up to 10 of those entries per hour. Can this mean a faulty network adapter?

Here's my observation. My laptop gets these logs whenever it sleeps/wakeup while the mobile phones creates the logs when it leaves and comes back. So it appears it s a normal wireless events that is now being logged as before it's not.