From owner-freebsd-hackers Mon Dec 7 11:52:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA06519 for freebsd-hackers-outgoing; Mon, 7 Dec 1998 11:52:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA06475 for ; Mon, 7 Dec 1998 11:52:12 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id LAA00142; Mon, 7 Dec 1998 11:47:15 -0800 (PST) (envelope-from marcs@znep.com) Date: Mon, 7 Dec 1998 11:47:15 -0800 (PST) From: Marc Slemko To: Ruslan Ermilov , Thomas David Rivers cc: hackers@FreeBSD.ORG Subject: Re: TCP bug In-Reply-To: <19981207163606.A7575@ucb.crimea.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 7 Dec 1998, Ruslan Ermilov wrote: > On Mon, Dec 07, 1998 at 11:11:16AM -0500, Thomas David Rivers wrote: > > > Umm. Have you tried to disable PMTU on your FreeBSD box? > > > > > > > Nope.. do you mean on the interior nodes or the gateway - or both? > > (Some of my interior nodes aren't FreeBSD... so I may not have that option.) > > > > I mean the FreeBSD box you are sitting on and from which you can't access > www.aol.com. That isn't overly likely to be an issue in this case. A tcpdump will show for sure the ack for that packet is getting back or not. On Mon, 7 Dec 1998, Thomas David Rivers wrote: > > On Mon, Dec 07, 1998 at 09:52:38AM -0500, Thomas David Rivers wrote: > > > Yes, it's a 3.0-RELEASE box. To change the MTU I simply specified > > > mtu 1500 on the ifconfig line for SL/IP. > > > > And your peer's MTU is equal to 1500 too, right? > > > > -- > > Ruslan > > > > Yep - I checked with them first. At least, my ISP claimed it was... Use ppp. It really makes stuff like this much easier since it actually supports negotiation for things. To check if the MTU is 1500, use: ping -s 1472 host-on-the-other-size while doing a tcpdump. Look to see if the response is fragmented or not. If it is fragmented, then the MTU isn't 1500. Note that someone stupidly changed -s so you have to be root to use it, which makes it a PITA to use ping for trying to debug network problems and really doesn't stop someone who wants to flood someone with traffic. On Mon, 7 Dec 1998, Thomas David Rivers wrote: > Ok - > > As I understood this discussion (which seemed clear to me); the > problem was that an internal node (behind the firewall) couldn't > get to some web sites because of fragmentation issues. The low > MTU at the firewall/gateway broke path MTU discovery.. > > > So - a possible work-around to the problem should be to set the > SL/IP MTU at 1500 at the gateway - right? That is one possible workaround if you are seeing the same problem. Does: marcs@alive:~$ telnet www.aol.com 80 Trying 152.163.210.28... Connected to aol.com. Escape character is '^]'. HEAD / HTTP/1.0 * * HTTP/1.0 200 OK MIME-Version: 1.0 Date: Mon, 07 Dec 1998 19:47:01 GMT Server: NaviServer/2.0 AOLserver/2.3 Content-Type: text/html Content-Length: 41177 Last-Modified: Mon, 07 Dec 1998 17:21:49 GMT Version: Mon, 07 Dec 1998 17:21:49 GMT Connection closed by foreign host. work? The lines with the * are what you enter, the second one is blank. On Mon, 7 Dec 1998, Ruslan Ermilov wrote: > On Mon, Dec 07, 1998 at 09:01:45AM -0500, Thomas David Rivers wrote: > > Ok - > > > > As I understood this discussion (which seemed clear to me); the > > problem was that an internal node (behind the firewall) couldn't > > get to some web sites because of fragmentation issues. The low > > MTU at the firewall/gateway broke path MTU discovery.. > > No, the problem is not with low MTU, but because AOL is blocking ICMP: > > PING aol.com (152.163.210.29): 56 data bytes > 36 bytes from www2-r10-P5-0-0.tpopr-rri.aol.com (152.163.133.6): Communication prohibited by filter > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > 4 5 00 5400 68cb 0 0000 ea 01 894d 194.93.177.113 152.163.210.29 > > ^C > --- aol.com ping statistics --- > 22 packets transmitted, 0 packets received, 100% packet loss While the blame should be assigned to someone who is filtering, it is important to note that just because you can't ping someone doesn't mean they are filtering all ICMP. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message