Wifi scale works with AC66U_B1 not with AC86U

[rjbu]

I have a wifi scale (Weight Gurus model 0396, 2.4 GHz only) that worked fine for years with my AC66U_B1 when it was my primary router.
I just switched to using a new AC86U as the primary router, same SSIDs/passwords/etc, running Merlin 384.19 and AiMesh, and now use the AC66U_B1 as an AiMesh node (ethernet backhaul).
ALL the rest of my ~50 devices connect to the AC86U just fine, but the scale will not.
If I look at the syslog when it tries to connect I see the AC86U DHCPOFFER it an IP, but the scale never proceeds further

Dec 24 15:11:52 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth5: Auth 7C:DD:90:C3:34:74, status: Successful (0)
Dec 24 15:11:52 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth5: Assoc 7C:DD:90:C3:34:74, status: Successful (0)
Dec 24 15:11:53 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:11:53 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:11:54 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:11:54 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:11:56 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:11:56 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:12:00 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:12:00 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:12:08 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:12:08 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:13:24 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:DD:90:C3:34:74, status: 0, reason: Disassociated due to inactivity (4)
Dec 24 15:13:24 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth5: Disassoc 7C:DD:90:C3:34:74, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

If I move the scale near the AC66U_B1 it still connects to it fine.

Dec 24 15:21:32 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:21:32 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:21:32 dnsmasq-dhcp[11192]: DHCPREQUEST(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:21:32 dnsmasq-dhcp[11192]: DHCPACK(br0) 192.168.51.130 7c:dd:90:c3:34:74 scale
Dec 24 15:22:36 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:22:36 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:22:36 dnsmasq-dhcp[11192]: DHCPREQUEST(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:22:36 dnsmasq-dhcp[11192]: DHCPACK(br0) 192.168.51.130 7c:dd:90:c3:34:74 scale

Any suggestions for anything to adjust on the AC86U to fix this?

 

[bbunge]

Already reported in the 386.1 beta thread.

 

[rjbu]

Already reported in the 386.1 beta thread.

Thanks, but I'm still on 384.19, haven't moved to 386 beta yet.

 

[OzarkEdge]

I have a wifi scale (Weight Gurus model 0396, 2.4 GHz only) that worked fine for years with my AC66U_B1 when it was my primary router.
I just switched to using a new AC86U as the primary router, same SSIDs/passwords/etc, running Merlin 384.19 and AiMesh, and now use the AC66U_B1 as an AiMesh node (ethernet backhaul).
ALL the rest of my ~50 devices connect to the AC86U just fine, but the scale will not.
If I look at the syslog when it tries to connect I see the AC86U DHCPOFFER it an IP, but the scale never proceeds further

Dec 24 15:11:52 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth5: Auth 7C:DD:90:C3:34:74, status: Successful (0)
Dec 24 15:11:52 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth5: Assoc 7C:DD:90:C3:34:74, status: Successful (0)
Dec 24 15:11:53 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:11:53 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:11:54 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:11:54 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:11:56 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:11:56 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:12:00 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:12:00 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:12:08 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:12:08 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:13:24 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind 7C:DD:90:C3:34:74, status: 0, reason: Disassociated due to inactivity (4)
Dec 24 15:13:24 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth5: Disassoc 7C:DD:90:C3:34:74, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

If I move the scale near the AC66U_B1 it still connects to it fine.

Dec 24 15:21:32 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:21:32 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:21:32 dnsmasq-dhcp[11192]: DHCPREQUEST(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:21:32 dnsmasq-dhcp[11192]: DHCPACK(br0) 192.168.51.130 7c:dd:90:c3:34:74 scale
Dec 24 15:22:36 dnsmasq-dhcp[11192]: DHCPDISCOVER(br0) 7c:dd:90:c3:34:74
Dec 24 15:22:36 dnsmasq-dhcp[11192]: DHCPOFFER(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:22:36 dnsmasq-dhcp[11192]: DHCPREQUEST(br0) 192.168.51.130 7c:dd:90:c3:34:74
Dec 24 15:22:36 dnsmasq-dhcp[11192]: DHCPACK(br0) 192.168.51.130 7c:dd:90:c3:34:74 scale

Any suggestions for anything to adjust on the AC86U to fix this?

Some things to try:

o Disable Airtime Fairness and Universal Beamforming per band.

o Forget/Recreate the client WiFi connection.

OE

 

[rjbu]

Some things to try:

o Disable Airtime Fairness and Universal Beamforming per band.

o Forget/Recreate the client WiFi connection.

OE

Thanks. Airtime Fairness was disabled, and I disabled Universal (Implicit) Beamforming on 2.4 GHz, Explicit Beamforming is still enabled.
I tried the scale once last night and it appeared to connect and work.
But this morning it is back to not working (same syslog messages showing does not seem to progress after AC86U sends DHCPOFFER with IP).

I also noticed another strange thing. I have a Harmony Hub, and last night I noticed it was connected (2.4 GHz) to the AC66U_B1 which is ~25 feet away and thru 2 walls,
instead of to the AC86U which is 10 ft away direct line of sight. After I disabled the Universal Beamforming, and the scale appeared to work,
I power cycled the Harmony Hub, and it connected to the AC86U.
But this morning I see it is back connected to the AC66U_B1.

Any other suggestions?

 

[OzarkEdge]

Thanks. Airtime Fairness was disabled, and I disabled Universal (Implicit) Beamforming on 2.4 GHz, Explicit Beamforming is still enabled.
I tried the scale once last night and it appeared to connect and work.
But this morning it is back to not working (same syslog messages showing does not seem to progress after AC86U sends DHCPOFFER with IP).

I also noticed another strange thing. I have a Harmony Hub, and last night I noticed it was connected (2.4 GHz) to the AC66U_B1 which is ~25 feet away and thru 2 walls,
instead of to the AC86U which is 10 ft away direct line of sight. After I disabled the Universal Beamforming, and the scale appeared to work,
I power cycled the Harmony Hub, and it connected to the AC86U.
But this morning I see it is back connected to the AC66U_B1.

Any other suggestions?

Try raising (less negative) the 2.4 Roaming Assistant RSSI threshold from the default of -70 dBm to -55. It sounds like your nodes are not very far apart, so both 2.4 signals look strong to the client, which I've seen cause client connection confusion/disruption.

I've been blaming this on the inclusion of a new WiFi OEM SDK in the Asus firmware that has improved the 'effective signal'... but what do I know.

OE

 

[rjbu]

Try raising (less negative) the 2.4 Roaming Assistant RSSI threshold from the default of -70 dBm to -55. It sounds like your nodes are not very far apart, so both 2.4 signals look strong to the client, which I've seen cause client connection confusion/disruption.

I've been blaming this on the inclusion of a new WiFi OEM SDK in the Asus firmware that has improved the 'effective signal'... but what do I know.

OE

Thanks. It now seems like doing anything that restarts wifi - Applying changes after enabling/disabling Roaming Assistant or Universal Beamforming, etc
or rebooting the router after making no changes at all, all allow the scale to connect for a while, but then in the morning its back to not working again.
Also finding more and more things not working right - if I reboot the AC86U then my Ring Alarm Base unit will not connect either;
Ring does DHCPDISCOVER, AC86U DHCPOFFERs IP address and Ring goes right back to DHCPDISCOVER....

When I started using AC86U I went straight to using AiMesh, so just as a test I stopped using AiMesh and went back to second node being in Access Point Mode,
but the problems still persisted,
So I'm out of time to keep playing with AC86U, so I went back to using AC66U_B1 (384.19) as my main router (not using AiMesh) and a second AC66U_B1 in access point Mode,
and everything is back to working fine again.

 

[OzarkEdge]

Thanks. It now seems like doing anything that restarts wifi - Applying changes after enabling/disabling Roaming Assistant or Universal Beamforming, etc
or rebooting the router after making no changes at all, all allow the scale to connect for a while, but then in the morning its back to not working again.
Also finding more and more things not working right - if I reboot the AC86U then my Ring Alarm Base unit will not connect either;
Ring does DHCPDISCOVER, AC86U DHCPOFFERs IP address and Ring goes right back to DHCPDISCOVER....

When I started using AC86U I went straight to using AiMesh, so just as a test I stopped using AiMesh and went back to second node being in Access Point Mode,
but the problems still persisted,
So I'm out of time to keep playing with AC86U, so I went back to using AC66U_B1 (384.19) as my main router (not using AiMesh) and a second AC66U_B1 in access point Mode,
and everything is back to working fine again.

My 2xRT-AC86U wireless AiMesh is running fine on Asuswrt RC2-9 beta firmware.

OE

 

[cooloutac]

Thanks. It now seems like doing anything that restarts wifi - Applying changes after enabling/disabling Roaming Assistant or Universal Beamforming, etc
or rebooting the router after making no changes at all, all allow the scale to connect for a while, but then in the morning its back to not working again.
Also finding more and more things not working right - if I reboot the AC86U then my Ring Alarm Base unit will not connect either;
Ring does DHCPDISCOVER, AC86U DHCPOFFERs IP address and Ring goes right back to DHCPDISCOVER....

When I started using AC86U I went straight to using AiMesh, so just as a test I stopped using AiMesh and went back to second node being in Access Point Mode,
but the problems still persisted,
So I'm out of time to keep playing with AC86U, so I went back to using AC66U_B1 (384.19) as my main router (not using AiMesh) and a second AC66U_B1 in access point Mode,
and everything is back to working fine again.

do the two ac66u_b1's in aimesh mode have the same problems the single ac86u did? Or is it because you prefer to keep one on a separate network?

I couldn't stand my ac86u and returned it after a month even though I had 90 days to use it lol. Worst experience I ever had with a router besides one totally going dead. I ended up getting an ax58u instead and love it. Has much better 2.4ghz range then the ac86u did and is very stable. Only thing its lacking is the fast openvpn speed, which I felt turned out not to be worth it in the end.

 

[rjbu]

do the two ac66u_b1's in aimesh mode have the same problems the single ac86u did? Or is it because you prefer to keep one on a separate network?

Unfortunately I didn't try the two ac66u_b1's in aimesh mode this time; I did use the two of them in aimesh mode a long time ago, and I don't recall having seen issues like this then. But I gave up on aimesh 1.0 when it did not provide the guest network on the aimesh node, and went to the current config using one in router mode and one in access point mode so I can have a guest network on both nodes.

I'll probably try the the two ac66u_b1's in aimesh 2.0 mode when I'm back at that house in a couple of months.

I couldn't stand my ac86u and returned it after a month even though I had 90 days to use it lol. Worst experience I ever had with a router besides one totally going dead. I ended up getting an ax58u instead and love it. Has much better 2.4ghz range then the ac86u did and is very stable. Only thing its lacking is the fast openvpn speed, which I felt turned out not to be worth it in the end.

Thanks for the recommendation on the ax58u. Yes, I'm not happy with the ac86u either, and will be returning it, and will probably keep looking for something else.

 

[cooloutac]

Unfortunately I didn't try the two ac66u_b1's in aimesh mode this time; I did use the two of them in aimesh mode a long time ago, and I don't recall having seen issues like this then. But I gave up on aimesh 1.0 when it did not provide the guest network on the aimesh node, and went to the current config using one in router mode and one in access point mode so I can have a guest network on both nodes.

I'll probably try the the two ac66u_b1's in aimesh 2.0 mode when I'm back at that house in a couple of months.



Thanks for the recommendation on the ax58u. Yes, I'm not happy with the ac86u either, and will be returning it, and will probably keep looking for something else.

ax58u does not have offical aimesh 2.0 yet. not sure why. I do feel it is super stable and notice from changelogs it has less vulnerabilities that needed patching compared to almost every asus router and almost every update addresses stability and compatibility issues. They might be just taking their time to get that one right.