[4550] in linux-net channel archive
Re: 2.0.21: TCP hangs solved by disabling Path MTU Discovery
daemon@ATHENA.MIT.EDU (rdm@tad.micro.umn.edu)
Fri Sep 27 16:38:39 1996
Date: 26 Sep 1996 15:50:31 -0000
From: rdm@tad.micro.umn.edu
To: "Derrick J. Brashear" <shadow@dementia.org>
Cc: linux-net@vger.rutgers.edu
Unknown person:
> > I recently reported that HTTP connections were hanging without
> > sending any data under 2.0.21. Alan Cox's suggestion of building with
> > Path MTU Discovery disabled has resolved that problem. Thanks
> > Alan, everything seems to be working fine now. I'll know for sure
> > tonight when cron runs the tape backup (which also failed under the
> > old kernel).
> > The Configure.help listing for Path MTU Discovery suggests it's
> > only useful for broken PC clients. But many non-local machines
> > including my PC running 2.0.20 failed to connect to this machine
> > until I rebuilt it as described. The machine is on a TCP/IP
> > network connected via a Cisco on a Frame Relay 56k
> > link. Since this is standard technology I'm uncertain why we ran
> > into the problem. Should Configure.help broaden it's description
> > of the Path MTU Discovery option or is there still a bug hiding
> > somewhere?...
Derrick J. Brashear:
> I put back a piece of code that had been if 0'd out around 2.0.16
> to get this to work with the path mtu discovery, but when I posted
> the patch as a possible fix for the PPP problems I was having,
> someone else posted that the patch was in there because it was
> making something break on his machine. Who knows? Note to
> sparclinux people: Perhaps path MTU should default to disabled? (I
> recall that it doesn't, but my SparcLinux box is, um, not here at
> the moment) -D
Maybe a better option would be to let the connection run with MTU
576, after a short delay, until Path MTU can complete? [Or do I
completely misunderstand the problem here?]
--
Raul
