BT Infinity and Sure Signal.

[Jimfew]

I have just changed ISP to BT Infinity. As expected, my Sure Signal has failed. I have tried all sorts of resets and have asked Vodafone support to reset my device and do a network reset. I have also done a hard reset myself. It still does not work. I have opened all the necessary ports on my router (not the BT hub but a Draytek 2820).

I wonder if I also need to ask BT to open ports on their servers? Is this necessary? My old ISP, Be*, did not restrict any ports but BT may be different.

Can anyone advise me.

My VSS number is 21221070754

Can anyone list all the ports the VSS needs to be open (as up to date as possible).

Many thanks, Jim.

[sparkiemike]

VDSL is going to become more and more popular, and people are going to want to choose the equipment they want to use. If this problem existed on ADSL and the answer was only to use one particular manufacturers bit of equipment everybody would be up in arms about it.

Vodafone do NOT make it clear when you purchase that there are compatibility issues with BT Infinity and that you are limited to one manufacturers equipment.

I am also of the opinion that this issue lies with the VSS Home Cell device, and trying to get DrayTek to make modifications is the tail wagging the dog. What happens when Netgear or D-link make a VDSL router?

Vodafone please be proactive about this and make your equipment work, and address the issue with the fragmented packets and the MTU size.

[Jimfew]

Hi Mike, what BT home hub did you use? I am told by BT that one of their Fibre Home Hubs (The Huwei I think) worked but the newer 2Wire business version does not as it adhers to the spec for PPPoE precisely.

BT still say that they do not support the VSS and that if it works you are lucky in that the router has been designed to allow for jumbo packets and will fragment them and pass them through.

All Vodafone need to do is to implement MTU negotiation on the VSS rather than accept a fixed MTU of 1500. This will solve all the problems and allow everyone to use whatever hardware suits their business needs..

For info, I have never had my VSS working on BT Infinity and we have tried the VSS version 1 and 2, the BT fibre hub (a 2Wire version 3), two types of modern Drayteks and a new Netgear hub. We have put the VSS into DMZ and this opens all ports through the firewall. BT advise me the newer 2Wire hubs implement PPPoE specs exactly and jumbo packets are refused. This is the root cause of the problem. BT say , even today! that the VSS will enver work with BT Infinity unless you are lucky and have a router/hub which fudges the issue.

[Jimfew]

OK, my team has done some extensive research and analysis and this is the current position. I apologise for some techy bits but it is needed.

Everyone knows that  data is transferred on modern networks using packets which have certanl characteristics. The packets have lengths and, within them, contain the data and some control bits. The exact make up is not need for this discussion. One of the control bits within each packet is a "do not fragment" flag which can be set to off or on. We think the VSS has fixed sized packets of 1500 MTU and the eF flag is set to disallow (i.e. do not fragment).

The two wide area lan confifurations in the UK use PPPoA and PPPoE as the format standard. Most UK hoseholds use PPPoA which is a hangover from old style telephony equiment which uses ATM. Nothing wrong with that.

If you connect the VSS to an ATM style connection using PPPoA, such as ADSL systems in the UK, the MTU can be set up to 1500 without the need to fragment. Even though the VSS packets do not allow fragmentation this was never a problem as none of the packets needed any and would be sent on their way by the broadband router (I assume for this discussion that all correct ports are open and the VSS is set up correctly).

However, the BT Infinity product uses PPPoE which meets the international standards and has a maximum MTU of 1492 which means any packets which are presented to it which are larger that this (called Jumbo packets) need to be fragmented. There is no way that you can send an un-fragmented packet of MTU 1500 through a properly configured PPPoE network such as the FTTC BT Infinity one.

So, any router confronted with this problem usually fragments the packet. This is a little inefficient but it does allow the data to pass (whether in a VPN tunnel or not). As some of the data sent is not superfluous, the speed will diminish but most will not see this effect.

With the VSS, the MTU 1500 packets need to be fragmented. But the control bit within each packets dissallows fragmentation. Any modern router cannot deal with this issue and just discards the packet presented in this way. They can do nothing else.

Some older routers do allow you to ignore the eF control bit and fragment the packet anyway. BT's older hubs do this to allow for older equipement using ATM connections and MTU's of 1500. The newer routers, including BT's latest version 3, 2Wire routers stick to the standard completely and do not support legacy ATM products (such as the VSS). Modern euipment, such as PC's etc use a facility called MTU Path Discover which tests the path of the packets to their destination and set their MTU (i.e. packet length) to the minimum that they find. This is why anything running Windows XP or 7 works fine. Other than the VSS we have had no other issues swapping from PPPoA to PPPoE.

There are four possible solutions to this, some of which people have already found.

1) Use a router (usually and older one) which ignores the eF flag and fragments packets anyway down to the PPPoE standard of 1492 or less. This does waste packets but it will work.

2) Find a router as in 1) above but put it as an interface between the VSS and your network (set the eF flag to ignore within the router software). This will fragment the packets down to a lower number and the BT Infinity router sees it as normal traffic.

3) Get Draytek (and others) to allow for a eF flag enable/disable oiption in their software which then will fragment the packets ignoring the eF flag set within the packets themselves.

4) Get Vodafone to implement MTU Path Discover within the software of the VSS and set the MTU to the minimum value found, i.e. an update to the network management software to meet the more modern standards.

We are looking for an interface router which will allow for legacy ATM products (such as telephone exchanges of older design). We think a Buffalo Airstation has the necessary requirements but, as yet, can't find one to try.

I'll keep you all informed.

[sparkiemike]

Thanks Jim, really appreciate the effort you and your team have put in.

