Vodafone Sure Signal - Is It Compatible With PPPoE Connections?

[s4vva]

After a long time testing and reconfiguring several makes of routers I have come the conclusion that the Sure Signal is not compatible with PPPoE connections.

If anyone does have it working please post the details here (router manufacturer, ISP etc.) I would love someone to prove me wrong!

@Vodafone - Are there any plans for a firmware/device upgrade that does support PPPoE?

[UKenGB]

There's a couple of posts I've seen around here where they have the SS working perfectly over PPPoE. It seems to be down to the individual hardware as to whether it works or not. I say again, it cannot have anything to do with PPP flavour used to make the connection as either should be passing the same data packets. If it isn't, it's down to the specific hardware.

You will notice that when a problem is raised on these forums, Vodafone representatives step in with a quick reply to say "most users have no problem" and then maybe follow up with a couple of lame responses if the thread continues, but when it gets to really sorting it out, they go strangely silent (or worse, mislead readers with technically inaccurate statements).

It's all very well discovering that the problem is with some hardware, but the truth is that the common factor with all these problem is the Sure Signal and that is down to Vodafone to face up to their responsibilities and put some effort into fixing it. Either that or they need to talk sternly to Sagem (the manufacturers) and get them to fix it. Either way, Vodafone are being particularly useless (which actually comes as no surprise).

[Retired-George]

Hi guys,

Thank you all for posting. To be honest, a lot of this thread is going over my head so I don't know the definite answers. I will seek clarification as to whether the Sure Signal works with PPPoE or not and get back to you when I know for definite.

George
eForum Team

[UKenGB]

Hi guys,

Thank you all for posting. To be honest, a lot of this thread is going over my head so I don't know the definite answers. I will seek clarification as to whether the Sure Signal works with PPPoE or not and get back to you when I know for definite.

George
eForum Team

The Sure Signal is ETHERNET and knows NOTHING about ANY PPP which stands for Point to Point Protocol and is used purely for end to end connections, unlike ethernet which is a networking protocol that allows multiple devices to connect together. There would be no point in the SS using any sort of PPP as it would need to hold all the login details and then be connected to your ISP taking up the entire Broadband connection which you could not then use for anything else - IOW utterly pointless.

Also the SS is known to work via PPPoE AND PPPoA connections to the Internet (i.e. as used by the local router to connect to the ISP), so the problem is not PPP per se, but the hardware providing the connectivity, some of which prevents the SS from working and rather than trying to convince every hardware manufacturer of these problematic devices to modify their product to ensure the SS works, it makes more sense for Vodafone to fix the SS so it works over ALL hardware - as it should.

[Retired-George]

Hi guys,

I've had word back from our Sure Signal project team. They've advised that the Sure Signal isn't designed to be used with PPPoE, in order to make it fully compatible a fundamental change in the actual Sure Signal hardware would be required, as such there are currently no plans to support PPPoE.

George
eForum Team

[Majik]

I've been looking at this, and have some observations.

Firstly, as stated, this is nto necessarily a direct incompatibility with PPPoE, but is a side-effect of using it, in some cases (but, oddly, not others).

If we look at the problem, it appears to be related to mismatched MTUs. Quite simply the ones Vodafone's servers are sending are too big for a PPPoE connection. However, it's not as simple as that as this *should* be handled gracefully.

The normal machanism for handling this is that, when the incompatible MTU is detected, an ICMP "fragmentation-needed" response is sent back which usually causes the sender to send smaller packets. I believe that, in the cases where PPPoE is working, this mechanism is working which leads me to suggest that the Vodafone servers are not at fault.

I believe the real problem is that these message are not being sent back. This could be for a number of reasons:

Firstly it might be the modem is blocking these. The oft-used Draytek devices have been blamed for this on a couple of occasions, including the analysis here: http://fkooman.wordpress.com/2011/01/22/draytek-vigor-120-as-router-without-nat-hack/ which concludes: "With blocking the fragmentation-needed ICMP response message, Path MTU Discovery breaks and remote hosts won’t be able to find out the MTU to your modem is actually only 1492 and not 1500. This results in a “black hole connection”"

I'm not so sure. I think the author here is seeing the symptom, not the cause. One reason for this belief is that, I find it highly unlikely that the Draytek bridge isn't transparent to the IP protocol which is, if you think about it, encapsulated within a PPP session between your router and the ISPs BRAS. To block ICMP responses in this way would require the device to act as a filtering PPP/IP proxy rather than a simple bridge. I really doubt that is the case.

My other reason for doubt is that I did some testing. I put a packet sniffer on the PPPoE connection (at the router end) and I observed that the first 1480 octets of some of the response packets from Vodafones servers were not getting through at all. In fact all I got was the final fragment with an offset=1480. The intial oversize packet was not there at all (even in a truncated form). In this case,my firewall would never have sent a "fragmentation-need" response because there was nothing to trigger such a response.

Also, if you think about it, at what point in the network should this response be generated? Surely it is at the point where the MTU drops to the lower value. The device at this point in the network should know the speed of all of the connections and should act accordingly. If it receives a packet which is too big for the downstream MTU, it should send the ICMP response.

In the case we have here, the device in question is going to be in the ISP's network, at the other end of the PPP connection. It's probably the ISPs BRAS.

So that leads me to think that the problem is not necessarily with PPPoE, or with Draytek modems, but with incorrectly configured BRAS devices. This would impact every UDP based protocol with large inbound packets (IPSEC and DNSSEC are two that spring to mind) but that's not many protocols, and that's probably why it's not been a big problem for most people: the incidence of people using both PPPoE and large-packet UDP protocols hasn't been enough to cause alarm bells.

So in the case where this does work, I'm tempted to blame the ISP rather than anything else, although there may be several factors at play (perhaps some routers are incorrectly negotiating the MTU in the PPP session).

ANYWAY

It also occurred to me that there may be any easy fix for this, as long as Vodafone are prepared to cooperate. That fix would be to manually set the MTU on the Suresignal VPN servers to a lower value. No firmware updates or anything else needed.

So, the question is, what do we need to do to get Vodafone to try this out. Personally I think it's in their benefit to sort this out, even ifit wasn't their fault to start with.

Cheers,

Keith

[hvdv]

Hi Keith! Interesting read! Do you think a similar problem could play at Sky users on mac encapsulated routing? Your explanation really is the only one that would make some sense as to why VSS would be so picky on a connection type in a layer it shouldnt care about.

[Majik]

Cant reply properly - vode forum broken

[Majik]

For some reason this forum is corrupting my replies, truncating much of them complaining of invalid html even though my html even though my posts are plain text

[hvdv]

Call the helpdesk I am sure you will learn that it is because your ISP uses red ethernet cables  :smileywink:

[Majik]

OK, I have a ,little more information on this (assuming the forum software lets me post it)

I have been told by someone who is using a PPPoE service with an MTU of 1500 octets (BT VDSL) that the large packets are being received by him (as two fragmemts). This contrasts with my service where I only receive the second fragment.

He also advised that the complete packet doesn't have the DF flag set. In this case there should be no iCMP response. the ISP router should simply fragment the larger packet and deliver it. This appears to not be happening. What seems to be happening is that this packet is simply discarded. This will happen for any packet which is larger than the MTU.

I conclude that, in my case (and probably in the case of most of the others having issues with this) the problem is within your ISPs network. I have raised a ticket with my ISP, and they basically came back with a "wont fix" response. I fully intend to change my service over to  a new ISP in the near future based on this.

However, I re-iterate that a simple fix for this appears to be to reduce the MTU on the VPN gateways at Vodafone's end.