Skip site navigation (1)Skip section navigation (2)
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>