Forum Help
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dbrb2
Contributor

on ‎08-11-2020 20h03

324 Views
Message 1 of 6

Premium wifi mesh - unreliable connections - possible steering problems...?

I have a 3 disc mesh setup. On a network with no other traffic and only a single laptop connected, I can see that the ping times to the local network occasionally rise significantly and for long periods - taking me from 10mS or below to over 1000mS 

On occasion the laptop (and other devices) will disconnect entirely before reconnecting a few seconds later, often to the same AP. 

I can't find the trigger for this bahaviour

I am running f/w SGAB205018

64 bytes from 192.168.1.1: icmp_seq=30516 ttl=64 time=28.0 ms
64 bytes from 192.168.1.1: icmp_seq=30517 ttl=64 time=6.57 ms
64 bytes from 192.168.1.1: icmp_seq=30518 ttl=64 time=4.16 ms
64 bytes from 192.168.1.1: icmp_seq=30519 ttl=64 time=4.41 ms
64 bytes from 192.168.1.1: icmp_seq=30520 ttl=64 time=5.97 ms
64 bytes from 192.168.1.1: icmp_seq=30521 ttl=64 time=3.99 ms
64 bytes from 192.168.1.1: icmp_seq=30522 ttl=64 time=9.54 ms
64 bytes from 192.168.1.1: icmp_seq=30523 ttl=64 time=8.07 ms
64 bytes from 192.168.1.1: icmp_seq=30524 ttl=64 time=7.64 ms
64 bytes from 192.168.1.1: icmp_seq=30525 ttl=64 time=4.88 ms
64 bytes from 192.168.1.1: icmp_seq=30526 ttl=64 time=3.74 ms
64 bytes from 192.168.1.1: icmp_seq=30527 ttl=64 time=12.2 ms
64 bytes from 192.168.1.1: icmp_seq=30528 ttl=64 time=4.77 ms
64 bytes from 192.168.1.1: icmp_seq=30529 ttl=64 time=8.61 ms
64 bytes from 192.168.1.1: icmp_seq=30530 ttl=64 time=6.41 ms
64 bytes from 192.168.1.1: icmp_seq=30531 ttl=64 time=4.24 ms
64 bytes from 192.168.1.1: icmp_seq=30532 ttl=64 time=3.01 ms
64 bytes from 192.168.1.1: icmp_seq=30533 ttl=64 time=11.5 ms
64 bytes from 192.168.1.1: icmp_seq=30534 ttl=64 time=10.7 ms
64 bytes from 192.168.1.1: icmp_seq=30535 ttl=64 time=8.39 ms
64 bytes from 192.168.1.1: icmp_seq=30536 ttl=64 time=6.56 ms
64 bytes from 192.168.1.1: icmp_seq=30537 ttl=64 time=4.97 ms
64 bytes from 192.168.1.1: icmp_seq=30538 ttl=64 time=3.48 ms
64 bytes from 192.168.1.1: icmp_seq=30539 ttl=64 time=11.9 ms
64 bytes from 192.168.1.1: icmp_seq=30540 ttl=64 time=10.9 ms
64 bytes from 192.168.1.1: icmp_seq=30541 ttl=64 time=59.5 ms
64 bytes from 192.168.1.1: icmp_seq=30542 ttl=64 time=78.3 ms
64 bytes from 192.168.1.1: icmp_seq=30543 ttl=64 time=106 ms
64 bytes from 192.168.1.1: icmp_seq=30544 ttl=64 time=145 ms
64 bytes from 192.168.1.1: icmp_seq=30545 ttl=64 time=6.74 ms
64 bytes from 192.168.1.1: icmp_seq=30546 ttl=64 time=183 ms
64 bytes from 192.168.1.1: icmp_seq=30547 ttl=64 time=26.8 ms
64 bytes from 192.168.1.1: icmp_seq=30548 ttl=64 time=10.7 ms
64 bytes from 192.168.1.1: icmp_seq=30549 ttl=64 time=18.7 ms
64 bytes from 192.168.1.1: icmp_seq=30550 ttl=64 time=6.15 ms
64 bytes from 192.168.1.1: icmp_seq=30551 ttl=64 time=14.7 ms
64 bytes from 192.168.1.1: icmp_seq=30552 ttl=64 time=2810 ms
64 bytes from 192.168.1.1: icmp_seq=30553 ttl=64 time=1942 ms
64 bytes from 192.168.1.1: icmp_seq=30554 ttl=64 time=918 ms
64 bytes from 192.168.1.1: icmp_seq=30555 ttl=64 time=210 ms
64 bytes from 192.168.1.1: icmp_seq=30556 ttl=64 time=113 ms
64 bytes from 192.168.1.1: icmp_seq=30557 ttl=64 time=14.6 ms
64 bytes from 192.168.1.1: icmp_seq=30558 ttl=64 time=387 ms
64 bytes from 192.168.1.1: icmp_seq=30559 ttl=64 time=3394 ms
64 bytes from 192.168.1.1: icmp_seq=30560 ttl=64 time=2383 ms
64 bytes from 192.168.1.1: icmp_seq=30561 ttl=64 time=1616 ms
64 bytes from 192.168.1.1: icmp_seq=30562 ttl=64 time=596 ms
64 bytes from 192.168.1.1: icmp_seq=30563 ttl=64 time=367 ms
64 bytes from 192.168.1.1: icmp_seq=30564 ttl=64 time=339 ms
64 bytes from 192.168.1.1: icmp_seq=30565 ttl=64 time=1144 ms
64 bytes from 192.168.1.1: icmp_seq=30566 ttl=64 time=113 ms
64 bytes from 192.168.1.1: icmp_seq=30567 ttl=64 time=308 ms
64 bytes from 192.168.1.1: icmp_seq=30569 ttl=64 time=78.7 ms
64 bytes from 192.168.1.1: icmp_seq=30570 ttl=64 time=355 ms
64 bytes from 192.168.1.1: icmp_seq=30572 ttl=64 time=765 ms
64 bytes from 192.168.1.1: icmp_seq=30573 ttl=64 time=85.0 ms
64 bytes from 192.168.1.1: icmp_seq=30574 ttl=64 time=455 ms
64 bytes from 192.168.1.1: icmp_seq=30575 ttl=64 time=1184 ms
64 bytes from 192.168.1.1: icmp_seq=30576 ttl=64 time=158 ms
64 bytes from 192.168.1.1: icmp_seq=30577 ttl=64 time=1069 ms
64 bytes from 192.168.1.1: icmp_seq=30578 ttl=64 time=1300 ms
64 bytes from 192.168.1.1: icmp_seq=30579 ttl=64 time=903 ms
64 bytes from 192.168.1.1: icmp_seq=30580 ttl=64 time=397 ms
64 bytes from 192.168.1.1: icmp_seq=30581 ttl=64 time=696 ms
64 bytes from 192.168.1.1: icmp_seq=30582 ttl=64 time=1132 ms
64 bytes from 192.168.1.1: icmp_seq=30583 ttl=64 time=109 ms
64 bytes from 192.168.1.1: icmp_seq=30584 ttl=64 time=366 ms
64 bytes from 192.168.1.1: icmp_seq=30585 ttl=64 time=183 ms
64 bytes from 192.168.1.1: icmp_seq=30586 ttl=64 time=579 ms
64 bytes from 192.168.1.1: icmp_seq=30587 ttl=64 time=21.2 ms
64 bytes from 192.168.1.1: icmp_seq=30588 ttl=64 time=632 ms
64 bytes from 192.168.1.1: icmp_seq=30589 ttl=64 time=322 ms

 

