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

[dbrb2]

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...? 

[dbrb2]

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?

[Sircoynie]

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.

[dbrb2]

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) 

[kevin_marchant]

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.

[dbrb2]

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....