Date: Tue, 3 Feb 1998 10:28:18 -0700 (MST) From: Dave Siegel <dave@rtd.net> To: rivers@dignus.com (Thomas David Rivers) Cc: freebsd-hackers@freefall.FreeBSD.org Subject: Re: natd "strangness".. Message-ID: <199802031728.KAA12904@seagull.rtd.com> In-Reply-To: <199802020301.WAA02139@lakes.dignus.com> from Thomas David Rivers at "Feb 1, 98 10:01:27 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> I've done this by running netscape on both machines, pointing to the > same sight. The netscape running on 'ponds' will get to the site just > fine, while the one on 'lakes' will bail out after some time indicating > the server wasn't working... this is especially true for something like, > an audio stream for example. > The symptom is that a large "something" (graphics, audio, etc....) > takes much longer, or is even impossible to receive, on 'lakes' - while > it works just fine on 'ponds'... at exactly the same time. I'm no expert on the NAT stuff, but the symptoms that you describe sound exactly like what happens when hosts don't handle fragmentation and reassembly well. I remember early versions of linux (~1993) behaving in this way. It's possible that the NAT code isn't dealing with fragmented packets (which you get a lot of on a SLIP line, especially if you use the default MTU size). My guess is that natd was tested largely on ethernet's, running behind a T1 gateway or higher. If this is what's really happening, you can minimize the impact by increasing MTU on both sides of the SLIP link, particularly your upstream (ISP?). Have them change from the default of 256 to 1400 or so. This will slow down interactive stuff (telnet) but should speed up browsing, ftp's, etc. The theory here is that fewer packets will be fragmented, so you should have a higher success rate. Dave -- Dave Siegel dave@rtd.net Network Engineer dave@pager.rtd.com (alpha pager) (520)579-0450 (home office) http://www.rtd.com/~dsiegel/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802031728.KAA12904>