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.

Edited by deleted (Fri 10-Jul-15 23:14:57)

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.

In reply to a post by iMiMiMx:

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.

Why would they do this?

In reply to a post by rippedcotton:

In reply to a post by iMiMiMx:

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.

Why would they do this?

Hypothetically, to move/balance suspected P2P/Torrent users - again, I have nothing to back this up, but I would imagine the large majority of UDP traffic over an ISP such as Zen will be torrent traffic... Just not in this case.

In reply to a post by iMiMiMx:

In reply to a post by rippedcotton:

In reply to a post by iMiMiMx:

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.

Why would they do this?

Hypothetically, to move/balance suspected P2P/Torrent users - again, I have nothing to back this up, but I would imagine the large majority of UDP traffic over an ISP such as Zen will be torrent traffic... Just not in this case.

As far as I'm aware, UDP is mostly only used with Bittorrent for connecting to the trackers. This is probably relatively low traffic levels. The actual downloads themselves take place over TCP.

Dropping UDP traffic makes no sense. Typically real time traffic is transported via UDP, such as VoIP. Throttling this would cause massive issues for anyone using something like this. Traffic shaping is done by dropping TCP packets, as these actually scale back upon congestion being encountered using Sliding Window. Dropping UDP packets would typically not cause UDP to scale back what it is sending, and therefore not cause the desired effect of causing traffic flows to slow down the sending of data.

Incidentally, 84:26:2b:a2:3c:da is an Alcatel-Lucent MAC address.

A job spec for them does not list Alcatel-Lucent as a required vendor. They do list Ericsson (formally Redback) however, which are a LNS vendor. It is likely that they are terminating your session on these.

I know (but can't provide evidence) that BT run Alcatel-Lucent's in their network. It looks like it is actually them that are pulling the session down for whatever reason. It would be interesting to find out what Zen are seeing as the session termination cause for your drops.

In reply to a post by Geordish:

As far as I'm aware, UDP is mostly only used with Bittorrent for connecting to the trackers. This is probably relatively low traffic levels. The actual downloads themselves take place over TCP.

This used to be the case before uTP was developed. Torrent traffic, both tracker and data transfer, now happens across UDP (using uTP transport protocol, which is BitTorrent specific protocol). That has timing information and all sorts of clever tricks to detect congestion, allowing clients to throttle back (at the application layer of the network stack) in order to not flood network links.

In reply to a post by Geordish:

Dropping UDP packets would typically not cause UDP to scale back what it is sending, and therefore not cause the desired effect of causing traffic flows to slow down the sending of data.

Again, per my above comment, uTP does scale back when detecting dropped packets, as it then sees that as a congested link. The protocol is specifically designed to make all this possible.

Further reading here: https://en.wikipedia.org/wiki/Micro_Transport_Protocol

Edited by deleted (Tue 14-Jul-15 15:36:18)

In reply to a post by Geordish:

In reply to a post by iMiMiMx:

In reply to a post by rippedcotton:

... nested quotes trimmed ...

Why would they do this?

Hypothetically, to move/balance suspected P2P/Torrent users - again, I have nothing to back this up, but I would imagine the large majority of UDP traffic over an ISP such as Zen will be torrent traffic... Just not in this case.

Dropping UDP traffic makes no sense.

I didn't say they were dropping UDP traffic, far from it, more that the ratio of UDP vs TCP was a potential catalyst for the PPP session being terminated from the remote end.

But, I have nothing to prove this conclusively - only that when I was seeing the regular resets I could more or less make it happen (or stop) simply by changing the predominant protocol. On Saturday night for example I would have been able to set my watch by it and it stopped pretty much bang on midnight.

In reply to a post by mixt:

In reply to a post by Geordish:

As far as I'm aware, UDP is mostly only used with Bittorrent for connecting to the trackers. This is probably relatively low traffic levels. The actual downloads themselves take place over TCP.

This used to be the case before uTP was developed. Torrent traffic, both tracker and data transfer, now happens across UDP (using uTP transport protocol, which is BitTorrent specific protocol). That has timing information and all sorts of clever tricks to detect congestion, allowing clients to throttle back (at the application layer of the network stack) in order to not flood network links.

I was aware of uTP, but I wasn't aware of how far deployed it is. I've just examined traffic on the network I operate (which isn't a typical network) and I'm seeing a ratio of roughly 5000:1 in favour of TCP for bittorrent transfers (That we can detect)

In reply to a post by mixt:

In reply to a post by Geordish:

Dropping UDP packets would typically not cause UDP to scale back what it is sending, and therefore not cause the desired effect of causing traffic flows to slow down the sending of data.

Again, per my above comment, uTP does scale back when detecting dropped packets, as it then sees that as a congested link. The protocol is specifically designed to make all this possible.

Further reading here: https://en.wikipedia.org/wiki/Micro_Transport_Protocol

Hence my use of the word typically. The client could (and allegedly does for uTP) implement parts of TCP that would make it detect congestion and scale back. This is not typical however. In general dropping UDP would not cause the protocol using it to scale back, and would not alleviate congestion. Zen dropping UDP traffic to limit traffic going across their network would be daft.

Additionally Zen claim not to do any traffic shaping.

You seem to be caught up on dropping UDP traffic, I did not say that is what they did - you've misunderstood. The PPP/PPPoE session itself is reset, please check the tcpdump earlier on in this thread.

Edited by deleted (Tue 14-Jul-15 17:36:38)

Dropping a PPP session makes even less sense (from a traffic management perspective). You're just going to reconnect and continue your UDP transfer.

While it does sound like something is going in, I would doubt it is intentionally malicious.