Beginning to again suspect Zen do something funky when the traffic seen is all UDP (or even primarily UDP), the moment I enable an OpenVPN UDP tunnel PPP starts getting reset again - between 1 and 20 minutes - traffic is generally pretty low, 10-100K/S, apart from the odd burst when rsync backups happen. So, I shut down the OpenVPN tunnel on the Zen routing domain and then loop downloaded a 100M speedtest file from Linode, so all traffic is TCP (other than maybe the odd DNS request).....PPP stays up.

It is interesting that the days I saw latency problems there were no PPP resets, after they did maintenance on DSL4 (confirmed) latency improved but the PPP resets started again. I have absolutely nothing concrete to back this up, but I'm beginning to wonder if there is something load-balancing-wise on their end that was disabled for a few days, latency gets worse, they re-enable it and I'm back to the PPP resets when most traffic is UDP. Are they potentially seeing it as P2P/Torrent traffic and trying to move me around to cope with the additional load of Wimbledon?!

Whilst it could be a coincidence, this started again yesterday afternoon about 14:00 when latency started to increase again - this was when Andy Murray was playing, things went mad last time he was playing in the tournament.

That is indeed super strange.

What happens if you bring the PPP interface up and send no IP traffic what so ever on it? Do Zen still disconnect you due to some time out being reached due to no traffic being sent?

This is not something I would expect them to do, but possibly this scenario is never reached nowadays because of general traffic noise that most networks now generate (NTP syncing, DNS lookups etc).

Edited by deleted (Thu 09-Jul-15 13:42:01)

Hi there,

If I connect the PPPoE interface and send no traffic, I mean no traffic as it is in its own routing domain with no daemons/services started, it stays up.

If I then loop a wget download from Linode, HTTP/TCP, it still stays up....

My conclusions (with nothing really to back them up, other than what I've seen) is that either they're trying to shift around heavy UDP traffic, or they're ignoring the LCP echo request/reply for the health check and check instead on seeing TCP traffic... for which there would be none at all when the OpenVPN tunnel is up.

Cheers,

Perhaps?

https://aastatus.net/1854 (and revK's link).

Right.

Ok, next couple of tests I would now try are:

1) Bring the interface up fresh and send just a single UDP packet out of the connection. Wait for it to drop/remain up.

2) Bring the interface up fresh and send just a single TCP packet out of the connection. Wait for it to drop/remain up.

It is indeed looking like what you are suggesting. It may just be the case that you'll have to cronjob some netcat open port test (nc -z ip port on Linux) to generate some kind of TCP traffic so they don't terminate the link. I would be interested to know the outcome of the above 2 tests though.

In reply to a post by camieabz:

Perhaps?

https://aastatus.net/1854 (and revK's link).

No, this is different - no ports are blacklisted and the reset *is* coming from the remote MAC, not just dropped. I'm also not using an HG612 at the moment.

I have however tested with HG612 (unlocked and fully updated, so would/should be patched), ECI modem, ECI modem running OpenWRT and a TG589v3.

Edited by deleted (Thu 09-Jul-15 13:57:17)

In reply to a post by mixt:

It is indeed looking like what you are suggesting. It may just be the case that you'll have to cronjob some netcat open port test (nc -z ip port on Linux) to generate some kind of TCP traffic so they don't terminate the link. I would be interested to know the outcome of the above 2 tests though.

If that is the case, I will be seeking contract cancellation and likely just going to A&A again....after the amount of time spent on this in the last week or so, I'll deal with the prices.

To be fair to Zen, I finally have a chap on the case who seems to have a natural geeky-curiosity-for-the-unexplained...something I was struggling with originally with people I spoke to @Zen, especially when told to wait and see if it happens again.

Am going for a walk for a bit, will run some of the tests mentioned above later on.

Edited by deleted (Thu 09-Jul-15 19:11:37)

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 all traffic out to the ISP was UDP) the PPP bouncing started again.

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

Edited by deleted (Thu 09-Jul-15 21:05:06)

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.

Edited by deleted (Fri 10-Jul-15 21:33:58)

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.