What's new

Release Asuswrt-Merlin 388.1 is now available for all supported Wifi 6 models

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

AX86u
Can anyone tell me what these errors are ?
My logs are full of this ....
Fresh install, full wipe and reset and keep getting these. Will put just a couple of lines below, many many more in the log.

Dec 13 07:05:07 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a980> JOIN blog<0xffffffc02f8b17c0>^[[0m
Dec 13 07:05:07 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f8b17c0> JOIN blog<0xffffffc02f844e40>^[[0m
Dec 13 07:05:10 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f860000> JOIN blog<0xffffffc02f842e40>^[[0m
 
Disconnecting Asus USB-AC68, obviously, fixes the issues, and the "br0: received packet on eth7 with own address as source address" isn't repeating every 10 seconds, but I've seen it once, related to another disconnect of a different device.

I'm not sure whether similar messages have been there with 386.7_2, but I _am_ sure that this exact setup worked rock-solid on Merlin's 386.7_2 version of AsusWRT.

Hm. Rarely, but I'm getting the same disconnects even with one built-in adapter. This is most definitely different to 386.7_2 and is probably related to this WiFi issue being discussed in this thread:

Dec 13 13:11:29 router hostapd: eth7: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated
Dec 13 13:11:29 router hostapd: eth7: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session 06876CB5AE1BB7A3
Dec 13 13:11:29 router hostapd: eth7: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Dec 13 13:17:08 router hostapd: eth7: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated
Dec 13 13:17:08 router hostapd: eth7: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 4)
Dec 13 13:17:08 router kernel: br0: received packet on eth7 with own address as source address
Dec 13 13:17:08 router hostapd: eth7: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated
Dec 13 13:17:08 router hostapd: eth7: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session B6F6D3E42DF458DB
Dec 13 13:17:08 router hostapd: eth7: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
 
AX86u
Can anyone tell me what these errors are ?
My logs are full of this ....
Fresh install, full wipe and reset and keep getting these. Will put just a couple of lines below, many many more in the log.

Dec 13 07:05:07 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a980> JOIN blog<0xffffffc02f8b17c0>^[[0m
Dec 13 07:05:07 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f8b17c0> JOIN blog<0xffffffc02f844e40>^[[0m
Dec 13 07:05:10 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f860000> JOIN blog<0xffffffc02f842e40>^[[0m
RMerlin said:
Related to a proprietary Broadcom component, no idea what it means.


Nothing to worry about !

and also not present on the latest firmware as far as I can tell on mine.
 
How does this wireguard vpn work? Need some help please.
I've imported a .conf file, I also see that I'm connected, but it is not working, see screenshot number 3.
Edit: Where can I set MTU for this wireguard client?
 

Attachments

  • Unbenannt.png
    Unbenannt.png
    104.5 KB · Views: 78
  • Unbenannt1.png
    Unbenannt1.png
    29.5 KB · Views: 81
  • Unbenannt2.png
    Unbenannt2.png
    6.5 KB · Views: 78
Last edited:
Update: I have now running the new firmware, but without Skynet en Diversion. Now running on Ad Guard Home and everything is stable now.
 
There seems to be a growing consensus the culprit for "MOST" of the recent WiFi disconnects is actually the setting of any Control Channel to Auto
So... Don't.
Meanwhile just pick the last control channel selected, or choose a channel that seems clear (maybe verify with a Wifi App)

But this leads to my point.
I had asked RMerlin about what happens when the router changes channels, Can connected clients migrate to the re-assigned channel?
He didn't think so & seemed to guess they would disconnect momentarily.
I did some research but had problems finding a definitive answer.

To me what needs to become known is...
(When Control Channel=Auto)
How often these routers check if the channel should actually change.

From the reading I've done...
Alot of routers & likely older firmware simply checked during boot-up or initialization.
However, it does seem feasible that with newer Asus firmware...

These routers are changing control channels more often.
 
Last edited:
There seems to be a growing consensus the culprit for "MOST" of the recent WiFi disconnects is actually the setting of the 5G Control Channel to Auto
So... Don't.

It is 2.4 GHz also. Just wanted to clarify this, seen a few comments claiming it is only occurring on 5 GHz. I've replicated it on both, and fixed it on both by setting control channels manually.
 
It is 2.4 GHz also. Just wanted to clarify this, seen a few comments claiming it is only occurring on 5 GHz. I've replicated it on both, and fixed it on both by setting control channels manually.
Are this issues router/ stock fw /rmerlin specific? I have "auto" set on all channels to include 5 GHz without any issues. Maybe we should specify the routers with the "supposed" issue.
 
It is 2.4 GHz also. Just wanted to clarify this, seen a few comments claiming it is only occurring on 5 GHz. I've replicated it on both, and fixed it on both by setting control channels manually.
That would make even more sense (Thank you for clarifying, I'll try to edit my post above).
A channel change on the 2.4-band would manifest similarly.
@Kingp1n : I was specifically referring to: Asuswrt-Merlin 388.1 & from what I've seen there has been a lot more of the RT-AX86U WiFi disconnecting type of complaints. Although with this router being one of the most popular... perhaps it is just higher complaint volumes due to sheer numbers.
 
Last edited:
That would make even more sense (Thank you for clarifying, I'll try to edit my post above).
A channel change on the 2.4-band would manifest similarly.
@Kingp1n : I was specifically referring to: Asuswrt-Merlin 388.1 & from what I've seen there has been a lot more of the RT-AT86U WiFi disconnecting type of complaints. Although with this router being one of the most popular... perhaps it is just higher complaint volumes due to sheer numbers.
I appreciate that.... it seems it might be affecting the RT-AX86U/S and possibly the AX88U models. Again no issues with the AX11000!
 
GT-AXE11000 - disconnect issue with 5GHz.
2.4GHz seems OK.

Yet to try the manual control channel "fix"
 
Sticking with RT-AX88U_386.7_2, as this series just fracks up everything on this router, more so my IPTV. So many random disconnects, Wi-Fi, and ethernet, despite wiping both router and my TV box. All great on 386.7_2, not a blip :)
 
That would make even more sense (Thank you for clarifying, I'll try to edit my post above).
A channel change on the 2.4-band would manifest similarly.
@Kingp1n : I was specifically referring to: Asuswrt-Merlin 388.1 & from what I've seen there has been a lot more of the RT-AX86U WiFi disconnecting type of complaints. Although with this router being one of the most popular... perhaps it is just higher complaint volumes due to sheer numbers.

Yes affecting RT-AX86U here. Stock and Merlin FW. I've not had an issue since setting manual control channels 24 hours ago and I left one camera streaming for hours overnight to really make sure. Family have stopped complaining about Netflix freezing. So, I'm happy now.. no need to rollback. Just providing info in the hope it helps others.
 
Sticking with RT-AX88U_386.7_2, as this series just fracks up everything on this router, more so my IPTV. So many random disconnects, Wi-Fi, and ethernet, despite wiping both router and my TV box. All great on 386.7_2, not a blip :)
LOL, well apparently there's no "U" in TEAM... But glad you're happy with your 24th of July firmware
 
Yes affecting RT-AX86U here. Stock and Merlin FW. I've not had an issue since setting manual control channels 24 hours ago and I left one camera streaming for hours overnight to really make sure. Family have stopped complaining about Netflix freezing. So, I'm happy now.. no need to rollback. Just providing info in the hope it helps others.
Ditto this, 10x!

2.4Ghz and 5Ghz control channels set manually, Nest cameras, doorbell and Tablets (monitoring the camera's) have been streaming non-stop for a few days.
AX88U on 388.1, 2x AX86u Mesh nodes on ASUS Firmware 3.0.0.4.388_21709. I rarely get any air traffic near enough for DFS to have any issues with radar.

The more I've read, the more I suspect the WiFi stability when the control channels were set to Auto was an issue before 388.1 and even before I reset and flashed the AX86's on ASUS firmware. I had both control channels set to Auto for the longest time and both would change channels often. I never correlated that to the disconnects from the tablets/cameras, particularly the new ones where WiFi would just stop necessitating a reboot to get it back (Android 13, AX 40Mhz 2.4Ghz tablets below) working again.

The older Android 8 tablet on 5Ghz rarely faulted (not much 5Ghz around me) but if it switched to 2.4Ghz, it also would drop the feed from the cameras frequently. I manually set the control channel on 5Ghz first, enabling 160Mhz/DFS for a laptop my eldest son was using for work (went from 866/866 to 1733/1733 with 160Mhz then to 2402/2402 with 160Mhz/DFS) some months ago, that introduced stability on that frequency (so much so I was wanting to get everything on 5Ghz). That should've prompted me to do the same for the 2.4Ghz radio as well.

In retrospect, stability, sometimes better, sometimes worse depending on Merlin/Asus version (Asus wireless driver used in the specific release as its closed source) on the router and mesh nodes, but never 100% on either 2.4Ghz/5Ghz when set to Auto. In hindsight based on where things sit today I probably should've set the control channels manually sooner.

For anyone who has gone back to 386.7-2 or earlier, curious if you're having the same connectivity experience setting Auto vs Fixed for the Control channels under those releases as well as I suspect I was having...

1670978123470.png
1670978194843.png


1670978244138.png
 
On my ASUS routers starting with the illustrious N66U, I have always set channels to manual.
On the occasions I have spaced out those settings while configuring from scratch it hasn't taken long to see the results in some of my less robust (read crap) devices.

On my AX86U manually setting up the both bands of WiFi (a number of other parameters for my devices happiness) is absolutely needed.
 
Just made an account to share my experience with this update: many WiFi dropouts on clients connected to AiMesh nodes on 388.1. I reverted back to 386.7_2 for now.

Main router: AX86U
AiMesh: 2x AC86U (connected via WiFi)

Thanks to those who suggested changing from auto to manual channels.
 
Last edited:
RMerlin said:
Related to a proprietary Broadcom component, no idea what it means.


Nothing to worry about !

and also not present on the latest firmware as far as I can tell on mine.

Thank you BreakingDad.
Unfortunately I have been getting these errors for the last few updates. Shame .... this and the 160 bug are quite annoying.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top