From owner-freebsd-pf@FreeBSD.ORG Mon Jul 4 11:07:07 2011 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEE3F1065674 for ; Mon, 4 Jul 2011 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B396E8FC15 for ; Mon, 4 Jul 2011 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p64B77FN040512 for ; Mon, 4 Jul 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p64B77ea040510 for freebsd-pf@FreeBSD.org; Mon, 4 Jul 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jul 2011 11:07:07 GMT Message-Id: <201107041107.p64B77ea040510@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org 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, 04 Jul 2011 11:07:08 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/146832 pf [pf] "(self)" not always matching all local IPv6 addre o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 46 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Jul 4 18:01:28 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70CDB106566B for ; Mon, 4 Jul 2011 18:01:28 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3839E8FC16 for ; Mon, 4 Jul 2011 18:01:28 +0000 (UTC) Received: by iwr19 with SMTP id 19so6202173iwr.13 for ; Mon, 04 Jul 2011 11:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fVWgWSrY4OHzsDyXBlnpLDdHDIKEME8pCVq/Wi/AUwA=; b=pbVK3t8shyq7EN+4K6BPjhvl/KcHI28WrAzFyd4EZVDhICC2j/k+bEBnRoul2GRuQP 6ax5lWrLMo/OFoxnmfZnImw1jZ4vrp67yEXFUPejFtICMpH4cnIeUZfcy0gLgye/SBlZ rOtCDEh8wg+AlRYKKxoyR+nNwUgbmzyly5Fdo= MIME-Version: 1.0 Received: by 10.42.151.73 with SMTP id d9mr7162268icw.2.1309802486854; Mon, 04 Jul 2011 11:01:26 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.171.148 with HTTP; Mon, 4 Jul 2011 11:01:26 -0700 (PDT) In-Reply-To: <4E0F3A2D.60409@userid.org> References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> <4E0F3A2D.60409@userid.org> Date: Mon, 4 Jul 2011 20:01:26 +0200 X-Google-Sender-Auth: Sqp-Vu4msY3cJhpjcldunxIC9n8 Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Pierre Lamy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... 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, 04 Jul 2011 18:01:28 -0000 On Sat, Jul 2, 2011 at 5:33 PM, Pierre Lamy wrote: > > > On 6/29/2011 1:22 PM, Fabian Keil wrote: >> >> "Bjoern A. Zeeb" =A0wrote: >> >>> Begin forwarded message: >>> >>>> From: "Bjoern A. Zeeb" >>>> Date: June 28, 2011 11:57:25 AM GMT+00:00 >>>> To: src-committers@freebsd.org, svn-src-all@freebsd.org, >>>> svn-src-head@freebsd.org >>>> Subject: svn commit: r223637 - in head: . contrib/pf/authpf >>>> contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd >>>> sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modu= les >>>> s... >>>> >>>> Author: bz >>>> Date: Tue Jun 28 11:57:25 2011 >>>> New Revision: 223637 >>>> URL: http://svn.freebsd.org/changeset/base/223637 >>>> >>>> Log: >>>> =A0Update packet filter (pf) code to OpenBSD 4.5. >> >> Thanks! >> >>> In short; please test! >> >> I didn't experience any real problems yet, but running >> Privoxy-Regression-Test, I reproducible got this log message >> for one of the tests: >> >> Jun 29 18:26:19 r500 kernel: pf: state key linking mismatch! dir=3DOUT, >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, proto= =3D6, found >> af=3D2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, proto=3D6. >> >> This didn't happen with the previous pf version. >> >> I tracked it down to a test that does a connect() >> to a local unbound port. >> >> It's also reproducible for every address on the system with: >> >> ifconfig -a | awk '/inet / {system("telnet "$2" 12345")}' >> >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, >> if=3Dlo0, stored af=3D2, a0: 192.168.5.49:61512, a1: 192.168.5.49:12345, >> proto=3D6, found af=3D2, a0: 192.168.5.49:61512, a1: 192.168.5.49:12345, >> proto=3D6. >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, >> if=3Dlo0, stored af=3D2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, proto= =3D6, >> found af=3D2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, proto=3D6. >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, >> if=3Dlo1, stored af=3D2, a0: 192.168.6.100:31600, a1: 192.168.6.100:1234= 5, >> proto=3D6, found af=3D2, a0: 192.168.6.100:31600, a1: 192.168.6.100:1234= 5, >> proto=3D6. >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, proto= =3D6, found >> af=3D2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, proto=3D6. >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, proto= =3D6, found >> af=3D2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, proto=3D6. >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, proto= =3D6, found >> af=3D2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, proto=3D6. >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, >> if=3Dlo0, stored af=3D2, a0: 192.168.0.106:32448, a1: 192.168.0.106:1234= 5, >> proto=3D6, found af=3D2, a0: 192.168.0.106:32448, a1: 192.168.0.106:1234= 5, >> proto=3D6. >> >> 12345 can be replaced with any unbound port it seems. >> >> I'm additionally occasionally seeing the message for successfully >> established connections (both internal and outgoing) but don't >> know how to reproduce it. >> >> Fabian > > I also get the state key mismatch problem, it seems that pf is leaking > states (I assume this is the same problem). I also see a strange NAT issu= e, > internal IPs leak somewhat on the outside int. Eventually the system runs > out of state entry slots and connectivity is lost. This is on a -current > kernel from ~Jun 30, after the 4.5 import. > > tun0: flags=3D8151 metric 0 mtu= 1492 > =A0 =A0 =A0 =A0options=3D80000 > =A0 =A0 =A0 =A0inet6 fe80::290:bff:fe1a:a674%tun0 prefixlen 64 scopeid 0x= f > =A0 =A0 =A0 =A0inet6 2607:f0b0:0:1:290:bff:fe1a:a674 prefixlen 64 autocon= f > =A0 =A0 =A0 =A0inet 216.106.102.33 --> 209.87.255.1 netmask 0xffffffff > =A0 =A0 =A0 =A0nd6 options=3D23 > =A0 =A0 =A0 =A0Opened by PID 3446 > > em0 is on the 192.168.3/24 network > > [/var/preserve/root] # tcpdump -i tun0 net 192.168.3= .0 > mask 255.255.255.0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decod= e > listening on tun0, link-type NULL (BSD loopback), capture size 65535 byte= s > 11:22:37.030244 IP 192.168.3.99 > 190.252.34.186: ICMP pandora.userid.org > udp port 16881 unreachable, length 134 > 11:24:03.137016 IP 192.168.3.99 > 190.252.34.186: ICMP pandora.userid.org > udp port 16881 unreachable, length 98 > > Relevant pf.conf lines: > int_if =3D "em0" > ext_if =3D "tun0" > # NAT > nat on $ext_if from $int_if:network to any -> ($ext_if) > > Here is the info about states leaking: > > State Table =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Total =A0 = =A0 =A0 =A0 =A0 =A0 Rate > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 108488 > > [/var/preserve/root] # pfctl -F states > 1003 states cleared > [/var/preserve/root] # pfctl -s info > Status: Enabled for 0 days 02:21:18 =A0 =A0 =A0 =A0 =A0 Debug: Urgent > > Interface Stats for tun0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IPv4 =A0 =A0 =A0 =A0 = =A0 =A0 IPv6 > =A0Bytes In =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01252327614 =A0 =A0= =A0 =A0 =A01907903 > =A0Bytes Out =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0373783492 =A0 =A0= =A0 =A0 =A01429003 > =A0Packets In > =A0 =A0Passed =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1341017 =A0= =A0 =A0 =A0 =A0 =A012360 > =A0 =A0Blocked =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A045437 = =A0 =A0 =A0 =A0 =A0 =A0 =A0831 > =A0Packets Out > =A0 =A0Passed =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1186359 =A0= =A0 =A0 =A0 =A0 =A013441 > =A0 =A0Blocked =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1641 = =A0 =A0 =A0 =A0 =A0 =A0 3724 > > State Table =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Total =A0 = =A0 =A0 =A0 =A0 =A0 Rate > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 125127 > > States aren't getting cleared properly. Below is a sample of the state ke= y > linking mismatch problem: > > Jul =A02 11:28:17 pyr7535 kernel: pf: state key linking mismatch! dir=3DO= UT, > if=3Dem0, stored af=3D2, a0: I just committed a fix for the state key linking mismatch issue. Can you test with the latest HEAD sources? > Jul =A02 11:28:17 pyr7535 kernel: 192.168.3.238:55590, a1: 216.106.102.33 > Jul =A02 11:28:18 pyr7535 kernel: :18825, proto=3D6 > Jul =A02 11:28:18 pyr7535 kernel: , found af=3D2, a0: 192.168.3.238 > Jul =A02 11:28:18 pyr7535 kernel: :55590, a1: > Jul =A02 11:28:18 pyr7535 kernel: 216.106.102.33:18825 > Jul =A02 11:28:18 pyr7535 kernel: , proto=3D6. > Jul =A02 11:28:18 pyr7535 kernel: pf: state key linking mismatch! dir=3DO= UT, > if=3Dem0, stored af=3D2, a0: 192.168.3.238:55590, a1: 216.106.102.33:1882= 5, > proto=3D6, found af=3D2, a0: 192.168.3.238:55590, a1: 216.106.102.33:1882= 5, > proto=3D6. > Jul =A02 11:28:19 pyr7535 kernel: pf: state key linking mismatch! dir=3DO= UT, > if=3Dem0, stored af=3D2, a0: 192.168.3.238 > Jul =A02 11:28:19 pyr7535 kernel: :55590, a1: > Jul =A02 11:28:19 pyr7535 kernel: 216.106.102.33:18825 > Jul =A02 11:28:19 pyr7535 kernel: , proto=3D6, found af=3D2, a0: > Jul =A02 11:28:19 pyr7535 kernel: 192.168.3.238:55590 > Jul =A02 11:28:19 pyr7535 kernel: , a1: 216.106.102.33 > Jul =A02 11:28:19 pyr7535 kernel: :18825, proto=3D6. > > > > _______________________________________________ > 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" > --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Mon Jul 4 19:55:50 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74DA51065672; Mon, 4 Jul 2011 19:55:50 +0000 (UTC) (envelope-from pierre@userid.org) Received: from mail.storm.ca (unknown [IPv6:2607:f0b0:0:6:209:87:239:66]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD818FC13; Mon, 4 Jul 2011 19:55:50 +0000 (UTC) Received: from mail.userid.org (pandora.userid.org [216.106.102.33]) by mail.storm.ca (8.14.2+Sun/8.14.2) with ESMTP id p64JJHg4026031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jul 2011 15:19:24 -0400 (EDT) Received: from [IPv6:2607:f0b0:1:3800:3c4d:9c3c:9460:13b2] (unknown [IPv6:2607:f0b0:1:3800:3c4d:9c3c:9460:13b2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre) by mail.userid.org (Postfix) with ESMTP id F16492C77C5; Mon, 4 Jul 2011 15:18:44 -0400 (EDT) Message-ID: <4E121207.30400@userid.org> Date: Mon, 04 Jul 2011 15:18:31 -0400 From: Pierre Lamy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> <4E0F3A2D.60409@userid.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-userid-MailScanner-Information: Please contact the ISP for more information X-userid-MailScanner-ID: F16492C77C5.AB72B X-userid-MailScanner: Found to be clean X-userid-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.599, required 6, J_CHICKENPOX_33 0.60, NO_RELAYS -0.00) X-userid-MailScanner-From: pierre@userid.org X-Spam-Status: No Cc: freebsd-pf@freebsd.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... 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, 04 Jul 2011 19:55:50 -0000 I'm just heading to NYC for the next 2 days, I will check it when I get back. Thanks! -Pierre On 7/4/2011 2:01 PM, Ermal Luçi wrote: > On Sat, Jul 2, 2011 at 5:33 PM, Pierre Lamy wrote: >> >> On 6/29/2011 1:22 PM, Fabian Keil wrote: >>> "Bjoern A. Zeeb" wrote: >>> >>>> Begin forwarded message: >>>> >>>>> From: "Bjoern A. Zeeb" >>>>> Date: June 28, 2011 11:57:25 AM GMT+00:00 >>>>> To: src-committers@freebsd.org, svn-src-all@freebsd.org, >>>>> svn-src-head@freebsd.org >>>>> Subject: svn commit: r223637 - in head: . contrib/pf/authpf >>>>> contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd >>>>> sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules >>>>> s... >>>>> >>>>> Author: bz >>>>> Date: Tue Jun 28 11:57:25 2011 >>>>> New Revision: 223637 >>>>> URL: http://svn.freebsd.org/changeset/base/223637 >>>>> >>>>> Log: >>>>> Update packet filter (pf) code to OpenBSD 4.5. >>> Thanks! >>> >>>> In short; please test! >>> I didn't experience any real problems yet, but running >>> Privoxy-Regression-Test, I reproducible got this log message >>> for one of the tests: >>> >>> Jun 29 18:26:19 r500 kernel: pf: state key linking mismatch! dir=OUT, >>> if=lo1, stored af=2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, proto=6, found >>> af=2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, proto=6. >>> >>> This didn't happen with the previous pf version. >>> >>> I tracked it down to a test that does a connect() >>> to a local unbound port. >>> >>> It's also reproducible for every address on the system with: >>> >>> ifconfig -a | awk '/inet / {system("telnet "$2" 12345")}' >>> >>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>> if=lo0, stored af=2, a0: 192.168.5.49:61512, a1: 192.168.5.49:12345, >>> proto=6, found af=2, a0: 192.168.5.49:61512, a1: 192.168.5.49:12345, >>> proto=6. >>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>> if=lo0, stored af=2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, proto=6, >>> found af=2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, proto=6. >>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>> if=lo1, stored af=2, a0: 192.168.6.100:31600, a1: 192.168.6.100:12345, >>> proto=6, found af=2, a0: 192.168.6.100:31600, a1: 192.168.6.100:12345, >>> proto=6. >>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>> if=lo1, stored af=2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, proto=6, found >>> af=2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, proto=6. >>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>> if=lo1, stored af=2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, proto=6, found >>> af=2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, proto=6. >>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>> if=lo1, stored af=2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, proto=6, found >>> af=2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, proto=6. >>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>> if=lo0, stored af=2, a0: 192.168.0.106:32448, a1: 192.168.0.106:12345, >>> proto=6, found af=2, a0: 192.168.0.106:32448, a1: 192.168.0.106:12345, >>> proto=6. >>> >>> 12345 can be replaced with any unbound port it seems. >>> >>> I'm additionally occasionally seeing the message for successfully >>> established connections (both internal and outgoing) but don't >>> know how to reproduce it. >>> >>> Fabian >> I also get the state key mismatch problem, it seems that pf is leaking >> states (I assume this is the same problem). I also see a strange NAT issue, >> internal IPs leak somewhat on the outside int. Eventually the system runs >> out of state entry slots and connectivity is lost. This is on a -current >> kernel from ~Jun 30, after the 4.5 import. >> >> tun0: flags=8151 metric 0 mtu 1492 >> options=80000 >> inet6 fe80::290:bff:fe1a:a674%tun0 prefixlen 64 scopeid 0xf >> inet6 2607:f0b0:0:1:290:bff:fe1a:a674 prefixlen 64 autoconf >> inet 216.106.102.33 --> 209.87.255.1 netmask 0xffffffff >> nd6 options=23 >> Opened by PID 3446 >> >> em0 is on the 192.168.3/24 network >> >> [/var/preserve/root] # tcpdump -i tun0 net 192.168.3.0 >> mask 255.255.255.0 >> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >> listening on tun0, link-type NULL (BSD loopback), capture size 65535 bytes >> 11:22:37.030244 IP 192.168.3.99> 190.252.34.186: ICMP pandora.userid.org >> udp port 16881 unreachable, length 134 >> 11:24:03.137016 IP 192.168.3.99> 190.252.34.186: ICMP pandora.userid.org >> udp port 16881 unreachable, length 98 >> >> Relevant pf.conf lines: >> int_if = "em0" >> ext_if = "tun0" >> # NAT >> nat on $ext_if from $int_if:network to any -> ($ext_if) >> >> Here is the info about states leaking: >> >> State Table Total Rate >> current entries 108488 >> >> [/var/preserve/root] # pfctl -F states >> 1003 states cleared >> [/var/preserve/root] # pfctl -s info >> Status: Enabled for 0 days 02:21:18 Debug: Urgent >> >> Interface Stats for tun0 IPv4 IPv6 >> Bytes In 1252327614 1907903 >> Bytes Out 373783492 1429003 >> Packets In >> Passed 1341017 12360 >> Blocked 45437 831 >> Packets Out >> Passed 1186359 13441 >> Blocked 1641 3724 >> >> State Table Total Rate >> current entries 125127 >> >> States aren't getting cleared properly. Below is a sample of the state key >> linking mismatch problem: >> >> Jul 2 11:28:17 pyr7535 kernel: pf: state key linking mismatch! dir=OUT, >> if=em0, stored af=2, a0: > I just committed a fix for the state key linking mismatch issue. > Can you test with the latest HEAD sources? > > > >> Jul 2 11:28:17 pyr7535 kernel: 192.168.3.238:55590, a1: 216.106.102.33 >> Jul 2 11:28:18 pyr7535 kernel: :18825, proto=6 >> Jul 2 11:28:18 pyr7535 kernel: , found af=2, a0: 192.168.3.238 >> Jul 2 11:28:18 pyr7535 kernel: :55590, a1: >> Jul 2 11:28:18 pyr7535 kernel: 216.106.102.33:18825 >> Jul 2 11:28:18 pyr7535 kernel: , proto=6. >> Jul 2 11:28:18 pyr7535 kernel: pf: state key linking mismatch! dir=OUT, >> if=em0, stored af=2, a0: 192.168.3.238:55590, a1: 216.106.102.33:18825, >> proto=6, found af=2, a0: 192.168.3.238:55590, a1: 216.106.102.33:18825, >> proto=6. >> Jul 2 11:28:19 pyr7535 kernel: pf: state key linking mismatch! dir=OUT, >> if=em0, stored af=2, a0: 192.168.3.238 >> Jul 2 11:28:19 pyr7535 kernel: :55590, a1: >> Jul 2 11:28:19 pyr7535 kernel: 216.106.102.33:18825 >> Jul 2 11:28:19 pyr7535 kernel: , proto=6, found af=2, a0: >> Jul 2 11:28:19 pyr7535 kernel: 192.168.3.238:55590 >> Jul 2 11:28:19 pyr7535 kernel: , a1: 216.106.102.33 >> Jul 2 11:28:19 pyr7535 kernel: :18825, proto=6. >> >> >> >> _______________________________________________ >> 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 Tue Jul 5 13:48:05 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84FDC106566C for ; Tue, 5 Jul 2011 13:48:05 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) by mx1.freebsd.org (Postfix) with ESMTP id F2D028FC12 for ; Tue, 5 Jul 2011 13:48:04 +0000 (UTC) Received: from [87.79.155.68] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Qe5ys-0007HT-VZ; Tue, 05 Jul 2011 15:48:03 +0200 Date: Tue, 5 Jul 2011 15:47:47 +0200 From: Fabian Keil To: Ermal =?ISO-8859-1?Q?Lu=E7i?= Message-ID: <20110705154747.547ac919@fabiankeil.de> In-Reply-To: References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> <4E0F3A2D.60409@userid.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/G6gQI.DPbwhVgPmFOuCczl3"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: freebsd-pf@freebsd.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... 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, 05 Jul 2011 13:48:05 -0000 --Sig_/G6gQI.DPbwhVgPmFOuCczl3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ermal Lu=E7i wrote: > On Sat, Jul 2, 2011 at 5:33 PM, Pierre Lamy wrote: > > > > > > On 6/29/2011 1:22 PM, Fabian Keil wrote: > >> > >> "Bjoern A. Zeeb" =A0wrote: > >> > >>> Begin forwarded message: > >>> > >>>> From: "Bjoern A. Zeeb" > >>>> Date: June 28, 2011 11:57:25 AM GMT+00:00 > >>>> To: src-committers@freebsd.org, svn-src-all@freebsd.org, > >>>> svn-src-head@freebsd.org > >>>> Subject: svn commit: r223637 - in head: . contrib/pf/authpf > >>>> contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflo= gd > >>>> sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/mo= dules > >>>> s... > >>>> > >>>> Author: bz > >>>> Date: Tue Jun 28 11:57:25 2011 > >>>> New Revision: 223637 > >>>> URL: http://svn.freebsd.org/changeset/base/223637 > >>>> > >>>> Log: > >>>> =A0Update packet filter (pf) code to OpenBSD 4.5. > >> > >> Thanks! > >> > >>> In short; please test! > >> > >> I didn't experience any real problems yet, but running > >> Privoxy-Regression-Test, I reproducible got this log message > >> for one of the tests: > >> > >> Jun 29 18:26:19 r500 kernel: pf: state key linking mismatch! dir=3DOUT, > >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, proto= =3D6, found > >> af=3D2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, proto=3D6. > >> > >> This didn't happen with the previous pf version. > >> > >> I tracked it down to a test that does a connect() > >> to a local unbound port. > >> > >> It's also reproducible for every address on the system with: > >> > >> ifconfig -a | awk '/inet / {system("telnet "$2" 12345")}' > >> > >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, > >> if=3Dlo0, stored af=3D2, a0: 192.168.5.49:61512, a1: 192.168.5.49:1234= 5, > >> proto=3D6, found af=3D2, a0: 192.168.5.49:61512, a1: 192.168.5.49:1234= 5, > >> proto=3D6. > >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, > >> if=3Dlo0, stored af=3D2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, pro= to=3D6, > >> found af=3D2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, proto=3D6. > >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, > >> if=3Dlo1, stored af=3D2, a0: 192.168.6.100:31600, a1: 192.168.6.100:12= 345, > >> proto=3D6, found af=3D2, a0: 192.168.6.100:31600, a1: 192.168.6.100:12= 345, > >> proto=3D6. > >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, > >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, proto= =3D6, found > >> af=3D2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, proto=3D6. > >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, > >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, proto= =3D6, found > >> af=3D2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, proto=3D6. > >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, > >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, proto= =3D6, found > >> af=3D2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, proto=3D6. > >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOUT, > >> if=3Dlo0, stored af=3D2, a0: 192.168.0.106:32448, a1: 192.168.0.106:12= 345, > >> proto=3D6, found af=3D2, a0: 192.168.0.106:32448, a1: 192.168.0.106:12= 345, > >> proto=3D6. > >> > >> 12345 can be replaced with any unbound port it seems. > >> > >> I'm additionally occasionally seeing the message for successfully > >> established connections (both internal and outgoing) but don't > >> know how to reproduce it. > >> > >> Fabian > > > > I also get the state key mismatch problem, it seems that pf is leaking > > states (I assume this is the same problem). I also see a strange NAT is= sue, > > internal IPs leak somewhat on the outside int. Eventually the system ru= ns > > out of state entry slots and connectivity is lost. This is on a -current > > kernel from ~Jun 30, after the 4.5 import. > > > > tun0: flags=3D8151 metric 0 m= tu 1492 > > =A0 =A0 =A0 =A0options=3D80000 > > =A0 =A0 =A0 =A0inet6 fe80::290:bff:fe1a:a674%tun0 prefixlen 64 scopeid = 0xf > > =A0 =A0 =A0 =A0inet6 2607:f0b0:0:1:290:bff:fe1a:a674 prefixlen 64 autoc= onf > > =A0 =A0 =A0 =A0inet 216.106.102.33 --> 209.87.255.1 netmask 0xffffffff > > =A0 =A0 =A0 =A0nd6 options=3D23 > > =A0 =A0 =A0 =A0Opened by PID 3446 > > > > em0 is on the 192.168.3/24 network > > > > [/var/preserve/root] # tcpdump -i tun0 net 192.168= .3.0 > > mask 255.255.255.0 > > tcpdump: verbose output suppressed, use -v or -vv for full protocol dec= ode > > listening on tun0, link-type NULL (BSD loopback), capture size 65535 by= tes > > 11:22:37.030244 IP 192.168.3.99 > 190.252.34.186: ICMP pandora.userid.o= rg > > udp port 16881 unreachable, length 134 > > 11:24:03.137016 IP 192.168.3.99 > 190.252.34.186: ICMP pandora.userid.o= rg > > udp port 16881 unreachable, length 98 > > > > Relevant pf.conf lines: > > int_if =3D "em0" > > ext_if =3D "tun0" > > # NAT > > nat on $ext_if from $int_if:network to any -> ($ext_if) > > > > Here is the info about states leaking: > > > > State Table =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Total = =A0 =A0 =A0 =A0 =A0 =A0 Rate > > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 108488 > > > > [/var/preserve/root] # pfctl -F states > > 1003 states cleared > > [/var/preserve/root] # pfctl -s info > > Status: Enabled for 0 days 02:21:18 =A0 =A0 =A0 =A0 =A0 Debug: Urgent > > > > Interface Stats for tun0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IPv4 =A0 =A0 =A0 = =A0 =A0 =A0 IPv6 > > =A0Bytes In =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01252327614 =A0 = =A0 =A0 =A0 =A01907903 > > =A0Bytes Out =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0373783492 =A0 = =A0 =A0 =A0 =A01429003 > > =A0Packets In > > =A0 =A0Passed =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1341017 = =A0 =A0 =A0 =A0 =A0 =A012360 > > =A0 =A0Blocked =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A045437= =A0 =A0 =A0 =A0 =A0 =A0 =A0831 > > =A0Packets Out > > =A0 =A0Passed =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1186359 = =A0 =A0 =A0 =A0 =A0 =A013441 > > =A0 =A0Blocked =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1641= =A0 =A0 =A0 =A0 =A0 =A0 3724 > > > > State Table =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Total = =A0 =A0 =A0 =A0 =A0 =A0 Rate > > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 125127 > > > > States aren't getting cleared properly. Below is a sample of the state = key > > linking mismatch problem: > > > > Jul =A02 11:28:17 pyr7535 kernel: pf: state key linking mismatch! dir= =3DOUT, > > if=3Dem0, stored af=3D2, a0: >=20 > I just committed a fix for the state key linking mismatch issue. > Can you test with the latest HEAD sources? Works for me, at least the error messages are gone. Thanks a lot. I never experienced the "state leak issue" Pierre described above, but it does seem to take a while until cleared states are reported as such: fk@r500 ~ $sudo pfctl -s all | grep current current entries 1556 fk@r500 ~ $sudo pfctl -F states 1556 states cleared fk@r500 ~ $sudo pfctl -s all | grep current current entries 1259 fk@r500 ~ $sudo pfctl -s all | grep current current entries 1133 fk@r500 ~ $sudo pfctl -s all | grep current current entries 1019 fk@r500 ~ $sudo pfctl -F states 0 states cleared fk@r500 ~ $sudo pfctl -s all | grep current current entries 742 fk@r500 ~ $sudo pfctl -s all | grep current current entries 667 fk@r500 ~ $sudo pfctl -s all | grep current current entries 667 fk@r500 ~ $sudo pfctl -F states 0 states cleared fk@r500 ~ $sudo pfctl -s all | grep current current entries 436 fk@r500 ~ $sudo pfctl -s all | grep current current entries 436 fk@r500 ~ $sudo pfctl -s all | grep current current entries 352 fk@r500 ~ $sudo pfctl -F states 0 states cleared fk@r500 ~ $sudo pfctl -s all | grep current current entries 185 I never looked at this before, so it might have always behaved that way. Fabian --Sig_/G6gQI.DPbwhVgPmFOuCczl3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4TFg8ACgkQBYqIVf93VJ0UAgCgp9AHqmczWUWSemuKC0WIhPvT SmMAni58NxcpnoKMRpzXjjEjbTw8yzgy =btE1 -----END PGP SIGNATURE----- --Sig_/G6gQI.DPbwhVgPmFOuCczl3-- From owner-freebsd-pf@FreeBSD.ORG Tue Jul 5 16:17:57 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F8B21065677 for ; Tue, 5 Jul 2011 16:17:57 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 046448FC1B for ; Tue, 5 Jul 2011 16:17:56 +0000 (UTC) Received: by iwr19 with SMTP id 19so7155137iwr.13 for ; Tue, 05 Jul 2011 09:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E9eKYBoNBF02xCpRKCz646ALoKqYFJCXdItha4Hk6wE=; b=o4A9JHe4ri4JTgLeSf0Ofwxa8DIlj9jFEflwNIeZH5bcqXxMf7+q+jRCpW/MBNLKlr icjjAtdGYDL2kDdtaaiwrG0cClBnKM/5cR6iTamqoIsriAsGCHEOe55myBHJz/hqSnSG JG5tfpaSsuiavHEZPs0JGAm3ds3cJOaPxdsYc= MIME-Version: 1.0 Received: by 10.231.28.17 with SMTP id k17mr6771203ibc.99.1309882676119; Tue, 05 Jul 2011 09:17:56 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.171.148 with HTTP; Tue, 5 Jul 2011 09:17:56 -0700 (PDT) In-Reply-To: <20110705154747.547ac919@fabiankeil.de> References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> <4E0F3A2D.60409@userid.org> <20110705154747.547ac919@fabiankeil.de> Date: Tue, 5 Jul 2011 18:17:56 +0200 X-Google-Sender-Auth: 7Kz_EwMyU_I70JmgounFRxAAh_A Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Fabian Keil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... 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, 05 Jul 2011 16:17:57 -0000 On Tue, Jul 5, 2011 at 3:47 PM, Fabian Keil wrote: > Ermal Lu=E7i wrote: > >> On Sat, Jul 2, 2011 at 5:33 PM, Pierre Lamy wrote: >> > >> > >> > On 6/29/2011 1:22 PM, Fabian Keil wrote: >> >> >> >> "Bjoern A. Zeeb" =A0wrote: >> >> >> >>> Begin forwarded message: >> >>> >> >>>> From: "Bjoern A. Zeeb" >> >>>> Date: June 28, 2011 11:57:25 AM GMT+00:00 >> >>>> To: src-committers@freebsd.org, svn-src-all@freebsd.org, >> >>>> svn-src-head@freebsd.org >> >>>> Subject: svn commit: r223637 - in head: . contrib/pf/authpf >> >>>> contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pfl= ogd >> >>>> sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/m= odules >> >>>> s... >> >>>> >> >>>> Author: bz >> >>>> Date: Tue Jun 28 11:57:25 2011 >> >>>> New Revision: 223637 >> >>>> URL: http://svn.freebsd.org/changeset/base/223637 >> >>>> >> >>>> Log: >> >>>> =A0Update packet filter (pf) code to OpenBSD 4.5. >> >> >> >> Thanks! >> >> >> >>> In short; please test! >> >> >> >> I didn't experience any real problems yet, but running >> >> Privoxy-Regression-Test, I reproducible got this log message >> >> for one of the tests: >> >> >> >> Jun 29 18:26:19 r500 kernel: pf: state key linking mismatch! dir=3DOU= T, >> >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, prot= o=3D6, found >> >> af=3D2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, proto=3D6. >> >> >> >> This didn't happen with the previous pf version. >> >> >> >> I tracked it down to a test that does a connect() >> >> to a local unbound port. >> >> >> >> It's also reproducible for every address on the system with: >> >> >> >> ifconfig -a | awk '/inet / {system("telnet "$2" 12345")}' >> >> >> >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOU= T, >> >> if=3Dlo0, stored af=3D2, a0: 192.168.5.49:61512, a1: 192.168.5.49:123= 45, >> >> proto=3D6, found af=3D2, a0: 192.168.5.49:61512, a1: 192.168.5.49:123= 45, >> >> proto=3D6. >> >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOU= T, >> >> if=3Dlo0, stored af=3D2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, pr= oto=3D6, >> >> found af=3D2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, proto=3D6. >> >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOU= T, >> >> if=3Dlo1, stored af=3D2, a0: 192.168.6.100:31600, a1: 192.168.6.100:1= 2345, >> >> proto=3D6, found af=3D2, a0: 192.168.6.100:31600, a1: 192.168.6.100:1= 2345, >> >> proto=3D6. >> >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOU= T, >> >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, prot= o=3D6, found >> >> af=3D2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, proto=3D6. >> >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOU= T, >> >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, prot= o=3D6, found >> >> af=3D2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, proto=3D6. >> >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOU= T, >> >> if=3Dlo1, stored af=3D2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, prot= o=3D6, found >> >> af=3D2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, proto=3D6. >> >> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=3DOU= T, >> >> if=3Dlo0, stored af=3D2, a0: 192.168.0.106:32448, a1: 192.168.0.106:1= 2345, >> >> proto=3D6, found af=3D2, a0: 192.168.0.106:32448, a1: 192.168.0.106:1= 2345, >> >> proto=3D6. >> >> >> >> 12345 can be replaced with any unbound port it seems. >> >> >> >> I'm additionally occasionally seeing the message for successfully >> >> established connections (both internal and outgoing) but don't >> >> know how to reproduce it. >> >> >> >> Fabian >> > >> > I also get the state key mismatch problem, it seems that pf is leaking >> > states (I assume this is the same problem). I also see a strange NAT i= ssue, >> > internal IPs leak somewhat on the outside int. Eventually the system r= uns >> > out of state entry slots and connectivity is lost. This is on a -curre= nt >> > kernel from ~Jun 30, after the 4.5 import. >> > >> > tun0: flags=3D8151 metric 0 = mtu 1492 >> > =A0 =A0 =A0 =A0options=3D80000 >> > =A0 =A0 =A0 =A0inet6 fe80::290:bff:fe1a:a674%tun0 prefixlen 64 scopeid= 0xf >> > =A0 =A0 =A0 =A0inet6 2607:f0b0:0:1:290:bff:fe1a:a674 prefixlen 64 auto= conf >> > =A0 =A0 =A0 =A0inet 216.106.102.33 --> 209.87.255.1 netmask 0xffffffff >> > =A0 =A0 =A0 =A0nd6 options=3D23 >> > =A0 =A0 =A0 =A0Opened by PID 3446 >> > >> > em0 is on the 192.168.3/24 network >> > >> > [/var/preserve/root] # tcpdump -i tun0 net 192.16= 8.3.0 >> > mask 255.255.255.0 >> > tcpdump: verbose output suppressed, use -v or -vv for full protocol de= code >> > listening on tun0, link-type NULL (BSD loopback), capture size 65535 b= ytes >> > 11:22:37.030244 IP 192.168.3.99 > 190.252.34.186: ICMP pandora.userid.= org >> > udp port 16881 unreachable, length 134 >> > 11:24:03.137016 IP 192.168.3.99 > 190.252.34.186: ICMP pandora.userid.= org >> > udp port 16881 unreachable, length 98 >> > >> > Relevant pf.conf lines: >> > int_if =3D "em0" >> > ext_if =3D "tun0" >> > # NAT >> > nat on $ext_if from $int_if:network to any -> ($ext_if) >> > >> > Here is the info about states leaking: >> > >> > State Table =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Total = =A0 =A0 =A0 =A0 =A0 =A0 Rate >> > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 108488 >> > >> > [/var/preserve/root] # pfctl -F states >> > 1003 states cleared >> > [/var/preserve/root] # pfctl -s info >> > Status: Enabled for 0 days 02:21:18 =A0 =A0 =A0 =A0 =A0 Debug: Urgent >> > >> > Interface Stats for tun0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IPv4 =A0 =A0 =A0 = =A0 =A0 =A0 IPv6 >> > =A0Bytes In =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01252327614 =A0 = =A0 =A0 =A0 =A01907903 >> > =A0Bytes Out =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0373783492 =A0 = =A0 =A0 =A0 =A01429003 >> > =A0Packets In >> > =A0 =A0Passed =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1341017 = =A0 =A0 =A0 =A0 =A0 =A012360 >> > =A0 =A0Blocked =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04543= 7 =A0 =A0 =A0 =A0 =A0 =A0 =A0831 >> > =A0Packets Out >> > =A0 =A0Passed =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1186359 = =A0 =A0 =A0 =A0 =A0 =A013441 >> > =A0 =A0Blocked =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 164= 1 =A0 =A0 =A0 =A0 =A0 =A0 3724 >> > >> > State Table =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Total = =A0 =A0 =A0 =A0 =A0 =A0 Rate >> > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 125127 >> > >> > States aren't getting cleared properly. Below is a sample of the state= key >> > linking mismatch problem: >> > >> > Jul =A02 11:28:17 pyr7535 kernel: pf: state key linking mismatch! dir= =3DOUT, >> > if=3Dem0, stored af=3D2, a0: >> >> I just committed a fix for the state key linking mismatch issue. >> Can you test with the latest HEAD sources? > > Works for me, at least the error messages are gone. Thanks a lot. > > I never experienced the "state leak issue" Pierre described above, > but it does seem to take a while until cleared states are reported > as such: It is normal the GC thread used for this takes only a bunch at a time. Though you want see those states in the output of pfctl -vss since they are masked out. > > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1556 > fk@r500 ~ $sudo pfctl -F states > 1556 states cleared > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1259 > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1133 > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1019 > fk@r500 ~ $sudo pfctl -F states > 0 states cleared > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0742 > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0667 > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0667 > fk@r500 ~ $sudo pfctl -F states > 0 states cleared > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0436 > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0436 > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0352 > fk@r500 ~ $sudo pfctl -F states > 0 states cleared > fk@r500 ~ $sudo pfctl -s all | grep current > =A0current entries =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0185 > > I never looked at this before, so it might have always behaved that way. > > Fabian > --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Tue Jul 5 16:29:00 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 594CB1065670; Tue, 5 Jul 2011 16:29:00 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1123E8FC12; Tue, 5 Jul 2011 16:28:59 +0000 (UTC) Received: from [87.79.155.68] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Qe8Uc-0002PC-BE; Tue, 05 Jul 2011 18:28:58 +0200 Date: Tue, 5 Jul 2011 18:28:46 +0200 From: Fabian Keil To: Ermal =?ISO-8859-1?Q?Lu=E7i?= Message-ID: <20110705182846.7be592a3@fabiankeil.de> In-Reply-To: References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> <4E0F3A2D.60409@userid.org> <20110705154747.547ac919@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/C3o/m9m_05fZh1q2.OQ+=zI"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: freebsd-pf@freebsd.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... 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, 05 Jul 2011 16:29:00 -0000 --Sig_/C3o/m9m_05fZh1q2.OQ+=zI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ermal Lu=E7i wrote: > On Tue, Jul 5, 2011 at 3:47 PM, Fabian Keil > wrote: > > Ermal Lu=E7i wrote: > >> I just committed a fix for the state key linking mismatch issue. > >> Can you test with the latest HEAD sources? > > > > Works for me, at least the error messages are gone. Thanks a lot. > > > > I never experienced the "state leak issue" Pierre described above, > > but it does seem to take a while until cleared states are reported > > as such: >=20 > It is normal the GC thread used for this takes only a bunch at a time. > Though you want see those states in the output of pfctl -vss since > they are masked out. Good to know, thanks for the clarification. Fabian --Sig_/C3o/m9m_05fZh1q2.OQ+=zI Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4TO8kACgkQBYqIVf93VJ3ggACfSg9z/TmWckOBk+fageotsLBC oU4AnjpcmWTGjts4bDO3qs9aB682IXrx =8D+4 -----END PGP SIGNATURE----- --Sig_/C3o/m9m_05fZh1q2.OQ+=zI-- From owner-freebsd-pf@FreeBSD.ORG Tue Jul 5 21:17:13 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9089106564A; Tue, 5 Jul 2011 21:17:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B2BC18FC17; Tue, 5 Jul 2011 21:17:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p65LHDGM067247; Tue, 5 Jul 2011 21:17:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p65LHDHq067243; Tue, 5 Jul 2011 21:17:13 GMT (envelope-from linimon) Date: Tue, 5 Jul 2011 21:17:13 GMT Message-Id: <201107052117.p65LHDHq067243@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158636: [pf] if_pfsync.c fails to build when NBPFILTER == 0 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, 05 Jul 2011 21:17:13 -0000 Old Synopsis: if_pfsync.c fails to build when NBPFILTER == 0 New Synopsis: [pf] if_pfsync.c fails to build when NBPFILTER == 0 Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jul 5 21:16:49 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158636 From owner-freebsd-pf@FreeBSD.ORG Wed Jul 6 15:51:02 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5550C106564A for ; Wed, 6 Jul 2011 15:51:02 +0000 (UTC) (envelope-from calomelopensourceresearch@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4518FC08 for ; Wed, 6 Jul 2011 15:51:01 +0000 (UTC) Received: by vws18 with SMTP id 18so77233vws.13 for ; Wed, 06 Jul 2011 08:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:reply-to:mime-version :content-type:content-disposition:errors-to:x-gpg-key-fingerprint; bh=MfF18F76L15yS9mfUXb8C6NBq6J17njIYhSt93U9xOI=; b=bGqX5XSEe0CsspVDKk+aQtTtu9sIOpHR/QNwqBeu/i4huvCxafFN0XGVp5V30LqTop rPuDvnbogXtXvXbRFMr9Le13/+gIURp9I2+eMaeuTyLecX4Js+HVkDp20b64enBLetOE cfGLOI+uCtFBY5Lqom0zFhDxV+8pCYtmIJphU= Received: by 10.52.176.101 with SMTP id ch5mr8437741vdc.129.1309965911362; Wed, 06 Jul 2011 08:25:11 -0700 (PDT) Received: from calomel.org (pool-71-166-62-51.bltmmd.fios.verizon.net [71.166.62.51]) by mx.google.com with ESMTPS id dp2sm4970769vbb.1.2011.07.06.08.25.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 08:25:10 -0700 (PDT) Sender: Calomel Org Received: by calomel.org (resilience smtpd, from userid 1000) id 69A60196DB; Wed, 6 Jul 2011 11:25:06 -0400 (EDT) Date: Wed, 6 Jul 2011 11:25:06 -0400 From: Calomel Org To: freebsd-pf@freebsd.org, misc@openbsd.org Message-ID: <20110706152506.GA26334@calomel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Errors-To: infallibilismindefeasibility@calomel.org X-GPG-Key-FingerPrint: 328F 9F03 C73F 7F31 B06B FA5B C1FC A1C7 3D2E ED32 Cc: Subject: pf ALTQ bandwidth limited to a 32bit value (4294Mb) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Calomel Org 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, 06 Jul 2011 15:51:02 -0000 ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any higher, altq will flip back to zero. This "bug" was found when trying to test 10 gigabit and 40 gigabit bandwidth models. These tests were done on OpenBSD 32bit and 64bit as well as FreeBSD 32bit and 64bit. If anyone else can verify this independently and agree with the results I would be happy to register it as a bug. How to replicate: A quick test is setting the bandwidth to 4294Mb and doing a pfctl -sq to check altq. altq on $ExtIf bandwidth 4294Mb hfsc queue { ack, web} queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web} Now set the bandwidth to 4295Mb and notice altq has flip to zero and add the 32.70Kb difference. altq on $ExtIf bandwidth 4295Mb hfsc queue { ack, web } queue root_em0 on em0 bandwidth 32.70Kb priority 0 {ack, web} Again, we can set the bandwidth to a multiple of two(2) to 8589Mb. The bandwidth value flips to zero once and the result is 4.29Gb. altq on $ExtIf bandwidth 8589Mb hfsc queue { ack, web} queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web} If we add one more megabit to 8590Mb the value flips twice and we are left with 65.41Kb. altq on $ExtIf bandwidth 8590Mb hfsc queue { ack, web} queue root_em0 on em0 bandwidth 65.41Kb priority 0 {ack, web} Thanks. -- Calomel @ https://calomel.org Open Source Research and Reference From owner-freebsd-pf@FreeBSD.ORG Wed Jul 6 16:50:22 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B85131065687 for ; Wed, 6 Jul 2011 16:50:22 +0000 (UTC) (envelope-from peter@bsdly.net) Received: from skapet.bsdly.net (cl-426.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:1a9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 731FF8FC12 for ; Wed, 6 Jul 2011 16:50:22 +0000 (UTC) Received: from [10.168.103.30] (helo=deeperthought.bsdly.net.bsdly.net ident=peter) by skapet.bsdly.net with esmtp (Exim 4.76) (envelope-from ) id 1QeVIr-0007wC-0K; Wed, 06 Jul 2011 18:50:21 +0200 From: peter@bsdly.net (Peter N. M. Hansteen) To: Calomel Org References: <20110706152506.GA26334@calomel.org> Date: Wed, 06 Jul 2011 18:50:18 +0200 In-Reply-To: <20110706152506.GA26334@calomel.org> (Calomel Org's message of "Wed, 6 Jul 2011 11:25:06 -0400") Message-ID: <877h7vcq0l.fsf@deeperthought.bsdly.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: misc@openbsd.org, freebsd-pf@freebsd.org Subject: Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb) 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, 06 Jul 2011 16:50:22 -0000 Calomel Org writes: > ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. > This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any > higher, altq will flip back to zero. This "bug" was found when trying > to test 10 gigabit and 40 gigabit bandwidth models. These tests were > done on OpenBSD 32bit and 64bit as well as FreeBSD 32bit and 64bit. Nice to hear you've got access to relatively high end gear for testing, I'm sure it will come in handy when the time comes to test any proposed fixes. The obvious workaround in the short term is to do the traffic shaping and filtering a bit closer to the end user, where bandwidth is a bit more scarce. In the slightly longer term, I'm sure a verified bug report (with patches against -current code if feasible) would be much appreciated. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. From owner-freebsd-pf@FreeBSD.ORG Wed Jul 6 23:09:49 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 189B7106566B for ; Wed, 6 Jul 2011 23:09:49 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail2.jellyfishnet.co.uk (mail2.jellyfishnet.co.uk [93.91.20.10]) by mx1.freebsd.org (Postfix) with ESMTP id AFEEA8FC0A for ; Wed, 6 Jul 2011 23:09:48 +0000 (UTC) Received: from pemexhub01.jellyfishnet.co.uk.local (93.91.20.3) by mail2.jellyfishnet.co.uk (93.91.20.10) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 7 Jul 2011 00:09:51 +0100 Received: from PEMEXMBXVS04.jellyfishnet.co.uk.local ([192.168.65.51]) by pemexhub01.jellyfishnet.co.uk.local ([192.168.65.7]) with mapi; Thu, 7 Jul 2011 00:09:47 +0100 From: Greg Hennessy To: Calomel Org , "freebsd-pf@freebsd.org" Date: Thu, 7 Jul 2011 00:09:43 +0100 Thread-Topic: pf ALTQ bandwidth limited to a 32bit value (4294Mb) Thread-Index: Acw79JIqWCqJe6eBT7+VzOsMdMCisAAPNDFg Message-ID: <9EB23F6C23A8B6488E8BCC92A48E83261277A0ACB9@PEMEXMBXVS04.jellyfishnet.co.uk.local> References: <20110706152506.GA26334@calomel.org> In-Reply-To: <20110706152506.GA26334@calomel.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: pf ALTQ bandwidth limited to a 32bit value (4294Mb) 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, 06 Jul 2011 23:09:49 -0000 >=20 > ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. > This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any hi= gher, > altq will flip back to zero. This "bug" was found when trying to test 10 = gigabit > and 40 gigabit bandwidth models.=20 What a problem to have :-)=20 On a side note out of pure curiousity, what's PF performance like up in the= stratosphere under those sort of loads/packet rates ? :-) Greg From owner-freebsd-pf@FreeBSD.ORG Thu Jul 7 09:05:21 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15FD8106574C for ; Thu, 7 Jul 2011 09:05:21 +0000 (UTC) (envelope-from mistrzipan@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id 94B878FC13 for ; Thu, 7 Jul 2011 09:05:20 +0000 (UTC) Received: by fxe6 with SMTP id 6so767844fxe.17 for ; Thu, 07 Jul 2011 02:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=74WSeplEY2g5ldCdvWgOTyMcJ6eKM86x9+1eygdl9r0=; b=Fhfl6YmAi3mm6UqWVYMxAaw4HAhmMINCx0GIwTxKWX1T/m4Cj0BWDwSbz59rWTL2X0 hqqhOOCgwrOWRUGJFhatPV34pofJQIXTJhe2WDy7FonWDq7NCQTmkewc/R4qGgOYq31h fadd5jKQgN6/cdn6DpTtPV1E9l/+J/Z0dFxiM= Received: by 10.223.145.6 with SMTP id b6mr936791fav.2.1310029519270; Thu, 07 Jul 2011 02:05:19 -0700 (PDT) Received: from [79.110.194.136] ([79.110.194.136]) by mx.google.com with ESMTPS id b13sm6580544fab.36.2011.07.07.02.05.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 02:05:16 -0700 (PDT) Message-ID: <4E1576C9.2070406@gmail.com> Date: Thu, 07 Jul 2011 11:05:13 +0200 From: "Bartek W. aka Mastier" User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <20110706152506.GA26334@calomel.org> <877h7vcq0l.fsf@deeperthought.bsdly.net> In-Reply-To: <877h7vcq0l.fsf@deeperthought.bsdly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb) 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: Thu, 07 Jul 2011 09:05:21 -0000 On 06.07.2011 18:50, Peter N. M. Hansteen wrote: > Calomel Org writes: > >> ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. >> This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any >> higher, altq will flip back to zero. This "bug" was found when trying >> to test 10 gigabit and 40 gigabit bandwidth models. These tests were >> done on OpenBSD 32bit and 64bit as well as FreeBSD 32bit and 64bit. > Nice to hear you've got access to relatively high end gear for testing, > I'm sure it will come in handy when the time comes to test any proposed > fixes. > > The obvious workaround in the short term is to do the traffic shaping > and filtering a bit closer to the end user, where bandwidth is a bit > more scarce. In the slightly longer term, I'm sure a verified bug > report (with patches against -current code if feasible) would be much > appreciated. > > - Peter > Haha ! I notice that too! Man, I'm shaping traffic for users end which total traffic is about 4Gb , but in my case I just used hfsc, and my "mighty" firewall generating script just divides the whole bandwidth like total/(no.users+1) for guaranteed speed. 1 stands for default queue. From owner-freebsd-pf@FreeBSD.ORG Thu Jul 7 13:28:01 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ACA81065670 for ; Thu, 7 Jul 2011 13:28:01 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 66A648FC12 for ; Thu, 7 Jul 2011 13:28:01 +0000 (UTC) Received: by iyb11 with SMTP id 11so1132069iyb.13 for ; Thu, 07 Jul 2011 06:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0mas8WJhQgjOcoerWAzicb9BFcYSDHOmKdrDP4Y0bw8=; b=R8TN9oItZOJHD4XyiKCU3E2tQsl5wHzCDxo6V/M+fIDf80szcK3diAUfR5NNnD+AFN R6+dI2lpPPqOGVVbzh453T5OA2X0jIlJ6funhx3uJ2vuzTaxSX3+2zE7z8tdGOXGqlRE YufJx6VJCwVORTUPg4Y3uMdpS8EdZzs9mDAIE= MIME-Version: 1.0 Received: by 10.231.200.20 with SMTP id eu20mr742347ibb.24.1310045280165; Thu, 07 Jul 2011 06:28:00 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.171.148 with HTTP; Thu, 7 Jul 2011 06:28:00 -0700 (PDT) In-Reply-To: <20110706152506.GA26334@calomel.org> References: <20110706152506.GA26334@calomel.org> Date: Thu, 7 Jul 2011 15:28:00 +0200 X-Google-Sender-Auth: SLPpiH2eiK7qBoetAVJDcsPdfwo Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Calomel Org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: misc@openbsd.org, freebsd-pf@freebsd.org Subject: Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb) 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: Thu, 07 Jul 2011 13:28:01 -0000 On Wed, Jul 6, 2011 at 5:25 PM, Calomel Org wrote: > ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. > This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any > higher, altq will flip back to zero. This "bug" was found when trying > to test 10 gigabit and 40 gigabit bandwidth models. These tests were > done on OpenBSD 32bit and 64bit as well as FreeBSD 32bit and 64bit. > > If anyone else can verify this independently and agree with the > results I would be happy to register it as a bug. > > > How to replicate: > > A quick test is setting the bandwidth to 4294Mb and doing a pfctl -sq > to check altq. > > =A0altq on $ExtIf bandwidth 4294Mb hfsc queue { ack, web} > =A0queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web} > > Now set the bandwidth to 4295Mb and notice altq has flip to zero and > add the 32.70Kb difference. > > =A0altq on $ExtIf bandwidth 4295Mb hfsc queue { ack, web } > =A0queue root_em0 on em0 bandwidth 32.70Kb priority 0 {ack, web} > > Again, we can set the bandwidth to a multiple of two(2) to 8589Mb. > The bandwidth value flips to zero once and the result is 4.29Gb. > > =A0altq on $ExtIf bandwidth 8589Mb hfsc queue { ack, web} > =A0queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web} > > If we add one more megabit to 8590Mb the value flips twice and we are > left with 65.41Kb. > > =A0altq on $ExtIf bandwidth 8590Mb hfsc queue { ack, web} > =A0queue root_em0 on em0 bandwidth 65.41Kb priority 0 {ack, web} > It is true that there is a limit because of data type used. Though it cannot be fixed easily on i386 but on amd64 this should work. Index: sys/contrib/pf/net/pfvar.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/contrib/pf/net/pfvar.h (revision 223824) +++ sys/contrib/pf/net/pfvar.h (working copy) @@ -1491,13 +1491,13 @@ /* scheduler spec */ u_int8_t scheduler; /* scheduler type */ u_int16_t tbrsize; /* tokenbucket regulator si= ze */ - u_int32_t ifbandwidth; /* interface bandwidth */ + u_int64_t ifbandwidth; /* interface bandwidth */ /* queue spec */ char qname[PF_QNAME_SIZE]; /* queue name */ char parent[PF_QNAME_SIZE]; /* parent name */ u_int32_t parent_qid; /* parent queue id */ - u_int32_t bandwidth; /* queue bandwidth */ + u_int64_t bandwidth; /* queue bandwidth */ u_int8_t priority; /* priority */ #ifdef __FreeBSD__ u_int8_t local_flags; /* dynamic interface */ > > Thanks. > > -- > =A0 Calomel @ https://calomel.org > =A0 Open Source Research and Reference > _______________________________________________ > 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" > --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Thu Jul 7 19:41:56 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6A2A106564A for ; Thu, 7 Jul 2011 19:41:56 +0000 (UTC) (envelope-from calomelopensourceresearch@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7BE7A8FC15 for ; Thu, 7 Jul 2011 19:41:56 +0000 (UTC) Received: by vws18 with SMTP id 18so1308451vws.13 for ; Thu, 07 Jul 2011 12:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to:errors-to :x-gpg-key-fingerprint; bh=YCiXwkG1C0GrY2pEd7ULlN4pSjcnhLzY2QFTkmEr5xs=; b=v5JMqTvJi9cO+doucHWJcqwhCfq3B0DZObYGGoBUcYwUlR8T+8Ojsm2VWR0pasbQNF gob2Y5uEubFmX0w5O7BmeNDMSjVg1ISGxP5NY4A8JhdRh6BMcFeIhAOzjDvt6QRBi98d W7pf943p9x4zOPIqeyNUjLcMaXPG5KzYWx7pw= Received: by 10.52.24.47 with SMTP id r15mr1641103vdf.110.1310067714984; Thu, 07 Jul 2011 12:41:54 -0700 (PDT) Received: from calomel.org (pool-71-166-62-51.bltmmd.fios.verizon.net [71.166.62.51]) by mx.google.com with ESMTPS id e8sm3403070vdf.45.2011.07.07.12.41.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 12:41:53 -0700 (PDT) Sender: Calomel Org Received: by calomel.org (resilience smtpd, from userid 1000) id 82FF6196DB; Thu, 7 Jul 2011 15:41:50 -0400 (EDT) Date: Thu, 7 Jul 2011 15:41:50 -0400 From: Calomel Org To: Greg Hennessy Message-ID: <20110707194150.GA6463@calomel.org> References: <20110706152506.GA26334@calomel.org> <9EB23F6C23A8B6488E8BCC92A48E83261277A0ACB9@PEMEXMBXVS04.jellyfishnet.co.uk.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9EB23F6C23A8B6488E8BCC92A48E83261277A0ACB9@PEMEXMBXVS04.jellyfishnet.co.uk.local> Errors-To: infallibilismindefeasibility@calomel.org X-GPG-Key-FingerPrint: 328F 9F03 C73F 7F31 B06B FA5B C1FC A1C7 3D2E ED32 Cc: "freebsd-pf@freebsd.org" Subject: Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Calomel Org 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: Thu, 07 Jul 2011 19:41:56 -0000 Greg, Pf performance is quite good. The machine averages 9.2 Gbits/sec or 1.15 gigabytes per second (GB/s) in each direction, simultaneously. Interrupt load is about 12%. With a single Linux box on either side of the firewall we see around 161K packets per second and can create 4000 states per second. With more machines on either side on the firewall we are looking to get closer to a million pps and a higher state creation rate. I am not sure what limits we will see then. We published a more detailed write up here under "Can we achieve 10 gigabit speeds ?" Network Tuning and Performance https://calomel.org/network_performance.html -- Calomel @ https://calomel.org Open Source Research and Reference On Wed, Jul 06, 2011 at 07:09:59PM -0400, Greg Hennessy wrote: >> >> ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. >> This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any higher, >> altq will flip back to zero. This "bug" was found when trying to test 10 gigabit >> and 40 gigabit bandwidth models. > >What a problem to have :-) > >On a side note out of pure curiousity, what's PF performance like up in the stratosphere under those sort of loads/packet rates ? :-) > > >Greg > >_______________________________________________ >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 Thu Jul 7 19:45:49 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F1561065672 for ; Thu, 7 Jul 2011 19:45:49 +0000 (UTC) (envelope-from calomelopensourceresearch@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 047508FC13 for ; Thu, 7 Jul 2011 19:45:48 +0000 (UTC) Received: by vxg33 with SMTP id 33so1279148vxg.13 for ; Thu, 07 Jul 2011 12:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to:errors-to :x-gpg-key-fingerprint; bh=M6mHQarf+ovVHiFwwLwWgfIvOd5p61CmmyvDmKZ60YM=; b=N1ceqR51PdmL+uQMMBBsGEqA7TS3Sa1ZSVvczBBo5gSahwyy+9g/pZhFNq3t+hH5u3 3sD7EUbBOhPs5GbTv6P+kkescyegZm/gvbh/8OmjI9u47gS5fdNr8B9DZyQJqh0JQ1dN U1tChuKTs5YkDIHSWjNm0Z7HZ7pkJ3mHs36Lw= Received: by 10.52.115.6 with SMTP id jk6mr1666637vdb.188.1310067948080; Thu, 07 Jul 2011 12:45:48 -0700 (PDT) Received: from calomel.org (pool-71-166-62-51.bltmmd.fios.verizon.net [71.166.62.51]) by mx.google.com with ESMTPS id ck16sm3406748vdb.8.2011.07.07.12.45.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 12:45:46 -0700 (PDT) Sender: Calomel Org Received: by calomel.org (resilience smtpd, from userid 1000) id 5FE3F196DB; Thu, 7 Jul 2011 15:45:45 -0400 (EDT) Date: Thu, 7 Jul 2011 15:45:45 -0400 From: Calomel Org To: Ermal Lu?i Message-ID: <20110707194545.GB6463@calomel.org> References: <20110706152506.GA26334@calomel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Errors-To: infallibilismindefeasibility@calomel.org X-GPG-Key-FingerPrint: 328F 9F03 C73F 7F31 B06B FA5B C1FC A1C7 3D2E ED32 Cc: misc@openbsd.org, freebsd-pf@freebsd.org Subject: Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Calomel Org 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: Thu, 07 Jul 2011 19:45:49 -0000 Ermal, Thanks for the diff. When we tried it on FreeBSD 8.2-p2, ALTq would no long start. We also looked into the source under /usr/src/sys/contrib/altq/altq. Sadly, most of the changes we made either broke altq completely or had no effect. If you have any other ideas we would be happy to try them out. -- Calomel @ https://calomel.org Open Source Research and Reference On Thu, Jul 07, 2011 at 09:28:13AM -0400, Ermal Lu?i wrote: >On Wed, Jul 6, 2011 at 5:25 PM, Calomel Org > wrote: >> ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. >> This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any >> higher, altq will flip back to zero. This "bug" was found when trying >> to test 10 gigabit and 40 gigabit bandwidth models. These tests were >> done on OpenBSD 32bit and 64bit as well as FreeBSD 32bit and 64bit. >> >> If anyone else can verify this independently and agree with the >> results I would be happy to register it as a bug. >> >> >> How to replicate: >> >> A quick test is setting the bandwidth to 4294Mb and doing a pfctl -sq >> to check altq. >> >> ?altq on $ExtIf bandwidth 4294Mb hfsc queue { ack, web} >> ?queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web} >> >> Now set the bandwidth to 4295Mb and notice altq has flip to zero and >> add the 32.70Kb difference. >> >> ?altq on $ExtIf bandwidth 4295Mb hfsc queue { ack, web } >> ?queue root_em0 on em0 bandwidth 32.70Kb priority 0 {ack, web} >> >> Again, we can set the bandwidth to a multiple of two(2) to 8589Mb. >> The bandwidth value flips to zero once and the result is 4.29Gb. >> >> ?altq on $ExtIf bandwidth 8589Mb hfsc queue { ack, web} >> ?queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web} >> >> If we add one more megabit to 8590Mb the value flips twice and we are >> left with 65.41Kb. >> >> ?altq on $ExtIf bandwidth 8590Mb hfsc queue { ack, web} >> ?queue root_em0 on em0 bandwidth 65.41Kb priority 0 {ack, web} >> > >It is true that there is a limit because of data type used. >Though it cannot be fixed easily on i386 but on amd64 this should work. > >Index: sys/contrib/pf/net/pfvar.h >=================================================================== >--- sys/contrib/pf/net/pfvar.h (revision 223824) >+++ sys/contrib/pf/net/pfvar.h (working copy) >@@ -1491,13 +1491,13 @@ > /* scheduler spec */ > u_int8_t scheduler; /* scheduler type */ > u_int16_t tbrsize; /* tokenbucket regulator size */ >- u_int32_t ifbandwidth; /* interface bandwidth */ >+ u_int64_t ifbandwidth; /* interface bandwidth */ > > /* queue spec */ > char qname[PF_QNAME_SIZE]; /* queue name */ > char parent[PF_QNAME_SIZE]; /* parent name */ > u_int32_t parent_qid; /* parent queue id */ >- u_int32_t bandwidth; /* queue bandwidth */ >+ u_int64_t bandwidth; /* queue bandwidth */ > u_int8_t priority; /* priority */ > #ifdef __FreeBSD__ > u_int8_t local_flags; /* dynamic interface */ > > >> >> Thanks. >> >> -- >> ? Calomel @ https://calomel.org >> ? Open Source Research and Reference >> _______________________________________________ >> 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" >> > > > >-- >Ermal >_______________________________________________ >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 Thu Jul 7 19:56:44 2011 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E16E1065672; Thu, 7 Jul 2011 19:56:44 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 51FCB8FC0C; Thu, 7 Jul 2011 19:56:44 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id p67JZdXA060669; Thu, 7 Jul 2011 12:35:39 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id p67JZdXH060668; Thu, 7 Jul 2011 12:35:39 -0700 (PDT) (envelope-from obrien) Date: Thu, 7 Jul 2011 12:35:39 -0700 From: "David O'Brien" To: "Bjoern A. Zeeb" Message-ID: <20110707193539.GA60591@dragon.NUXI.org> References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110629192224.2283efc8@fabiankeil.de> X-Operating-System: FreeBSD 7.4-STABLE Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-pf@FreeBSD.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org 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: Thu, 07 Jul 2011 19:56:44 -0000 On Wed, Jun 29, 2011 at 07:22:24PM +0200, Fabian Keil wrote: > "Bjoern A. Zeeb" wrote: > > In short; please test! > > I didn't experience any real problems yet, but running Hi Bjoern, Unfortunately I've had MAJOR network problems since the pf upgrade. Besides getting the "state key linking mismatch!" issue: pf: state key linking mismatch! dir=OUT, if=fxp0, stored af=2, a0: 208.83.139.205:2703, a1: 74.95.12.85:20474, proto=6, found af=2, a0: 208.83.139.205:2703, a1: 74.95.12.85:20474, proto=6. pf: state key linking mismatch! dir=OUT, if=fxp0, stored af=2, a0: 87.98.164.164:44387, a1: 74.95.12.85:53, proto=6, found af=2, a0: 87.98.164.164:44387, a1: 74.95.12.85:53, proto=6. pf: state key linking mismatch! dir=OUT, if=fxp0, stored af=2, a0: 87.98.164.164:44387, a1: 74.95.12.85:53, proto=6, found af=2, a0: 87.98.164.164:44387, a1: 74.95.12.85:53, proto=6. I found that my kernel (@ r223671) would stop sending packets 3-4 hours after reboot. New connections could not be established, I could not ping any of the direct connections on any of my interfaces. Existing connections would remain established for quite some time (hours) but eventually close also. No amount of re-running /etc/rc.d/* scripts ('pf restart', 'netif restart', 'routing restart', etc...) would bring back working networking. Since reverting back to r223636, my kernel has had rock solid networking. I have 'pfctl', 'netstat', 'netstat -rn', and 'sysctl -a' output from one of these experiences. Would they be useful to you in looking into this? -- -- David (obrien@FreeBSD.org) From owner-freebsd-pf@FreeBSD.ORG Thu Jul 7 22:24:14 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3327106566B for ; Thu, 7 Jul 2011 22:24:14 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail2.jellyfishnet.co.uk (mail2.jellyfishnet.co.uk [93.91.20.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3ED8FC15 for ; Thu, 7 Jul 2011 22:24:14 +0000 (UTC) Received: from pemexhub01.jellyfishnet.co.uk.local (93.91.20.2) by mail2.jellyfishnet.co.uk (93.91.20.10) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 7 Jul 2011 23:24:15 +0100 Received: from PEMEXMBXVS04.jellyfishnet.co.uk.local ([192.168.65.51]) by pemexhub01.jellyfishnet.co.uk.local ([192.168.65.7]) with mapi; Thu, 7 Jul 2011 23:24:13 +0100 From: Greg Hennessy To: Calomel Org Date: Thu, 7 Jul 2011 23:24:12 +0100 Thread-Topic: pf ALTQ bandwidth limited to a 32bit value (4294Mb) Thread-Index: Acw83e7+r7wjbnM8QvGennLH9akvMQAFqm7g Message-ID: <9EB23F6C23A8B6488E8BCC92A48E832612777E37A7@PEMEXMBXVS04.jellyfishnet.co.uk.local> References: <20110706152506.GA26334@calomel.org> <9EB23F6C23A8B6488E8BCC92A48E83261277A0ACB9@PEMEXMBXVS04.jellyfishnet.co.uk.local>, <20110707194150.GA6463@calomel.org> In-Reply-To: <20110707194150.GA6463@calomel.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-pf@freebsd.org" Subject: Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb) 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: Thu, 07 Jul 2011 22:24:14 -0000 Interesting read. Sounds like you need a BreakingPoint to really give it a workout with real = world style traffic profiles and volumes. Greg Sent from my Android phone using TouchDown (www.nitrodesk.com) ________________________________ From: Calomel Org Sent: 07 July 2011 19:41:50 To: Greg Hennessy Cc: freebsd-pf@freebsd.org Subject: Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb) Greg, Pf performance is quite good. The machine averages 9.2 Gbits/sec or 1.15 gigabytes per second (GB/s) in each direction, simultaneously. Interrupt load is about 12%. With a single Linux box on either side of the firewall we see around 161K packets per second and can create 4000 states per second. With more machines on either side on the firewall we are looking to get closer to a million pps and a higher state creation rate. I am not sure what limits we will see then. We published a more detailed write up here under "Can we achieve 10 gigabit speeds ?" Network Tuning and Performance https://calomel.org/network_performance.html -- Calomel @ https://calomel.org Open Source Research and Reference On Wed, Jul 06, 2011 at 07:09:59PM -0400, Greg Hennessy wrote: >> >> ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. >> This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any h= igher, >> altq will flip back to zero. This "bug" was found when trying to test 10= gigabit >> and 40 gigabit bandwidth models. > >What a problem to have :-) > >On a side note out of pure curiousity, what's PF performance like up in th= e stratosphere under those sort of loads/packet rates ? :-) > > >Greg > >_______________________________________________ >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 Fri Jul 8 00:40:59 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F2E106566C; Fri, 8 Jul 2011 00:40:59 +0000 (UTC) (envelope-from pierre@userid.org) Received: from mail.storm.ca (unknown [IPv6:2607:f0b0:0:6:209:87:239:66]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1B08FC12; Fri, 8 Jul 2011 00:40:59 +0000 (UTC) Received: from mail.userid.org (pandora.userid.org [216.106.102.33]) by mail.storm.ca (8.14.2+Sun/8.14.2) with ESMTP id p68079MF023477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jul 2011 20:07:15 -0400 (EDT) Received: from [IPv6:2607:f0b0:1:3800:3c4d:9c3c:9460:13b2] (unknown [IPv6:2607:f0b0:1:3800:3c4d:9c3c:9460:13b2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre) by mail.userid.org (Postfix) with ESMTP id A91DA2C77A6; Thu, 7 Jul 2011 20:06:38 -0400 (EDT) Message-ID: <4E164A00.6040706@userid.org> Date: Thu, 07 Jul 2011 20:06:24 -0400 From: Pierre Lamy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> <4E0F3A2D.60409@userid.org> <4E121207.30400@userid.org> In-Reply-To: <4E121207.30400@userid.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-userid-MailScanner-Information: Please contact the ISP for more information X-userid-MailScanner-ID: A91DA2C77A6.AAA60 X-userid-MailScanner: Found to be clean X-userid-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.599, required 6, J_CHICKENPOX_33 0.60, NO_RELAYS -0.00) X-userid-MailScanner-From: pierre@userid.org X-Spam-Status: No Cc: freebsd-pf@freebsd.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... 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: Fri, 08 Jul 2011 00:40:59 -0000 Yes, this seems to have resolved the state key mismatch error messages. Unfortunately the state deletions don't seem to be working, but I suspect that this was not related in any way to the 4.5 merge. Guess I will keep digging on that one. -Pierre On 7/4/2011 3:18 PM, Pierre Lamy wrote: > I'm just heading to NYC for the next 2 days, I will check it when I > get back. > > Thanks! > > -Pierre > > On 7/4/2011 2:01 PM, Ermal Luçi wrote: >> On Sat, Jul 2, 2011 at 5:33 PM, Pierre Lamy wrote: >>> >>> On 6/29/2011 1:22 PM, Fabian Keil wrote: >>>> "Bjoern A. Zeeb" wrote: >>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: "Bjoern A. Zeeb" >>>>>> Date: June 28, 2011 11:57:25 AM GMT+00:00 >>>>>> To: src-committers@freebsd.org, svn-src-all@freebsd.org, >>>>>> svn-src-head@freebsd.org >>>>>> Subject: svn commit: r223637 - in head: . contrib/pf/authpf >>>>>> contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl >>>>>> contrib/pf/pflogd >>>>>> sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net >>>>>> sys/modules >>>>>> s... >>>>>> >>>>>> Author: bz >>>>>> Date: Tue Jun 28 11:57:25 2011 >>>>>> New Revision: 223637 >>>>>> URL: http://svn.freebsd.org/changeset/base/223637 >>>>>> >>>>>> Log: >>>>>> Update packet filter (pf) code to OpenBSD 4.5. >>>> Thanks! >>>> >>>>> In short; please test! >>>> I didn't experience any real problems yet, but running >>>> Privoxy-Regression-Test, I reproducible got this log message >>>> for one of the tests: >>>> >>>> Jun 29 18:26:19 r500 kernel: pf: state key linking mismatch! dir=OUT, >>>> if=lo1, stored af=2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, >>>> proto=6, found >>>> af=2, a0: 10.0.0.1:50722, a1: 10.0.0.1:12345, proto=6. >>>> >>>> This didn't happen with the previous pf version. >>>> >>>> I tracked it down to a test that does a connect() >>>> to a local unbound port. >>>> >>>> It's also reproducible for every address on the system with: >>>> >>>> ifconfig -a | awk '/inet / {system("telnet "$2" 12345")}' >>>> >>>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>>> if=lo0, stored af=2, a0: 192.168.5.49:61512, a1: 192.168.5.49:12345, >>>> proto=6, found af=2, a0: 192.168.5.49:61512, a1: 192.168.5.49:12345, >>>> proto=6. >>>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>>> if=lo0, stored af=2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, >>>> proto=6, >>>> found af=2, a0: 127.0.0.1:44717, a1: 127.0.0.1:12345, proto=6. >>>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>>> if=lo1, stored af=2, a0: 192.168.6.100:31600, a1: 192.168.6.100:12345, >>>> proto=6, found af=2, a0: 192.168.6.100:31600, a1: 192.168.6.100:12345, >>>> proto=6. >>>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>>> if=lo1, stored af=2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, >>>> proto=6, found >>>> af=2, a0: 10.0.0.1:20126, a1: 10.0.0.1:12345, proto=6. >>>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>>> if=lo1, stored af=2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, >>>> proto=6, found >>>> af=2, a0: 10.0.0.1:10895, a1: 10.0.0.2:12345, proto=6. >>>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>>> if=lo1, stored af=2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, >>>> proto=6, found >>>> af=2, a0: 10.0.0.1:25081, a1: 10.0.0.3:12345, proto=6. >>>> Jun 29 18:30:49 r500 kernel: pf: state key linking mismatch! dir=OUT, >>>> if=lo0, stored af=2, a0: 192.168.0.106:32448, a1: 192.168.0.106:12345, >>>> proto=6, found af=2, a0: 192.168.0.106:32448, a1: 192.168.0.106:12345, >>>> proto=6. >>>> >>>> 12345 can be replaced with any unbound port it seems. >>>> >>>> I'm additionally occasionally seeing the message for successfully >>>> established connections (both internal and outgoing) but don't >>>> know how to reproduce it. >>>> >>>> Fabian >>> I also get the state key mismatch problem, it seems that pf is leaking >>> states (I assume this is the same problem). I also see a strange NAT >>> issue, >>> internal IPs leak somewhat on the outside int. Eventually the system >>> runs >>> out of state entry slots and connectivity is lost. This is on a >>> -current >>> kernel from ~Jun 30, after the 4.5 import. >>> >>> tun0: flags=8151 metric 0 >>> mtu 1492 >>> options=80000 >>> inet6 fe80::290:bff:fe1a:a674%tun0 prefixlen 64 scopeid 0xf >>> inet6 2607:f0b0:0:1:290:bff:fe1a:a674 prefixlen 64 autoconf >>> inet 216.106.102.33 --> 209.87.255.1 netmask 0xffffffff >>> nd6 options=23 >>> Opened by PID 3446 >>> >>> em0 is on the 192.168.3/24 network >>> >>> [/var/preserve/root] # tcpdump -i tun0 net >>> 192.168.3.0 >>> mask 255.255.255.0 >>> tcpdump: verbose output suppressed, use -v or -vv for full protocol >>> decode >>> listening on tun0, link-type NULL (BSD loopback), capture size 65535 >>> bytes >>> 11:22:37.030244 IP 192.168.3.99> 190.252.34.186: ICMP >>> pandora.userid.org >>> udp port 16881 unreachable, length 134 >>> 11:24:03.137016 IP 192.168.3.99> 190.252.34.186: ICMP >>> pandora.userid.org >>> udp port 16881 unreachable, length 98 >>> >>> Relevant pf.conf lines: >>> int_if = "em0" >>> ext_if = "tun0" >>> # NAT >>> nat on $ext_if from $int_if:network to any -> ($ext_if) >>> >>> Here is the info about states leaking: >>> >>> State Table Total Rate >>> current entries 108488 >>> >>> [/var/preserve/root] # pfctl -F states >>> 1003 states cleared >>> [/var/preserve/root] # pfctl -s info >>> Status: Enabled for 0 days 02:21:18 Debug: Urgent >>> >>> Interface Stats for tun0 IPv4 IPv6 >>> Bytes In 1252327614 1907903 >>> Bytes Out 373783492 1429003 >>> Packets In >>> Passed 1341017 12360 >>> Blocked 45437 831 >>> Packets Out >>> Passed 1186359 13441 >>> Blocked 1641 3724 >>> >>> State Table Total Rate >>> current entries 125127 >>> >>> States aren't getting cleared properly. Below is a sample of the >>> state key >>> linking mismatch problem: >>> >>> Jul 2 11:28:17 pyr7535 kernel: pf: state key linking mismatch! >>> dir=OUT, >>> if=em0, stored af=2, a0: >> I just committed a fix for the state key linking mismatch issue. >> Can you test with the latest HEAD sources? >> >> >> >>> Jul 2 11:28:17 pyr7535 kernel: 192.168.3.238:55590, a1: 216.106.102.33 >>> Jul 2 11:28:18 pyr7535 kernel: :18825, proto=6 >>> Jul 2 11:28:18 pyr7535 kernel: , found af=2, a0: 192.168.3.238 >>> Jul 2 11:28:18 pyr7535 kernel: :55590, a1: >>> Jul 2 11:28:18 pyr7535 kernel: 216.106.102.33:18825 >>> Jul 2 11:28:18 pyr7535 kernel: , proto=6. >>> Jul 2 11:28:18 pyr7535 kernel: pf: state key linking mismatch! >>> dir=OUT, >>> if=em0, stored af=2, a0: 192.168.3.238:55590, a1: 216.106.102.33:18825, >>> proto=6, found af=2, a0: 192.168.3.238:55590, a1: 216.106.102.33:18825, >>> proto=6. >>> Jul 2 11:28:19 pyr7535 kernel: pf: state key linking mismatch! >>> dir=OUT, >>> if=em0, stored af=2, a0: 192.168.3.238 >>> Jul 2 11:28:19 pyr7535 kernel: :55590, a1: >>> Jul 2 11:28:19 pyr7535 kernel: 216.106.102.33:18825 >>> Jul 2 11:28:19 pyr7535 kernel: , proto=6, found af=2, a0: >>> Jul 2 11:28:19 pyr7535 kernel: 192.168.3.238:55590 >>> Jul 2 11:28:19 pyr7535 kernel: , a1: 216.106.102.33 >>> Jul 2 11:28:19 pyr7535 kernel: :18825, proto=6. >>> >>> >>> >>> _______________________________________________ >>> 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" >>> >> >> > > > _______________________________________________ > 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 Fri Jul 8 12:26:38 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3604D106566C; Fri, 8 Jul 2011 12:26:38 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E4D9D8FC0C; Fri, 8 Jul 2011 12:26:37 +0000 (UTC) Received: by iwr19 with SMTP id 19so2248974iwr.13 for ; Fri, 08 Jul 2011 05:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dtGkKwiVbqUU9cHRfJn6V3dsH/BDVNaLQs6bKERUhSE=; b=lxGo4PMCfVgH7sVvoeltw+Y5m0OEVZc1y02j2GzX2Q7ywyKwjQkRZjT5b+82Cc3FN4 B0BheWPrTYeNBQghUxuq+e7AB1e06PF3JD6zZPGINS/FAunEcgK0uWFeTwHUVcee0uPG OaLf+HK6TbneJnxGdbyMXL7Z85S+3ug27p6Ws= MIME-Version: 1.0 Received: by 10.231.91.208 with SMTP id o16mr1724234ibm.49.1310127997250; Fri, 08 Jul 2011 05:26:37 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.171.148 with HTTP; Fri, 8 Jul 2011 05:26:37 -0700 (PDT) In-Reply-To: <20110707193539.GA60591@dragon.NUXI.org> References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> <20110707193539.GA60591@dragon.NUXI.org> Date: Fri, 8 Jul 2011 14:26:37 +0200 X-Google-Sender-Auth: DGff36IBLyn2isbwOr549s0gNeE Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: obrien@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , freebsd-pf@freebsd.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... 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: Fri, 08 Jul 2011 12:26:38 -0000 On Thu, Jul 7, 2011 at 9:35 PM, David O'Brien wrote: > On Wed, Jun 29, 2011 at 07:22:24PM +0200, Fabian Keil wrote: >> "Bjoern A. Zeeb" wrote: >> > In short; please test! >> >> I didn't experience any real problems yet, but running > > Hi Bjoern, > Unfortunately I've had MAJOR network problems since the pf upgrade. > > Besides getting the "state key linking mismatch!" issue: > > pf: state key linking mismatch! dir=3DOUT, if=3Dfxp0, stored af=3D2, a0: = 208.83.139.205:2703, a1: 74.95.12.85:20474, proto=3D6, found af=3D2, a0: 20= 8.83.139.205:2703, a1: 74.95.12.85:20474, proto=3D6. > pf: state key linking mismatch! dir=3DOUT, if=3Dfxp0, stored af=3D2, a0: = 87.98.164.164:44387, a1: 74.95.12.85:53, proto=3D6, found af=3D2, a0: 87.98= .164.164:44387, a1: 74.95.12.85:53, proto=3D6. > pf: state key linking mismatch! dir=3DOUT, if=3Dfxp0, stored af=3D2, a0: = 87.98.164.164:44387, a1: 74.95.12.85:53, proto=3D6, found af=3D2, a0: 87.98= .164.164:44387, a1: 74.95.12.85:53, proto=3D6. > > I found that my kernel (@ r223671) would stop sending packets 3-4 hours > after reboot. =A0New connections could not be established, I could not pi= ng > any of the direct connections on any of my interfaces. =A0Existing > connections would remain established for quite some time (hours) but > eventually close also. > > No amount of re-running /etc/rc.d/* scripts ('pf restart', 'netif > restart', 'routing restart', etc...) would bring back working networking. > > Since reverting back to r223636, my kernel has had rock solid networking. > > I have 'pfctl', 'netstat', 'netstat -rn', and 'sysctl -a' output from one > of these experiences. =A0Would they be useful to you in looking into this= ? > please send those. Also useful would be a description of your setup. > -- > -- David =A0 =A0(obrien@FreeBSD.org) > _______________________________________________ > 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" > --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Fri Jul 8 17:02:45 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D45E3106566B; Fri, 8 Jul 2011 17:02:45 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id AE3FF8FC13; Fri, 8 Jul 2011 17:02:45 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.5/8.14.5) with ESMTP id p68H2eFn059042; Fri, 8 Jul 2011 10:02:41 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.5/8.14.4/Submit) id p68H2eMI059041; Fri, 8 Jul 2011 10:02:40 -0700 (PDT) (envelope-from obrien) Date: Fri, 8 Jul 2011 10:02:40 -0700 From: "David O'Brien" To: Ermal =?unknown-8bit?Q?Lu=E7i?= Message-ID: <20110708170240.GA59024@dragon.NUXI.org> References: <201106281157.p5SBvP5g048097@svn.freebsd.org> <20110629192224.2283efc8@fabiankeil.de> <20110707193539.GA60591@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Bjoern A. Zeeb" , freebsd-pf@freebsd.org Subject: Re: svn commit: r223637 - in head: . contrib/pf/authpf contrib/pf/ftp-proxy contrib/pf/man contrib/pf/pfctl contrib/pf/pflogd sbin/pflogd sys/conf sys/contrib/altq/altq sys/contrib/pf/net sys/modules s... X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org 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: Fri, 08 Jul 2011 17:02:45 -0000 On Fri, Jul 08, 2011 at 02:26:37PM +0200, Ermal Lui wrote: > On Thu, Jul 7, 2011 at 9:35 PM, David O'Brien wrote: > > I have 'pfctl', 'netstat', 'netstat -rn', and 'sysctl -a' output from one > > of these experiences.  Would they be useful to you in looking into this? > > please send those. > Also useful would be a description of your setup. Ermal, Thanks. I'll send to you off list. -- -- David (obrien@FreeBSD.org)