Date: Fri, 26 Feb 1999 14:47:06 +0100 From: Jakob Schripsema <sch@hdxf02.unix.telecom.ptt.nl> To: freebsd-net@freebsd.org Cc: sch@kpn.com Subject: TCP/IP stack question Message-ID: <199902261347.OAA11430@sat-relay2.pc.telecom.ptt.nl>
next in thread | raw e-mail | index | archive | help
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.
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.
2. Linux has the ability to do ip-reassembly before the firewall
code is used.
Are there changes between 2.2.2 and the more recent versions of FBSD
regarding these items ?? The problem with the IP-fragmentation is
minor, but the arp-problem is a real pain in the ass.
Regards,
Jakob Schripsema
ARP problem:
Network topology:
Production backbone
--------+----------------------------+-------------
| ---> 1 |
| <-- 2 |
mac1 | ---> 3 mac2 |
ip1 | ip2 |
.------------. .-------------.
| | | |
| FW | | MHH |
| | `-------------'
| | mac4 | ip3
| | ip4 | mac3
| |----------------------+--------
| | <--- 4 Maintenance backbone
`------------' ---> 5
| <--- 6
|
|
| FW: FreeBSD 2.2.2-RELEASE
.------------. MHH: Linux RedHAT 5.x
| |
| PC |
| |
`------------'
The firewall FW routes 'forward' traffic from PC to the ip2 via the
production backbone. The Multi-Homed-Host MHH routes the return traffic
via the maintenance backbone.
The FW reports changes in MAC address for the production interface of the
MHH, ip2. Running tcpdump on FW reveals the following scenario:
1. PC tries to connect to ip2 (HTTP request
2. FW issues an arp-request (asking for mac2) on the production
backbone: packet 1
3. MHH replies with an arp-reply: packet 2
4. FW sends first IP packet to MHH: packet 3
5. MHH issues an arp-request (asking for mac4) on the maintenance
backbone: packet 4
6. FW replies with an arp-reply: packet 5
7. MHH sends first IP return packet to FW: packet 6.
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)
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
Jakob
-----
Jakob Schripsema Phone:+31 50 5855537 E-mail:j.schripsema@kpn.com
DISCLAIMER: This statement is not an official statement from, nor does
it represent an official position of, KPN Telecom BV.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902261347.OAA11430>