AC86U disconnecting certain devices

[markpv]

I've done a search on this and have not had much luck to match my issue. Have a AC86U running Merlin 386.1 and my SmartThings hub is constantly being kicked off the network. Looking at the system log I see a bunch of "not mesh client, can't update it's ip" for the MAC address of the hub. It does this to other devices sporadically however it seems to really have a problem with my SmartThings hub. As stated I have done a search and tried a few things that were mentioned such as changing WiFi channels from auto to a set channel, picking ones that have minimal interference from neighboring networks.

 

[ColinTaylor]

Is your SmartThings connected to the first guest network? If so change to using the 2nd guest network as the first one now works differently in 386.1.

 

[markpv]

Forgive my ignorance but I don't know what you are referring to, I have it on the main network?

 

[ColinTaylor]

Forgive my ignorance but I don't know what you are referring to, I have it on the main network?

OK ignore what I said then. I thought your device might be connected wirelessly to one of the router's guest WiFi networks.

Searching the forum there appear to be many reports of this message since the 386 firmware was released. For example here.

 

[markpv]

Yes seen those in my search but as mentioned they don't really apply for me. It keeps disconnecting the hub every time and I've tried setting it as manual IP and still no luck. So basically the errors that I end up in turn will boot the device from the network as well.

 

[L&LD]

@markpv the following suggestions may help get your router/network back to a good/known state where the router is using the defaults it's expecting for the firmware that is currently installed on it.

Best Practice Update/Setup Router/AiMesh Node(s) 2021

 

[markpv]

Okay so I feel like an idiot now. It turns out it's not an issue with the router kicking the client off it just seemed to be that way. When upon closer inspection the message is generated when the device reconnects to the router. Due to times in the system log being close to each other I thought it was kicking them off.

 

[zd59]

@markpv the following suggestions may help get your router/network back to a good/known state where the router is using the defaults it's expecting for the firmware that is currently installed on it.

Best Practice Update/Setup Router/AiMesh Node(s) 2021

After careful following your instructions regarding router upgrade, it worked without any problem for a week.
Upgraded RT-AC86u from 384.17 to 386.1 (RMerlin)
Today it started to disconnecting WiFi devices (main not guest networks) with a messages:
Feb 18 11:28:43 dnsmasq-dhcp[1174]: DHCPOFFER(br0) 10.200.200.197 xxxxxx:01:aa
Feb 18 11:28:45 dnsmasq-dhcp[1174]: DHCPDISCOVER(br0) xxxxxx:01:aa
Feb 18 11:28:45 dnsmasq-dhcp[1174]: DHCPOFFER(br0) 10.200.200.197 xxxxxx:01:aa
Feb 18 11:28:45 dnsmasq-dhcp[1174]: DHCPREQUEST(br0) 10.200.200.197 xxxxxx:01:aa
Feb 18 11:28:45 dnsmasq-dhcp[1174]: DHCPACK(br0) 10.200.200.197xxxxxx:01:aa Galaxy-A20e
Feb 18 11:28:45 kernel: xxxxxx:A9:5C not mesh client, can't update it's ip
Feb 18 11:28:45 kernel: xxxxxx:C9:1E not mesh client, can't update it's ip
Feb 18 11:28:45 kernel: xxxxxx:01:AA not mesh client, can't update it's ip

Reboot do not help.
The resources are also OK:

 

[markpv]

After careful following your instructions regarding router upgrade, it worked without any problem for a week.
Upgraded RT-AC86u from 384.17 to 386.1 (RMerlin)
Today it started to disconnecting WiFi devices (main not guest networks) with a messages:
Feb 18 11:28:43 dnsmasq-dhcp[1174]: DHCPOFFER(br0) 10.200.200.197 xxxxxx:01:aa
Feb 18 11:28:45 dnsmasq-dhcp[1174]: DHCPDISCOVER(br0) xxxxxx:01:aa
Feb 18 11:28:45 dnsmasq-dhcp[1174]: DHCPOFFER(br0) 10.200.200.197 xxxxxx:01:aa
Feb 18 11:28:45 dnsmasq-dhcp[1174]: DHCPREQUEST(br0) 10.200.200.197 xxxxxx:01:aa
Feb 18 11:28:45 dnsmasq-dhcp[1174]: DHCPACK(br0) 10.200.200.197xxxxxx:01:aa Galaxy-A20e
Feb 18 11:28:45 kernel: xxxxxx:A9:5C not mesh client, can't update it's ip
Feb 18 11:28:45 kernel: xxxxxx:C9:1E not mesh client, can't update it's ip
Feb 18 11:28:45 kernel: xxxxxx:01:AA not mesh client, can't update it's ip

Reboot do not help.
The resources are also OK:
View attachment 30909

So as I mentioned it was an error on my part due to the timing of the logs being do close to each other. You'll need Scribe and UIScribe to view the extra logs that I am about to reference. Under system messages you will see the "not mesh client, can't update it's ip". If you scroll to the last log being the wlceventd.log you will see around the same time indicated in System Messages that the same device has Disassociated for one reason or another. Theses messages as mentioned in a previous thread are just a system message that doesn't really do anything and can be ignored. Please see my example below:

System Messages:
Feb 18 03:42:18 DOBBY kernel: xx:xx:xx:xx:05:22 not mesh client, can't update it's ip
Feb 18 03:56:08 DOBBY kernel: xx:xx:xx:xx:F9:5D not mesh client, can't update it's ip

wlceventd.log:
Feb 18 03:56:07 DOBBY wlceventd: wlceventd_proc_event(507): eth5: Disassoc xx:xx:xx:xx:F9:5D, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 18 03:56:07 DOBBY wlceventd: wlceventd_proc_event(526): eth5: Auth xx:xx:xx:xx:F9:5D, status: Successful (0), rssi:0
Feb 18 03:56:07 DOBBY wlceventd: wlceventd_proc_event(555): eth5: Assoc xx:xx:xx:xx:F9:5D, status: Successful (0), rssi:0

Note the xx:xx:xx:xx:F9:5D "left" at 03:56:07 and the "not mesh client" message is one second later. So for what ever reason that device disconnected and reconnected. This is proved even more by the 03:42:18 xx:xx:xx:xx:05:22 in my system messages because that device is a hardwired weather station receiver. Hope my post sheds some light on your issue and in my opinion the router is not disconnecting these devices it's the devices going offline for one reason or another.