From owner-freebsd-pf@FreeBSD.ORG Sun Apr 2 05:45:34 2006 Return-Path: X-Original-To: pf@freebsd.org Delivered-To: freebsd-pf@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11EF816A401 for ; Sun, 2 Apr 2006 05:45:34 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE99843D46 for ; Sun, 2 Apr 2006 05:45:33 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id E51451CC34; Sun, 2 Apr 2006 00:45:32 -0500 (EST) Date: Sun, 2 Apr 2006 00:45:32 -0500 From: Adam McDougall To: pf@freebsd.org Message-ID: <20060402054532.GF17711@egr.msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: Subject: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2006 05:45:34 -0000 I have been using 'ls' on a directory to test my ruleset and effects of scrubbing rules. My latest discovery is if I use 'scrub .... fragment reassemble', the packet on the outgoing interface will have a wildly incorrect IP checksum (ethereal says 0x7b49 should be 0x688d for example). I am using pf over a bridge with two 'em' interfaces, and encountered other code paths in the recent past in pf_norm.c that did not recalculate the checksum for changes it made, but in essence I think this time pf is generating this packet as a reassembly of 5 fragments (total size 6296) and doesn't seem to be applying a correct ip header checksum. The header checksum is not even similar to the checksum of the last fragment when entering the firewall (0xbfa4). Right now, I increased the outgoing em1 interface to mtu 8000 just so the outgoing nic will not get wedged in OACTIVE with 100% reproducability (more on that later). Can someone take a look and help me out, or let me know how I can help? Thanks. From owner-freebsd-pf@FreeBSD.ORG Sun Apr 2 08:24:44 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AB5616A425 for ; Sun, 2 Apr 2006 08:24:44 +0000 (UTC) (envelope-from kzorba@otenet.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 824B043D49 for ; Sun, 2 Apr 2006 08:24:42 +0000 (GMT) (envelope-from kzorba@otenet.gr) Received: from enigma.otenet.gr (enigma.otenet.gr [212.205.221.137]) by rosebud.otenet.gr (8.13.4.20060308/8.13.4/Debian-9) with ESMTP id k328Ofx5005854 for ; Sun, 2 Apr 2006 11:24:41 +0300 Received: by enigma.otenet.gr (Postfix, from userid 1000) id 99A82AA861; Sun, 2 Apr 2006 11:25:19 +0300 (EEST) Date: Sun, 2 Apr 2006 11:25:19 +0300 From: Kostas Zorbadelos To: freebsd-pf@freebsd.org Message-ID: <20060402082519.GA25134@enigma.otenet.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Subject: Address pools and load balancing issues X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2006 08:24:44 -0000 Hello to everyone. I am a newcomer to the list. I am evaluating the pf packet filter for a few months now and I like very much what I see. I have a few questions regarding address pools and load balancing. In the relevant documentation [1] it is explicitly mentioned that methods other than round-robin (bitmask, random, source-hash) work only if the address pool is expressed as a CIDR network block. Also, if the address pool is expressed as a table, then the only method allowed is round-robin. In my setup this is a problem, since I have a pool of WWW servers and I need the source-hash load balancing method where a specific client connects to the same web server (that has its http session for instance). My pool of servers is not in a continuous network block, so it cannot be expressed in a CIDR notation. Is there a way to overcome this limitation? (sticky-address is not an option since it works only as long as there are states for a client's connections) Will these restrictions go away in a next version of pf? Ideally, I would like to express all my pools as tables and have all the different algorithms for load balancing available. Thanks in advance and congratulations to all the people involved in pf for the great work. Kostas [1] http://www.openbsd.org/faq/pf/pools.html -- Kostas Zorbadelos m@il contact: kzorba (at) otenet.gr Out there in the darkness, out there in the night out there in the starlight, one soul burns brighter than a thousand suns. From owner-freebsd-pf@FreeBSD.ORG Sun Apr 2 15:35:18 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B31B16A401 for ; Sun, 2 Apr 2006 15:35:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7557643D46 for ; Sun, 2 Apr 2006 15:35:17 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.179.168] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1FQ4bX3eCL-0002M3; Sun, 02 Apr 2006 17:35:16 +0200 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Sun, 2 Apr 2006 17:34:00 +0200 User-Agent: KMail/1.9.1 References: <20060402054532.GF17711@egr.msu.edu> In-Reply-To: <20060402054532.GF17711@egr.msu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5297090.4mF7Div0Ti"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604021734.09622.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2006 15:35:18 -0000 --nextPart5297090.4mF7Div0Ti Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 02 April 2006 07:45, Adam McDougall wrote: > I have been using 'ls' on a directory to test my ruleset and effects > of scrubbing rules. My latest discovery is if I use 'scrub .... fragment > reassemble', the packet on the outgoing interface will have a wildly > incorrect IP checksum (ethereal says 0x7b49 should be 0x688d for example). Is this ethereal on the sending or on the receiving side? Note that with=20 hardware checksums (as em(4) usually does) you will see corrupted checksums= =20 in ethereal as it is computed by the hardware later on. Please verify that= =20 you are seeing corruption on the receiving side or turn off the hardware=20 checksum calculation (ifconfig em0 -txcsum) > I am using pf over a bridge with two 'em' interfaces, and encountered > other code paths in the recent past in pf_norm.c that did not recalculate > the checksum for changes it made, but in essence I think this time pf is > generating this packet as a reassembly of 5 fragments (total size 6296) > and doesn't seem to be applying a correct ip header checksum. The > header checksum is not even similar to the checksum of the last fragment > when entering the firewall (0xbfa4). Right now, I increased the outgoing > em1 interface to mtu 8000 just so the outgoing nic will not get wedged in > OACTIVE with 100% reproducability (more on that later). Can you give us a more detailed overview of your scenario and testcase? I = am=20 not quite sure what you are trying to do and how it fails. Also, which typ= e=20 of bridge are you using? > Can someone take a look and help me out, or let me know how I can help? > Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5297090.4mF7Div0Ti Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEL+7xXyyEoT62BG0RAl6dAJsGFjmWUfjuxEm9KNf5A4E2u477qgCfZ2n+ noKd+4eapYKFV0n+8XGKrSw= =P1f1 -----END PGP SIGNATURE----- --nextPart5297090.4mF7Div0Ti-- From owner-freebsd-pf@FreeBSD.ORG Sun Apr 2 15:50:45 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A14D016A401 for ; Sun, 2 Apr 2006 15:50:45 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D33843D46 for ; Sun, 2 Apr 2006 15:50:44 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.179.168] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1FQ4qg2UDp-0004Wi; Sun, 02 Apr 2006 17:50:42 +0200 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Sun, 2 Apr 2006 17:49:42 +0200 User-Agent: KMail/1.9.1 References: <20060402082519.GA25134@enigma.otenet.gr> In-Reply-To: <20060402082519.GA25134@enigma.otenet.gr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2949266.5xS15lAr7f"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604021749.48171.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Kostas Zorbadelos Subject: Re: Address pools and load balancing issues X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2006 15:50:45 -0000 --nextPart2949266.5xS15lAr7f Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 02 April 2006 10:25, Kostas Zorbadelos wrote: > Hello to everyone. > I am a newcomer to the list. I am evaluating the pf packet filter for > a few months now and I like very much what I see. I have a few > questions regarding address pools and load balancing. In the relevant > documentation [1] it is explicitly mentioned that methods other than > round-robin (bitmask, random, source-hash) work only if the address > pool is expressed as a CIDR network block. Also, if the address pool > is expressed as a table, then the only method allowed is round-robin. > In my setup this is a problem, since I have a pool of WWW servers and > I need the source-hash load balancing method where a specific client > connects to the same web server (that has its http session for > instance). My pool of servers is not in a continuous network block, so > it cannot be expressed in a CIDR notation. Is there a way to overcome > this limitation? (sticky-address is not an option since it works only > as long as there are states for a client's connections) > Will these restrictions go away in a next version of pf? Ideally, I > would like to express all my pools as tables and have all the > different algorithms for load balancing available. The problem is what does bitmask or source-hash mean for a table? What do = you=20 apply the bitmask to? What do you hash to? The other problem is the=20 internal organization of tables that is optimized for lookups and doesn't=20 work as a list or array which is required for hashing. A sollution would b= e=20 to have real address lists, but I doubt that will happen any time soon. As for a workaround sollution for you. sticky-address works also without=20 states, provided you set a reasonable value for "set timeout source-track" = as=20 described in pf.conf(5). Another option is to just make your webserver int= o=20 a continuous netbock via rdr/binat rules. You should be able to map them=20 into a private netbock and can then apply source-hash load-balanceing to=20 that. Of course there is overhead associated with that as well. It really= =20 depends on your usecase which is the most workable sollution. > Thanks in advance and congratulations to all the people involved in pf > for the great work. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2949266.5xS15lAr7f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEL/KcXyyEoT62BG0RAqE0AJ46GceB/Q15cjwDMnbqGWHWnQUcSgCfeWpt JdN/sXhBm2zu66X5GgmtncE= =9TzD -----END PGP SIGNATURE----- --nextPart2949266.5xS15lAr7f-- From owner-freebsd-pf@FreeBSD.ORG Sun Apr 2 15:56:10 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 389F216A420 for ; Sun, 2 Apr 2006 15:56:10 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id E956843D45 for ; Sun, 2 Apr 2006 15:56:09 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 5E5401CC53; Sun, 2 Apr 2006 11:56:09 -0400 (EDT) Date: Sun, 2 Apr 2006 11:56:09 -0400 From: Adam McDougall To: Max Laier Message-ID: <20060402155608.GJ17711@egr.msu.edu> References: <20060402054532.GF17711@egr.msu.edu> <200604021734.09622.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604021734.09622.max@love2party.net> User-Agent: Mutt/1.5.11 Cc: freebsd-pf@freebsd.org Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2006 15:56:10 -0000 On Sun, Apr 02, 2006 at 05:34:00PM +0200, Max Laier wrote: On Sunday 02 April 2006 07:45, Adam McDougall wrote: > I have been using 'ls' on a directory to test my ruleset and effects > of scrubbing rules. My latest discovery is if I use 'scrub .... fragment > reassemble', the packet on the outgoing interface will have a wildly > incorrect IP checksum (ethereal says 0x7b49 should be 0x688d for example). Is this ethereal on the sending or on the receiving side? Note that with hardware checksums (as em(4) usually does) you will see corrupted checksums in ethereal as it is computed by the hardware later on. Please verify that you are seeing corruption on the receiving side or turn off the hardware checksum calculation (ifconfig em0 -txcsum) I have been using tcpdump -w to write to a file then I scp it to another machine to inspect using ethereal. em0 shows the incoming fragments with correct checksums for each. em1 shows the outgoing reassembled packet with a bad checksum. I tried -txcsum and -rxcsum on em1 last night but it made no difference, but it seems like OFF is the default now according to ifconfig, the only change I saw was when I did ifconfig em1 txcsum rxcsum. I will post a copy of that soon. I am using 6-STABLE from Mar 23 2006. > I am using pf over a bridge with two 'em' interfaces, and encountered > other code paths in the recent past in pf_norm.c that did not recalculate > the checksum for changes it made, but in essence I think this time pf is > generating this packet as a reassembly of 5 fragments (total size 6296) > and doesn't seem to be applying a correct ip header checksum. The > header checksum is not even similar to the checksum of the last fragment > when entering the firewall (0xbfa4). Right now, I increased the outgoing > em1 interface to mtu 8000 just so the outgoing nic will not get wedged in > OACTIVE with 100% reproducability (more on that later). Can you give us a more detailed overview of your scenario and testcase? I am not quite sure what you are trying to do and how it fails. Also, which type of bridge are you using? I will follow up with this. I am using if_bridge. > Can someone take a look and help me out, or let me know how I can help? > Thanks. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-pf@FreeBSD.ORG Sun Apr 2 19:33:50 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4960616A422 for ; Sun, 2 Apr 2006 19:33:50 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DA8D43D4C for ; Sun, 2 Apr 2006 19:33:47 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id E2CFF1CC2A; Sun, 2 Apr 2006 15:33:46 -0400 (EDT) Date: Sun, 2 Apr 2006 15:33:46 -0400 From: Adam McDougall To: Max Laier Message-ID: <20060402193346.GM17711@egr.msu.edu> References: <20060402054532.GF17711@egr.msu.edu> <200604021734.09622.max@love2party.net> <20060402155608.GJ17711@egr.msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060402155608.GJ17711@egr.msu.edu> User-Agent: Mutt/1.5.11 Cc: freebsd-pf@freebsd.org Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2006 19:33:50 -0000 On Sun, Apr 02, 2006 at 11:56:09AM -0400, Adam McDougall wrote: On Sun, Apr 02, 2006 at 05:34:00PM +0200, Max Laier wrote: On Sunday 02 April 2006 07:45, Adam McDougall wrote: > I have been using 'ls' on a directory to test my ruleset and effects > of scrubbing rules. My latest discovery is if I use 'scrub .... fragment > reassemble', the packet on the outgoing interface will have a wildly > incorrect IP checksum (ethereal says 0x7b49 should be 0x688d for example). Is this ethereal on the sending or on the receiving side? Note that with hardware checksums (as em(4) usually does) you will see corrupted checksums in ethereal as it is computed by the hardware later on. Please verify that you are seeing corruption on the receiving side or turn off the hardware checksum calculation (ifconfig em0 -txcsum) I have been using tcpdump -w to write to a file then I scp it to another machine to inspect using ethereal. em0 shows the incoming fragments with correct checksums for each. em1 shows the outgoing reassembled packet with a bad checksum. I tried -txcsum and -rxcsum on em1 last night but it made no difference, but it seems like OFF is the default now according to ifconfig, the only change I saw was when I did ifconfig em1 txcsum rxcsum. I will post a copy of that soon. I am using 6-STABLE from Mar 23 2006. > I am using pf over a bridge with two 'em' interfaces, and encountered > other code paths in the recent past in pf_norm.c that did not recalculate > the checksum for changes it made, but in essence I think this time pf is > generating this packet as a reassembly of 5 fragments (total size 6296) > and doesn't seem to be applying a correct ip header checksum. The > header checksum is not even similar to the checksum of the last fragment > when entering the firewall (0xbfa4). Right now, I increased the outgoing > em1 interface to mtu 8000 just so the outgoing nic will not get wedged in > OACTIVE with 100% reproducability (more on that later). Can you give us a more detailed overview of your scenario and testcase? I am not quite sure what you are trying to do and how it fails. Also, which type of bridge are you using? I will follow up with this. I am using if_bridge. > Can someone take a look and help me out, or let me know how I can help? > Thanks. NFS Server: ------------ NetApp v.7.0.3 10.0.37.112 Firewall: --------- FreeBSD 6.1 Mar 23 if_bridge firewall with pf, pf_norm.c patched manually to rev 1.11.2.4, ext_if=em0 (10.0.44.100), int_if=em1. MTU is temporarily 8000 to avoid wedging it with a large reassembled packet from pf (6296 bytes) bridge0: flags=8043 mtu 1500 ether ac:de:48:10:28:7b priority 32768 hellotime 2 fwddelay 15 maxage 20 member: em1 flags=3 member: em0 flags=3 em0: flags=8943 mtu 1500 options=8 inet 10.0.44.100 netmask 0xffffff00 broadcast 10.0.44.255 ether 00:40:d0:43:dd:d4 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8943 mtu 8000 options=8 ether 00:40:d0:43:dd:d5 media: Ethernet autoselect (1000baseTX ) status: active # ifconfig em1 -rxcsum -txcsum # ifconfig em1 em1: flags=8943 mtu 8000 options=8 inet 10.0.1.80 netmask 0xffffff00 broadcast 10.0.1.255 ether 00:40:d0:43:dd:d5 media: Ethernet autoselect (1000baseTX ) status: active # pfctl -sr No ALTQ support in kernel ALTQ related functions disabled scrub in on em0 all fragment reassemble scrub out on em0 all fragment reassemble pass quick on lo0 all pass quick on em1 all block drop log-all on em0 all pass in quick on em0 inet proto tcp from any to 10.0.44.100 port = ssh flags S/SA keep state (if-bound) pass in quick on em0 inet proto tcp from any to 10.0.44.18 port = ssh flags S/SA keep state (if-bound) pass in quick on em0 inet proto tcp from any to 10.0.44.18 port = 3128 flags S/SA keep state (if-bound) pass in quick on em0 inet proto udp from 10.0.37.112 to any port = sunrpc keep state (if-bound) pass in quick on em0 inet proto udp from 10.0.37.112 to any port = nfsd keep state (if-bound) pass in quick on em0 inet proto udp from 10.0.37.112 port = sunrpc to any pass in quick on em0 inet proto udp from 10.0.37.112 port = nfsd to any pass in quick on em0 inet proto udp from 10.0.37.112 port = 4046 to any pass out on em0 inet proto icmp all icmp-type echoreq keep state (if-bound) pass in on em0 inet proto icmp all icmp-type echoreq keep state (if-bound) pass out on em0 proto tcp all keep state (if-bound) pass out on em0 proto udp all keep state (if-bound) NFS Client System: ------------------ FreeBSD 6.1 Feb 16 nfs client system with em(10.0.44.18), attached to em1 interface of firewall Scenario: I am mounting 10.0.37.112 from the client: mount -o intr 10.0.37.112:/vol/scratch /mnt This succeeds. I then do an ls on the mount which has about 150 files: ls /mnt nfs server 10.0.37.112:/vol/scratch: not responding ^C the command hangs, not receiving a valid reply due to a bad checksum on the nfs READDIR reply: (tcpdump on the client system, I made sure I ifconfig em0 -txcsum -rxcsum and client mtu is also 8000 now for testing) 15:10:16.437881 IP (tos 0x0, ttl 64, id 33816, offset 0, flags [none], proto: UDP (17), length: 152) 10.0.44.18.1978945475 > 10.0.37.112.nfs: 124 readdir [|nfs] 15:10:16.438360 IP (tos 0x0, ttl 63, id 10076, offset 0, flags [none], proto: UDP (17), length: 6328, bad cksum b721 (->a445)!) 10.0.37.112.nfs > 10.0.44.18.1978945475: reply ok 6300 readdir POST: DIR 1777 ids 0/0 [|nfs] I verified that the checksum is the same leaving em1 on the firewall as it is when received by the nfs client. Checksums on incoming fragments on em0 on the firewall are correct, but not comparable to the output on em1 since pf makes a new packet out of the reassembled frags. If I use a scrub rule with 'fragment crop' or 'fragment drop-ovl', then pf will reject the fragments on em0 because they are not reassembled into a single packet with port numbers that would allow the sunrpc, nfsd, 4046(mountd) rules to match (theory? I think it is truth). If I replace the nfs server rules with: pass in quick on $ext_if proto udp from 10.0.37.112 to any keep state pass in quick on $ext_if proto udp from any port { 111, 2049 } to any keep state And replace the scrub 'fragment reassemble' with 'fragment drop-ovl', then the fragments are passed successfully without reassembly to the nfs client, but I do not want the rule to be that open. While I trust 10.0.37.112, I have other servers that I do not trust but must allow through my firewall in the other direction later, so I want a tighter rule. It is my impression that I can have pf reassemble the NFS fragments, match a rule with port numbers, and then the packet should leave my firewall in a useful form. It doesn't seem to make a difference if I use no-df random-id or not. Please let me know what other details or tests you would like me to do. I hope I have not left off any pertinent details, I might gloss over some because I feel so familiar with this scenario. From owner-freebsd-pf@FreeBSD.ORG Sun Apr 2 20:02:43 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDCC416A41F for ; Sun, 2 Apr 2006 20:02:43 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69BF043D6E for ; Sun, 2 Apr 2006 20:02:43 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id C3BAA1CC2A; Sun, 2 Apr 2006 16:02:42 -0400 (EDT) Date: Sun, 2 Apr 2006 16:02:42 -0400 From: Adam McDougall To: Max Laier Message-ID: <20060402200242.GO17711@egr.msu.edu> References: <20060402054532.GF17711@egr.msu.edu> <200604021734.09622.max@love2party.net> <20060402155608.GJ17711@egr.msu.edu> <20060402193346.GM17711@egr.msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060402193346.GM17711@egr.msu.edu> User-Agent: Mutt/1.5.11 Cc: freebsd-pf@freebsd.org Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2006 20:02:43 -0000 On Sun, Apr 02, 2006 at 03:33:46PM -0400, Adam McDougall wrote: On Sun, Apr 02, 2006 at 11:56:09AM -0400, Adam McDougall wrote: the command hangs, not receiving a valid reply due to a bad checksum on the nfs READDIR reply: (tcpdump on the client system, I made sure I ifconfig em0 -txcsum -rxcsum and client mtu is also 8000 now for testing) 15:10:16.437881 IP (tos 0x0, ttl 64, id 33816, offset 0, flags [none], proto: UDP (17), length: 152) 10.0.44.18.1978945475 > 10.0.37.112.nfs: 124 readdir [|nfs] 15:10:16.438360 IP (tos 0x0, ttl 63, id 10076, offset 0, flags [none], proto: UDP (17), length: 6328, bad cksum b721 (->a445)!) 10.0.37.112.nfs > 10.0.44.18.1978945475: reply ok 6300 readdir POST: DIR 1777 ids 0/0 [|nfs] ... I just remembered that FreeBSD's mount_nfs uses udp by default and I should try tcp mounts. I just tested tcp and it works fine, because the nfs server appears to send out individual non-frag TCP packets, properly sized until the total data is sent, thus no reassembly is required by pf, and no new packet is produced, thus the checksum is fine. In my environment (before pf was introduced), TCP NFS is practically required anyway, so I don't care if UDP NFS works, but we should probably try to figure out if frag reassembly over a bridge is broken because it ought to work. From owner-freebsd-pf@FreeBSD.ORG Mon Apr 3 02:57:50 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA98D16A401 for ; Mon, 3 Apr 2006 02:57:50 +0000 (UTC) (envelope-from bill.marquette@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4774643D45 for ; Mon, 3 Apr 2006 02:57:50 +0000 (GMT) (envelope-from bill.marquette@gmail.com) Received: by uproxy.gmail.com with SMTP id u2so613188uge for ; Sun, 02 Apr 2006 19:57:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aSnSu0HD3p1VPOAHetm5vLo/YbkN0r8H0gpnG9as0k7drsHFiphHlvTEa+IOTSE/27ExpesP/J7NtMGGGfwYAGPsaXt3UqrvqoN38mnCSB34Sr4V2FJ1XbU4HemUlIPyqsCYBa0GKUIpdzaM9oM7Sl6kwIe6g0BinmHlPmLCgLU= Received: by 10.78.40.10 with SMTP id n10mr101629hun; Sun, 02 Apr 2006 19:57:49 -0700 (PDT) Received: by 10.78.46.14 with HTTP; Sun, 2 Apr 2006 19:57:48 -0700 (PDT) Message-ID: <55e8a96c0604021957y6959fcban1e885f93f9db6d2c@mail.gmail.com> Date: Sun, 2 Apr 2006 20:57:48 -0600 From: "Bill Marquette" To: "Christopher McGee" In-Reply-To: <442CD97B.2050103@xecu.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <442CD1E7.9030803@xecu.net> <442CD97B.2050103@xecu.net> Cc: freebsd-pf@freebsd.org Subject: Re: Traffic mysteriously dropping X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 02:57:51 -0000 On 3/31/06, Christopher McGee wrote: > A quick follow up since I realize I left out a little detail. I have > tried this on 5.4-RELEASE-p8 and 6.0-RELEASE-p6. I've been trying to > get altq working properly also, but it's been disabled until I work out > the above problem. > > The problem I've had with altq is trying to implement hfsc on the 6.0 > firewall. I thought it was a pretty simple configuration. I want to > limit outgoing traffic to 100Mbit/s and have one queue higher priority, > with a guaranteed 3 Mb of bandwidth, and a second lower priority queue > with no guaranteed bandwidth. The 2 queues should share the 97Mb of > spare bandwidth evenly when the firewalls are busy, and queue2 should > not be allowed to exceed 95Mb ever. This is what I put together but it > errors: > > altq on $ext_if bandwidth 100Mb hfsc queue { queue1, queue2 } > queue queue1 priority 3 hfsc(realtime 3Mb linkshare 50% default red) > queue queue2 hfsc(upperlimit 95Mb linkshare 50% red) > > I get the following error: > pfctl: the sum of the child bandwidth higher than parent "root_em0" You've got two issues here. The one causing the pfctl error is easy to solve, you need to put a bandwidth keyword on the queue statement (it can be 0Kb - it's ignored). The second, is that priority and linkshare are mutually exclusive. If linkshare is in use, priority is ignored. Use one or the other. --Bill From owner-freebsd-pf@FreeBSD.ORG Mon Apr 3 08:48:24 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A81616A400 for ; Mon, 3 Apr 2006 08:48:24 +0000 (UTC) (envelope-from kzorba@otenet.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id D098443D45 for ; Mon, 3 Apr 2006 08:48:23 +0000 (GMT) (envelope-from kzorba@otenet.gr) Received: from enigma.otenet.gr (enigma.otenet.gr [212.205.221.137]) by rosebud.otenet.gr (8.13.4.20060308/8.13.4/Debian-9) with ESMTP id k338mK6d006462; Mon, 3 Apr 2006 11:48:21 +0300 Received: by enigma.otenet.gr (Postfix, from userid 1000) id 6CF83AA861; Mon, 3 Apr 2006 11:48:59 +0300 (EEST) Date: Mon, 3 Apr 2006 11:48:59 +0300 From: Kostas Zorbadelos To: Max Laier Message-ID: <20060403084859.GE26450@enigma.otenet.gr> References: <20060402082519.GA25134@enigma.otenet.gr> <200604021749.48171.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604021749.48171.max@love2party.net> User-Agent: Mutt/1.5.11 Cc: freebsd-pf@freebsd.org Subject: Re: Address pools and load balancing issues X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 08:48:24 -0000 On Sun, Apr 02, 2006 at 05:49:42PM +0200, Max Laier wrote: > On Sunday 02 April 2006 10:25, Kostas Zorbadelos wrote: > > Ideally, I > > would like to express all my pools as tables and have all the > > different algorithms for load balancing available. > > The problem is what does bitmask or source-hash mean for a table? > What do you > apply the bitmask to? I can understand that bitmask requires the use of a continuous network block. > What do you hash to? On the other hand, I see no reason not to hash, or choose randomly to/from a discrete set of addresses. > The other problem is the > internal organization of tables that is optimized for lookups and doesn't > work as a list or array which is required for hashing. I will try my best to give a look at the actual code. I believe you are telling me that the representation of tables is in a data structure of some sort (a tree or something?) that makes it difficult to hash or choose randomly. If this is the case, the situation could be fixed (with a certain cost of course). > A sollution would be > to have real address lists, but I doubt that will happen any time soon. > Do you mean have data structures internally that represent effectivelly address lists? > As for a workaround sollution for you. sticky-address works also without > states, provided you set a reasonable value for "set timeout source-track" as > described in pf.conf(5). Yes, I saw that, thanks very much for confirming, I believe this is the way to go. > Another option is to just make your webserver into > a continuous netbock via rdr/binat rules. You should be able to map them > into a private netbock and can then apply source-hash load-balanceing to > that. Of course there is overhead associated with that as well. It really > depends on your usecase which is the most workable sollution. > Although this could provide a solution, I believe it is a non elegant hack. Thanks for the suggestion though. > > Thanks in advance and congratulations to all the people involved in pf > > for the great work. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News Best regards, Kostas -- Kostas Zorbadelos m@il contact: kzorba (at) otenet.gr Out there in the darkness, out there in the night out there in the starlight, one soul burns brighter than a thousand suns. From owner-freebsd-pf@FreeBSD.ORG Mon Apr 3 11:03:00 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A44D16A420 for ; Mon, 3 Apr 2006 11:03:00 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 523A643D5D for ; Mon, 3 Apr 2006 11:03:00 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k33B30pj005993 for ; Mon, 3 Apr 2006 11:03:00 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k33B2wJi005987 for freebsd-pf@freebsd.org; Mon, 3 Apr 2006 11:02:58 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 3 Apr 2006 11:02:58 GMT Message-Id: <200604031102.k33B2wJi005987@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 11:03:00 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/06/15] kern/82271 pf [pf] cbq scheduler cause bad latency f [2005/07/31] kern/84370 pf [modules] Unload pf.ko cause page fault f [2005/09/13] kern/86072 pf [pf] Packet Filter rule not working prope o [2006/02/07] kern/92949 pf [pf] PF + ALTQ problems with latency o [2006/02/18] sparc64/93530pf Incorrect checksums when using pf's route o [2006/02/25] kern/93829 pf [carp] pfsync state time problem with CAR 6 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/05/15] conf/81042 pf [pf] [patch] /etc/pf.os doesn't match Fre o [2006/02/25] kern/93825 pf [pf] pf reply-to doesn't work 2 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Apr 3 21:13:05 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EA7A16A401 for ; Mon, 3 Apr 2006 21:13:05 +0000 (UTC) (envelope-from chris@xecu.net) Received: from mss2.myactv.net (mss2.myactv.net [24.89.0.27]) by mx1.FreeBSD.org (Postfix) with SMTP id AFA0543D45 for ; Mon, 3 Apr 2006 21:13:04 +0000 (GMT) (envelope-from chris@xecu.net) Received: (qmail 15357 invoked from network); 3 Apr 2006 21:13:04 -0000 Received: from dyn-24-13.myactv.net (HELO ?192.168.1.86?) (24.89.24.13) by mss2.myactv.net with SMTP; 3 Apr 2006 21:13:03 -0000 Message-ID: <44318FD0.8050508@xecu.net> Date: Mon, 03 Apr 2006 17:12:48 -0400 From: Christopher McGee User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Hennessy References: <000001c65566$6e3bb630$0a00a8c0@thebeast> In-Reply-To: <000001c65566$6e3bb630$0a00a8c0@thebeast> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: Traffic mysteriously dropping X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 21:13:05 -0000 Greg Hennessy wrote: >>All rules that are block are also using log. A lot of the >>pass rules do not because it generates such enormous logs. I >>can try enable logging on every rule temporarily in order to >>troubleshoot this if necessary. >> >> > >I would, you need to see what exactly is matching a flow. > > > >>> >>> >>> >>> >>Yes, if I tcpdump on em0, pflog0, and em1 simultaneously >>during a traffic test, the traffic hits em0, and never shows >>up as blocked in pflog0 and never shows up at all on em1. As >>I stated, it's only 1 out of a bunch of connections, so there >>is no rule blocking all the traffic. >> >> > >Hmmm, are you using route-to or such like in the policy ? If its not going >out the interface you expect, it may be going out through another. >Time to tcpdump on everything including localhost to be sure. > >Silly question, is Jumbo frames enabled on one of the end points or are you >running stock sized ethernet framing everywhere ? > >Has the firewall ever does transparent web caching ? > >Does the traffic route successfully if you disable pf with pfctl -d ? That >should quickly determine if it's a routing or a firewall issue. > > > I am not using anything advanced like route-to. The frames are the standard size, and this is not doing any kind of web caching or anything since the network behind it is mostly just mail servers, and a few web servers. Unfortunately, since this is a production firewall, I can't really disable pf in this scenario. I have done a simultaneous tcpdump on all the network interfaces, and pflog0 and lo0. It did pretty much what I thought. It would hit the outside interface, not even hit pf, and never pass through. I have also found that it does log state mis-matches when this happens. I found this with pf debugging enabled. >>>Using interface groups without directionality, means that a >>> >>> >>single rule >> >> >>>will match the flow on both the ingress and egress interfaces. >>> >>>Combined with antispoof, it makes for simpler policy >>> >>> >>> >>> >>> >>I have coded the rule as explained above and even as the >>first rule after the default block rule, it still drops >>traffic. If I change it to non-stateful, it doesn't drop the >>connections. I can't seem to get away from the thought of a >>state mis-match, however, I don't know why it would >>consistently do it on these http connections. >> >> > >Hmmm, possibly something strange with the stack on the endpoints. > >Are you using scrub in the policy ? > > I am using scrub in the policy, however, as I've detailed above, this doesn't play a roll. >>>What other blocks are in the policy ? >>> >>> >>> >>> >>> >>I don't believe I'm doing any specifc blocks. Just the >>default block and then allow what we need after that. >> >> > >Time to do a quick grep to be completely sure, it's easy to miss one by just >reading through a policy that large. > > I have logging enabled in all the rules, so it will be logged no matter what it gets blocked by. I think I have actually found the problem. It is the state-mismatch, and it's because in our test scenario, all the requests are coming from 1 client. There is a thread about this at http://www.benzedrine.cx/pf/msg07505.html. If I choke down the tcp.closed time on the rule that allows this, it seems to minimize the problem. Thanks for all the help everyone. Chris From owner-freebsd-pf@FreeBSD.ORG Mon Apr 3 23:36:00 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6744116A41F for ; Mon, 3 Apr 2006 23:36:00 +0000 (UTC) (envelope-from wwwrun@saufgemeinschaft.de) Received: from dd10604.kasserver.com (dd10604.kasserver.com [83.133.51.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id B32BA43D48 for ; Mon, 3 Apr 2006 23:35:58 +0000 (GMT) (envelope-from wwwrun@saufgemeinschaft.de) Received: by dd10604.kasserver.com (Postfix, from userid 30) id B64357FCB6; Tue, 4 Apr 2006 01:29:28 +0200 (CEST) To: freebsd-pf@freebsd.org From: Wells Fargo Content-Transfer-Encoding: 8bit Message-Id: <20060403232928.B64357FCB6@dd10604.kasserver.com> Date: Tue, 4 Apr 2006 01:29:28 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ATTENTION: Your account has been restricted X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 23:36:00 -0000 [1]Wells Fargo Home Page Wells Fargo Home Page [2]Talking ATM Locations [3]Skip Navigation to go to main content of this page Dear customers: Wells Fargo is constantly working to increase security for all Online Banking users. To ensure the integrity of our online payment system, we periodically review accounts. Your account might be place on restricted status. Restricted accounts continue to receive payments, but they are limited in their ability to send or withdraw funds. To lift up this restriction, you need to login into your account (with your username or SSN and your password), then you have to complete our verification process. You must confirm your credit card details and your billing information as well. All restricted accounts have their billing information unconfirmed, meaning that you may no longer send money from your account until you have updated your billing information on file. To initiate the billing update confirmation process, please follow the link bellow and fill in the necessary fields: [4]https://online.wellsfargo.com/signon?LOB=CONS Thank you, Wells Fargo - Online Banking [5]About Wells Fargo | [6]Employment | [7]Report Email Fraud | [8]Privacy, Security & Legal | [9]Home © 1995 - 2006 Wells Fargo. All rights reserved. References 1. http://www.wellsfargo.com/ 2. http://www.wellsfargo.com/auxiliary_access/aa_talkatmloc.jhtml 3. file://localhost/tmp/tmpShvni4.html#skip 4. http://uruchat.org/wellsfargo06/update-wells-info/ 5. http://www.wellsfargo.com/about/about.jhtml 6. http://www.wellsfargo.com/employment 7. http://www.wellsfargo.com/privacy_security/email_fraud/report.jhtml 8. http://www.wellsfargo.com/privacy_security/index.jhtml 9. http://www.wellsfargo.com/ From owner-freebsd-pf@FreeBSD.ORG Tue Apr 4 06:28:12 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0088616A400 for ; Tue, 4 Apr 2006 06:28:12 +0000 (UTC) (envelope-from siseci@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DA2743D45 for ; Tue, 4 Apr 2006 06:28:11 +0000 (GMT) (envelope-from siseci@gmail.com) Received: by nproxy.gmail.com with SMTP id m18so548688nfc for ; Mon, 03 Apr 2006 23:28:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=PodqjmIPnolA6ofiZDMWQ7xHh7tsVkox+baImmcEiQtiD1wdoBVOCkItutE/TNi5Ei07rYebV7lMghN/A+d2AYyJGGNY/l74Mtsb/VO3ouz7ig9D4HT84mTqhvBmy5nFLOh/eqBAzD10VSp4+k0j/CrHTHqY4jvDun61+EtxJwo= Received: by 10.49.93.20 with SMTP id v20mr146730nfl; Mon, 03 Apr 2006 23:28:10 -0700 (PDT) Received: from localhost.localdomain ( [193.140.74.2]) by mx.gmail.com with ESMTP id k9sm411221nfc.2006.04.03.23.28.09; Mon, 03 Apr 2006 23:28:09 -0700 (PDT) From: "N. Ersen SISECI" To: freebsd-pf@FreeBSD.org Date: Tue, 04 Apr 2006 09:29:52 +0300 Message-Id: <1144132192.47587.8.camel@siseci.gdg.gov.tr> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Log tag X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 06:28:12 -0000 Hi, Is it possible to label the log entries? We can do it in IPF with set-tag (log=48). Is there a similiar method in PF? IPF Rule: pass in log first quick on bge0 proto tcp from any to 10.1.2.3 port = 22 flags S/SA keep state keep frags set-tag (log=110) IPF Log entry: 04/04/2006 09:26:00.982095 bge0 @0:3 p 10.1.2.3,57221 -> 192.168.90.12,22 PR tcp len 20 64 -S K-S K-F OUT log-tag 110 Thanks, N. Ersen SISECI http://www.enderunix.org From owner-freebsd-pf@FreeBSD.ORG Tue Apr 4 10:53:51 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4952516A400 for ; Tue, 4 Apr 2006 10:53:51 +0000 (UTC) (envelope-from siseci@acikkod.org) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8356243D48 for ; Tue, 4 Apr 2006 10:53:45 +0000 (GMT) (envelope-from siseci@acikkod.org) Received: (qmail 20021 invoked by uid 89); 4 Apr 2006 10:53:55 -0000 X-Mail-Scanner: Scanned by qSheff 2.1 (http://www.enderunix.org/qsheff/) Received: from unknown (HELO localhost) (193.140.143.25) by 0 with SMTP; 4 Apr 2006 10:53:54 -0000 From: "N.Ersen SISECI" To: freebsd-pf@freebsd.org Date: Tue, 04 Apr 2006 13:53:29 +0300 Message-Id: <1144148009.855.1.camel@siseci.gdg.gov.tr> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Carp and state sync. X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 10:53:51 -0000 Hi, Is state sync. supported under FreeBSD 5-4-Release-p13? Thanks. -- N.Ersen SISECI From owner-freebsd-pf@FreeBSD.ORG Tue Apr 4 12:01:14 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0CAE16A400 for ; Tue, 4 Apr 2006 12:01:14 +0000 (UTC) (envelope-from bill.marquette@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FB0743D4C for ; Tue, 4 Apr 2006 12:01:13 +0000 (GMT) (envelope-from bill.marquette@gmail.com) Received: by uproxy.gmail.com with SMTP id m3so864389ugc for ; Tue, 04 Apr 2006 05:01:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XOfWj/QifCovAlUOSQRIgBXdUitlxTPp3LS51NiLcfDqofHRKsKOTiKXM5uzyTtAaTfak78cRzGvDLLFSbka4t3z6GGhM2Zidss8SQ5TGYc6Qx1EjfosTnorYTJ0RzuzO2d3GyWacq20OUEek6Bn40YTRImR57pQMwyZhHUrauQ= Received: by 10.78.21.7 with SMTP id 7mr167020huu; Tue, 04 Apr 2006 05:01:12 -0700 (PDT) Received: by 10.78.46.14 with HTTP; Tue, 4 Apr 2006 05:01:12 -0700 (PDT) Message-ID: <55e8a96c0604040501y719b4241ue9d989263797c8dc@mail.gmail.com> Date: Tue, 4 Apr 2006 06:01:12 -0600 From: "Bill Marquette" To: "N. Ersen SISECI" In-Reply-To: <1144132192.47587.8.camel@siseci.gdg.gov.tr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1144132192.47587.8.camel@siseci.gdg.gov.tr> Cc: freebsd-pf@freebsd.org Subject: Re: Log tag X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 12:01:15 -0000 On 4/4/06, N. Ersen SISECI wrote: > > > Hi, > > Is it possible to label the log entries? > We can do it in IPF with set-tag (log=3D48). > Is there a similiar method in PF? > > > IPF Rule: > pass in log first quick on bge0 proto tcp from any to 10.1.2.3 port =3D 2= 2 > flags S/SA keep state keep frags set-tag (log=3D110) > > IPF Log entry: > 04/04/2006 09:26:00.982095 bge0 @0:3 p 10.1.2.3,57221 -> > 192.168.90.12,22 PR tcp len 20 64 -S K-S K-F OUT log-tag 110 The "label" keyword is what you want (and gives you a plain text description instead of number?!?!?! ouch). pass in log from foo to bar label "foo to bar rule" --Bill From owner-freebsd-pf@FreeBSD.ORG Tue Apr 4 13:10:32 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8804516A401 for ; Tue, 4 Apr 2006 13:10:32 +0000 (UTC) (envelope-from bill.marquette@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id E158843D46 for ; Tue, 4 Apr 2006 13:10:31 +0000 (GMT) (envelope-from bill.marquette@gmail.com) Received: by uproxy.gmail.com with SMTP id m3so871874ugc for ; Tue, 04 Apr 2006 06:10:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FGVJl46TJnE+S9khsa09zNBj4cSm3DCYUano8/UAZpQxeJ1+qCzlXMZ+PAHFYl0hAiKoM1BQbm+FVNLvFrdwMzyvlWELUSFb3nlHgi7c2w8thwdfkTKVK5QriBQVZnJ74Aqgwy/FWJdj7LvJOedBKtCMNW1uyaRp9ZdRE7RKFgo= Received: by 10.78.39.16 with SMTP id m16mr167521hum; Tue, 04 Apr 2006 06:10:30 -0700 (PDT) Received: by 10.78.46.14 with HTTP; Tue, 4 Apr 2006 06:10:30 -0700 (PDT) Message-ID: <55e8a96c0604040610s6be12570m77293780b0c0e7c5@mail.gmail.com> Date: Tue, 4 Apr 2006 08:10:30 -0500 From: "Bill Marquette" To: freebsd-pf@freebsd.org In-Reply-To: <55e8a96c0604040501y719b4241ue9d989263797c8dc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1144132192.47587.8.camel@siseci.gdg.gov.tr> <55e8a96c0604040501y719b4241ue9d989263797c8dc@mail.gmail.com> Subject: Re: Log tag X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 13:10:32 -0000 On 4/4/06, Bill Marquette wrote: > On 4/4/06, N. Ersen SISECI wrote: > > > > > > Hi, > > > > Is it possible to label the log entries? > > We can do it in IPF with set-tag (log=3D48). > > Is there a similiar method in PF? > > > > > > IPF Rule: > > pass in log first quick on bge0 proto tcp from any to 10.1.2.3 port =3D= 22 > > flags S/SA keep state keep frags set-tag (log=3D110) > > > > IPF Log entry: > > 04/04/2006 09:26:00.982095 bge0 @0:3 p 10.1.2.3,57221 -> > > 192.168.90.12,22 PR tcp len 20 64 -S K-S K-F OUT log-tag 110 > > The "label" keyword is what you want (and gives you a plain text > description instead of number?!?!?! ouch). > > pass in log from foo to bar label "foo to bar rule" It's early...this was incorrect advice. The labels only show in pfctl -sr, not in /dev/pflog0. I'm not sure if there's a way to make this show up in /dev/pflog0. --Bill From owner-freebsd-pf@FreeBSD.ORG Tue Apr 4 13:23:01 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CC3816A401 for ; Tue, 4 Apr 2006 13:23:01 +0000 (UTC) (envelope-from hdemir@metu.edu.tr) Received: from tenedos.general.services.metu.edu.tr (tenedos.general.services.metu.edu.tr [144.122.144.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AED543D45 for ; Tue, 4 Apr 2006 13:22:58 +0000 (GMT) (envelope-from hdemir@metu.edu.tr) Received: from simena.user.services.metu.edu.tr (simena.user.services.metu.edu.tr [144.122.144.15]) by tenedos.general.services.metu.edu.tr (8.13.6/8.13.6) with ESMTP id k34DMs7D023808; Tue, 4 Apr 2006 16:22:54 +0300 Received: (from hdemir@localhost) by simena.user.services.metu.edu.tr (8.13.6/8.13.6/Submit) id k34DMsDm3215494; Tue, 4 Apr 2006 16:22:54 +0300 Date: Tue, 4 Apr 2006 16:22:53 +0300 From: husnu demir To: Bill Marquette Message-ID: <20060404132253.GA3293270@metu.edu.tr> References: <1144132192.47587.8.camel@siseci.gdg.gov.tr> <55e8a96c0604040501y719b4241ue9d989263797c8dc@mail.gmail.com> <55e8a96c0604040610s6be12570m77293780b0c0e7c5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55e8a96c0604040610s6be12570m77293780b0c0e7c5@mail.gmail.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: ClamAV 0.88/1374/Tue Apr 4 08:50:45 2006 on tenedos.general.services.metu.edu.tr X-Virus-Status: Clean Cc: freebsd-pf@freebsd.org Subject: Re: Log tag X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 13:23:01 -0000 On Tue, Apr 04, 2006 at 08:10:30AM -0500, Bill Marquette wrote: > On 4/4/06, Bill Marquette wrote: > > On 4/4/06, N. Ersen SISECI wrote: > > > > > > > > > Hi, > > > > > > Is it possible to label the log entries? > > > We can do it in IPF with set-tag (log=48). > > > Is there a similiar method in PF? > > > > > > > > > IPF Rule: > > > pass in log first quick on bge0 proto tcp from any to 10.1.2.3 port = 22 > > > flags S/SA keep state keep frags set-tag (log=110) > > > > > > IPF Log entry: > > > 04/04/2006 09:26:00.982095 bge0 @0:3 p 10.1.2.3,57221 -> > > > 192.168.90.12,22 PR tcp len 20 64 -S K-S K-F OUT log-tag 110 > > > > The "label" keyword is what you want (and gives you a plain text > > description instead of number?!?!?! ouch). > > > > pass in log from foo to bar label "foo to bar rule" > > It's early...this was incorrect advice. The labels only show in pfctl > -sr, not in /dev/pflog0. I'm not sure if there's a way to make this > show up in /dev/pflog0. does "tcpdump -ttt -e -i pflog0 -n" show the rule number. so this may be used as label :) At least I get used that info extensively. > > --Bill > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" Husnu Demir. From owner-freebsd-pf@FreeBSD.ORG Tue Apr 4 14:57:06 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27A7816A422 for ; Tue, 4 Apr 2006 14:57:06 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 736D743D48 for ; Tue, 4 Apr 2006 14:57:05 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k34Ev4IQ019518 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 4 Apr 2006 16:57:05 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k34Ev4wV011738; Tue, 4 Apr 2006 16:57:04 +0200 (MEST) Date: Tue, 4 Apr 2006 16:57:04 +0200 From: Daniel Hartmeier To: Max Laier Message-ID: <20060404145704.GW2684@insomnia.benzedrine.cx> References: <20060402054532.GF17711@egr.msu.edu> <200604021734.09622.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604021734.09622.max@love2party.net> User-Agent: Mutt/1.5.10i Cc: freebsd-pf@freebsd.org Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 14:57:06 -0000 It begins to look like OpenBSD does fix IP checksums on bridges outside of pf, while FreeBSD doesn't. The weird thing is that I haven't found where exactly this happens. It's kind of a layer violation for bridge code to do that, but maybe it's somewhere else along the code path. Instead of adding checksum fixup code again, I think it's better to take a step back and find out why the checksums are correct on OpenBSD. The previous fixes assumed the checksums would be wrong on OpenBSD as well, but they related to pf actions more subtle than basic fragment reassembly. Daniel From owner-freebsd-pf@FreeBSD.ORG Tue Apr 4 15:34:49 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C58816A401; Tue, 4 Apr 2006 15:34:49 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7A3343D46; Tue, 4 Apr 2006 15:34:48 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k34FYkL6008769 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 4 Apr 2006 17:34:46 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k34FYiMq032056; Tue, 4 Apr 2006 17:34:44 +0200 (MEST) Date: Tue, 4 Apr 2006 17:34:44 +0200 From: Daniel Hartmeier To: Max Laier Message-ID: <20060404153443.GX2684@insomnia.benzedrine.cx> References: <20060402054532.GF17711@egr.msu.edu> <200604021734.09622.max@love2party.net> <20060404145704.GW2684@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060404145704.GW2684@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.10i Cc: Andrew Thompson , freebsd-pf@freebsd.org Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 15:34:49 -0000 Ok, I found the reason for all these IP checksum problems. The reason is that OpenBSD's bridge code always recalculates the IP checksum, while FreeBSD's doesn't. In OpenBSD we have src/sys/net/if_bridge.c with the following code path. bridgeintr_frame() Main entry point on input path, gets called for every frame coming in on a member interface. It calls bridge_filter(IN, real_src_if) to filter the incoming frame on the real source interface the frame came in on. This corresponds to pfil_run_hooks(), as it calls the packet filter with pf_test(IN, real_src_if) this can not only drop or pass the IP packet unmodified, it can also drop a fragment after consumption into the reassembly cache, or return a different modified packet, for instance when rdr is used, or when a final fragment is consumed and the fully reassembled packet is returned instead. That completes the input path. pf doesn't really care to set the IP checksum correctly when it modifies the IP header in various ways, because the output path will fix it: if frame should be broadcast bridge_broadcast() bridge_filter(OUT, real_dst_if) pf_test(OUT, real_dst_if) else (unicast) bridge_filter(OUT, real_dst_if) pf_test(OUT, real_dst_if) if size fits mtu bridge_ifenqueue() else bridge_fragment() bridge_fragment() ip_fragment() bridge_ifenqueue() bridge_ifenqueue() IFQ_ENQUEUE(dst_if) dst_if->if_start() What I missed before is in bridge_filter(), right after the pf_test() call: if (pf_test(dir, ifp, &m, eh) != PF_PASS) goto dropit; if (m == NULL) goto dropit; /* Rebuild the IP header */ if (m->m_len < hlen && ((m = m_pullup(m, hlen)) == NULL)) return (NULL); if (m->m_len < sizeof(struct ip)) goto dropit; ip = mtod(m, struct ip *); ip->ip_sum = 0; ip->ip_sum = in_cksum(m, hlen); FreeBSD has no such part that I can find. Hence, when pf_test() returns a packet with an invalid IP checksum, nothing fixes the checksum, maybe except for hardware-checksumming NICs. Andrew, what do you suggest we do about this? Are the FreeBSD semantics very clear and state that the IP checksum is pfil hook's responsibility, and other pfil hooks (besides pf) are doing exactly that? I haven't used the FreeBSD bridge code with other packet filters beside pf, so I simply don't know. If pf should return only IP packets to bridge which have correct IP checksums already, we can either force an unconditional recomputation in pf's pfil hook function (which wraps pf_test()), or we can go further down the road of doing incremental checksum fixups whenever pf changes the IP header internally. Once that would be complete, OpenBSD's bridge could remove the unconditional checksum recomputation, too. But I'm not sure what's cheaper, on average, fixing up the checksum on each header change (there might be multiple changes per packet processed), or simply doing it once, unconditionally, at the end. Right now, we're in the suboptimal middle. pf does some incremental fixups, but leaves the checksum incorrect in other cases. Daniel From owner-freebsd-pf@FreeBSD.ORG Tue Apr 4 17:23:01 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 062D916A41F for ; Tue, 4 Apr 2006 17:23:01 +0000 (UTC) (envelope-from bill.marquette@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F7FF43D45 for ; Tue, 4 Apr 2006 17:22:59 +0000 (GMT) (envelope-from bill.marquette@gmail.com) Received: by uproxy.gmail.com with SMTP id m3so914189ugc for ; Tue, 04 Apr 2006 10:22:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gFQwu1evCSHa1j4QF3joXcBjlRkrIiuF1uzRj2XLFfMB2OTzcgSQn4JqENFIChEbUuQYFlLvfbARI7Dm5M5Ewa0B6ISBO9JHvafifS5Vl6l9Dq6rFCr30NBtFDlkMrRgIROsdSSFZfkqQ86CvYg2COdO2/1n4zp8b+hEOAwMFKw= Received: by 10.78.57.11 with SMTP id f11mr180183hua; Tue, 04 Apr 2006 10:22:58 -0700 (PDT) Received: by 10.78.46.14 with HTTP; Tue, 4 Apr 2006 10:22:58 -0700 (PDT) Message-ID: <55e8a96c0604041022t5026422as6be2967fd2fbe494@mail.gmail.com> Date: Tue, 4 Apr 2006 12:22:58 -0500 From: "Bill Marquette" To: "husnu demir" In-Reply-To: <20060404132253.GA3293270@metu.edu.tr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1144132192.47587.8.camel@siseci.gdg.gov.tr> <55e8a96c0604040501y719b4241ue9d989263797c8dc@mail.gmail.com> <55e8a96c0604040610s6be12570m77293780b0c0e7c5@mail.gmail.com> <20060404132253.GA3293270@metu.edu.tr> Cc: freebsd-pf@freebsd.org Subject: Re: Log tag X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 17:23:01 -0000 On 4/4/06, husnu demir wrote: > > On Tue, Apr 04, 2006 at 08:10:30AM -0500, Bill Marquette wrote: > > On 4/4/06, Bill Marquette wrote: > > > On 4/4/06, N. Ersen SISECI wrote: > > > > > > > > > > > > Hi, > > > > > > > > Is it possible to label the log entries? > > > > We can do it in IPF with set-tag (log=3D48). > > > > Is there a similiar method in PF? > > > > > > > > > > > > IPF Rule: > > > > pass in log first quick on bge0 proto tcp from any to 10.1.2.3 port= =3D 22 > > > > flags S/SA keep state keep frags set-tag (log=3D110) > > > > > > > > IPF Log entry: > > > > 04/04/2006 09:26:00.982095 bge0 @0:3 p 10.1.2.3,57221 -> > > > > 192.168.90.12,22 PR tcp len 20 64 -S K-S K-F OUT log-tag 110 > > > > > > The "label" keyword is what you want (and gives you a plain text > > > description instead of number?!?!?! ouch). > > > > > > pass in log from foo to bar label "foo to bar rule" > > > > It's early...this was incorrect advice. The labels only show in pfctl > > -sr, not in /dev/pflog0. I'm not sure if there's a way to make this > > show up in /dev/pflog0. > > > does "tcpdump -ttt -e -i pflog0 -n" show the rule number. so this may be = used as label :) At least I get used that info extensively. It does and can be used for correlation (in conjunction with pfctl -sr)...up until the rules change :) But outside of (relatively easy) scripting, the info isn't supplied in a single place. --Bill From owner-freebsd-pf@FreeBSD.ORG Mon Apr 3 20:26:48 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F346D16A420 for ; Mon, 3 Apr 2006 20:26:47 +0000 (UTC) (envelope-from link@warped.ro) Received: from mail.warped.ro (warped.ro [86.104.83.66]) by mx1.FreeBSD.org (Postfix) with SMTP id E0D3843D4C for ; Mon, 3 Apr 2006 20:26:46 +0000 (GMT) (envelope-from link@warped.ro) Received: (qmail 5068 invoked by uid 1009); 3 Apr 2006 20:24:31 -0000 Received: from link.warped.ro (HELO anonymous) (86.104.83.83) by mail.warped.ro with SMTP; 3 Apr 2006 20:24:31 -0000 Message-ID: <002001c6575c$e1336f50$53536856@anonymous> From: "Robert" To: Date: Mon, 3 Apr 2006 23:26:22 +0300 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailman-Approved-At: Wed, 05 Apr 2006 12:42:05 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: queue number X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 20:26:48 -0000 someboy told me that alq +hsfc only supports under 1000 queues is that true ? i have 5, 6 big queues ( 7-8Mb) with 500, 600 subqueues=20 will it work ? From owner-freebsd-pf@FreeBSD.ORG Wed Apr 5 12:42:13 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F54A16A401; Wed, 5 Apr 2006 12:42:13 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86D6543D4C; Wed, 5 Apr 2006 12:42:10 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.179.94] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1FR7Kq1TwF-0001nA; Wed, 05 Apr 2006 14:42:08 +0200 From: Max Laier Organization: FreeBSD To: Daniel Hartmeier Date: Wed, 5 Apr 2006 14:41:09 +0200 User-Agent: KMail/1.9.1 References: <20060402054532.GF17711@egr.msu.edu> <20060404145704.GW2684@insomnia.benzedrine.cx> <20060404153443.GX2684@insomnia.benzedrine.cx> In-Reply-To: <20060404153443.GX2684@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1276437.b4U7kJYxsO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604051441.16865.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Andrew Thompson , freebsd-pf@freebsd.org Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 12:42:13 -0000 --nextPart1276437.b4U7kJYxsO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 04 April 2006 17:34, Daniel Hartmeier wrote: > Ok, I found the reason for all these IP checksum problems. The reason is > that OpenBSD's bridge code always recalculates the IP checksum, while > FreeBSD's doesn't. > ... > What I missed before is in bridge_filter(), right after the pf_test() > call: > > if (pf_test(dir, ifp, &m, eh) !=3D PF_PASS) > goto dropit; > if (m =3D=3D NULL) > goto dropit; > > /* Rebuild the IP header */ > if (m->m_len < hlen && ((m =3D m_pullup(m, hlen)) =3D=3D = NULL)) > return (NULL); > if (m->m_len < sizeof(struct ip)) > goto dropit; > ip =3D mtod(m, struct ip *); > ip->ip_sum =3D 0; > ip->ip_sum =3D in_cksum(m, hlen); > > FreeBSD has no such part that I can find. Hence, when pf_test() returns > a packet with an invalid IP checksum, nothing fixes the checksum, maybe > except for hardware-checksumming NICs. > > Andrew, what do you suggest we do about this? Are the FreeBSD semantics > very clear and state that the IP checksum is pfil hook's responsibility, > and other pfil hooks (besides pf) are doing exactly that? I haven't used > the FreeBSD bridge code with other packet filters beside pf, so I simply > don't know. > > If pf should return only IP packets to bridge which have correct IP > checksums already, we can either force an unconditional recomputation in > pf's pfil hook function (which wraps pf_test()), or we can go further > down the road of doing incremental checksum fixups whenever pf changes > the IP header internally. Once that would be complete, OpenBSD's bridge > could remove the unconditional checksum recomputation, too. > > But I'm not sure what's cheaper, on average, fixing up the checksum > on each header change (there might be multiple changes per packet > processed), or simply doing it once, unconditionally, at the end. > > Right now, we're in the suboptimal middle. pf does some incremental > fixups, but leaves the checksum incorrect in other cases. AFAIR, we somewhat keep track of the checksum status with csum_flags in the= =20 pkthdr. We have still some 8 bit left to use if we need them, but I think = we=20 can express everything that might happen already. If we did that pf (or an= y=20 other pfil consumer) could decide if it is worth to recalculate the cksum o= r=20 if it is something to leave to the bridge/ip_output. If it decides to fix= =20 the checksum no other action is required, if it decides not to fix the=20 checksum it sets a flag indicating that the checksum needs to be=20 recalculated. The bridge code would then check with the outgoing interface= 's=20 hardware capabilities and either leave the job to the hardware or do it in= =20 software itself. The other big problem that just crossed my mind: Reassembly in the bridge= =20 path!? It doesn't look like the current bridge code on either OS is ready = to=20 deal with packets > MTU coming out of the filter. The question here is=20 probably how much IP processing we want to do in the bridge code? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1276437.b4U7kJYxsO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEM7rsXyyEoT62BG0RArlgAJ9qv+o4u2KA/qoA58x024JvA3TtPgCfbAPH vk14TtASyR+52PKp5Jpr5WM= =JEXv -----END PGP SIGNATURE----- --nextPart1276437.b4U7kJYxsO-- From owner-freebsd-pf@FreeBSD.ORG Wed Apr 5 13:06:52 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 847D416A423; Wed, 5 Apr 2006 13:06:52 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B189E43D70; Wed, 5 Apr 2006 13:06:48 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k35D6kdr002400 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 5 Apr 2006 15:06:46 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k35D6kl4002137; Wed, 5 Apr 2006 15:06:46 +0200 (MEST) Date: Wed, 5 Apr 2006 15:06:45 +0200 From: Daniel Hartmeier To: Max Laier Message-ID: <20060405130645.GB5683@insomnia.benzedrine.cx> References: <20060402054532.GF17711@egr.msu.edu> <20060404145704.GW2684@insomnia.benzedrine.cx> <20060404153443.GX2684@insomnia.benzedrine.cx> <200604051441.16865.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604051441.16865.max@love2party.net> User-Agent: Mutt/1.5.10i Cc: Andrew Thompson , freebsd-pf@freebsd.org Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 13:06:52 -0000 On Wed, Apr 05, 2006 at 02:41:09PM +0200, Max Laier wrote: > The other big problem that just crossed my mind: Reassembly in the bridge > path!? It doesn't look like the current bridge code on either OS is ready to > deal with packets > MTU coming out of the filter. The question here is > probably how much IP processing we want to do in the bridge code? OpenBSD's bridge does, see bridge_fragment(). IIRC, we slightly adjusted ip_fragment() so it could be called from there, and not too much code had to be duplicated. if ((len - ETHER_HDR_LEN) > dst_if->if_mtu) bridge_fragment(sc, dst_if, &eh, m); else { ... bridge_ifenqueue(sc, dst_if, m); ... } bridge_fragment() error = ip_fragment(m, ifp, ifp->if_mtu); if (error) { m = NULL; goto dropit; } for (; m; m = m0) { m0 = m->m_nextpkt; m->m_nextpkt = NULL; ... error = bridge_ifenqueue(sc, ifp, m); ... } That's one more layer violation in bridge, but stateful filtering basically requires fragment reassembly, at least in general. Daniel From owner-freebsd-pf@FreeBSD.ORG Wed Apr 5 13:28:31 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82B1516A401 for ; Wed, 5 Apr 2006 13:28:31 +0000 (UTC) (envelope-from sthalik@tehran.lain.pl) Received: from tehran.lain.pl (tehran.lain.pl [85.221.230.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03B6743D4C for ; Wed, 5 Apr 2006 13:28:30 +0000 (GMT) (envelope-from sthalik@tehran.lain.pl) Received: from sthalik by tehran.lain.pl with local (envelope-from ) id 1FR83h-0003IF-NV for freebsd-pf@freebsd.org; Wed, 05 Apr 2006 15:28:29 +0200 Date: Wed, 5 Apr 2006 15:28:29 +0200 From: Stanislaw Halik To: freebsd-pf@freebsd.org Message-ID: <20060405132829.GA12653@tehran.lain.pl> Mail-Followup-To: freebsd-pf@freebsd.org References: <002001c6575c$e1336f50$53536856@anonymous> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <002001c6575c$e1336f50$53536856@anonymous> X-PGP-Key: http://tehran.lain.pl/public.key User-Agent: Mutt/1.5.11 Sender: Stanislaw Halik X-User: sthalik Subject: Re: queue number X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 13:28:31 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 03, 2006, Robert wrote: > someboy told me that alq +hsfc only supports under 1000 queues > is that true ? > i have 5, 6 big queues ( 7-8Mb) with 500, 600 subqueues=20 > will it work ? the queue limit is static, therefore you might need to increase it and rebuild the kernel: sys/contrib/altq/altq/altq_hfsc.h:#define HFSC_MAX_CLASSES 64 HTH, -- sh --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEM8X9adU+vjT62TERArbuAJ9ebwhYdKm/sCFDosi8sdalDkmeNQCggpo0 O5UE9tF06tlemSNdIVlKarw= =QKKc -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-pf@FreeBSD.ORG Wed Apr 5 13:39:32 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4529416A41F; Wed, 5 Apr 2006 13:39:32 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB34343D46; Wed, 5 Apr 2006 13:39:31 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 246391CC53; Wed, 5 Apr 2006 09:39:31 -0400 (EDT) Date: Wed, 5 Apr 2006 09:39:31 -0400 From: Adam McDougall To: Daniel Hartmeier Message-ID: <20060405133930.GV14961@egr.msu.edu> References: <20060402054532.GF17711@egr.msu.edu> <20060404145704.GW2684@insomnia.benzedrine.cx> <20060404153443.GX2684@insomnia.benzedrine.cx> <200604051441.16865.max@love2party.net> <20060405130645.GB5683@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060405130645.GB5683@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.11 Cc: Andrew Thompson , freebsd-pf@freebsd.org Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 13:39:32 -0000 On Wed, Apr 05, 2006 at 03:06:45PM +0200, Daniel Hartmeier wrote: On Wed, Apr 05, 2006 at 02:41:09PM +0200, Max Laier wrote: > The other big problem that just crossed my mind: Reassembly in the bridge > path!? It doesn't look like the current bridge code on either OS is ready to > deal with packets > MTU coming out of the filter. The question here is > probably how much IP processing we want to do in the bridge code? This is also something I came across while evaluating pf+if_bridge on FreeBSD. NFS fragment reassembly was the first repeatable offender, and then I found I could wedge the outgoing interface in OACTIVE with a simple ping -s 8000. I've also seen my internal interface wedge in OACTIVE mode after several (10+?) ruleset reloads, with unapparent cause. OpenBSD's bridge does, see bridge_fragment(). IIRC, we slightly adjusted ip_fragment() so it could be called from there, and not too much code had to be duplicated. if ((len - ETHER_HDR_LEN) > dst_if->if_mtu) bridge_fragment(sc, dst_if, &eh, m); else { ... bridge_ifenqueue(sc, dst_if, m); ... } bridge_fragment() error = ip_fragment(m, ifp, ifp->if_mtu); if (error) { m = NULL; goto dropit; } for (; m; m = m0) { m0 = m->m_nextpkt; m->m_nextpkt = NULL; ... error = bridge_ifenqueue(sc, ifp, m); ... } That's one more layer violation in bridge, but stateful filtering basically requires fragment reassembly, at least in general. Daniel _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Wed Apr 5 20:40:26 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 731C216A44C for ; Wed, 5 Apr 2006 20:40:26 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from dbmail-mx1.orcon.net.nz (loadbalancer1.orcon.net.nz [219.88.242.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E04643D77 for ; Wed, 5 Apr 2006 20:40:24 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received-SPF: none Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by dbmail-mx1.orcon.net.nz (8.13.6/8.13.6/Debian-1) with SMTP id k35Keqsg012055; Thu, 6 Apr 2006 08:40:58 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 5BA741CC37; Thu, 6 Apr 2006 08:40:05 +1200 (NZST) Date: Thu, 6 Apr 2006 08:40:05 +1200 From: Andrew Thompson To: Max Laier Message-ID: <20060405204005.GA86576@heff.fud.org.nz> References: <20060402054532.GF17711@egr.msu.edu> <20060404145704.GW2684@insomnia.benzedrine.cx> <20060404153443.GX2684@insomnia.benzedrine.cx> <200604051441.16865.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604051441.16865.max@love2party.net> User-Agent: Mutt/1.5.11 X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on dbmail-mx1.orcon.net.nz X-Virus-Status: Clean Cc: freebsd-pf@freebsd.org Subject: Re: broken ip checksum after frag reassemble of nfs READDIR? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 20:40:26 -0000 On Wed, Apr 05, 2006 at 02:41:09PM +0200, Max Laier wrote: > On Tuesday 04 April 2006 17:34, Daniel Hartmeier wrote: > > > > FreeBSD has no such part that I can find. Hence, when pf_test() returns > > a packet with an invalid IP checksum, nothing fixes the checksum, maybe > > except for hardware-checksumming NICs. > > > > Andrew, what do you suggest we do about this? Are the FreeBSD semantics > > very clear and state that the IP checksum is pfil hook's responsibility, > > and other pfil hooks (besides pf) are doing exactly that? I haven't used > > the FreeBSD bridge code with other packet filters beside pf, so I simply > > don't know. > > > > If pf should return only IP packets to bridge which have correct IP > > checksums already, we can either force an unconditional recomputation in > > pf's pfil hook function (which wraps pf_test()), or we can go further > > down the road of doing incremental checksum fixups whenever pf changes > > the IP header internally. Once that would be complete, OpenBSD's bridge > > could remove the unconditional checksum recomputation, too. > > > > But I'm not sure what's cheaper, on average, fixing up the checksum > > on each header change (there might be multiple changes per packet > > processed), or simply doing it once, unconditionally, at the end. > > > > Right now, we're in the suboptimal middle. pf does some incremental > > fixups, but leaves the checksum incorrect in other cases. > > AFAIR, we somewhat keep track of the checksum status with csum_flags in the > pkthdr. We have still some 8 bit left to use if we need them, but I think we > can express everything that might happen already. If we did that pf (or any > other pfil consumer) could decide if it is worth to recalculate the cksum or > if it is something to leave to the bridge/ip_output. If it decides to fix > the checksum no other action is required, if it decides not to fix the > checksum it sets a flag indicating that the checksum needs to be > recalculated. The bridge code would then check with the outgoing interface's > hardware capabilities and either leave the job to the hardware or do it in > software itself. Whatever the solutions is, the packet filter should either return the packet with a correct checksum or not update it at all. Doing incremental updates are wasted if all cases are not handled. Personally I would like to keep the bridge doing layer2 as much as possible so if pf can return the packet with all the layer3 processing completed it would be great. The bridge will disable hardware txcsums on its interfaces which pf should detect and know to fully calculate the csum before returning. Andrew