WiFi signal dropping out every 30s for a few seconds

[bph2]

Hello team,

I am having an issue for the past 3 days where my WiFi signal on my Hub5 with a M350 service is dropping for a seconds every 30 seconds or so.  This is making it unworkable to do video conferencing and work from home.

My troubleshooting (I'm a network engineer) leads me to think it is a problem with the WiFi on the hub 5.  I get good consistent pings from the hub5 to the internet.  All devices on the wifi are affected - MacBook, iPhone, iPad.  It happens whether I am in the same room as the hub5 or elsewhere.  It also happens when I am streaming music from my phone to my stereo on the WiFi connected to Ethernet via hub5.

Video of the pings from my laptop shooting up from 30/40 ms to 3000+ ms RTT while the WiFi Tx signal on my laptop dropping from 200+ Mbps to 0.  

64 bytes from 142.250.200.46: icmp_seq=3650 ttl=115 time=32.710 ms

64 bytes from 142.250.200.46: icmp_seq=3651 ttl=115 time=28.056 ms

64 bytes from 142.250.200.46: icmp_seq=3652 ttl=115 time=23.141 ms

64 bytes from 142.250.200.46: icmp_seq=3653 ttl=115 time=3888.180 ms

64 bytes from 142.250.200.46: icmp_seq=3654 ttl=115 time=2882.864 ms

64 bytes from 142.250.200.46: icmp_seq=3655 ttl=115 time=1878.623 ms

64 bytes from 142.250.200.46: icmp_seq=3656 ttl=115 time=883.653 ms

64 bytes from 142.250.200.46: icmp_seq=3657 ttl=115 time=22.718 ms

64 bytes from 142.250.200.46: icmp_seq=3658 ttl=115 time=22.994 ms

64 bytes from 142.250.200.46: icmp_seq=3659 ttl=115 time=23.203 ms

Hub logs don't show anything.  Set up today at: Thinkbroadband Monitor 

I've ordered a WiFi pod but no longer think this will fix it.  I'm also open to signing up to WiFi Max.  Any thoughts?

[Steveburnley1]

Mine keep dropping to especially today and yesterday, woke up with all green flashing lights on my hub 3 and restarted it. It goes OK then slow then OK again and slow, not sure what the deal is here 

[Client62]

WiFi Max only a marketing term for shared SSID + Auto Channel selection / Channel optimization.

Our Hub's Wi-Fi is far more stable with Channel Optimization Disabled and with manual selected channels on both bands and with the no longer used legacy Wi-Fi modes earlier than 802.11n Disabled.

[bph2]

Thanks @client62 - will try that.  QQ: what tool did you use to select the best channel?  And have you disabled 2.4Ghz to get better results too?

[Client62]

Try a free WI-Fi analyser on a dual band mobile, they are all much the same is showing graphs of channel usage and lists of access points showing the makers names and encryption modes.

For 5Ghz, we use Channel 44 with a 20/40 Mhz bandwidth, we have no kit that show any improvement with 80Mhz enabled.

We have two of 2.4Ghz Wi-Fi access points + the VM Hub so we use Channels 1, 6 &11 all on 20Mhz bandwidth, in a larger property with many solid internal walls the extra indoor and outdoor range of the 2.4Ghz band is very handy for supporting Wi-Fi calling & Whatapp / Messanger calls where a robust connection is more important than higher bandwidth.

Note VM have a Wi-Fi policy that re-enables both 2.4 & 5 Ghz bands for VM Hubs in Router mode, disabling Wi-Fi band(s) is possible for a period, but expect in hours to days the band(s) will re-enable.

[bph2]

Thanks @client62.  I found the macOS Wireless Diagnostics app is pretty good.  

The change to manual channel selection and optimisation turned off has improved it.  No difference with 2.4Ghz off.  I'm still seeing a regular blip with Tx to 0Mbps RTT increase, albeit smaller... any idea what could be causing this?

64 bytes from 172.217.16.238: icmp_seq=4398 ttl=115 time=22.378 ms

64 bytes from 172.217.16.238: icmp_seq=4399 ttl=115 time=29.322 ms

64 bytes from 172.217.16.238: icmp_seq=4400 ttl=115 time=27.703 ms

64 bytes from 172.217.16.238: icmp_seq=4401 ttl=115 time=20.313 ms

64 bytes from 172.217.16.238: icmp_seq=4402 ttl=115 time=1471.992 ms

64 bytes from 172.217.16.238: icmp_seq=4403 ttl=115 time=471.694 ms

64 bytes from 172.217.16.238: icmp_seq=4404 ttl=115 time=22.843 ms

64 bytes from 172.217.16.238: icmp_seq=4405 ttl=115 time=25.258 ms

64 bytes from 172.217.16.238: icmp_seq=4406 ttl=115 time=26.925 ms

64 bytes from 172.217.16.238: icmp_seq=4407 ttl=115 time=27.361 ms

64 bytes from 172.217.16.238: icmp_seq=4408 ttl=115 time=24.951 ms

64 bytes from 172.217.16.238: icmp_seq=4409 ttl=115 time=22.541 ms

64 bytes from 172.217.16.238: icmp_seq=4410 ttl=115 time=25.401 ms

64 bytes from 172.217.16.238: icmp_seq=4411 ttl=115 time=21.753 ms

64 bytes from 172.217.16.238: icmp_seq=4412 ttl=115 time=22.921 ms

64 bytes from 172.217.16.238: icmp_seq=4413 ttl=115 time=24.108 ms

64 bytes from 172.217.16.238: icmp_seq=4414 ttl=115 time=23.222 ms

64 bytes from 172.217.16.238: icmp_seq=4415 ttl=115 time=22.591 ms

64 bytes from 172.217.16.238: icmp_seq=4416 ttl=115 time=25.921 ms

64 bytes from 172.217.16.238: icmp_seq=4417 ttl=115 time=68.159 ms

64 bytes from 172.217.16.238: icmp_seq=4418 ttl=115 time=28.201 ms

64 bytes from 172.217.16.238: icmp_seq=4419 ttl=115 time=23.863 ms

64 bytes from 172.217.16.238: icmp_seq=4420 ttl=115 time=28.394 ms

64 bytes from 172.217.16.238: icmp_seq=4421 ttl=115 time=24.264 ms

64 bytes from 172.217.16.238: icmp_seq=4422 ttl=115 time=22.453 ms

64 bytes from 172.217.16.238: icmp_seq=4423 ttl=115 time=24.832 ms

64 bytes from 172.217.16.238: icmp_seq=4424 ttl=115 time=1189.603 ms

64 bytes from 172.217.16.238: icmp_seq=4425 ttl=115 time=186.048 ms

64 bytes from 172.217.16.238: icmp_seq=4426 ttl=115 time=34.806 ms

64 bytes from 172.217.16.238: icmp_seq=4427 ttl=115 time=39.614 ms

64 bytes from 172.217.16.238: icmp_seq=4428 ttl=115 time=26.088 ms

64 bytes from 172.217.16.238: icmp_seq=4429 ttl=115 time=25.288 ms

64 bytes from 172.217.16.238: icmp_seq=4430 ttl=115 time=27.322 ms

64 bytes from 172.217.16.238: icmp_seq=4431 ttl=115 time=23.308 ms

64 bytes from 172.217.16.238: icmp_seq=4432 ttl=115 time=24.245 ms

64 bytes from 172.217.16.238: icmp_seq=4433 ttl=115 time=26.866 ms

64 bytes from 172.217.16.238: icmp_seq=4434 ttl=115 time=26.903 ms

64 bytes from 172.217.16.238: icmp_seq=4435 ttl=115 time=22.831 ms

64 bytes from 172.217.16.238: icmp_seq=4436 ttl=115 time=23.706 ms

64 bytes from 172.217.16.238: icmp_seq=4437 ttl=115 time=32.882 ms

64 bytes from 172.217.16.238: icmp_seq=4438 ttl=115 time=30.676 ms

64 bytes from 172.217.16.238: icmp_seq=4439 ttl=115 time=23.922 ms

64 bytes from 172.217.16.238: icmp_seq=4440 ttl=115 time=21.451 ms

64 bytes from 172.217.16.238: icmp_seq=4441 ttl=115 time=23.683 ms

64 bytes from 172.217.16.238: icmp_seq=4442 ttl=115 time=26.847 ms

64 bytes from 172.217.16.238: icmp_seq=4443 ttl=115 time=27.083 ms

64 bytes from 172.217.16.238: icmp_seq=4444 ttl=115 time=30.083 ms

64 bytes from 172.217.16.238: icmp_seq=4445 ttl=115 time=22.788 ms

64 bytes from 172.217.16.238: icmp_seq=4446 ttl=115 time=913.862 ms

64 bytes from 172.217.16.238: icmp_seq=4447 ttl=115 time=24.450 ms

64 bytes from 172.217.16.238: icmp_seq=4448 ttl=115 time=33.602 ms

[Mr_Angry]

I wish I understood ANY of this!

[bph2]

OK update on this - issue is still occurring with the above setting changes.

Interestingly, when modifying the default SSID and changing security to WPA2/3 the 5Ghz channel never gets connected, even when I'm sitting next to the hub5...

This looks like it's coming down to crappy hub5 WiFi tech.  Virgin Media engineers looking for your guidance else figure I need to switch off hub5 router & WiFi and get an independent device... 

[Client62]

Using the Hub 5 in Modem mode with a 3rd party Wi-Fi Router may be the only route to stability and sanity.

[bph2]

Yep that's where I'm at.  Thanks for your messages.  Much, much better WiFi performance around the house now with the Google WiFi Pro and not getting the regular WiFi Tx drops.  So testing the cable service for performance from here on in hoping the regular dropouts are not coming from the broadband network...