From owner-freebsd-pf@FreeBSD.ORG Sun Dec 19 18:30:14 2010 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 D4CDA1065670 for ; Sun, 19 Dec 2010 18:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A9D8A8FC17 for ; Sun, 19 Dec 2010 18:30:14 +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 oBJIUEEU014549 for ; Sun, 19 Dec 2010 18:30:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBJIUEku014546; Sun, 19 Dec 2010 18:30:14 GMT (envelope-from gnats) Date: Sun, 19 Dec 2010 18:30:14 GMT Message-Id: <201012191830.oBJIUEku014546@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: olli hauer Cc: Subject: Re: bin/143504: [patch] outgoing states are not killed by authpf(8) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: olli hauer List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 18:30:14 -0000 The following reply was made to PR bin/143504; it has been noted by GNATS. From: olli hauer To: bug-followup@FreeBSD.org, freebsd-pf@freebsd.org Cc: Subject: Re: bin/143504: [patch] outgoing states are not killed by authpf(8) Date: Sun, 19 Dec 2010 19:29:16 +0100 Any change to get this trivial fixes into FreeBSD_7_4/8_2 or become any feedback? http://www.freebsd.org/cgi/query-pr.cgi?pr=140369 http://www.freebsd.org/cgi/query-pr.cgi?pr=143504 -- Regards, olli From owner-freebsd-pf@FreeBSD.ORG Sun Dec 19 18:53:15 2010 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 EFB63106566C for ; Sun, 19 Dec 2010 18:53:15 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 4752C8FC24 for ; Sun, 19 Dec 2010 18:53:14 +0000 (UTC) Received: (qmail invoked by alias); 19 Dec 2010 18:26:33 -0000 Received: from u18-124.dslaccess.de (EHLO [172.20.1.100]) [194.231.39.124] by mail.gmx.net (mp025) with SMTP; 19 Dec 2010 19:26:33 +0100 X-Authenticated: #1956535 X-Provags-ID: V01U2FsdGVkX18ftcBMzOgfZfbtLk+5I1zSuyxnKrA23Oxh9z8vH6 i+wJcmIR0VMF92 Message-ID: <4D0E4EFC.7000802@gmx.de> Date: Sun, 19 Dec 2010 19:29:16 +0100 From: olli hauer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: bug-followup@FreeBSD.org, freebsd-pf@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Subject: Re: bin/143504: [patch] outgoing states are not killed by authpf(8) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 18:53:16 -0000 Any change to get this trivial fixes into FreeBSD_7_4/8_2 or become any feedback? http://www.freebsd.org/cgi/query-pr.cgi?pr=140369 http://www.freebsd.org/cgi/query-pr.cgi?pr=143504 -- Regards, olli From owner-freebsd-pf@FreeBSD.ORG Mon Dec 20 05:47:51 2010 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 C74B9106566C for ; Mon, 20 Dec 2010 05:47:51 +0000 (UTC) (envelope-from s.dave.jones@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 8DC7E8FC0A for ; Mon, 20 Dec 2010 05:47:51 +0000 (UTC) Received: by iyb26 with SMTP id 26so1967674iyb.13 for ; Sun, 19 Dec 2010 21:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D2s7F97EObxzGLA/5iVwSEkcSLYvZurwzvrji9UTGL8=; b=VFHG7aLdYbG2biYe83iz6SzCkxwNn0yHuSE5eUZs6od2fPM4I7XuWiEdDjkhFMnYY7 CaK8gCtMgi0gO5aqqulod04mHtoPVkefmjAQx31tietGtaVSd1c4PBhWGsLqs6CUYukh 8U65tbcxeCdrzdsqAynB+4aTnr19wEMgeQPWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MOnl9wRf8ChJKGSqFx/wji75JlnlxgaiUc/IDuBJ1dxTGJcnfVa24TFQBcYOr/Z7/i akPiS5DzHQMHdnsg3BMV6h2sye+ycfjHMoZZumB/ZmSrKy9YX6X53+NUy7Wqzo81CQw0 M9btT/9no4OnKg284VgzYV+37W5Wv6yBtnon0= MIME-Version: 1.0 Received: by 10.231.15.132 with SMTP id k4mr3581009iba.60.1292824070260; Sun, 19 Dec 2010 21:47:50 -0800 (PST) Received: by 10.231.188.18 with HTTP; Sun, 19 Dec 2010 21:47:50 -0800 (PST) In-Reply-To: <4D0A01B8.8010009@aws-net.org.ua> References: <4D0A01B8.8010009@aws-net.org.ua> Date: Mon, 20 Dec 2010 13:47:50 +0800 Message-ID: From: dave jones To: Artyom Viklenko Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: Questions about multicast forwarding 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, 20 Dec 2010 05:47:52 -0000 Hi Artyom, I tried to use igmpproxy with no lock. "netstat -g" shows: IPv4 Virtual Interface Table Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out 0 1 172.16.112.2 0 0 1 1 172.16.113.8 0 0 2 1 172.16.112.2 0 0 Ipv4 Multicast Forwarding Table is empty In /usr/local/etc/igmpporxy: quickleave phyint re0 upstream ratelimit 0 threashold 1 phyint re1 downstream ratelimit 0 threshold 1 Did I set something wrong? Thanks! Cheers, Dave. On Thu, Dec 16, 2010 at 8:10 PM, Artyom Viklenko wro= te: > 16.12.2010 12:04, dave jones =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >> Hi, >> >> I have the following networks: >> >> =C2=A0----------------------------------------------- >> =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| >> =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| >> =C2=A0 =C2=A0iptv device (172.16.113.2) FreeBSD (re0:172.16.113.8) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 (re1:172.16.112.2= ) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PCs >> >> The iptv device which sends to multicast 224.0.3.2, I want my PCs to >> receive multicast packets and let clients watch TV. >> Should I use net/mrouted or use pf can do that? >> Would anyone tell me how to do? Thanks. >> > > I'd suggest to use igmpproxy from ports. > > > -- > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sincerely yours, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Artyom Viklenko. > ------------------------------------------------------- > artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem > artem@viklenko.net =C2=A0 | JID: artem@jabber.aws-net.org.ua > FreeBSD: The Power to Serve =C2=A0 - =C2=A0http://www.freebsd.org > From owner-freebsd-pf@FreeBSD.ORG Mon Dec 20 07:07:04 2010 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 1EA5D106566B for ; Mon, 20 Dec 2010 07:07:04 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from lazy.aws-net.org.ua (lazy.aws-net.org.ua [IPv6:2a00:1db0:20::828:140]) by mx1.freebsd.org (Postfix) with ESMTP id 5CBF78FC0A for ; Mon, 20 Dec 2010 07:07:03 +0000 (UTC) Received: from rainbow.vl.net.ua (rainbow.vl.net.ua [188.230.120.215]) (authenticated bits=0) by lazy.aws-net.org.ua (8.14.3/8.14.3) with ESMTP id oBK76s1E080435 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 20 Dec 2010 09:07:01 +0200 (EET) (envelope-from artem@aws-net.org.ua) Message-ID: <4D0F008E.4070204@aws-net.org.ua> Date: Mon, 20 Dec 2010 09:06:54 +0200 From: Artyom Viklenko Organization: Art&Co. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.11) Gecko/20101025 Thunderbird/3.1.5 MIME-Version: 1.0 To: dave jones References: <4D0A01B8.8010009@aws-net.org.ua> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (lazy.aws-net.org.ua [188.230.120.140]); Mon, 20 Dec 2010 09:07:01 +0200 (EET) Cc: freebsd-pf@freebsd.org Subject: Re: Questions about multicast forwarding 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, 20 Dec 2010 07:07:04 -0000 20.12.2010 07:47, dave jones пишет: > Hi Artyom, > > I tried to use igmpproxy with no lock. "netstat -g" shows: > IPv4 Virtual Interface Table > Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out > 0 1 172.16.112.2 0 0 > 1 1 172.16.113.8 0 0 > 2 1 172.16.112.2 0 0 > > Ipv4 Multicast Forwarding Table is empty > > > In /usr/local/etc/igmpporxy: > > quickleave > phyint re0 upstream ratelimit 0 threashold 1 > phyint re1 downstream ratelimit 0 threshold 1 > Hi, Dave! Actually, my config like yours except one additional thing 'altnet': quickleave phyint fxp0 upstream ratelimit 0 threshold 1 altnet m.m.m.m/32 phyint fxp1 downstream ratelimit 0 threshold 1 m.m.m.m/32 is the IP address of the multicast streams source in our network sveral hops away, but in you case it is on the same subnet as upstream interface. But I have only two Vif-s after igmpproxy started: IPv4 Virtual Interface Table Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out 0 1 x.x.x.y 0 0 1 1 x.x.x.z 0 0 And then I start to watch TV on my notebook, connected to network on fxp1 interface, multicast flow appears on interfaces and I see: IPv4 Virtual Interface Table Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out 0 1 x.x.x.y 391353 0 1 1 x.x.x.z 0 391353 IPv4 Multicast Forwarding Table Origin Group Packets In-Vif Out-Vifs:Ttls m.m.m.m MMM.MMM.2.2 17641 0 1:1 Also, check rules in your firewall to enable igmp traffic and multicast streams. One additional thing to check is a switches through which you connect your equipment. If it's an unmanaged switch, it should unconditionally pass group traffic. If it is some kind of managed or "smart" switch, you have to check is igmp snooping enabled and configured on it and multicast forwarding works. Hope this helps! > Did I set something wrong? Thanks! > > Cheers, > Dave. > > On Thu, Dec 16, 2010 at 8:10 PM, Artyom Viklenko wrote: >> 16.12.2010 12:04, dave jones пишет: >>> >>> Hi, >>> >>> I have the following networks: >>> >>> ----------------------------------------------- >>> | | >>> | | >>> iptv device (172.16.113.2) FreeBSD (re0:172.16.113.8) >>> | (re1:172.16.112.2) >>> | >>> PCs >>> >>> The iptv device which sends to multicast 224.0.3.2, I want my PCs to >>> receive multicast packets and let clients watch TV. >>> Should I use net/mrouted or use pf can do that? >>> Would anyone tell me how to do? Thanks. >>> >> >> I'd suggest to use igmpproxy from ports. >> >> >> -- >> Sincerely yours, >> Artyom Viklenko. >> ------------------------------------------------------- >> artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem >> artem@viklenko.net | JID: artem@jabber.aws-net.org.ua >> FreeBSD: The Power to Serve - http://www.freebsd.org >> -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net | JID: artem@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-pf@FreeBSD.ORG Mon Dec 20 11:07:02 2010 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 4FA7E10656A5 for ; Mon, 20 Dec 2010 11:07:02 +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 3CCE18FC1D for ; Mon, 20 Dec 2010 11:07:02 +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 oBKB72bi024611 for ; Mon, 20 Dec 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKB71YP024608 for freebsd-pf@FreeBSD.org; Mon, 20 Dec 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Dec 2010 11:07:01 GMT Message-Id: <201012201107.oBKB71YP024608@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, 20 Dec 2010 11:07:02 -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/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 o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 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 45 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Dec 20 15:19:49 2010 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 45F471065673; Mon, 20 Dec 2010 15:19:49 +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 1C4D28FC2C; Mon, 20 Dec 2010 15:19:49 +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 oBKFJmrF097529; Mon, 20 Dec 2010 15:19:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBKFJmlD097525; Mon, 20 Dec 2010 15:19:48 GMT (envelope-from linimon) Date: Mon, 20 Dec 2010 15:19:48 GMT Message-Id: <201012201519.oBKFJmlD097525@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153307: [pf] Bug with PF firewall 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, 20 Dec 2010 15:19:49 -0000 Old Synopsis: Bug with PF firewall New Synopsis: [pf] Bug with PF firewall Responsible-Changed-From-To: freebsd-amd64->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 20 15:19:33 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153307 From owner-freebsd-pf@FreeBSD.ORG Wed Dec 22 12:10:46 2010 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 2E8041065674 for ; Wed, 22 Dec 2010 12:10:46 +0000 (UTC) (envelope-from Aleksej.Spenst@harman.com) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by mx1.freebsd.org (Postfix) with SMTP id 8FBFF8FC16 for ; Wed, 22 Dec 2010 12:10:45 +0000 (UTC) Received: from source ([194.121.90.173]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKTRHqxXCGNIG00SrDLCsfhNo5VpscuhJH@postini.com; Wed, 22 Dec 2010 04:10:45 PST Received: from HIKAWSEX01.ad.harman.com ([fe80::28ec:7810:cfab:2739]) by HIKAWSEX02.ad.harman.com ([172.16.1.216]) with mapi; Wed, 22 Dec 2010 12:59:51 +0100 From: "Spenst, Aleksej" To: "'freebsd-pf@freebsd.org'" Date: Wed, 22 Dec 2010 12:59:50 +0100 Thread-Topic: why ALTQ must be supported by interface drivers? Thread-Index: Acuhz70V44smhZJVTimJ0E+cLgBkGA== Message-ID: <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: why ALTQ must be supported by interface drivers? 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, 22 Dec 2010 12:10:46 -0000 Hi All, at what network level is ALTQ (QoS) implemented? At the IP level or at the = driver level? I would think that all queuing functionality is probabliy working at the IP= level and should not depend on underlying interfaces. Is that correct? If = this is true, I don't understand why ALTQ must be supported by interface dr= ivers? If I understand it correctly: (1) the driver has to support ALTQ. (2= ) the driver has to be compiled as ALTQ-aware with some special flags. Thanks, Aleksej. From owner-freebsd-pf@FreeBSD.ORG Wed Dec 22 19:29:22 2010 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 0EDFF106566B for ; Wed, 22 Dec 2010 19:29:22 +0000 (UTC) (envelope-from RCharlet@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E33E48FC19 for ; Wed, 22 Dec 2010 19:29:21 +0000 (UTC) X-ASG-Debug-ID: 1293036896-48919a7e0001-7tp3by Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id b6wOybmYzxOlZujC; Wed, 22 Dec 2010 08:54:56 -0800 (PST) X-Barracuda-Envelope-From: RCharlet@adaranet.com Received: from SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523]) by SJ-EXCH-1.adaranet.com ([fe80::7042:d8c2:5973:c523%14]) with mapi; Wed, 22 Dec 2010 08:54:56 -0800 From: "Ricky Charlet" X-Barracuda-BBL-IP: fe80::7042:d8c2:5973:c523 X-Barracuda-RBL-IP: fe80::7042:d8c2:5973:c523 To: "'Spenst, Aleksej'" , "'freebsd-pf@freebsd.org'" Date: Wed, 22 Dec 2010 08:54:55 -0800 X-ASG-Orig-Subj: RE: why ALTQ must be supported by interface drivers? Thread-Topic: why ALTQ must be supported by interface drivers? Thread-Index: Acuhz70V44smhZJVTimJ0E+cLgBkGAAJwq/A Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC@SJ-EXCH-1.adaranet.com> References: <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com> In-Reply-To: <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1293036896 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at adaranet.com Cc: Subject: RE: why ALTQ must be supported by interface drivers? 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, 22 Dec 2010 19:29:22 -0000 Hi Aleksej, I happen to have recently been 'playing' with altq and trying to (s= uccessfully eventually) get to work well in the 100Mb utilization range. So you need to think of it like this, AltQ is replacing a current q= ueueing system... that of the driver. Each driver has a simple FIFO queue. = AltQ is just a more sophisticated queue for the driver to use when sending = out packets (enforcement). If, in-fact, a driver happens to implement anoth= er queue underneath the AltQ queue (sometimes happens in sophisticated hard= ware) then this 'lower' queue will probably be a FIFO queue and may wind up= destroying the value of AltQ. Now a piece of that added sophistication is classification. Site ad= ministrators set policy on which packets are more or less preferential to d= rop during congestion. AltQ's classification is implemented via the packet-= filters. A very common use case for classification is to distinguish traffic= based on layer3 and layer4 (IP and TCP/UDP/ICMP/SCTP...) headers. However = this is not the only use case and classification based on layer2 headers sh= ould continue to be supported for those few sites that wish it. In conclusion, AltQ enforcement must be implemented at the lowest l= ayer, and AltQ classification should maintain ability to examine low level = headers even though it is much more common to examine layer3 /layer4 header= s. So much for philosophy. About compiling, yes you understood quite c= orrectly. I have found these web sites to have helpful AltQ info (in no par= ticular order): http://www.sonycsl.co.jp/~kjc/software/altq-new-design.txt http://www.sonycsl.co.jp/person/kjc/software.html#ALTQ http://www.sonycsl.co.jp/person/kjc/software/TIPS.txt http://www.openbsd.org/faq/pf/index.html http://openbsd.org/faq/pf/queueing.html http://loquefaltaba.com/documentacion/pf/en/altqintro.html http://system-tribudi.blogspot.com/2006/08/pf-hfsc-part-i.html http://www.probsd.net/pf/index.php/Hednod%27s_HFSC_explained http://www.icir.org/floyd/cbq.html --- Ricky Charlet > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd- > pf@freebsd.org] On Behalf Of Spenst, Aleksej > Sent: Wednesday, December 22, 2010 4:00 AM > To: 'freebsd-pf@freebsd.org' > Subject: why ALTQ must be supported by interface drivers? > > Hi All, > > at what network level is ALTQ (QoS) implemented? At the IP level or at > the driver level? > > I would think that all queuing functionality is probabliy working at > the IP level and should not depend on underlying interfaces. Is that > correct? If this is true, I don't understand why ALTQ must be supported > by interface drivers? If I understand it correctly: (1) the driver has > to support ALTQ. (2) the driver has to be compiled as ALTQ-aware with > some special flags. > > Thanks, > Aleksej. > > > > > _______________________________________________ > 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 Dec 23 09:03:18 2010 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 99F52106566B for ; Thu, 23 Dec 2010 09:03:18 +0000 (UTC) (envelope-from Aleksej.Spenst@harman.com) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by mx1.freebsd.org (Postfix) with SMTP id E321E8FC1A for ; Thu, 23 Dec 2010 09:03:17 +0000 (UTC) Received: from source ([194.121.90.173]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTRMQVfwTMtH+aspjH2bTSYPSHkIhNc+n@postini.com; Thu, 23 Dec 2010 01:03:18 PST Received: from HIKAWSEX01.ad.harman.com ([fe80::28ec:7810:cfab:2739]) by HIKAWSEX03.ad.harman.com ([172.16.1.217]) with mapi; Thu, 23 Dec 2010 10:03:15 +0100 From: "Spenst, Aleksej" To: "'Ricky Charlet'" , "'freebsd-pf@freebsd.org'" Date: Thu, 23 Dec 2010 10:03:15 +0100 Thread-Topic: why ALTQ must be supported by interface drivers? Thread-Index: Acuhz70V44smhZJVTimJ0E+cLgBkGAAJwq/AACD4qnA= Message-ID: <20290C577F743240B5256C89EFA753810CAC5EC007@HIKAWSEX01.ad.harman.com> References: <20290C577F743240B5256C89EFA753810CAC5EC003@HIKAWSEX01.ad.harman.com> <32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC@SJ-EXCH-1.adaranet.com> In-Reply-To: <32AB5C9615CC494997D9ABB1DB12783C024C6FC1BC@SJ-EXCH-1.adaranet.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: AW: why ALTQ must be supported by interface drivers? 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, 23 Dec 2010 09:03:19 -0000 Hi Ricky, Thanks for your explanations.=20 >If, in-fact, a driver happens to=20 >implement another queue underneath the AltQ queue (sometimes=20 >happens in sophisticated hardware) then this 'lower' queue=20 >will probably be a FIFO queue and may wind up destroying the=20 >value of AltQ. If the driver supports only one FIFO queue, I don't think it can destroy AL= TQ functionality, since prioritization of traffic is done at layer 3 and th= is FIFO queue at layer 2 can be used to send packets in the order according= to classification performed at layer 3. However, if the driver supports it= s own queuing mechanism I see that there can be problems. I don't think tha= t pf has to be aware of layer 2 queuing mechanism to make any kind of mappi= ng between two queuing systems at layers 2 and 3. So, I suppose, either pf = disables the queuing mechanism at layer 2 or pf makes nothing (but in this = case one wouldn't need the driver to support pf). So, I'm still not sure wh= y pf needs the drivers to support ALTQ. >In conclusion, AltQ enforcement must be implemented at=20 >the lowest layer, and AltQ classification should maintain=20 >ability to examine low level headers even though it is much=20 >more common to examine layer3 /layer4 headers. Ok, this would answer my question, but what kind of layer 2 classification = is supported by pf? I don't remember any pf rules that can set layer 2 tags= or filter all packets based on layer 2 information. Thanks, Aleksej. >-----Urspr=FCngliche Nachricht----- >Von: Ricky Charlet [mailto:RCharlet@adaranet.com]=20 >Gesendet: Mittwoch, 22. Dezember 2010 17:55 >An: Spenst, Aleksej; 'freebsd-pf@freebsd.org' >Betreff: RE: why ALTQ must be supported by interface drivers? > >Hi Aleksej, > > I happen to have recently been 'playing' with altq and=20 >trying to (successfully eventually) get to work well in the=20 >100Mb utilization range. > > So you need to think of it like this, AltQ is=20 >replacing a current queueing system... that of the driver.=20 >Each driver has a simple FIFO queue. AltQ is just a more=20 >sophisticated queue for the driver to use when sending out=20 >packets (enforcement). If, in-fact, a driver happens to=20 >implement another queue underneath the AltQ queue (sometimes=20 >happens in sophisticated hardware) then this 'lower' queue=20 >will probably be a FIFO queue and may wind up destroying the=20 >value of AltQ. > > Now a piece of that added sophistication is=20 >classification. Site administrators set policy on which=20 >packets are more or less preferential to drop during=20 >congestion. AltQ's classification is implemented via the=20 >packet-filters. > > A very common use case for classification is to=20 >distinguish traffic based on layer3 and layer4 (IP and=20 >TCP/UDP/ICMP/SCTP...) headers. However this is not the only=20 >use case and classification based on layer2 headers should=20 >continue to be supported for those few sites that wish it. > > In conclusion, AltQ enforcement must be implemented at=20 >the lowest layer, and AltQ classification should maintain=20 >ability to examine low level headers even though it is much=20 >more common to examine layer3 /layer4 headers. > > > So much for philosophy. About compiling, yes you=20 >understood quite correctly. I have found these web sites to=20 >have helpful AltQ info (in no particular order): > >http://www.sonycsl.co.jp/~kjc/software/altq-new-design.txt >http://www.sonycsl.co.jp/person/kjc/software.html#ALTQ >http://www.sonycsl.co.jp/person/kjc/software/TIPS.txt >http://www.openbsd.org/faq/pf/index.html >http://openbsd.org/faq/pf/queueing.html >http://loquefaltaba.com/documentacion/pf/en/altqintro.html >http://system-tribudi.blogspot.com/2006/08/pf-hfsc-part-i.html >http://www.probsd.net/pf/index.php/Hednod%27s_HFSC_explained >http://www.icir.org/floyd/cbq.html > > > >--- >Ricky Charlet > > > > > >> -----Original Message----- >> From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-=20 >> pf@freebsd.org] On Behalf Of Spenst, Aleksej >> Sent: Wednesday, December 22, 2010 4:00 AM >> To: 'freebsd-pf@freebsd.org' >> Subject: why ALTQ must be supported by interface drivers? >> >> Hi All, >> >> at what network level is ALTQ (QoS) implemented? At the IP=20 >level or at=20 >> the driver level? >> >> I would think that all queuing functionality is probabliy working at=20 >> the IP level and should not depend on underlying interfaces. Is that=20 >> correct? If this is true, I don't understand why ALTQ must be=20 >> supported by interface drivers? If I understand it=20 >correctly: (1) the=20 >> driver has to support ALTQ. (2) the driver has to be compiled as=20 >> ALTQ-aware with some special flags. >> >> Thanks, >> Aleksej. >> >> >> >> >> _______________________________________________ >> 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" >=