Date: Thu, 8 Feb 1996 10:56:24 +0000 (GMT) From: "Adam David" <adam@veda.is> To: olah@cs.utwente.nl (Andras Olah) Cc: wollman@lcs.mit.edu, freebsd-current@freebsd.org Subject: Re: TCP/IP interoperability problem, workaround Message-ID: <199602081056.KAA26615@veda.is> In-Reply-To: <6935.823768430@curie.cs.utwente.nl> from "Andras Olah" at Feb 8, 96 09:33:50 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > The problem that I had been experiencing with some TCP/IP connections not > > working (typically manifesting as input being received but output not being > > sent) can be worked around by setting the MTU to 552 on the relevant network > > interface. This problem started in -current sometime around Nov/Dec AFAIK > > Is it possible that some device on the path gets confused by MTU > discovery? Just a wild guess... Looks probable. The very next hop in our local network is a pcroute-derived router. If there are implementations out there that choke on MTU Discovery, is there a better failure mode than hanging the (output) connection? An MTU of 552 at either end of the connection was enough to prevent the hang, but this is only a workaround not a fix, since any network node might get confused if it doesn't handle MTU discovery. > On Tue, 05 Dec 1995 09:47:13 PST, "Garrett A. Wollman" wrote: > > wollman 95/12/05 09:47:09 > > > > Modified: sys/netinet in_rmx.c ip_icmp.c ip_output.c ip_var.h > > tcp_output.c tcp_subr.c tcp_var.h > > Log: > > Path MTU Discovery is now standard. -- Adam David <adam@veda.is>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602081056.KAA26615>