I recently began noticing seeing intermittent connectivity issues with my B One router. This began several weeks ago but has gotten worse recently. It manifests as increased latencies or complete drops in wifi performance and is resolved by disconnecting and reconnecting the client from the network. I have observed this behavior with multiple client devices.
As an example I initiated a ping to the router during a period of poor connectivity here:
PING 10.10.10.1 (10.10.10.1): 56 data bytes
...
Request timeout for icmp_seq 34
64 bytes from 10.10.10.1: icmp_seq=30 ttl=64 time=5702.556 ms
64 bytes from 10.10.10.1: icmp_seq=31 ttl=64 time=5858.969 ms
Request timeout for icmp_seq 37
64 bytes from 10.10.10.1: icmp_seq=33 ttl=64 time=5748.882 ms
64 bytes from 10.10.10.1: icmp_seq=35 ttl=64 time=4338.091 ms
64 bytes from 10.10.10.1: icmp_seq=36 ttl=64 time=3515.805 ms
64 bytes from 10.10.10.1: icmp_seq=37 ttl=64 time=2513.597 ms
64 bytes from 10.10.10.1: icmp_seq=38 ttl=64 time=1895.467 ms
64 bytes from 10.10.10.1: icmp_seq=39 ttl=64 time=1596.822 ms
64 bytes from 10.10.10.1: icmp_seq=41 ttl=64 time=1632.295 ms
64 bytes from 10.10.10.1: icmp_seq=44 ttl=64 time=335.079 ms
64 bytes from 10.10.10.1: icmp_seq=46 ttl=64 time=72.477 ms
64 bytes from 10.10.10.1: icmp_seq=47 ttl=64 time=205.017 ms
64 bytes from 10.10.10.1: icmp_seq=48 ttl=64 time=18.307 ms
64 bytes from 10.10.10.1: icmp_seq=49 ttl=64 time=25.475 ms
Request timeout for icmp_seq 50
Request timeout for icmp_seq 51
Request timeout for icmp_seq 52
Request timeout for icmp_seq 53
64 bytes from 10.10.10.1: icmp_seq=54 ttl=64 time=134.847 ms
Request timeout for icmp_seq 55
// ----------------------------------------
// Here I disconnected and reconnected the client from wifi
// ----------------------------------------
64 bytes from 10.10.10.1: icmp_seq=56 ttl=64 time=4.823 ms
64 bytes from 10.10.10.1: icmp_seq=57 ttl=64 time=29.681 ms
64 bytes from 10.10.10.1: icmp_seq=58 ttl=64 time=2.449 ms
64 bytes from 10.10.10.1: icmp_seq=59 ttl=64 time=67.155 ms
64 bytes from 10.10.10.1: icmp_seq=60 ttl=64 time=3.572 ms
64 bytes from 10.10.10.1: icmp_seq=61 ttl=64 time=127.769 ms
64 bytes from 10.10.10.1: icmp_seq=62 ttl=64 time=15.713 ms
64 bytes from 10.10.10.1: icmp_seq=63 ttl=64 time=94.300 ms
64 bytes from 10.10.10.1: icmp_seq=64 ttl=64 time=10.801 ms
64 bytes from 10.10.10.1: icmp_seq=65 ttl=64 time=9.233 ms
64 bytes from 10.10.10.1: icmp_seq=66 ttl=64 time=6.236 ms
64 bytes from 10.10.10.1: icmp_seq=67 ttl=64 time=2.828 ms
I am on the latest firmware version 8.5.1. I can’t say for certain if this issue correlates with the 8.5.0 upgrade but I’m confident I was not observing issues prior to that version.
Changing the channel does not seem to have an impact.
On a hunch I tried downgrading the firmware version back to 8.4.1 and since then I have no longer observed any issues. I will stay with this version for now and hopefully it will be addressed in a future patch.
I have the same issue under 8.5.1 firmware. I’ve tried fixing any channel but the router insists on reverting back to channel 6 on 2.4 GHz and 149 on 5 GHz. Don’t have QoS enabled. I’ll try downgrading the firmware to 8.4.1 and see what happens.
One of the odd things is that my VLAN problems come and go, as if there is some process which is getting corrupted then eventually rebooting or recovering? My VLAN issues seem to last for 1-2 hours and show up ever 4-8 hours roughly.
I think firmware 8.5.x has some fundamental problem and many of use are seeing it in various manifestations.
Peplink has been pretty quiet on this - we really need more feedback. C’mon Peplink!
and… until now… I don’t see this kind of issue at devices that I have.
Maybe I am just a luck guy.
I believe… that is a HARDWARE + SOFTWARE issue…
Like what happened to old tst-duo, when was discovered that was a issue with ethernet chip of the device, when connected to Starlink.
Are you also seeing this with any wired clients. I know you were asked about QOS and you said none was set, but is it likely that you have it turned on but not interacting with any devices? I ask as we have seen lan latency issues on 20+ B One 5g devices at one point with similar results to what you are showing. We don’t use the wifi though. We were also having random reboots which was linked to a QOS bug. Turning QOS off stopped the issue. We had customer firmware to fix the crash but one the one site we re-enabled QOS (not affecting any devices, just turned on) we saw the latency issue return after a couple of weeks.
We have been trying to replicate in our lab but without luck so far.
I don’t have any wired clients to validate with unfortunately so I can’t confirm on that. I’m not sure if any QoS settings are enabled by default but I didn’t change them myself and checking in the router settings there didn’t seem to be anything set up
Yep. I’m experiencing similar drop out issues that I believed were associated with distance from the AP… The times I have seen this is when I was some way from the router. Thinking the client was hanging on to the AP but not switching to the appropriate MCS rate and or frequency. I’d the forcibly disconnect and reassociate with the AP… Reason I thought it was specific client devices (phones) is my son runs his PS5 over WiFi. (so I can kick him off when I need to if he’s being an ass). Never has issues online gaming. So it’s why I never considered the actual router on the AP itself.
My son’s room is using a poweline adapter which luckily (without no noticable performance loss) for me runs through a tapo smart plug for those very instances.
My son’s room is using a poweline adapter which luckily (without no noticable performance loss) for me runs through a tapo smart plug for those very instances.