The logs do seem to be full of errors regarding steering - though it looks like there are placeholders in the logs that should contain data but don't (like "<reasoon>"). 60:45 is the machine from which the ping trace above came. Does this fit with any known issues? 

 

2020-11-08 18:56:16 | 6 | MGMT | 713 | <Device Hostname> (74:DF:BF:5A:60:45) cannot be steered. Reason: Device currently making traffic.
2020-11-08 18:56:13 | 7 | MGMT | 709 | <Device Hostname> (40:A1:08:87:6E:2A) added to the steer backoff list for 1440 minutes
2020-11-08 18:56:13 | 6 | MGMT | 716 | LEGACY steer for <Device Hostname> (40:A1:08:87:6E:2A) from 7A:65:59:8D:C2:83 to failed. Reason: It keeps coming back to the same AP
2020-11-08 18:56:13 | 7 | MGMT | 711 | <Device Hostname> (40:A1:08:87:6E:2A) removed from the steer unfriendly list
2020-11-08 18:56:08 | 6 | WIFI | 206 | <Device Hostname> (40:A1:08:87:6E:2A) has connected to the 5G network with signal strength -85
2020-11-08 18:56:08 | 6 | WIFI | 207 | <Device Hostname> (40:A1:08:87:6E:2A) has authenticated successfully
2020-11-08 18:56:03 | 6 | WIFI | 209 | <Device Hostname> (40:A1:08:87:6E:2A) has deauthenticated (<Reason>)
2020-11-08 18:56:03 | 7 | MGMT | 710 | <Device Hostname> (40:A1:08:87:6E:2A) added to the steer unfriendly list for 10 seconds
2020-11-08 18:56:03 | 6 | MGMT | 714 | LEGACY steer triggered for <Device Hostname> (40:A1:08:87:6E:2A) from 7A:65:59:8D:C2:83 to . Reason: RSSI low
2020-11-08 18:55:46 | 6 | MGMT | 713 | <Device Hostname> (74:DF:BF:5A:60:45) cannot be steered. Reason: Device currently making traffic.
2020-11-08 18:55:43 | 7 | MGMT | 709 | <Device Hostname> (40:A1:08:87:6E:2A) added to the steer backoff list for 1440 minutes
2020-11-08 18:55:43 | 6 | MGMT | 716 | LEGACY steer for <Device Hostname> (40:A1:08:87:6E:2A) from 7A:65:59:8D:C2:83 to failed. Reason: It keeps coming back to the same AP

 

