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


38 posts


#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 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
66335 posts

Uber Geek

Lifetime subscriber


Arrma Basher
10398 posts

Uber Geek

Mod Emeritus
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 :)

XPD / Gavin / DemiseNZ


Arrma RC Owner ? Check out Arrma Addicts Auckland


6373 posts

Uber Geek

Lifetime subscriber

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

Working fine on Xtra BB

6957 posts

Uber Geek

Lifetime subscriber

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

Working for me from TCL fibre.


38 posts


  #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 (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.


38 posts


  #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?


38 posts


  #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 and LinkedIn »

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 »

Intel introduces 10th Gen Intel Core H-series for mobile devices
Posted 2-Apr-2020 21:09

COVID-19: new charitable initiative to fund remote monitoring for at-risk patients
Posted 2-Apr-2020 11:07

Huawei introduces the P40 Series of Android-based smartphones
Posted 31-Mar-2020 17:03

Samsung Galaxy Z Flip now available for pre-order in New Zealand
Posted 31-Mar-2020 16:39

New online learning platform for kids stuck at home during COVID-19 lockdown
Posted 26-Mar-2020 21:35

New 5G Nokia smartphone unveiled as portfolio expands
Posted 26-Mar-2020 17:11

D-Link ANZ launches wireless AC1200 4G LTE router
Posted 26-Mar-2020 16:32

Ring introduces two new video doorbells and new pre-roll technology
Posted 17-Mar-2020 16:59

OPPO uncovers flagship Find X2 Pro smartphone
Posted 17-Mar-2020 16:54

D-Link COVR-2202 mesh Wi-Fi system now protected by McAfee
Posted 17-Mar-2020 16:00

Spark Sport opens its platform up to all New Zealanders at no charge
Posted 17-Mar-2020 10:04

Spark launches 5G Starter Fund
Posted 8-Mar-2020 19:19

TRENDnet launches high-performance WiFi Mesh Router System
Posted 5-Mar-2020 08:48

Sony boosts full-frame lens line-up with introduction of FE 20mm F1.8 G large-aperture ultra-wide-angle prime Lens
Posted 5-Mar-2020 08:44

Vector and Spark teamed up on smart metering initiative
Posted 5-Mar-2020 08:42

Geekzone Live »

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

Support Geekzone »

Our community of supporters help make Geekzone possible. Click the button below to join them.

Support Geezone on PressPatron

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.