Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[boogy]

hi iMx

As you know, I'm on zen too. If there is a straightforward way to get a summary of traffic (bandwidth) passing over udp and tcp ports plus a way to generate udp traffic, I'd be happy to try that and see if the same phenomena happens here.

Cheers

[iMx]

It's a bit of a tricky one, I have both of my FTTC lines (1 Zen 1 BT) in separate routing domains on the same router (so multiple default routes exist and can exist in their own routing domain), this allows me to start programs/services/daemons in a specific routing domain (as the router is effectively a 'PC' running BSD) so I *know* that is the only traffic being generated and going out over the that line.

You could see the UDP/TCP traffic with something like wireshark or tcpdump, however analysing the data to find out the percentage of UDP vs TCP would be difficult.  Similarly, trying to generate valid UDP traffic back and forth (i.e not just a plain DoS, firing out random UDP traffic) would be difficult, other than Torrents of course (a Linux ISO or something legal), as any other devices on your network are likely to generate some TCP traffic (checking into Microsoft update, or similar, background refreshing/loading web pages etc). :-/

Am awaiting, hopefully, my daily call back from the Zen chap I've been dealing with - he set up monitoring on his end, so I'm hoping he can see that things have deteriorated drastically - or had until I stopped the OpenVPN UDP tunnel and only started loop downloading a file over HTTP (TCP).

[boogy]

ok keep us posted. If you get the chance, have a look at this page which has a number of testing tools available:

http://www.windowsnetworking.com/articles-tutorials/netgeneral/network-throughput-testing-tools.html

[iMx]

iPerf is one option I've used many times before, you can burst both UDP and TCP with that, but you'd need a remote server somewhere to test with.

[iMx]

Interface was up with an infinite loop downloading a Linode speedtest file over HTTP for over 5 hours, within 30 minutes of re-enabling the OpenVPN UDP interface (so only UDP traffic was going out to Zen) the PPP bouncing started again.

Disclaimer: Yes, I accept it could be coincidence....again

[iMx]

Latency was good through the Andy Murray match - PPP was reasonably stable throughout the day, even with a UDP OpenVPN tunnel, stayed up for 5 hours, has just gone down hill in the last 30 minutes with at least 4 term-reqs from the remote end.

May or may not be related, problems started more or less 24 hours after I restarted the OpenVPN UDP tunnel - restarted it yesterday evening about 9PM-ish, had one reset shortly after doing so, then remained stable-ish (i.e 4-5 hours) until now.

[iMx]

PPP continued to reset pretty much every 5-6 minutes for the last hour, bringing down the OpenVPN UDP tunnel and restarting the infinite loop HTTP (TCP) download from Linode.

2nd FTTC line (BT) at the same premises, running exactly the same OpenVPN UDP tunnel, up for 4 days on PPP - was a manual restart even then.

[iMx]

Looped HTTP download (no OpenVPN UDP tunnel) ran without a PPP drop for around an hour, starting the OpenVPN UDP tunnel again I get a PPP reset within 5-6 minutes.  PPP has been reset 4 times so far, again every 5-6 minutes.

Either there is a new chipset bug somewhere (that impacts both HG612, TG589, ECI but only on Zen lines), or Zen (?) have something running to analyse the protocols over the line potentially over a 24 hour period, running every 5 minutes, then resetting if there is X amount/percentage of UDP vs TCP traffic.  Others with similar problems probably see the resets as almost random, however as I can/have tested with 100% either UDP or TCP (but never both at the same time) can exacerbate the problem.  I do however suspect that this is only done at certain times, or perhaps when certain load is seen in general on their network.

The above is about the only conclusion I can draw from what I have seen.... But maybe I'm looking for conspiracy that isn't there.

[iMx]

With the UDP OpenVPN tunnel up resets are almost like clockwork this evening - started at around 14:20, next at 16:20 then... you guessed it..18:20.  Every 2 hours almost to the minute, give or take a couple.

[iMx]

Now, I'm probably going to jinx myself... but I appear to be heading for the second 24 hour PPP session since migrating this line to Zen, previous got to around 3 days from memory, currently at around ~22 hours.  Nothing changed on my end, last reconnection around midday yesterday (Friday) put me on DSL1 - don't recall being on that gateway for a long time, but more than likely have with the amount of reconnections.

Only thing that 'changed' yesterday was throwing a little tantrum, after around a week of 10-20 PPP term-reqs sent from the remote end per day, either asking to be allowed to leave my contract with Zen with no early termination charges and allow us all to get on with our lives, or issue me a deadlock letter so we can go to arbitration early as whatever the cause Zen have - to date - been unable to solve or advise what is causing it.

Attached f8lure graph is quite interesting, line migrated to Zen at around 08:00 - up until this point there is the odd bit of packet loss, normal, then from 8am onwards the longer red lines indicate PPP term-reqs, the thicker longer red lines are where multiple termreqs were received in quick succession, then at around 21:00 I gave everything a 'timeout' and powered off the modem for an hour, just to see if anything changed.  Nothing did.

UPDATE: Got to 1 day and around 1.5 hours, then term-req came.

[iMx]

Case has now been escalated to the head of the NOC, currently no explanation for the term-reqs - only suggestion given was that this would happen if the echo request/response was not processed, however from my logs this completes 4 seconds prior to the term-req coming down the line (and no signs of any drops/timeouts on my end).

Frequency has tailed off a bit, however at Zen's request I swapped out the TG589 (as apparently they have/had seen some strange goings on when in bridge mode, although it happens in router mode as well for me when running the OpenVPN UDP tunnel) for an HG612 this morning - term-reqs have been roughly every 2 hours, give or take 10-15 minutes, since the swap.  I was however initially running an HG612 (and ECI) when I first encountered this problem, before even using the TG589, but swap was done any way...

[tickmike]

Use   'Nmap'          https://nmap.org/     to scan your line.

[iMx]

Use   'Nmap'          https://nmap.org/     to scan your line.

This would show which Layer 4 ports are open?  tcpdump is what is needed, which is what was used

[iMx]

Was advised today that it had been escalated to 'one of the main NOC guys' - just checking a few things now, LCP echo requests seem to be coming every 10 seconds (this matches my BT FTTC line), checking my earlier dumps/captures they were every 3 seconds...

Now, from the logs the term-req was sent around 4 seconds after the last echo LCP request/response - could this be the problem?  One going missing at 3 seconds, then resetting at 4 - either some loss somewhere (but remember modem sync remains), or an overloaded device generating the echo requests (which could fit with me seeing massive deterioration during Andy Murray/Wimbledon), or simply a little to frequent for real world use? 

Will see what Zen come back with tomorrow and I'll raise it with them then.

[iMx]

Nope - LCP interval still seems to be 10 seconds this morning, but I've had 3 term-reqs in the last few minutes from around 08:30 - modem sync still rock solid.