Any ideas? Could this be down to the devices themselves not coping with wifi steering...? 

Reply
5 REPLIES 5
dbrb2
Contributor

on ‎08-11-2020 20h18

318 Views
Message 2 of 6

Re: Premium wifi mesh - unreliable connections - possible steering problems...?

Possibly related - I know this kit does not let you split the wifi bands, but if the issue was with steering I thought about trying to force 2G4. However, this option seems to be missing:

2.4GHz Device Setup Mode:Not applicable

Is this expected?
0 Ratings
Reply
Sircoynie
Aspiring Expert

on ‎08-11-2020 21h42

308 Views
Message 3 of 6

Re: Premium wifi mesh - unreliable connections - possible steering problems...?

Sorry to not be constructive but this system has had issues like this for over 9 months and we are still awaiting an update that fixes it.
0 Ratings
Reply
dbrb2
Contributor

on ‎08-11-2020 21h59

304 Views
Message 4 of 6

Re: Premium wifi mesh - unreliable connections - possible steering problems...?

Oh dear. Does it seem to be under active development still, or is it becoming a stale product? 

I saw a new f/w release came out about a month back. And to be fair, this has worked reasonably well for me until recently....so maybe I will try moving some of my units / checking all my wiring - it might be that it's limitations are being exacerbated by some other factor that i have control over (which would explain why it has become more prominent recently) 

0 Ratings
Reply
kevin_marchant
Contributor

‎09-11-2020 18h48 - edited ‎09-11-2020 18h49

259 Views
Message 5 of 6

Re: Premium wifi mesh - unreliable connections - possible steering problems...?

As Sirconie said, they’re a bag of spanners.  I get long ping times and packet loss when I connect a disk via Ethernet backhaul (it just doesn’t work to connect the satellites to the main disk via Ethernet cable.  I mention this just to make sure you’re not doing this.

Reply
dbrb2
Contributor

on ‎09-11-2020 22h14

239 Views
Message 6 of 6

Re: Premium wifi mesh - unreliable connections - possible steering problems...?

In this case, changing out the cable between the master disc and the router has helped massively. 

Previously it was intermittent poor performance, but I realised that the cable was a flat cat5 - so likely not twisted pair, and possibly succeptible to interference, which might explain why it was ocasionally fine....

With a more standard cable, all seems OK - touch wood....

0 Ratings
Reply