Date: Wed, 2 Dec 1998 13:00:53 -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.9812021232280.463-100000@alive.znep.com> In-Reply-To: <199812022029.NAA07307@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Dec 1998, Nate Williams wrote: > > 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. It isn't working so much as it has no need to be invoked so it isn't failing. > > 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. > > 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. > '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. > > 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). > > > 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. 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. 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. 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.9812021232280.463-100000>