From owner-freebsd-net  Fri Feb 26  7:33:40 1999
Delivered-To: freebsd-net@freebsd.org
Received: from obie.softweyr.com (unknown [204.68.178.33])
	by hub.freebsd.org (Postfix) with ESMTP id 5573014FD1
	for <freebsd-net@FreeBSD.ORG>; Fri, 26 Feb 1999 07:33:36 -0800 (PST)
	(envelope-from wes@softweyr.com)
Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35])
	by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id IAA12126;
	Fri, 26 Feb 1999 08:31:45 -0700 (MST)
	(envelope-from wes@softweyr.com)
Message-ID: <36D6BE61.E64A2CEE@softweyr.com>
Date: Fri, 26 Feb 1999 08:31:45 -0700
From: Wes Peters <wes@softweyr.com>
Organization: Softweyr llc
X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: j.schripsema@kpn.com
Cc: freebsd-net@FreeBSD.ORG, sch@kpn.com
Subject: Re: TCP/IP stack question
References: <199902261347.OAA11430@sat-relay2.pc.telecom.ptt.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Jakob Schripsema wrote:
> 
> Hi,
> 
> Recently we ran into 2 TCP/IP-stack related problems with our
> 2.2.2-RELEASE based Firewall:
> 
> 1. An ARP related problem described in detail below
> 
> 2. A (minor) problem with IPFW and IP-fragmentation: we forgot to include
>    rules for IP-fragments.

You don't need rules for IP-fragments.  If you block the first frag, the
rest of the fragments will be dropped by the host.  Unless it has bugs,
which are a separate problem.  FreeBSD doesn't appear to.  ;^)

> These problems resulted in a number of arguments between FreeBSD lovers (me)
> and Linux lovers. (Comparable with the Z80 vs 6800 arguments from the old
> days ..). We have found 2 differences between the Linux stack and
> the 2.2.2 stack:
> 
> 1. Linux expects a per-interface arp cache, while 2.2.2. has a global
>    arp cache.

Neither is necessarily wrong.

> 2. Linux has the ability to do ip-reassembly before the firewall
>    code is used.

And the point of this would be?  IP packets aren't worms; if you cut
off the head, the rest of the packet dies.  ;^)

> This should work but the arp-request from MHH, packet 4, contains unexpected
> information:
> 
>         source hardware addres = mac3
>         source protocol address = ip2 (I expected ip3)

This is a bug in the Linux arp response code.  Get them to fix it.

>         destination hardawre addres = NULL
>         destination protocal addres = ip4
> 
> This packet forces the FW to change its arp-cache: the mac addres for ip2
> is set to mac3. This effectively blocks all traffic between PC end MHH

Replace Linux with FreeBSD?  Run whatever applications it's carrying
in compatiblity mode?  ;^)

-- 
       "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                 Softweyr LLC
http://www.softweyr.com/~softweyr                      wes@softweyr.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message