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

wtf

38 posts

Geek


#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
freitasm
BDFL - Memuneh
79254 posts

Uber Geek

Administrator
ID Verified
Trusted
Geekzone
Lifetime subscriber

  #293839 28-Jan-2010 11:36
Send private message

Working fine for me on TelstraClear cable.




Please support Geekzone by subscribing, or using one of our referral links: Samsung | AliExpress | Wise | Sharesies | Hatch | GoodSyncBackblaze backup




xpd

xpd
Geek @ Coastguard NZ
13765 posts

Uber Geek

Retired Mod
ID Verified
Trusted
Lifetime subscriber

  #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 :)




       Gavin / xpd / FastRaccoon / Geek of Coastguard New Zealand

 

                      LinkTree

 

 

 


nate
6473 posts

Uber Geek

Retired Mod
Trusted
Lifetime subscriber

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

Working fine on Xtra BB



Behodar
10502 posts

Uber Geek

Trusted
Lifetime subscriber

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

Working for me from TCL fibre.

wtf

wtf

38 posts

Geek


  #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

wtf

38 posts

Geek


  #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

wtf

38 posts

Geek


  #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





News and reviews »

Air New Zealand Starts AI adoption with OpenAI
Posted 24-Jul-2025 16:00


eero Pro 7 Review
Posted 23-Jul-2025 12:07


BeeStation Plus Review
Posted 21-Jul-2025 14:21


eero Unveils New Wi-Fi 7 Products in New Zealand
Posted 21-Jul-2025 00:01


WiZ Introduces HDMI Sync Box and other Light Devices
Posted 20-Jul-2025 17:32


RedShield Enhances DDoS and Bot Attack Protection
Posted 20-Jul-2025 17:26


Seagate Ships 30TB Drives
Posted 17-Jul-2025 11:24


Oclean AirPump A10 Water Flosser Review
Posted 13-Jul-2025 11:05


Samsung Galaxy Z Fold7: Raising the Bar for Smartphones
Posted 10-Jul-2025 02:01


Samsung Galaxy Z Flip7 Brings New Edge-To-Edge FlexWindow
Posted 10-Jul-2025 02:01


Epson Launches New AM-C550Z WorkForce Enterprise printer
Posted 9-Jul-2025 18:22


Samsung Releases Smart Monitor M9
Posted 9-Jul-2025 17:46


Nearly Half of Older Kiwis Still Write their Passwords on Paper
Posted 9-Jul-2025 08:42


D-Link 4G+ Cat6 Wi-Fi 6 DWR-933M Mobile Hotspot Review
Posted 1-Jul-2025 11:34


Oppo A5 Series Launches With New Levels of Durability
Posted 30-Jun-2025 10:15









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.