XT8 (AP mode) DHCP not working upon roaming to ONE node, ONE wifi band

[Philibuster]

I've been having some roaming issues to one "WAP" on one wifi band. I have a linux router running ubuntu and two XT8s running independently in AP mode as my WAPs. I have manually assigned non-overlapping channels and low interference channels from my neighbors' wifi networks. Both WAPs are running the beta 41994 build. The other WAP has no issues, ever. Only when roaming to the other WAP have I seen this issue.
The symptoms I see are that my phone will drop the wifi network and go to LTE data. It will try to reconnect to my home wifi but can't get an IP through DHCP. If I change the MAC address in wifi settings to "Randomize MAC" then it will get a new IP address.
Smart Connect is disabled.

Things I have tried to fix this:
1) Factory reset WAP. Both WPS button and reset button methods tried, as well as using the admin page method.
2) Disable IGMP Snooping.
3) Disable UAPSD.
4) Disable Roaming Assistant.
5) Rebooting the WAP works.

In looking at the logs of both the DHCP server and the WAP, it looks like the issue begins at 19:41:34 (internal clock on both devices are sync'd). The WAP log shows Deauth_ind and the DHCP server shows it is replying with DHCPOFFER. Then things go off the rails, until I change to a randomized mac (omitted, as seems irrelevant).

Maybe the device is pingponging to and from this node? And something in the WAP is rate limiting how often it can connect? Sometimes the phone will be able to connect to the 2.4ghz band (even when the phone isn't set to randomized MAC), but only when it decides the 5.0ghz band is too weak.

Any ideas on this?

Feb 7 19:41:34 kaofiles dhcpd[291774]: reuse_lease: lease age 397 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:41:34 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:35 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:37 kaofiles dhcpd[291774]: reuse_lease: lease age 400 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:41:37 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:38 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:41 kaofiles dhcpd[291774]: reuse_lease: lease age 404 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:41:41 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:42 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:48 kaofiles dhcpd[291774]: reuse_lease: lease age 411 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:41:48 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:49 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:55 kaofiles dhcpd[291774]: reuse_lease: lease age 418 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:41:55 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:56 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:56 kaofiles dhcpd[291774]: reuse_lease: lease age 419 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:41:56 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:56 kaofiles dhcpd[291774]: unexpected ICMP Echo Reply from 8.8.8.8
Feb 7 19:41:57 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:57 kaofiles dhcpd[291774]: reuse_lease: lease age 420 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:41:57 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:41:58 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:42:01 kaofiles dhcpd[291774]: reuse_lease: lease age 424 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:42:01 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:42:02 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:42:13 kaofiles dhcpd[291774]: reuse_lease: lease age 436 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:42:13 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:42:14 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:42:14 kaofiles dhcpd[291774]: reuse_lease: lease age 437 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:42:14 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:42:15 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0
Feb 7 19:42:16 kaofiles dhcpd[291774]: reuse_lease: lease age 439 (secs) under 25% threshold, reply with unaltered, existing lease for 10.1.1.240
Feb 7 19:42:16 kaofiles dhcpd[291774]: DHCPDISCOVER from 7c:d9:5c:b7:31:4a via br0
Feb 7 19:42:17 kaofiles dhcpd[291774]: DHCPOFFER on 10.1.1.240 to 7c:d9:5c:b7:31:4a via br0

Feb 7 19:36:00 wlceventd: wlceventd_proc_event(527): eth6: Auth 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:36:00 wlceventd: wlceventd_proc_event(537): eth6: ReAssoc 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:37:12 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 7C9:5C:B7:31:4A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 7 19:37:12 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 7C9:5C:B7:31:4A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 7 19:37:49 wlceventd: wlceventd_proc_event(527): eth6: Auth 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:37:49 wlceventd: wlceventd_proc_event(537): eth6: ReAssoc 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:40:06 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 7C9:5C:B7:31:4A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 7 19:40:06 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 7C9:5C:B7:31:4A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 7 19:41:26 wlceventd: wlceventd_proc_event(527): eth6: Auth 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:41:26 wlceventd: wlceventd_proc_event(537): eth6: ReAssoc 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:41:31 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 7C9:5C:B7:31:4A, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Feb 7 19:41:34 wlceventd: wlceventd_proc_event(527): eth6: Auth 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:41:34 wlceventd: wlceventd_proc_event(556): eth6: Assoc 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:41:52 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 7C9:5C:B7:31:4A, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Feb 7 19:41:54 wlceventd: wlceventd_proc_event(527): eth6: Auth 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:41:54 wlceventd: wlceventd_proc_event(556): eth6: Assoc 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:42:09 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 7C9:5C:B7:31:4A, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Feb 7 19:42:13 wlceventd: wlceventd_proc_event(527): eth6: Auth 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:42:13 wlceventd: wlceventd_proc_event(556): eth6: Assoc 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:42:31 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 7C9:5C:B7:31:4A, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Feb 7 19:42:34 wlceventd: wlceventd_proc_event(527): eth6: Auth 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:42:34 wlceventd: wlceventd_proc_event(556): eth6: Assoc 7C9:5C:B7:31:4A, status: Successful (0), rssi:0
Feb 7 19:42:52 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 7C9:5C:B7:31:4A, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0

 

[OzarkEdge]

I've been having some roaming issues to one "WAP" on one wifi band. I have a linux router running ubuntu and two XT8s running independently in AP mode as my WAPs. I have manually assigned non-overlapping channels and low interference channels from my neighbors' wifi networks. Both WAPs are running the beta 41994 build. The other WAP has no issues, ever. Only when roaming to the other WAP have I seen this issue.
The symptoms I see are that my phone will drop the wifi network and go to LTE data. It will try to reconnect to my home wifi but can't get an IP through DHCP. If I change the MAC address in wifi settings to "Randomize MAC" then it will get a new IP address.
Smart Connect is disabled.

Things I have tried to fix this:
1) Factory reset WAP. Both WPS button and reset button methods tried, as well as using the admin page method.
2) Disable IGMP Snooping.
3) Disable UAPSD.
4) Disable Roaming Assistant.
5) Rebooting the WAP works.

In looking at the logs of both the DHCP server and the WAP, it looks like the issue begins at 19:41:34 (internal clock on both devices are sync'd). The WAP log shows Deauth_ind and the DHCP server shows it is replying with DHCPOFFER. Then things go off the rails, until I change to a randomized mac (omitted, as seems irrelevant).

Maybe the device is pingponging to and from this node? And something in the WAP is rate limiting how often it can connect? Sometimes the phone will be able to connect to the 2.4ghz band (even when the phone isn't set to randomized MAC), but only when it decides the 5.0ghz band is too weak.

Any ideas on this?

I would try:
o Disable Smart Connect and set different SSIDs per band.
o Enable Roaming Assistant and raise (less negative) the troubled band RSSI threshold by 15 dBm.
o Connect clients to the preferred band/SSID.
o Later, if desired, enable Smart Connect and set same SSIDs per band.

OE

 

[Philibuster]

I enabled roaming assistant last night. It did not kick me off of my wifi, but usually this problem arises after a few days. Hoping it's fixed!

 

[Philibuster]

I changed the orientation of the node to cover the area where I notice the issue more. It's now lying on its side, hopefully better signal in the vertical axis now. I haven't had the issue come back up, but it's only been 2 days since a reboot.