Carey Fisher - NCS wrote: > James, > If it helps any, the largest MTU I could get thru was 1272. Larger MTUs > give the "Packet Fragmented by DF set." message. > Also, attached is the result of a tracert. > Carey I can get through larger ones. First set your network interface MTU to maximum (1500 on mine, and I think it is the max on Ethernet) $ ping -s 1464 google.com PING google.com (216.239.37.99) 1464(1492) bytes of data. 64 bytes from 216.239.37.99: icmp_seq=1 ttl=241 (truncated) $ ping -s 1465 google.com PING google.com (216.239.57.99) 1465(1493) bytes of data.0 (the truncated stuff is google's servers that do that) $ ping -s 1464 piclist.com PING piclist.com (66.13.172.18) 1464(1492) bytes of data. 1472 bytes from mail.efplus.com (66.13.172.18): icmp_seq=1 ttl=137 time=807 ms $ ping -s 1465 piclist.com PING piclist.com (66.13.172.18) 1465(1493) bytes of data. Same results as google. Ethereal captures Ethernet packets 1506 bytes long for a 1464(1492) payload PING, since Ethernet headers are 14 bytes long. Anything larger than that does not get through. Carey, someone on your path is limiting you to 1300 MTU (probaly your own network interface settings) (watch that the ping byte payload gets 28 added to it due to headers, see the number in parentheses in my ping results. Add 14 to that for Ethernet headers). Anyway the MTU limit shouldn't be a problem, since packets are supposed to be fragmented. The problem would be packets coming from piclist.com with the DF set or something along those lines. *fires up ethereal and checks piclist.com* Don't Fragment: set. 1506 bytes captured, 1492 w/o Ethernet. HTTP headers sent as a smaller packet, without any data tacked on the same packet. *checks google.com* Don't Fragment: not set. 1466 bytes captured, 1452 w/o Ethernet headers (14). *checks iisanswers.com, another microsoft-served site* Don't Fragment: set. 1468 bytes captured, 1454 w/o Ethernet headers (14). *checks microsoft.com, another (duh) microsoft-served site* Don't Fragment: set. 1468 bytes captured, 1454 w/o Ethernet headers (14). My bets are on my initial guess: your MTU is too high and your server is sending DF. Headers are sent separately. Clients behind a node with a stricter MTU limit will drop all packets, but HTTP headers get through. OTOH, I've tested some other sites and they use DF and high MTUs too, but when I lower the MTU at my DSL router, they respond by (correctly) using lower packet sizes, i.e. Path MTU discovery is working fine. piclist.com keeps sending me 1506 byte packets. Using DF with PMTU discovery is common, since (hopefully, and if the routers behave well) you'll simply get "too large and DF set" ICMP messages, and that way you can reduce your MTU to optimal size and prevent fragmentation. But if the reducing isn't working and the DF bit is still set... then bad things will happen. To test further having access to a location with the problem would be a good idea, as would having a static txt somewhere on piclist.com with only a few bytes data (that way we can confirm that small packets get through). -- Hector Martin (hector@marcansoft.com) Public Key: http://www.marcansoft.com/hector.asc -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist