Date: Wed, 2 Dec 1998 14:12:01 -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: <199812022112.OAA07817@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9812021232280.463-100000@alive.znep.com> References: <199812022029.NAA07307@mt.sri.com> <Pine.BSF.4.05.9812021232280.463-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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? > > You mean PMTU-D; the PMTU (path MTU) is simply a term describing the > smallest MTU of any link along the path. Gotcha. I'm not trying to mess up the terminology, so feel free to correct any misconceptions I have. > It isn't working so much as it has no need to be invoked so it isn't > failing. Ok so far. > > > 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? > > Right, probably very close to www.nfl.com. Agreed. > > 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 > > It isn't the window that it is advertising, but the mss. If you look at > your tcpdumps, the "mss 1460" or "mss 512" bits in the SYN show each end's > mss. The mss is the mtu - 40; ie. the maximum packet size minus the size > of the headers, so the mss is the amount of actual data that can fit in > one packet while the mtu is the total size of the packet. Ok. > > '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? > > I think that is a different packet you are seeing that comes later or > something. Nope. 'caddis' had only one connection up at the time, and I zero'd out the firewall entries before I started the connection attempt, and stopped the attempt before I dumped out the information. Nothing else was running on caddis (it's a Win95 box). > > Also, why does the packet sent from www.nfl.com have the DF flag set? > > Is that part of the PMTU code? > > Yes. The whole way that PMTU-D works is to set the DF bit on packets and, > if it finds they are too big, then it can try a smaller size (on modern > routers, the system sending the can't fragment will include the actual MTU > in the ICMP response so the remote system doesn't even have to guess). So, www.nfl.com assumes PMTU-D is working but some router between my box and it is blocking ICMP-Type 3 packets, essentially breaking PMTU-D? > > 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. > > There is something broken going on with your tcpdumps. The second one (of > le0) doesn't even show the SYN from www.nfl.com to caddis, but it has to > be getting there since otherwise the connection couldn't proceed. It > shows no traffic from www.nfl.com, which is obviously bogus. > > So obviously, for some reason, the le0 tcpdump isn't showing what is > really happening. I don't use the le driver; oh, ok, it is probably that > the driver or the card can't see packets that it puts on the wire. Things > make more sense now. So I would suggest you either dump the le0 traffic > from a different system that can see it or just ignore that dump. Hmm, that'll be difficult since the only machines on the network in question are either generating traffic or routing it. I'll grab my laptop and bring it home to run tcpdump. However, is it safe to run tcpdump on the SLIP connection w/out getting any weird behavior? I have to run it on one of the boxes generating traffic since there isn't any machine in between. :) :) > Now, you still do have one extra packet from www.nfl.com showing up at the > end of the ipfw output that doesn't show up in the sl0 tcpdump. Are you > sure that packet just didn't come in after you had stopped the tcpdump but > before you looked at the ipfw logs? If you are logging the ipfw messages > in /var/log/kern or something, look at the timestamps there. It shouldn't given my test setup. I'll bring my laptop home tonight and setup another test and maybe it'll shed some more light on things. 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?199812022112.OAA07817>