Date: Wed, 2 Dec 1998 13:29:37 -0700 From: Nate Williams <nate@mt.sri.com> To: Marc Slemko <marcs@znep.com> Cc: Nate Williams <nate@mt.sri.com>, Daniel Eischen <eischen@vigrid.com>, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, luigi@labinfo.iet.unipi.it Subject: Re: TCP bug Message-ID: <199812022029.NAA07307@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9812020949040.463-100000@alive.znep.com> References: <199812021636.JAA06068@mt.sri.com> <Pine.BSF.4.05.9812020949040.463-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ By the way, this has been an interesting and informative discusstion. Thanks to all involved. ] > > 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. Fair enough. So, is PMTU working from that box? > 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. The box it's connected to is another FreeBSD box. The way it looks is: Internet <-> FreeBSD firewall <----> FreeBSD router <----> Internal box The FreeBSD firewall box is allowing ICMP type 3 packets through (per your WWW page) so PMTU should work from my end at least. You're saying that the ICMP message is getting blocked somewhere between my firewall box and www.nfl.com, right? And, because my 'SLIP' box is originally broadcasting an MTU of 552, there is never any need to fragment the packet. It's starting to make sense to me. So, let me summarize. Let's call my Slip router box 'trout', and my Internal box behind it 'caddis'. trout has no trouble connecting to these 'broken' machines on the internet because it initially advertises a window of 552, so 'www.nfl.com' generates packets no bigger than that. However, poor 'caddis' advertises a window of 1500, which is received by 'www.nfl.com' which sends a packet of size '1500'. This is too big, so 'trout' doesn't get it because when my firewall drops it (due to the DF flag being sent) because it can't send it to trout who has a small SLIP mtu of 552 (< 1500). So far so good, and it even makes sense. However, *WHY* does the IPFW code on trout think it has a packet from 'www.nfl.com' even though the packet should have been dropped at the firewall because all traffic to caddis has to be split into chunks of 552? Also, why does the packet sent from www.nfl.com have the DF flag set? Is that part of the PMTU code? > 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. See above. Here is another attempt where I'm running two tcpdumps at the same time on the different interfaces. Do they make any more sense? I am also showing the firewall information as well, which has it's only purpose to show that some sort of packet is received destined for caddis from www.nfl.com that never makes it onto the wire. trout:~ # tcpdump -i sl0 host caddis and www.nfl.com tcpdump: listening on sl0 11:20:11.374690 caddis.mt.sri.com.1174 > 204.202.130.220.http: S 45779929:45779929(0) win 8192 <mss 1460> (DF) 11:20:11.563975 204.202.130.220.http > caddis.mt.sri.com.1174: S 63039543:63039543(0) ack 45779930 win 8760 <mss 1460> (DF) 11:20:11.573961 caddis.mt.sri.com.1174 > 204.202.130.220.http: . ack 1 win 8760 (DF) 11:20:11.578700 caddis.mt.sri.com.1174 > 204.202.130.220.http: P 1:238(237) ack 1 win 8760 (DF) 11:20:14.781813 caddis.mt.sri.com.1174 > 204.202.130.220.http: P 1:238(237) ack 1 win 8760 (DF) 11:20:15.016280 204.202.130.220.http > caddis.mt.sri.com.1174: . ack 238 win 8523 (DF) trout:~ # tcpdump -i le0 host caddis and www.nfl.com tcpdump: listening on le0 11:20:11.369849 caddis.mt.sri.com.1174 > 204.202.130.220.http: S 45779929:45779929(0) win 8192 <mss 1460> (DF) 11:20:11.569066 caddis.mt.sri.com.1174 > 204.202.130.220.http: . ack 63039544 win 8760 (DF) 11:20:11.571399 caddis.mt.sri.com.1174 > 204.202.130.220.http: P 0:237(237) ack 1 win 8760 (DF) 11:20:14.776812 caddis.mt.sri.com.1174 > 204.202.130.220.http: P 0:237(237) ack 1 win 8760 (DF) trout:~ # ipfw list FireWall chain entries: 700 0 00100 allow log tcp from 206.127.76.139 to any 80 via le0 00110 allow log tcp from 206.127.76.139 to any 80 via sl0 00200 allow log tcp from any 80 to 206.127.76.139 via sl0 00210 allow log tcp from any 80 to 206.127.76.139 via le0 trout:~ # dmesg ipfw: Accounting cleared. ipfw: 100 Allow TCP 206.127.76.139:1174 204.202.130.220:80 ipfw: 110 Allow TCP 206.127.76.139:1174 204.202.130.220:80 ipfw: 200 Allow TCP 204.202.130.220:80 206.127.76.139:1174 ipfw: 210 Allow TCP 204.202.130.220:80 206.127.76.139:1174 ipfw: 100 Allow TCP 206.127.76.139:1174 204.202.130.220:80 ipfw: 110 Allow TCP 206.127.76.139:1174 204.202.130.220:80 ipfw: 100 Allow TCP 206.127.76.139:1174 204.202.130.220:80 ipfw: 110 Allow TCP 206.127.76.139:1174 204.202.130.220:80 ipfw: 100 Allow TCP 206.127.76.139:1174 204.202.130.220:80 ipfw: 110 Allow TCP 206.127.76.139:1174 204.202.130.220:80 ipfw: 200 Allow TCP 204.202.130.220:80 206.127.76.139:1174 ipfw: 210 Allow TCP 204.202.130.220:80 206.127.76.139:1174 ipfw: 200 Allow TCP 204.202.130.220:80 206.127.76.139:1174 ipfw: 210 Allow TCP 204.202.130.220:80 206.127.76.139:1174 Thanks again! Nate 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?199812022029.NAA07307>