on 26-10-2022 10:54
We upgraded to Volt Gig1 recently and replaced Hub 3 with Hub 4. We now have noticeable packet loss at certain times of day.
I've been using Think Broadband's Broadband Quality Monitor to keep track. Here's a link to the live graph.
This is an example of a bad day on 24th October 2022. The red at the top of the chart is packet loss with the axes on the right hand side. More red = higher packet loss:
Nearly 20% lost packets for a period in the morning and a smaller loss in the afternoon.
This was one the week before on 18th October:
Similar problems in the morning and afternoon.
Please could someone check my connection and let me know if there is anything I can do to resolve this? Thanks
on 07-11-2022 08:15
Hi @Paul_DN, thanks for checking in. Unfortunately I'm still having intermittent problems. Here are days from last week with issues:
Tuesday 1st November
Friday 4th November (with router restart at about 8am)
I've rebooted the router this morning as well and I'm looking at options for monitoring my home network traffic so that I can see if there is a device on my network that is getting greedy and overwhelming the connection at these times. Any suggestions for that or any other ideas gratefully received.
Thanks also for checking in @legacy1, Sunday was one of the few days with no problems🤓. It's interesting that my problems almost always seem to coincide with video calling. I'm wondering if something about that kind of traffic is either causing the problem itself or highlighting an underlying problem.
11-11-2022 08:27 - edited 11-11-2022 08:28
There was high packet loss on Monday, Tuesday & Thursday this week. I restarted the router on Monday morning and Tuesday morning, but as it doesn't seem have made much difference I didn't make it a regular thing.
Monday 7th November
Tuesday 8th November
Thursday 10th November
I'm planning on doing some selective device switching off over the coming days to see if there is something on my home network that is causing problems. I've been wondering if it could be linked to bandwidth usage. Does anyone know if it is possible to get utilization data from the Hub 4?
on 13-11-2022 14:13
Thank you for your reply.
Have you been able to run the checks listed in your last message?
If so, have these helped at all?
Please do let us know and we will be happy to assist further.
Thanks,
on 15-11-2022 08:55
Hi @Natalie_L,
On Saturday morning I switched off a lot of devices, but it doesn't seem to have made a difference. We still experienced high rates of packet loss on Saturday & Sunday .
Sunday (with a router reboot early afternoon)
I have been trying to use the IGD stats on the router to track usage, but I don't think they work on the Hub 4. I've used a simple bash/curl script to query the ByteReceived every second and give a total and difference which should roughly work out to be the bytes/second, but the figure doesn't seem to vary with usage.
Here's a screen cap during a speed test. There's very little variation in the rate that the figure is changing.
I also found that the figures are 32 bit integers and overflow after a couple of days anyway. The only way I found to reset them to 0 is to restart the router. Is there a firmware update for the Hub 4 that I can get that might fix this?
Here's the script in case anyone wants to try and reproduce. I don't know if the port on the hub is the same for everyone. You'll need to restart your router to get the figures to start at zero. If your router has been switched on for a while you'll just get a total figure of 2147483647 and no delta at all.
while sleep 1; do NEW_TOTAL=$(curl -s --location --request POST 'http://192.168.0.1:49152/upnp/control/WANCommonInterfaceConfig0' --header 'Content-Type: text/xml' --header 'SOAPAction: "urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1#GetTotalBytesReceived"' --data-raw '<?xml version="1.0"?><s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><u:GetTotalBytesReceived xmlns:u="urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1"></u:GetTotalBytesReceived></s:Body></s:Envelope>' | grep -oPm1 "(?<=<NewTotalBytesReceived>)[^<]+"); echo "Total: $NEW_TOTAL @ $(( NEW_TOTAL - TOTAL)) bytes/second";TOTAL=$NEW_TOTAL;done
I think the next thing I'm going to try is building an OpenWRT device, switching the hub to modem mode and use OpenWRT as the gateway. Hopefully I'll be able to get more info out of OpenWRT and track down the cause of my issues.
15-11-2022 10:06 - edited 15-11-2022 10:27
Hi Natalie_L,
I thought I had made a post, but it isn't here, so I must have forgotten to press "post" 😶🌴.
On Saturday morning I switched off a load of devices in the house, but it doesn't seem that any of them were the cause because Saturday and Sunday still had high levels of packet loss.
I've been trying to use the IGD stats from the Hub 4 to understand my usage, but I don't seem to be able to get any meaningful stats out of it. I've written a little bash/curl script to query the TotalBytesReceived every second and show the running total and the delta for the last second. However, running the script while doing a speed test at the same time doesn't appear to change the rate at which TotalBytesReceived increases each second.
The script is here in case anyone wants to try and reproduce. Requires bash with curl & grep installed. You may need to change the IP/port to match your router. (You can use this python script to find the IP/port of your local device: https://github.com/tenable/upnp_info).
while sleep 1; do NEW_TOTAL=$(curl -s --location --request POST 'http://192.168.0.1:49152/upnp/control/WANCommonInterfaceConfig0' --header 'Content-Type: text/xml' --header 'SOAPAction: "urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1#GetTotalBytesReceived"' --data-raw '<?xml version="1.0"?><s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><u:GetTotalBytesReceived xmlns:u="urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1"></u:GetTotalBytesReceived></s:Body></s:Envelope>' | grep -oPm1 "(?<=<NewTotalBytesReceived>)[^<]+"); echo "Total: $NEW_TOTAL @ $(( NEW_TOTAL - TOTAL)) bytes/second";TOTAL=$NEW_TOTAL;done
There seems to be at least one other bug with this implementation which is that the figures supplied are 32bit integers... which means when they reach 2,147,483,647 they stop increasing. If you try this and you're only getting that number, you'll need to restart your router to get it back to zero again.
The next thing I'm going to try is building an OpenWRT and switch the hub to modem mode. Hopefully I'll be able to get more information out of it and a better understanding of what's happening on my local network when these packet losses occur.
Cheers
on 17-11-2022 17:13
Hi @Onyx1811, thanks for the reply on the forums.
I'm sorry to see this issue occur with the connection.
After seeing the recent BQM graphs, this will require further investigating.
I will send a private message - watch out for the purple envelope inviting you in.
Kind regards,
Ilyas.