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