Vodafone Sure Signal

[thermionic]

There isn't a problem with PPPoE. With the right hardware the SS works perfectly over a PPPoE Internet connection.

We need to stop talking about PPPoE and PPPoA as it just confuses those poor souls in Vodafone tech support.
H2 more things to be added to "What I know" :-

The SS DOES work over a PPPoE Internet connection as well as a PPPoA based one. (oops, I mentioned the dreaded PPP thing again)

The SS does NOT necessarily work over a connection that works perfectly with other IPSEc VPNs.

I agree that the PPPoE part is a partial red herring, but as I'm sure you're aware different IPSec Implementations have different requirements and just because one (or many) work does not mean that all will, hence my request that Vodafone explain exactly what the VSS requirements are, or why it will not work over a link that has a PPPoE section

[UKenGB]

I agree that the PPPoE part is a partial red herring, but as I'm sure you're aware different IPSec Implementations have different requirements and just because one (or many) work does not mean that all will, hence my request that Vodafone explain exactly what the VSS requirements are,

Of course. I just wanted to point out that use of IPSec alone is not the cause of the problem.

or why it will not work over a link that has a PPPoE section

Be careful how you phrase that. It sounds like you're saying PPPoE will cause it to fail, but this is demonstrably not the case. There are documented examples on this forum of the SS working perfectly over PPPoE. The problem seems to occur when a PPPoE/PPPoA bridge is used, but I cannot say for sure this is 100%. There will undoubtedly be other (possibly unrelated) problems and maybe it's possible for that bridging to work, but I don't know of any hardware other than the Vigor 100/120 that can perform PPPoE to PPPoA bridging. Those that purport to do so are usually actually referring to PPPoEoA, but we don't want to go there.

[thermionic]

They are making a claim without any backup or reference. I'm quite happy for them to make the claim, as long as they provide the reference for us to understand the "why"

If they came back and said that the RPY needed to be at least 78 in combination with the HGT no more than 276, and that most PPPoE implementations would not provide this, it would at least provide us with something to investigate further, or go back to manufactures with and ask if their equipment can be tuned to provide it. RPY and HGT are of course made up three letter acronyms, not real one :-)

Instead there is this blanket "it will not work" passed on to us by people that that appear to be simply repeating what they have been told with no comprehension, and because of their lack of comprehension, a question that we might ask can be subtly and unknowingly changed to have a very different meaning, such as the previous answer that the VSS does not support PPPoE, when this question was not asked.



So my previous comes from trying to ask a question that Vodafone cannot misinterpret.

perhaps "or why Vodafone claim that the VSS will not work over a connection that has a PPPoE section non adjacent to the VSS" might be even better.

[s4vva]

Just wanted to put this one to bed;

As you all know I have tested several routers with the PPPoE connection and couldn't get the SS to work. I have since ordered a secondary PPPoA connection, same routers, same settings and the SS works.

I would say that is quite conclusive that the SS does not like PPPoE.

And for anyone that is interested I tested Linksys, Netgear and Draytek (2800 & 2820) routers. Currently running a Draytek 2820 with both connections (load balanced) with the SS only using the PPPoA connection. Life is good now, shame Vodafone support isn't.

[UKenGB]

Just wanted to put this one to bed;

As you all know I have tested several routers with the PPPoE connection and couldn't get the SS to work. I have since ordered a secondary PPPoA connection, same routers, same settings and the SS works.

I would say that is quite conclusive that the SS does not like PPPoE.

I don't know how many times I have to say this, but the problem is not PPPoE. There are people on these forums who use PPPoE from their router to their provider and the SS works perfectly. I say again, it is NOT PPPoE. The SS knows NOTHING about how it's packets get transmitted apart from the fact it sends them out onto an ETHERNET network. It's like saying I don't like sending letters via the motorway when the truth is I have no knowledge of or need to know the actual roads over which my letter is transported. However, there might be an issue with a motorway being closed for some reason and that preventing my letter from getting through, but that doesn't mean the post doesn't work over motorways. Use a different motorway and everything works.

As to what the real reason is for the SS failing to work in some situations, still no answer from Vodafone who are being suspiciously silent on the matter. Same as Draytek in fact who have nothing to say about why their Vigor 120 causes the problem.

[thermionic]

I concur, until VF can provide a reason to back up their claim, then the claim is spurious

[s4vva]

I don't know how many times I have to say this, but the problem is not PPPoE. There are people on these forums who use PPPoE from their router to their provider and the SS works perfectly. I say again, it is NOT PPPoE. The SS knows NOTHING about how it's packets get transmitted apart from the fact it sends them out onto an ETHERNET network. It's like saying I don't like sending letters via the motorway when the truth is I have no knowledge of or need to know the actual roads over which my letter is transported. However, there might be an issue with a motorway being closed for some reason and that preventing my letter from getting through, but that doesn't mean the post doesn't work over motorways. Use a different motorway and everything works.

As to what the real reason is for the SS failing to work in some situations, still no answer from Vodafone who are being suspiciously silent on the matter. Same as Draytek in fact who have nothing to say about why their Vigor 120 causes the problem.

I don't know why you have this attitude, you can say it as many times as you like. It won't change the fact that the SS does not work on three routers on a PPPoE connection, when the connection is changed to a PPPoA connection and the remaining router settings are left the same the SS works.

Your analogy is poor and irrelevant. You probably know already but there are differences between the two connections mentioned e.g. MTU size being just one. These differences could easily (and quite obviously in my case) have an impact on the functionality of the SS.

I am not saying that the SS will never work with PPPoE but my experience tells me that it is less likely to work with PPPoE than PPPoA, and as such potential buyers should be aware.

[fundutzi]

This post may be related here.

[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  

[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.

[squirrel_nutkin]

BT came 2 weeks ago and upgraded my home adsl line (was creeking under the wait of line loss parameters) to BT Infinity.

They provided a BT Home Hub3 with blue lights to boot, very nice! and a new cream coloured vdsl modem/interface box with 2 ethernet outs. The line speed is now terrific but my VSS does not work anymore. This only happen after I disconnected it and reconnected it again. (normally you leave it running etc) The new Home Hub connects to the Modem using PPPoE.

So I changed back to my old Linksys WRT320n Adsl router (it has the ability to use Ethernet Plug position1 at the rear as a WAN port. Connecting this to the Modem over PPPoE (password needed for BT Infinity to work) still resulted in VSS not working.

I have also experience a problem at another site where VSS was working until we added a Managed Communication/Daisy Comms Bonded adsl solution. The output from the Bonded adsl is PPPoE,via Cisco 1841 router.

There is also a  BT adsl line and router (same segment) uses a BT adsl 2wire router that I use for  DHCP but Inow  route all traffic (lower metric value) out over the Bonded adsl because it is faster,  However I can't force the VSS to use the adsl line (as they are not unconfigurable) so it automatically goes out throught the linked PPPoE, hence they won't work.

I must admit it has been a frustrating time recently as this was baffling me until finally I find all this information about other users having issues with PPPoE, now I begin to understand why things have gone wrong.

The trick is (as someone has already written) to power on the VSS when there is an adsl connection and then switch over to PPPoE,  I suspect that this issue is a Setup negotiation process issue, so once a VSS link has become established, they will continue to work over PPPoE until the power is disturbed or because of some other interuption, perhaps server down at Vodafone HQ. Anyway, these are my findings, but nothing more. Hope this helps!

[RichNewman]

Well, a couple of days ago I tried my SureSignal on my (small packet size) PPPoE connection. It seems that since the latest firmware updates, it now works fine!

NOTHING has changed at my end. Same modem, same network, same ISP, same everything. Now works. Great.

[Majik]

It's still not working for me.

[noodles2k]

try using an mtu of 1454.

[kingskintim]

Hi there,

just to add my set up, I'm using a SonicWall ISA which connects to LLU via PPoE. I have all the correct ports forwarded and cant connect the VSS. I talked to support who remotely connected to my Router only to say " you probably know more about it than me" - great. (he was right on that front however). So I'm stuck with a poor signal in my office, and a £50 box which does nothing other than frustrate me.

tim 

[noodles2k]

is the SW connected to a vpn?