My preferred option would be 4) Get Vodafone to implement MTU Path Discover within the software of the VSS and set the MTU to the minimum value found, i.e. an update to the network management software to meet the more modern standards.

I don't think it is reasonable for Vodafone to expect all the router manufactures to modify their firmware to accommodate VSS.

Come on Vodafone please make your equipment comply with modern standards!!!!!!

[e630193]

Hi Jimfew, apologies for my slow response, been away.

The BT Hub that I used to get things working initially was the 2wire 2701HGV-C, which is a BT Business Hub. As previously mentioned, as opposed to the very latest BT Hub, you can change the MTU setting on it. The VSS was setup in the hubs DMZ with a public, static IP, just to get things working.

I wasn't happy with that setup, or the BT hub so I now have the VSS inside my local network, I have discarded the the BT hub and I use a linux device to act as my router/firewall and the VSS still works.

I find it hard to understand what difference it makes, what kind of internet connection one has when using ANY network device locally. Unless of course, as you say, packets are being dropped due to a setting within the packet itself in which case a device would struggle. Surely though, dropping packets willy nilly does not make sense.

Now I know next to nothing about network providers and their topology so where does the pppoa & pppoe come into the equation? It must just be the bit from the cabinet on the street to your house/business? If not, any setup that currently works could easily stop working if routed through a device which drops said packets, i.e by traversing a pppoe segment.

Ok, starting to get dizzy now I can't believe in this day and age we are dependent on luck?

Cheers,

Mike.

[Sander123]

I understand this won't help some of you but as a bt infinity customer myself I read this thread before ordering the sure signal and I wasnt't hopeful. Fortunately after an initial 1 hour setup time the sure signal has been working fine with bt infinity for us here. We have the white open reach modem followed by the bt home hub (v2 I believe) so for us the bt supplied equipment has worked without any further tinkering as such. I can understand bt's equipment may not suit every bodies needs but I thought it would be worthwhile to share my experience in regards to this topic.

[bartletm]

I've got my Sure Signal 2 to work on FTTC WITHOUT the need to use BT's standard Home Hub Router (which does work). Im using a Draytek 2920, though the solution below should work with any PPPoE router you directly connect to the modem.

Last week i moved to FTTC and use Zen Internet as my ISP. Im using a Draytek 2920 router attached to the BT OpenReach standard modem thats provided with the FTTC installation. It was not possible to get the SS working directly attached to the Draytek 2920 due to that modem being in "PPPoE" connection mode. However, by simply connecting an old router to the Draytek router and plugging the SS in to the old router it works fine (i did the port forwarding rules for the 8,50,500,4500,123). My guess is tha the "inner network" created by old router doesn't know anything about it being on "PPPoE", so does what ever is necessary for the SS to work (perhaps handling the packet fragmenting as some are sure is important).

So, a solution that DOES WORK needs an extra "hop" of equipment between the draytek and the SS, but only the SS is on that sub-network so doesnt impact the rest of my network usage. The Draytek 2920 isn't the key bit of the solution here, it should work for any PPPoE router, but you do need to create an inner network where the WAN port of the inner router comes the internal subnet from your PPPoE outer router.

A bit more info to help others:

Wall Socket->BT OpenReach Modem->(Ext Ip) DrayTek 2920 (192.168.1.1)->Belkin N1 (Old Router)(192.168.10.1)->SS(192.168.10.2)

The rest of my network just comes directly of the 2920 just how i want it.

Initialisation & Connection to Vodafone of the SS only took about 10 minutes when setup like that.

Thanks to everyone's posts that helped lead me to this solution and I hope my post helps others achieve the same success.

[bartletm]

Couple of other tips with the setup:

If your outer router supports it, then put the inner router "wan port ip" (192.168.x.x) in to the outer routers DMZ. If not, remember you'll need to port route from the outer router->Inner Router and then Inner Router->VSS (ie, two sets of rule setups) depending on whether you have PnP enabled in all places.Other options include assigning the inner router with a second public IP if you have one. All options should be fine.

Remember, The key part of the solution is using a 2nd router with subnet  (ethernet in /ethernet out) inside the main outer router (PPPoE /ethernet).

[Jimfew]

Ok, my team and I have finally got it working today.

The problem is with the 1500 MTU (as explained previously)  and the fact that the Draytek 2820 (and all the other routers we tried) would discard the "jumbo framed" packets rather than fragment them.

The answer was to allow fragmentation and ignore the "do not fragment" bit in the packet headers from the VSS.

It took ages to find the right method and I'd like to share this with you all.

In the Draytek you have to issue a telnet command to change the DFcheck flag from enable to disable. If you do a telnet help command and search the available commands then you will find the coorect one.

However, this is NOT activated by a soft reset via the web interface. It only enacts when you do a full hard reset by power cycling. Goodness knows why Draytek made this a feature but they did and it took us weeks to find this out.

Once we made the telnet DFCheck change and did an on/off power cycle, everything came on and the VSS now works properly. Effectively the Draytek has now been configured to ignore the "Do Not Fragment" flag in the packet headers and just fragments the jumbo packets down to MTU 1492 which can then be passed over the BT FTTC Ethernet backhaul network. It seems the Vodafone servers do not reject the fragmented packets and everything sets up and runs, albeit a bit slower because of the fragmentation but on the new FTTC super fast broadband network, this does not effect the performance.

Job done, hope this helps everyone. Certainly a weight off my mind!

Jim.

[Jimfew]

As an addition, I think Vodafone should implement MTU Path Discover (or the more modern equivalents) and adjust their packets to meet the found maximum packet size (MTU 1492 in my case). Windows 7 (and XP and Vista previously) does this for network computers etc. This would make their device much more robust for the future.