Date: Wed, 2 Dec 1998 10:04:47 -0800 (PST) From: Marc Slemko <marcs@znep.com> To: Nate Williams <nate@mt.sri.com> Cc: Daniel Eischen <eischen@vigrid.com>, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, luigi@labinfo.iet.unipi.it Subject: Re: TCP bug Message-ID: <Pine.BSF.4.05.9812020949040.463-100000@alive.znep.com> In-Reply-To: <199812021636.JAA06068@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Dec 1998, Nate Williams wrote: > No, the router can, but any machines hung off it's ethernet can't. On a > whim (based on a hint I got from Karl Peilorz) I changed the MTU on the > router (which is running SLIP to get to the net) from 552 to 1500, and > now things work. > > The strange things is that that the mtu of the SLIP interface if/was 552 > and all traffic that originated on that box was fine, and the mtu on the > ethernet interface was 1500, and traffic generated from there did not > work. > > I would have thought that you wouldn't need to fragment any packets that > had a mtu of 552 to stick it on an ethernet with an mtu of 1500. If you make a connection directly from the box with the low MTU, it knows to advertise a low MSS so no one will try to send packets that are too big. If you make a connection from a high MTU box behind it, then it will advertise a large MSS so the remote end will try sending large segments. If the first <1500 MTU is at the "router" referred to above, then for some reason an ICMP can't fragment message probably is not getting from the machine on the other side of the router's SLIP link to the origin host. Again, the place where a large segment would be dropped and an ICMP "can't fragment" sent back is at the system on the other end of the SLIP link. The tcpdumps you sent earlier don't make a lot of sense since they don't actually show any data being transferred for the connection you say works and for the one you say doesn't, it only shows a SYN going one way, not the other. However, since www.nfl.com does block ICMP echo requests or echo responses and it does try to do PMTU-D, this is very likely the problem even though the tcpdumps you posted don't appear to make any sense. As always, http://www.worldgate.com/~marcs/mtu/ for a discussion of PMTU-D, why it gets broken and how you can work around the problem. The real issue in this case is that www.nfl.com is broken and appears to be causing the problem. You should try to contact StarWave (which manages nfl.com, and a whole bunch of other sites that may be broken in the same way) and tell them to fix their broken system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9812020949040.463-100000>