Like many people here, I've been trying to get a SureSignal (v1 and v3) working with a BT broadband connection. Following extensive testing, I'm pretty sure I've identified the root cause - which, unfortunately, appears to be on BT's network.
Firstly, the internet connection from BT is provided over a standard phone line using either ADSL (for conventional broadband) or VDSL (for BT infinity).The connection is established using PPPoA or PPPoE - the former for conventional broadband, and the latter for infinity. The PPP connection allows data to be transferred between your router and a device inside BT's network - it is effectively a tunnelled connection. This connection has an MTU associated with it, which defines the maximum packet size that can be conveyed across the link.
For a standard wired Ethernet segment, the MTU is almost always 1500 bytes. For a PPPoE session, the MTU is usually set to 1492 bytes, as the PPPoE protocol has a 6-byte header, and the PPP protocol uses an additional two bytes. This means that the maximum packet size conveyed by the PPPoE connection is 1492 bytes.
In order to transfer more than 1492 bytes, it is necessary to split the packet into multiple parts, i.e. fragment it. The transmitting host will automatically try to determine the path MTU (i.e. the effective MTU between devices). It is possible to verify this under Linux using the 'tracepath' command. This works according to RFC 1191 - it sends a large packet to the remote host, and watches for any ICMP replies. If a router along the path can't transfer the packet, it will return an ICMP response indicating that the packet is too large, and that it requires fragmentation. Running the tracepath command from inside my network to a host on the internet correctly indicates that the path MTU of my infinity connection is 1492 bytes.
Now, if the same command is run from a host on the internet, the path MTU is reported as 1500 bytes. This indicates that the router that needs to reduce the size of the MTU is not sending the ICMP 'too large' response. The router responsible for sending this is the PPP concentrator on BT's network. It needs to send this response to allow remote hosts to correctly discover the path MTU, but for some reason, it doesn't. So we effectively have an internet connection that doesn't obey the rules.
Why does this matter? When the SureSignal attempts to establish communication with the Vodafone servers, it is trying to set up an IPSEC VPN. As part of the negotiation, the Vodafone server will try to send a certificate to the SureSignal. This is quite large, and results in a fragmented packet. The Vodafone server automatically splits the packet into 1500-octet chunks, as this is the MTU of the segment that the machine is connected to.
When the 1500-octet packet reaches the BT PPP concentrator, the packet clearly exceeds the 1492-byte MTU, and an ICMP 'too large' packet should be sent back to the Vodafone server. In turn, the server will reduce the packet size, and the packet will be sent through the PPP link successfully. However, as the ICMP response isn't being sent, the packet is too large to fit through the PPP tunnel, and is dropped by the BT PPP concentrator. How nice. We (on the customer side of the BT PPP tunnel) would never know - the packet simply wouldn't arrive. In fact, if you trace packets on this interface, you can see the final small fragment arriving - clearly useless without the previous packet data.
So the fix is simple: BT needs to make their concentrator return the ICMP response as per RFC 1191. This would allow the Vodafone server to reduce the packet size, and in turn the IPSEC VPN could be established between the Vodafone server and the SureSignal. Now - I've said it is simple but I really have no idea whether this is even possible - I don't work for BT, and have no knowledge of their configuration. However, it is a national issue, and they do need to fix it.
As to why some routers work and some don't: it is possible to change the MTU of the PPP connection to more than 1492 bytes. Setting the MTU to 1500 should work, as it will match the corresponding MTU on Vodafone's Ethernet segment. It doesn't fix the problem, but it does allow you to work around it. BT allows you to increase the PPP link MTU, but the PPP client needs to support RFC 4638.
However, there's another caveat: if (like me) you're trying to make this work on a conventional ADSL connection using a Vigor 120 ADSL modem, then you may be out of luck. The Vigor 120 essentially converts between PPPoE and PPPoA, allowing a router to connect to the BT ADSL network using PPPoE. The overhead of PPPoE means that setting the MTU of the PPP link to 1500 means that the MTU of the Ethernet segment connected to the modem needs to be set to 1508. This is known as a baby jumbo frame. If you can find a router that supports this (I'm using a MikroTik RouterBoard) then great - but unfortunately the Vigor doesn't support an Ethernet MTU of greater than 1500 bytes. I have identified another modem to try (D-Link DSL320B) but I have yet to experiment with it.
The long and short of it is: BT need to fix their broken implementation to send the correct ICMP response for packets which exceed the PPP MTU. Vodafone could theoretically reduce their Ethernet MTU to achieve the same result, but this really isn't the right solution to the problem - BT needs to make its network behave as per the standards. You may have some success changing the MTU of the PPP connection (some of the BT hubs support this), but again, you're only really working around the problem.
I have raised this as an issue with BT (who, incidentally are familiar with the SureSignal issue, and are blaming Vodafone). I will post updates if I receive a sensible reply... in the meantime, I'm happy to help anyone who might be wanting to seek a better understanding of the problem. Hope this is useful to someone.
.png "Moderator (Retired)"){kind=icon}
