[TelstraClear] Can you surf to Vodafone?

Forums › Vodafone New Zealand › [TelstraClear] Can you surf to Vodafone?

wtf

38 posts

Geek

#56909 28-Jan-2010 11:20

Hi All,

I am investigating a problem that I have noticed on my Telstra Clear ADSL connection. I cannot load the www.vodafone.co.nz website. Every other website I have tried works fine. I wonder if anyone else on TCL would care to try loading this site and see what happens.

Note...I have some idea about what the problem is, and would emphasise that this is not necessarily a TCL issue. In fact there could be problems on either or both sides, but I am not in a position to prove it either way.

freitasm

BDFL - Memuneh
66335 posts

Uber Geek

Administrator

Trusted

Geekzone

Lifetime subscriber

#293839 28-Jan-2010 11:36

Working fine for me on TelstraClear cable.

xpd

Arrma Basher
10398 posts

Uber Geek

Mod Emeritus

Trusted

Lifetime subscriber

#293843 28-Jan-2010 11:38

Working fine for me on TelstraClear fibre also.
Working fine for me on Orcon ADSL as well.

Edit: Whoops, should have been fibre not cable - updated :)

XPD / Gavin / DemiseNZ

Arrma RC Owner ? Check out Arrma Addicts Auckland

nate

6373 posts

Uber Geek

Moderator

Trusted

Lifetime subscriber

#293845 28-Jan-2010 11:40

Working fine on Xtra BB

Behodar

6957 posts

Uber Geek

Trusted

Lifetime subscriber

#293894 28-Jan-2010 13:16

Working for me from TCL fibre.

wtf

38 posts

Geek

#293908 28-Jan-2010 13:46

OK...maybe I should tell you a bit more about what I know so far. The symptoms are that you type in the URL, firefox says loading, and nothing further happens. Wireshark shows me a normal DNS lookup, followed by a TCP handshake to the server. The browser does an http get and then no data is seen from the server. After a timeout, my end sends a duplicate ACK for the last packet it got, and this cycles until the browser gives up. The problem has been duplicated on two machines running XP on my LAN, also on a Windows Vista machine running on the WLAN. As mentioned, all other websites appear to load normally. From the Vodafone side, the server keeps sending packets towards me, and getting duplicate Acks from me that say I didn't get them. I don't know what size those packets were.

This is consistent with a path MTU problem, and the traces that were obtained by Vodafone were also consistent with that, although they did not try to confirm if they were seeing any ICMP type 3 code 4 packets arriving from the path between them and me. (such packets would not come from my address, so they would need to know the possible source address to trace them.) I tried some exploratory pings from my machine out towards the Internet, well, to Google in fact. On that path I see a maximum of 1480 bytes on the uplink, but only 1464 on the downlink. (This is done using the -l option to set the size, and the -f option to set "don't fragment") There is of course no way to know exactly where those limits are occurring, it could in principle be anywhere along the path. Since Vodafones web site would be a different path, it need not have the same limits. (I beleive Vodafone and TCL have direct peering to each other.) It would also follow that people trying to load Vodafones web site from other ISPs need not be using the same path, and indeed if everyone was getting this problem it would be obvious enough to get fixed pretty smartly. On the other hand it is unlikely to apply to just me....if it was something unique about my configuration you would have to wonder why other web sites work fine. If I had a rule in my ADSL router blocking traffic from Vodafone, it should also block the TCP SYN and ACKs, not just the larger packets when the transfer starts. Incidently the Vodafone web site can be loaded by going to a proxy.

So my money at the moment is on their being some sort of Path MTU problem between myself and the Vodafone server, but not between myself and the rest of the Internet. I would expect it to apply to other TCL customers with a similar service to mine, but not necessarily to all. I'd be interested to know what maximum packet size other users see. Try this:

ping -f -l 1400 www.google.com... (or any other site you like that will return a ping)

