On Wed, Jul 30, 2008 at 2:37 PM, Bill Mott <v12bill@xxxxxxxxx> wrote: > Looks like an MTU size problem / do not fragment problem. > Since from earlier post, reducing the MTU makes it work, why not fix it that > way? For the following reasons: a) Dropping the mtu down to 1499 doesn't tell me why wget works under windows (without the need to drop the mtu). b) Dropping the mtu down to 1499 doesn't tell me why wget (under linux) works if I force my router to grab a public-facing ip address in the range 93.96.x.x. c) Dropping the mtu down to 1499 doesn't agree with/explain the results of the ping testing, which follows... I originally thought that it was an mtu-size / do-not-fragment problem so I read up on "TCP Path Maximum Transmission Unit (PMTU) Discovery" in Karajit Siyan's book, "Windows 2000 TCP/IP" (the chapter required is available at http://vig.pearsoned.co.uk/samplechapter/0735709920.pdf). He explains that if I ping the destination with the "don't fragment" option set and a sufficiently large packet-size, then I can find the largest permissible mtu by checking for something like "Packet needs to be fragmented but DF set" in the output. Here are the results of the 2 boundary-case pings: $ ping -s 1472 -M do ocp.com.com PING c18-ad-xw-lb.cnet.com (216.239.122.193) 1472(1500) bytes of data. 64 bytes from c18-ad-xw-lb.cnet.com (216.239.122.193): icmp_seq=1 ttl=241 (truncated) 64 bytes from c18-ad-xw-lb.cnet.com (216.239.122.193): icmp_seq=2 ttl=241 (truncated) 64 bytes from c18-ad-xw-lb.cnet.com (216.239.122.193): icmp_seq=3 ttl=241 (truncated) 64 bytes from c18-ad-xw-lb.cnet.com (216.239.122.193): icmp_seq=4 ttl=241 (truncated) $ ping -s 1473 -M do ocp.com.com PING c18-ad-xw-lb.cnet.com (216.239.122.193) 1473(1501) bytes of data. >From t60jt (192.168.0.3) icmp_seq=1 Frag needed and DF set (mtu = 1500) >From t60jt (192.168.0.3) icmp_seq=1 Frag needed and DF set (mtu = 1500) >From t60jt (192.168.0.3) icmp_seq=1 Frag needed and DF set (mtu = 1500) >From t60jt (192.168.0.3) icmp_seq=1 Frag needed and DF set (mtu = 1500) If I am correct, success with "-s 1472" means that an mtu of 1500 should work (i.e. lowering the mtu down to 1499 should not be necessary). Consequently, I don't want to drop the mtu down to 1499 if that will simply mask/cover a bigger problem. (I must admit, I'm not sure whether the "(truncated)" on the end of the first ping is indicative of another problem - perhaps there's a clue there somewhere?) > You can use traceroute, and specify a packetlen. This will help you prove / > disprove an MTU problem along the route. > Good luck! I had a quick play with tracert in the beginning but, like I said, many lines contained asterisks and I wasn't perfectly sure exactly what it meant. Here are some example runs: (connected to 78.105.x.x): # tracert ocp.com.com 20 traceroute to ocp.com.com (216.239.122.193), 30 hops max, 20 byte packets 1 router (192.168.0.1) 78.772 ms 77.768 ms 77.753 ms 2 * * * 3 213.161.72.69 (213.161.72.69) 22.761 ms * * 4 * * * 5 * * * 6 * so-3-0-0.mpr1.iad2.us.above.net (64.125.29.134) 89.867 ms * 7 * * so-3-0-0.mpr1.iad10.us.above.net (64.125.30.117) 89.937 ms 8 above-oc48.iad.att.net (64.125.13.14) 90.860 ms 89.908 ms 89.918 ms 9 tbr2.wswdc.ip.att.net (12.122.84.202) 128.888 ms 126.870 ms 127.900 ms 10 cr2.wswdc.ip.att.net (12.122.16.101) 125.903 ms 125.872 ms 125.910 ms 11 cr1.attga.ip.att.net (12.122.1.173) 125.899 ms 125.894 ms 125.896 ms 12 cr2.dlstx.ip.att.net (12.122.28.174) 126.884 ms 126.883 ms 126.900 ms 13 tbr2.dlstx.ip.att.net (12.122.18.230) 126.918 ms 127.758 ms 126.900 ms 14 12.122.100.97 (12.122.100.97) 126.899 ms 125.895 ms 125.865 ms 15 12.87.121.22 (12.87.121.22) 125.898 ms 125.905 ms 125.896 ms 16 c18-ad-xw-lb.cnet.com (216.239.122.193) 126.897 ms 125.894 ms 125.899 ms (also connected to 78.105.x.x): # tracert ocp.com.com 1500 traceroute to ocp.com.com (216.239.122.193), 30 hops max, 1500 byte packets 1 router (192.168.0.1) 53.710 ms 53.675 ms 52.681 ms 2 78-86-32-1.zone2.bethere.co.uk (78.86.32.1) 175.626 ms * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * so-3-0-0.mpr1.iad10.us.above.net (64.125.30.117) 197.719 ms 101.894 ms 8 above-oc48.iad.att.net (64.125.13.14) 102.912 ms 101.897 ms 102.907 ms 9 * * * 10 cr2.wswdc.ip.att.net (12.122.16.101) 162.785 ms * * 11 * * * 12 * * * 13 * * * 14 * 12.122.100.97 (12.122.100.97) 147.854 ms * 15 12.87.121.22 (12.87.121.22) 137.859 ms 146.883 ms 137.890 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * While it looks good, I don't understand what it means (other than being a partially-identified list of routers between me and the destination). Do you have any idea what traceroute/tracert commands I should be running and, more importantly, exactly how I can interpret the results? One other thing I forgot to mention: my isp/provider uses rfc 1483 / 2684 (ethernet over atm) rather than ppp, but I don't think that has much of a bearing on my problem. If anyone has any suggestions, again I'd be really thankful. Jaime. -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
