Date: Mon, 4 Nov 2002 12:27:03 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Steve Francis <steve@expertcity.com> Cc: Agent Drek <drek@smashpow.net>, net@freebsd.org Subject: Re: MTU problems ... Message-ID: <Pine.BSF.4.21.0211041223400.63544-100000@InterJet.elischer.org> In-Reply-To: <3DC6A7BF.7010209@expertcity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 4 Nov 2002, Steve Francis wrote: > The problem below (which is still a problem in FreeBSD, but one that > will be rarely encountered) was caused by a load balancer in front of > the BSD boxes, that did not NAT part of the ICMP unreachable message > payload to the BSD's address. (The ICMP includes part of the original > datagram that caused the problem, and the load balancer did not > translate the sequence numbers, I think.) Its still a BSD problem (I'd > say) as if BSD hears the ICMP and reduces its MSS, it should not resend > the original packet at a size > MSS. > > So this could be your issue if your ISP is forcing all your traffic > through a proxy that does the same thing. > > A workaround would be disable PMTU-discovery. > > > Agent Drek wrote: > > hi, > > > > I'll start this off by claiming ignorance about the deep inner workings of > > tcp/ip. As such, this is not going to be a really technically detailed > > report. I will be more than happy to provide any info that might help in > > tracking this problem down though! > > > > The problem manifests as large downloads hanging (ftp/http/scp). The only > > way to make a download work is to choose an MTU setting on tun0 (this is > > a pppoe session) of the FreeBSD server (currently 4.6.2-Rel) until I find > > a value (1452, 1460, most things work at 1492 though) that makes the download > > complete properly. Sometimes finding an MTU that works is just not possible. > > The only icmp rule in ipfw is to allow all icmp so I am not unwittingly > > disallowing anything important. > > > > Could this thread be related to my problem? and was there any resolution > > with this? > > > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=61954+0+/usr/local/www/db/text/2002/freebsd-net/20020825.freebsd-net > > > > According to my ISP (and a few other ISP's in the area) only FreeBSD systems > > and certain IOS versions are experiencing this problem. > > > > What can I do to start debugging this? Please CC me as I am not subscribed > > to net@. > > > > cheers, > > TCPMSSD(8) FreeBSD System Manager's Manual TCPMSSD(8) NAME tcpmssd - TCP Maximum Segment Size option corrector SYNOPSIS tcpmssd [-v] -p port {-i iface | -m mtu} DESCRIPTION tcpmssd is a program that adjusts outgoing TCP SYN packets so that the maximum receive segment size is not greater than the amount allowed by the interface MTU. This is necessary in many setups to avoid problems caused by routers that drop ICMP ``Datagram Too Big'' messages, thus breaking Path MTU discovery algorithm (RFC 1191). Without these messages, the originating machine sends data, it passes the rogue router then hits a machine that has an MTU that is not big enough for the data. Because the IP ``don't fragment'' option is set, this machine sends an ICMP ``Datagram Too Big'' message back to the originator and drops the packet. The rogue router drops the ICMP and the originator never gets to discover that it must reduce the Path MTU value or exclude the IP ``don't fragment'' option from its outgoing data. tcpmssd normally runs in the background as a daemon. It intercept TCP packets from a divert(4) socket bound to the port specified with the -p option and reduces the value of TCP MSS option if necessary so that the incoming TCP messages will pass through this host without need to send ICMP ``Datagram Too Big'' messages. The maximum value for the TCP MSS option is determined based on a MTU given either as an absolute value with the -m option or derived from a network interface specified with the -i option. If run with the -v option, tcpmssd does not detach from its controlling terminal and writes various diagnostic messages to the standard error output. The following steps are necessary to run tcpmssd : 1. Build your kernel with the following options: options IPFIREWALL options IPDIVERT Refer to the Handbook for detailed instructions on building a custom kernel. 2. Make sure to redirect TCP traffic to the divert(4) port port. Refer to the ipfw(8) manual page for details. SEE ALSO divert(4), ipfw(8). AUTHORS This program was written by Ruslan Ermilov <ru@FreeBSD.org> based on work done by Patrick Bihan-Faou <patrick@mindstep.com>. FreeBSD July 17, 2000 FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" 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.21.0211041223400.63544-100000>