Vary the size. (the 1400 number) You are likely to find as I did that larger ones, over 1480 in my case, time out with a message to the effect "packet too large and DF set", that means the uplink can't take it, and is sending you the icmp message to let you know. 1480 is normal for PPP over DSL. Smaller packets may time out until you get below another size, 1464 in my case. That means that the downlink is unable to take packets that big so your ping reply gets dropped. You don't get the ICMP message in that case since it is sent back to the source, eg Google, for the ping reply. If your downlink limit was the same as or larger than your uplink limit then you would not see this effect. For those who might be wondering, the existence of a limit is not a big deal and is not a problem in itself.

wtf

38 posts

Geek

#294220 29-Jan-2010 02:01

OK, replying to myself, bad form I know, but I have learned some more, which actually increases the mystery a bit more...

Telstra Clear have got back to me with a suggestion which actually works. They were able to detect that the MRU size on my D-link was set to 1492, and suggested setting it to 1500. OK, so I tried this and it works.

BUT...this is a PPP setting, it would change the maximum size of packet over my link, on the downlink towards me, from 1492 to 1500. The observed maximum packet size on the link towards me seems to be less than that anyway, going by my ping tests.lthough that could be happening is some otehr link, eg not local to me and TCL. Also if the router at the TCL end can't send a packet towards me, it ought to generate the "can't fragment" packet and send it back towards Vodafone. Maybe they are and Vodafone is dropping or ignoring it. Because the other question would be, if this setting was wrong, why was anything else working? The probable answer to me would be that either other sites are getting the ICMP and acting on it, or they are doing something some sites do, sending whatever size seems good to them and not setting the DF bit. This seems quite probable since I do see some reassembled packets on general surfing, and was before the fix went in...If PMTUD is configured properly you don't see these, which of course is more efficient and faster.

Another interesting question is how did this come to be set wrong...and the answer seems to be that 1492 would actually be right for a PPPoE system over an underlying network that has a maximum packet size of 1500, as would have been the case a few years back. This particular router was set up a few years back, when we first moved here, which would be 2002, and I don't think the PPPoE setting have been touched since...if it ain't broke... Actually they were touched once by Telecom, which killed the connection and seemed to me a highly questionable thing for Telecom to do, since I am not their customer and they did it without asking. But that was probably at least 5 years back. So the setting may well have been right after that, but I suspect that TCL now has an underlying network that supports packets bigger than 1500, so they can support an MRU of 1500. Which allows us users to receive 1500, which is what a lot of misconfigured web servers are going to send you by default. It is an old rule, going back a long time, that you don't actually send people packets larger than 576 bytes unless you have their permission. This permission would normally be given in the TCP SYN, eg the MSS sent in that packet. Most systems these days will default to sending 1500 as the MSS unless you have taken the trouble to change it, a registry setting on Windows so I suspect few users tinker. I get the impression that some servers are ignoring that size, potentially a mistake as it can make your server unreachable for some users.

Speaking of which, an interesting feature now is that one of my machines has had the registry tinkered with, so the very machine I am typing this on has an MTU size of 1300 Bytes. But when I go to the Vodafone site with it, the packets I receive are 1460 bytes, eg a 1500 byte packet with a 40 byte TCP/IP overhead. So my conclusion from this is that Vodafone are not respecting the MSS size sent in my SYN packets. I think from the earlier reasoning that they are also not implementing PMTUD or any of the workarounds So that is why they broke, and not anyone else that I have observed yet. From what I read ther are a fair number of sites around the web that get all this wrong, although evidently not many that I go to. If they want to at least make things mostly work, they should probably make sure the DF bit is turned off in their packets. That will allow intervening routers, like the ones at Telstra Clear for instance, fragment the packets and send them on. Not pretty but it works. Incidently the end user cannot be sure if the DF bit on the packet that arrives is the same as what was sent, as intervening systems can change it, with of course unpredictable results. Too bad if the end sytem really can't reassemble it.

So anyway, thanks to Telstra for being on the ball with this one. Now I wonder how many other people still have the old MRU setting?

wtf

38 posts

Geek

#294221 29-Jan-2010 02:10

Oops, sorry Mauricio, can you delete the first of those...I thought something must be broken again so I interrupted it and started wireshark. But given long enough it comes through.

Hmm...I'm getting big packets from you too, but with DF not set. Has this become the new standard?