From owner-freebsd-hackers Tue Feb 3 09:31:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA00345 for hackers-outgoing; Tue, 3 Feb 1998 09:31:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from seagull.rtd.com (dsiegel@seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA00340 for ; Tue, 3 Feb 1998 09:31:36 -0800 (PST) (envelope-from dave@rtd.net) Received: (from dsiegel@localhost) by seagull.rtd.com (8.8.5/8.8.5) id KAA12904; Tue, 3 Feb 1998 10:28:18 -0700 (MST) From: Dave Siegel Message-Id: <199802031728.KAA12904@seagull.rtd.com> Subject: Re: natd "strangness".. In-Reply-To: <199802020301.WAA02139@lakes.dignus.com> from Thomas David Rivers at "Feb 1, 98 10:01:27 pm" To: rivers@dignus.com (Thomas David Rivers) Date: Tue, 3 Feb 1998 10:28:18 -0700 (MST) Cc: freebsd-hackers@freefall.FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" > 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/