What's new

not mesh client, can't update it's ip

  • 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!

bertilak

Regular Contributor
RT-AC86U, Merlin 386.2_6.

This message is scattered about in my system log:
Jun 8 05:43:09 kernel: 00:BB:3A:C9:03:BE not mesh client, can't update it's ip
Sure enough, the MAC address has nothing to do with mesh. It's a Kindle. What is special about this device that it generates that message? Why would its IP need updating? After all, there are many other clients that are not mesh clients but there are no such messages about them.

There are also the following messages that appear, sometimes nearby the above and sometimes not.
Jun 8 05:43:08 wlceventd: wlceventd_proc_event(527): eth5: Auth 00:BB:3A:C9:03:BE, status: Successful (0), rssi:0
Jun 8 05:43:08 wlceventd: wlceventd_proc_event(556): eth5: Assoc 00:BB:3A:C9:03:BE, status: Successful (0), rssi:0

P.S. All is working well. I just wonder about that message.

P.P.S. That should be "its ip" and not "it's ip"
 
Ignore them.
 
Ignore them.
I'm facing the same issue with several devices, but when it happens with my 2 August Locks Wifi Bridge, they loose its connection and eventually it reconnects automatically but in some cases I have to power cycle the bridges.

Wondering if I can tweak something here to fix it. Or if I can provide any additional logs to try to find the root cause (not stating it is router/firmware related, but it's the best way to find the cause).

EDIT: Forgot to mention... 2.4GHZ and same behavior with ou without Beamforming / Airtime Fairness / Mimo

Thanks
 
Last edited:
I'm getting this msg too and I'm thinking it's for device that I have "Bound" to a specific mesh node... which is something I would LIKE to do because they are devices that don't move around and I know which node they are always physically closest to (I also hate that one of them bounces around on the mesh when unbound simply because I opened a door to its room). So, I've Unbound most of them for now. The msg MIGHT be harmless but, I'm having a lot of disconnection issues with a couple of my 2.4 Ghz devices and I have no idea if this is the cause. I'm going to create a support ticket with ASUS.

Router(s) + mesh: ASUS Zen Wifi XT8
Firmware version: 3.0.0.4.386_431818_g6099e58
Mesh is backhaul over ethernet only
 
I'm getting this msg too and I'm thinking it's for device that I have "Bound" to a specific mesh node... which is something I would LIKE to do because they are devices that don't move around and I know which node they are always physically closest to (I also hate that one of them bounces around on the mesh when unbound simply because I opened a door to its room). So, I've Unbound most of them for now. The msg MIGHT be harmless but, I'm having a lot of disconnection issues with a couple of my 2.4 Ghz devices and I have no idea if this is the cause. I'm going to create a support ticket with ASUS.

Router(s) + mesh: ASUS Zen Wifi XT8
Firmware version: 3.0.0.4.386_431818_g6099e58
Mesh is backhaul over ethernet only
No "bounding" here also.

I haven't tried ASUS because in the past I had to "revert" to stock FW to receive any advice from them...
 
I have the same issue with mine, TUF-AX3000, with the latest firmware, mesh with AU56UV2.
I also see some connection lost between Router and Modem, don't know if that linked or not.
In addition, I found below error too:
acsd: acs_candidate_score_busy(940): eth6: busy check failed for chanspec: 0xe832
acsd: acs_candidate_score_intf(992): eth6: intf check failed for chanspec: 0xe832
acsd: acs_candidate_score_fcs(1109): eth6: fcs check failed for chanspec: 0xe832
wlceventd: wlceventd_proc_event(527): eth5: Auth 54:AE:27:51:CC:68, status: Successful (0), rssi:0
wlceventd: wlceventd_proc_event(556): eth5: Assoc 54:AE:27:51:CC:68, status: Successful (0), rssi:-67
I've already contact ASUS Service and provide the log, but they haven't reply yet for the last few weeks.
 
It is unlikely they are linked issues howielbh.

Note in the latest firmware this message has changed to "not mesh client, can't delete it". I have a log on my RT-AX92U mesh that only has the message (apart from the overnight firmware checks).

I would ignore this, but for some devices it causes connection instability (notably iMac on 5Ghz WiFi, IPCamera on 2.4Ghz WiFi and Smart TV wired).

It would really help if we knew what the router was trying to accomplish that it cannot. Delete from where? Update IP because?

Bound or unbound to a node this happens, also if MAC & IP is bound or unbound.
 
Have the same messages popping up at regular intervals with my iPhone's MAC and my wired NAS MAC on GT-AX11000. The NAS is connected to an AiMesh node on RT-AX58U
 
I'm also experiencing (too) frequent client-disconnections, slowdowns, etc...just opened the logs and I get this in the logs once every few seconds. What does this even mean?


Jan 2 20:52:15 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:52:21 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:52:23 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:52:28 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:52:34 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:52:37 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:52:41 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:52:57 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:53:04 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:53:14 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:53:32 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:53:36 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:53:42 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:53:43 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT
Jan 2 20:53:49 kernel: SmartLogEvent: TX TIMEOUT SUBEVENT

I also see the frequent:

Jan 2 20:49:05 kernel: 4C:C9:5E:XX:XX:XX not mesh client, can't delete it

Super disappointed with Asus' expensive yet unreliable equipment.
 
I also see the frequent:
These are just debugging output, as I said earlier in this thread, simply ignore them.
 
These are just debugging output, as I said earlier in this thread, simply ignore them.
What is interesting is whenever i get these messages, it is when a device is having trouble connecting.

They would do it for hours before they finally connect. What I do notice is if i power off the device, they usually connect without a problem. Something seems like it gets stale and is correlated with that message.
 
Boss said ignore them, that's what I do, and I've been getting them for about a hundert years or so.
They don't mean nothing to us.
 

Sign Up For SNBForums Daily Digest

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