Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


wtf



38 posts

Geek


Topic # 56909 28-Jan-2010 11:20
Send private message

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.


Create new topic
BDFL - Memuneh
59173 posts

Uber Geek
+1 received by user: 10411

Administrator
Trusted
Geekzone
Subscriber

xpd

8360 posts

Uber Geek
+1 received by user: 1102

Mod Emeritus
Trusted
Subscriber

  Reply # 293843 28-Jan-2010 11:38
Send private message

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

 

Maybe if we start telling people the brain is an app they will start using it.

 

This signature proudly stripped of anything interesting by a lack of imagination.


 
 
 
 


6294 posts

Uber Geek
+1 received by user: 377

Moderator
Trusted
Subscriber

  Reply # 293845 28-Jan-2010 11:40
Send private message

Working fine on Xtra BB

5922 posts

Uber Geek
+1 received by user: 870

Trusted
Subscriber

  Reply # 293894 28-Jan-2010 13:16
Send private message

Working for me from TCL fibre.

wtf



38 posts

Geek


  Reply # 293908 28-Jan-2010 13:46
Send private message

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


  Reply # 294220 29-Jan-2010 02:01
Send private message

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


  Reply # 294221 29-Jan-2010 02:10
Send private message

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?

Create new topic



Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:





News »

UAV Traffic Management Trial launching today in New Zealand
Posted 12-Dec-2017 16:06


UFB connections pass 460,000
Posted 11-Dec-2017 11:26


The Warehouse Group to adopt IBM Cloud to support digital transformation
Posted 11-Dec-2017 11:22


Dimension Data peeks into digital business 2018
Posted 11-Dec-2017 10:55


2018 Cyber Security Predictions
Posted 7-Dec-2017 14:55


Global Govtech Accelerator to drive public sector innovation in Wellington
Posted 7-Dec-2017 11:21


Stuff Pix media strategy a new direction
Posted 7-Dec-2017 09:37


Digital transformation is dead
Posted 7-Dec-2017 09:31


Fake news and cyber security
Posted 7-Dec-2017 09:27


Dimension Data New Zealand strengthens cybersecurity practice
Posted 5-Dec-2017 20:27


Epson NZ launches new Expression Premium Photo range
Posted 5-Dec-2017 20:26


Eventbrite and Twickets launch integration partnership in Australia and New Zealand
Posted 5-Dec-2017 20:23


New Fujifilm macro lens lands in New Zealand
Posted 5-Dec-2017 20:16


Cyber security not being taken seriously enough
Posted 5-Dec-2017 20:13


Sony commences Android 8.0 Oreo rollout in New Zealand
Posted 5-Dec-2017 20:08



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.