not sure if anyone who also has ever encountered similar issue before?Nov 13 17:59:49 acsd: acsd_main_loop(1285): sync_id: 22152, status:4, misc.error/abort
Nov 13 17:59:53 kernel: WLC_SCB_DEAUTHORIZE error (-30)
Nov 13 17:59:53 kernel: WLC_SCB_DEAUTHORIZE error (-30)
Nov 13 17:59:53 kernel: WLC_SCB_DEAUTHORIZE error (-30)
Nov 13 17:59:53 kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
Nov 13 17:59:53 kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
Nov 13 17:59:53 kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
Nov 13 17:59:54 kernel: WLC_SCB_DEAUTHORIZE error (-30)
Nov 13 17:59:54 kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
The bug was that it only checked for 4908 and 4912, and didn't check for 4916. If you look at the new first line, it now checks for all three CPU models that shouldn't prioritize CHACHA.@RMerlin
I think this change entry is wrong. This affects the BCM4912 too! Not only the BCM4916 devices.
- FIXED: OpenSSL 1.1.1 would prioritize CHACHA20 over AES
on BCM4916 devices
View attachment 68896
If you REALLY want to have some fun, make that the default SSID for any router flashed with your firmware.There must have been over 20+ SSIDs all starting with "skyrealm" visible at that time.
You're right, 'www.asusrouter.com' resolves to an ipv4 address only. People using that won't see this bug.I'm not sure if the stock firmware even expects logging to happen over IPv6, as they automatically redirect you to www.asusrouter.com, which probably resolves only as an IPv4. Asuswrt-Merlin does not enforce that redirection, so it might be causing this issue.
That means I will probably have to see if I can fix that myself. At least part of that log code is open source, no idea if enough of it is accessible for me to fix it. I suspect I might be able to fix the syslog portion, but not the Security Log portion.
If you're using 'www.asusrouter.com' or ipv4 address in browser, you won't see this - it's an ipv6 thing. Or do you actually see ipv6 addresses in log?On my AX86-Pro these correctly show logins to the router. Not sure why this would be called "Security Update Notivication" or noted as "successed".
That string isn`t part of the webui, so it was written by an engineer who probably has very limited English skills. The webui uses language catalogs that do get handled by a translation team.But seriously Asus - successed instead of succeeded...
“successed” is not a proper word in the English language I know, and I am not native either. Or is it a misspelling from linux?
When using a hostname on an IPv6-enabled network, your browser might resolve to an IPv6. In my case for example, https://stargate/ resolves to an IPv6.If you're using 'www.asusrouter.com' or ipv4 address in browser, you won't see this - it's an ipv6 thing. Or do you actually see ipv6 addresses in log?
''BUMMER'' - but I kind of expected that. Thanks for investigating. Still embarrassing for Asus IMHO, ipv6 is almost 30 years old and still "Oops, we didn't expect ipv6".Fixing the IPv6 logging won't be doable on my end. Internally, that function does not receive the whole IPv6, it only receives a small subset of it.
Fixing it will require more low-level changes, which falls in Asus' courtyard.

Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!