From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 21 01:34:51 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F5011065675 for ; Mon, 21 Jun 2010 01:34:51 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2D55E8FC1B for ; Mon, 21 Jun 2010 01:34:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OQVuQ-00005E-SD for freebsd-ipfw@freebsd.org; Mon, 21 Jun 2010 03:34:46 +0200 Received: from static-78-8-147-77.ssp.dialog.net.pl ([78.8.147.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jun 2010 03:34:46 +0200 Received: from mwisnicki+freebsd by static-78-8-147-77.ssp.dialog.net.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jun 2010 03:34:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Marcin Wisnicki Date: Mon, 21 Jun 2010 01:34:35 +0000 (UTC) Lines: 29 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: static-78-8-147-77.ssp.dialog.net.pl User-Agent: Pan/0.132 (Waxed in Black) Subject: Re: tcpdump on ipfw0 and ipv6 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 01:34:51 -0000 On Sat, 19 Jun 2010 16:47:00 +0000, Marcin Wisnicki wrote: > > however when I do `ipfw disable verbose` and `tpdump -ni ipfw0` all I > can see is: > > # tcpdump -ni ipfw0 > tcpdump: WARNING: ipfw0: no IPv4 address assigned tcpdump: verbose > output suppressed, use -v or -vv for full protocol decode listening on > ipfw0, link-type EN10MB (Ethernet), capture size 96 bytes > 18:41:43.563579 IP6 , wrong link-layer encapsulationbad-hlen 0 > 18:41:43.563598 IP6 , wrong link-layer encapsulationbad-hlen 0 > 18:41:43.563747 IP6 , wrong link-layer encapsulationbad-hlen 0 > More verbose output: # tcpdump -nei ipfw0 -s1600 -vvv tcpdump: WARNING: ipfw0: no IPv4 address assigned tcpdump: listening on ipfw0, link-type EN10MB (Ethernet), capture size 1600 bytes 03:33:17.205641 53:53:53:53:53:53 > 44:44:44:44:44:44, ethertype IPv4 (0x0800), length 126: IP6 , wrong link-layer encapsulationbad-hlen 0 03:33:17.206322 53:53:53:53:53:53 > 44:44:44:44:44:44, ethertype IPv4 (0x0800), length 190: IP6 , wrong link-layer encapsulationbad-hlen 0 03:33:17.206621 53:53:53:53:53:53 > 44:44:44:44:44:44, ethertype IPv4 (0x0800), length 74: IP6 , wrong link-layer encapsulationbad-hlen 0 03:33:18.019095 53:53:53:53:53:53 > 44:44:44:44:44:44, ethertype IPv4 (0x0800), length 126: IP6 , wrong link-layer encapsulationbad-hlen 0 03:33:18.020181 53:53:53:53:53:53 > 44:44:44:44:44:44, ethertype IPv4 (0x0800), length 126: IP6 , wrong link-layer encapsulationbad-hlen 0 03:33:18.171231 53:53:53:53:53:53 > 44:44:44:44:44:44, ethertype IPv4 (0x0800), length 126: IP6 , wrong link-layer encapsulationbad-hlen 0 03:33:18.172473 53:53:53:53:53:53 > 44:44:44:44:44:44, ethertype IPv4 (0x0800), length 126: IP6 , wrong link-layer encapsulationbad-hl From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 21 11:06:57 2010 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D2EB106566B for ; Mon, 21 Jun 2010 11:06:57 +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 6AE268FC30 for ; Mon, 21 Jun 2010 11:06:57 +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 o5LB6vR7098278 for ; Mon, 21 Jun 2010 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5LB6uo4098276 for freebsd-ipfw@FreeBSD.org; Mon, 21 Jun 2010 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Jun 2010 11:06:56 GMT Message-Id: <201006211106.o5LB6uo4098276@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 11:06:57 -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/147798 ipfw [ipfw]: skipto skips over the complex rule o kern/147720 ipfw [ipfw] ipfw dynamic rules and fwd o kern/145733 ipfw [ipfw] [patch] ipfw flaws with ipv6 fragments o kern/145305 ipfw [ipfw] ipfw problems, panics, data corruption, ipv6 so o kern/145167 ipfw [ipfw] ipfw nat does not follow its documentation o kern/144869 ipfw [ipfw] [panic] Instant kernel panic when adding NAT ru o kern/144269 ipfw [ipfw] problem with ipfw tables o kern/144187 ipfw [ipfw] deadlock using multiple ipfw nat and multiple l o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143653 ipfw [ipfw] [patch] ipfw nat redirect_port "buf is too smal o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/143474 ipfw [ipfw] ipfw table contains the same address f kern/142951 ipfw [dummynet] using pipes&queues gives OUCH! pipe should o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 73 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 21 11:42:17 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476B31065670; Mon, 21 Jun 2010 11:42:17 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 684598FC0C; Mon, 21 Jun 2010 11:42:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o5LBgAnp079408; Mon, 21 Jun 2010 21:42:10 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 21 Jun 2010 21:42:10 +1000 (EST) From: Ian Smith To: Luigi Rizzo Message-ID: <20100621212134.K9227@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1718654167-1277120478=:9227" Content-ID: <20100621214150.B9227@sola.nimnet.asn.au> Cc: freebsd-ipfw@freebsd.org, Morgan Wesstr?m , freebsd-questions@freebsd.org, Modulok Subject: Re: Online gaming and file downloads - latency hell! (fwd) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 11:42:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1718654167-1277120478=:9227 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20100621214150.X9227@sola.nimnet.asn.au> Hi .. as suggested, posting this discussion to ipfw@ too .. thanks, Ian ---------- Forwarded message ---------- Date: Mon, 21 Jun 2010 13:00:14 +0200 From: Luigi Rizzo To: Ian Smith Subject: Re: Online gaming and file downloads - latency hell! (fwd) On Mon, Jun 21, 2010 at 10:25 AM, Ian Smith wrote: > Hi Luigi, > > thought you might be interested, seeing you and ipfw+dummynet rate a > mention .. maybe I'm ill-informed about the gaming latency aspect? > > cheers, Ian for responsive flows (e.g. tcp), it is actually effective to shape incoming traffic for the flows that you want slow down. In fact, even though it is true that packets have already traversed the bottleneck, you are slowing down their arrival to the receiving TCP, which has the side effect of slowing down outgoing acks and thus slowing down the source. Queues will build up at the remote end while the system settles, but after that (and if you make sure that the total rate is lower than link capacity) it will be the sources that do not generate traffic that saturates the link. Pretty trivial to implement, too: you just need a set of rules that match the incoming traffic that you want to slow down, pass it to one pipe, and let the other traffic go through without filtering. cheers luigi > > ---------- Forwarded message ---------- > Date: Mon, 21 Jun 2010 15:50:05 +1000 (EST) > From: Ian Smith > To: Morgan Wesstr?m > Cc: freebsd-questions@freebsd.org, Modulok > Subject: Re: Online gaming and file downloads - latency hell! > > In freebsd-questions Digest, Vol 315, Issue 11, Message: 9 > On Fri, 18 Jun 2010 12:11:48 +0200 > Morgan Wesstr?m wrote: >  > On 2010-06-16 02:51, Modulok wrote: >  > > Yo, >  > > >  > > I have a FreeBSD box acting as a router between me and the Internet. >  > > Whenever someone on the local network downloads something, the other >  > > connections have a really high latency. A second or more. For people >  > > who like to download large files and play online games, it's not good. >  > > >  > > I tried traffic shaping with PF, which works - almost: I tried the >  > > home example in the PF book, but it doesn't work out so well. I can >  > > throttle users with no trouble, but even so that doesn't seem to help >  > > the latency issue unless I choke the 'big file download' users almost >  > > completely off. It's like nothing helps. I tried a priority based >  > > queue where all traffic on the gaming ports was placed in front of all >  > > other traffic, and while I saw a very mild improvement, latency was >  > > still really pitiful. >  > > >  > > Is there anything else I can do? Anyone have a similar setup and wish >  > > to share config files? Are there some sysctl's that would help this >  > > out or something. I'm almost ready to just buy a 'gaming' *gag* router >  > > which implements their own brand of QoS, but don't want to sink to >  > > that level if I don't have to. >  > > >  > > Help! >  > > -Modulok- >  > >  > Traffic shaping on your side when downloading unfortunately doesn't help >  > you. The data has already been transferred across your cable or DSL >  > connection by then and reordering any packets on your side will not >  > change the latency. Traffic shaping your download has to be performed at >  > your upstream router which you probably don't control. PF can help you >  > traffic shape your outgoing traffic. I have used it for this for the >  > past 6 years to help me maintain a low and stable ping while I play >  > online, even if I upload simultaneously. I've read about people trying >  > to throttle outgoing ACKs to slow down their download but that still >  > wouldn't rearrange any incoming data packets so I don't see how that >  > would help. I haven't tried it myself though but neither have I read >  > about anyone successfully accomplishing this. >  > >  > Regards >  > Morgan > > A short story: > > About 15 months ago, before becoming aware that Luigi and colleagues had > been busy porting ipfw and dummynet to Linux, I was asked to implement a > shaping solution for a very limited (512/512kbps) ADSL connection for a > community radio station using a Linux firewall-in-a-box called IPCop as > router, whose shaping was based on Bert Hubert's WonderShaper script, > using Linux' tc module to prioritise and shape only outbound traffic. > > Having used ipfw+dummynet successfully for some years to shape traffic > for a local voluntary organisation 'Community Technology Centre', I was > staggered to find that all of the collective Linux wisdom on the subject > chanted that same mantra .. that you can't prioritise download traffic, > as the ISP will have 'gigantic queues' of TCP traffic that you can't > control, and that prioritising ACKs, QoS and ICMP traffic and such is > the best you can do.  By this philosophy, tc only implements limiting > total bandwidth of inbound traffic, shaping outbound by QoS and classes. > > To disprove this pervasive myth I had to implement inbound shaping by > using tc to control the _outbound_ traffic to the _inside_ interface, > where all sorts of random clients are doing big downloads, yootoobing > and such plus some big uploads, while guaranteeing that the station's > outbound audio stream had fully half the outbound-to-net bandwidth free > without undue pressure and that remote ssh sessions etc remained snappy. > > This involves queuing inbound (mostly TCP) traffic on the local router, > dropping any excess, which works most effectively to maintain a hard > limit to downloads (at around 85% of 512kbps) while keeping the outbound > (to-net) channel lightly loaded after streaming, ACKs, and uploads. > > I don't know how pf works (or can be made to work) in this regard, nor > can I speculate about gaming latency particularly, but hope to find out > soon by either replacing the old IPCop box with pfSense, or trying ipfw > and dummynet on Linux .. I know, but they're still reluctant to shop > other than Linux, and the idea of implementing a FreeBSD-derived > firewall and shaping solution on Linux has a good deal of appeal .. > > HTH (or at least, doesn't hurt :) > > cheers, Ian > --0-1718654167-1277120478=:9227-- From owner-freebsd-ipfw@FreeBSD.ORG Tue Jun 22 16:10:09 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31B441065673 for ; Tue, 22 Jun 2010 16:10:09 +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 2080C8FC17 for ; Tue, 22 Jun 2010 16:10:09 +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 o5MGA8Lv032651 for ; Tue, 22 Jun 2010 16:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5MGA8Yd032650; Tue, 22 Jun 2010 16:10:08 GMT (envelope-from gnats) Date: Tue, 22 Jun 2010 16:10:08 GMT Message-Id: <201006221610.o5MGA8Yd032650@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Terrence Koeman" Cc: Subject: Re: kern/145305: [ipfw] ipfw problems, panics, data corruption, ipv6 socket weirdness X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Terrence Koeman List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 16:10:09 -0000 The following reply was made to PR kern/145305; it has been noted by GNATS. From: "Terrence Koeman" To: "bug-followup@FreeBSD.org" Cc: Subject: Re: kern/145305: [ipfw] ipfw problems, panics, data corruption, ipv6 socket weirdness Date: Tue, 22 Jun 2010 17:59:35 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01CB1234.A95D1440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This *seems* to be fixed in 8-STABLE (8.1-PRERELEASE) of today. -- Regards, T. Koeman, MTh/BSc/BPsy; Technical Monk MediaMonks B.V. (www.mediamonks.com) Please quote all replies in correspondence. ------=_NextPart_000_0000_01CB1234.A95D1440 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ2zCCA3Uw ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggPjMIICy6ADAgECAgsEAAAAAAEeRKXfMTAN BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTk5MDEyODEz MDAwMFoXDTE3MDEyNzEyMDAwMFowbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCSjP7v9EWO F0Fu/Ni/IW+rBp1SwSwAnT+Ohbh/So+9oGMqykknrlqC9HTiVZL/wtGqeaK2+tWdggRPxrLGXmOn OrrY7uuKb5+2uyhBwCL7TkgaBpLXv9fPudm9OE87DURuVUH+/Anb2L/zjiHx6BK19hOl08ZMkyKw Av/uHQzEqGtPdWhW6NwoElD3qCSdLiQ5+wkF3uWjZEkh0Gh+cTCRsWDgOfRQ+HpNmABrfHm6Ts5K 4ro2HbfFNhWVnGRC6l/EuvVABb7hOlm9hKcZuN5NU1DOB9HSUdPvDYFs5udty118P3zM7E+DJyX/ cFD2g1l1hAZmWCzeiY0Apkn5pUN3AgMBAAGjgZkwgZYwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB /wQFMAMBAf8wHQYDVR0OBBYEFHznsrEs3rGna+l2DOGj/U5sx7n2MDMGA1UdHwQsMCowKKAmoCSG Imh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvUm9vdC5jcmwwHwYDVR0jBBgwFoAUYHtmGkUNl8qJ UC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEBAGgRjjoMPFOdxJ3nyglVKuQrH6KYOV5XvygO qKU7oR8o61w4Wvxshe/xCYNSPAM5NUVGRbfsjcECetbplZ0zrDfca5m7Y9/9HFqOTdwAW1dXMgdx TilR1VTRttdOXK5MtwT9AHk/6TnPxXjRrSd9y4uPfFE5ZTC3pAkl33yi5Nbre36D3aopA8KlbExA f8/A8p/X08+Cxn/NYHwlCPfyng9Adr+z/t0y6KuRGdLghNqMZyUxp46qipaieWDFVVewpWfuSkh5 LsB24B9BblchvubpnUskLG2hhqyA454ZZ9oyYVsVhNvE12F0hAS5NPhQ+3e9ep74CIVQFFgJcyHU FvUwggS2MIIDnqADAgECAgsBAAAAAAElc8eP4zANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENsYXNz IDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0EwHhcNMDkx MjA5MTMyMjQ0WhcNMTIxMjA5MTMyMjQxWjCBwTELMAkGA1UEBhMCTkwxGzAZBgNVBAwTElRlY2hu aWNhbCBEaXJlY3RvcjEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJSGlsdmVyc3Vt MSswKQYDVQQKEyJNZWRpYU1vbmtzIE11bHRpbWVkaWEgSG9sZGluZyBCLlYuMRgwFgYDVQQDEw9U ZXJyZW5jZSBLb2VtYW4xIjAgBgkqhkiG9w0BCQEWE3Jvb3RAbWVkaWFtb25rcy5uZXQwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAKvtl7cjemV/ISLtXrfngKiW/bkpT3EeSim++dmCSfvWVJqC bxN6cj1wWEfstozl84be8M5/3O2U4spihbm4jkE5E5+jjeFbDJKRmgcx2ZXpKdTL8LTg970SeRFr 1VxnPAwgrjLtFpy4KcOMgtBh2DrDCAqbuUlqyNqkNqqAAFQ3AgMBAAGjggF6MIIBdjAfBgNVHSME GDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBWBggrBgEFBQcBAQRKMEgwRgYIKwYBBQUHMAKGOmh0 dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5uZXQvY2FjZXJ0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcnQw QQYDVR0fBDowODA2oDSgMoYwaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25D bGFzczIuY3JsMB4GA1UdEQQXMBWBE3Jvb3RAbWVkaWFtb25rcy5uZXQwCQYDVR0TBAIwADAOBgNV HQ8BAf8EBAMCBPAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEsGA1UdIAREMEIwQAYJ KwYBBAGgMgEoMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZ2xvYmFsc2lnbi5uZXQvcmVwb3Np dG9yeS8wEQYJYIZIAYb4QgEBBAQDAgWgMA0GCSqGSIb3DQEBBQUAA4IBAQAj71rVZ+4k8tUMca3Z Ej67QXe9OnHCJlUIdyfRFyqn07QRLm4ElOAlcWSX6OOuc1Uz9zDLzcJl+2kSUfQ0OyZsoQGyRD0x Ypd0qG8yZxJN38S1K6C/qgilTzft9bb0OSgfPJ3FJUk3zIzwmgWEBE0DbiOccyaAwu1lmsAXJMYa SpCELzWNBfGdMBJPRBX+jQbcK0pR8mT6P1hYLYsgDW+9SA732Z2VR9aXdzytPVe+BBj4celz8pob 51vLq08G0RUWu52K9NEkXUOWCzEEYladdQ0MWkznXQkXlK/gSXTH5RsnTPDSlM0N7DVYd3yrDBY4 e9ADriQBXWN5hc0oUg0XMIIEvTCCA6WgAwIBAgILBAAAAAABHkSl6CowDQYJKoZIhvcNAQEFBQAw bTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExGzAZBgNVBAsTElByaW1h cnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQcmltYXJ5IENsYXNzIDIgQ0EwHhcN MDQwMTIyMTAwMDAwWhcNMTcwMTI3MTEwMDAwWjB3MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMT Ikdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyh f1LFzVmOaZX8X41n93Eu/7L34wHM192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74 gV6TeE4EVwrkUXgqs+j5JLtJXkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiU ngjpMlAxvmr/9+6KMug0ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5 SHFLXIWLhCSlZAGJ9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjggFSMIIBTjAOBgNV HQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUbcQrwX2FEKD5ExYNVSsD ujZMITEwSgYDVR0gBEMwQTA/BgkrBgEEAaAyASgwMjAwBggrBgEFBQcCARYkaHR0cDovL3d3dy5n bG9iYWxzaWduLm5ldC9yZXBvc2l0b3J5MDkGA1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xv YmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5jcmwwTgYIKwYBBQUHAQEEQjBAMD4GCCsGAQUFBzAChjJo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24ubmV0L2NhY2VydC9QcmltQ2xhc3MyLmNydDARBglghkgB hvhCAQEEBAMCAQYwHwYDVR0jBBgwFoAUfOeysSzesadr6XYM4aP9TmzHufYwDQYJKoZIhvcNAQEF BQADggEBACHomV6TRHH0FST5Evl4te2y0JSEWH1AFpd+e+mSfOPQcDfStZDOI/MYODDKl8UNy6Cb /8iPaeqn6q7nW/JuGl5HiP9OQEFwYbwdNF6FS7R7sn5k3E5g8D29WhxvINqeSNIuP8Om8lOVcmNu 2l/XeE4zfyMVs20SL0CIcfjkdqviKWJyub8upan0jqldIeX4uuCasnCKi+3gM50D8SvwBY0bpct+ kG52JISw2S3cbBHcHNuOzGsu8tv17IyvKjCiMr75AMEtogrs2FXNsqDhD6bY2YCi7JWDAVsz8B1v QtCG/ft/mX84UPC/vzfh9O8HD9v2CwQunIYPYe/ZYRkqyG8xggN+MIIDegIBATCBhjB3MQswCQYD VQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWdu IENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0EC CwEAAAAAASVzx4/jMAkGBSsOAwIaBQCgggJNMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEwMDYyMjE1NTkyOVowIwYJKoZIhvcNAQkEMRYEFN8BL/Qi60F2vSq2m1MM W/D+ZuqLMIGXBgkrBgEEAYI3EAQxgYkwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2Jh bFNpZ24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAElc8eP4zCBmQYLKoZIhvcN AQkQAgsxgYmggYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExIDAe BgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJHbG9iYWxTaWduIFBlcnNv bmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAElc8eP4zCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCG SAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMC AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglg hkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0B AQEFAASBgAFoIhJckb3cY59ZwCQtLiSlrGzUJh7gTbvYqb0qnkE4q0IjA6Nth3Zvvd3I4ykB+OQW pmV13M6V00jdZL/v5WW1CBcgJNQyJEO+NY/7185pxQ/PZZLIZs0bvTXCMaXS2Qv89xK9JYufTdcv sH1QElXMvUoz1t9TV1Vn66Gt+bBLAAAAAAAA ------=_NextPart_000_0000_01CB1234.A95D1440-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 23 13:32:15 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10E3A106564A for ; Wed, 23 Jun 2010 13:32:15 +0000 (UTC) (envelope-from ml@infosec.pl) Received: from v027580.home.net.pl (v027580.home.net.pl [89.161.156.148]) by mx1.freebsd.org (Postfix) with SMTP id 50F388FC1A for ; Wed, 23 Jun 2010 13:32:13 +0000 (UTC) Received: from 94-193-57-116.zone7.bethere.co.uk [94.193.57.116] (HELO [192.168.1.111]) by freeside.home.pl [89.161.156.148] with SMTP (IdeaSmtpServer v0.70) id 93d90e580692e7b1; Wed, 23 Jun 2010 15:32:16 +0200 Message-ID: <4C220CD6.9020209@infosec.pl> Date: Wed, 23 Jun 2010 14:32:06 +0100 From: Michal User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100620 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: ipfw nat X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 13:32:15 -0000 Hello. I am currently trying to replace pf with ipfw. NAT is the biggest missing bit in my configuration. I want to go with ipfw nat (libalias) because I've been told it works fine with dynamic rules (unlike divert) - is that statement correct? If yes, then could somebody point me to some kind of howto or manual please. All I'm finding in handbook, manuals and google is about divert and not ipfw nat. Thanks, M. -- "The real problem is not whether machines think but whether men do." -B. F. Skinner From owner-freebsd-ipfw@FreeBSD.ORG Thu Jun 24 02:50:07 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C531C1065676 for ; Thu, 24 Jun 2010 02:50:07 +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 9BA178FC1A for ; Thu, 24 Jun 2010 02:50: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 o5O2o7wn055127 for ; Thu, 24 Jun 2010 02:50:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5O2o7xb055126; Thu, 24 Jun 2010 02:50:07 GMT (envelope-from gnats) Date: Thu, 24 Jun 2010 02:50:07 GMT Message-Id: <201006240250.o5O2o7xb055126@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Christoph Weber-Fahr Cc: Subject: Re: kern/132553: [ipfw] ipfw doesn't understand ftp-data port X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christoph Weber-Fahr List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 02:50:07 -0000 The following reply was made to PR kern/132553; it has been noted by GNATS. From: Christoph Weber-Fahr To: bug-followup@FreeBSD.org, cwf-ml@arcor.de Cc: Subject: Re: kern/132553: [ipfw] ipfw doesn't understand ftp-data port Date: Thu, 24 Jun 2010 04:16:29 +0200 Hello, this PR should indeed be closed. I have no system left to even check the original case, and the documentation of this (less fortunate) syntax quirk is there in more current systems. Regards Christoph Weber-Fahr From owner-freebsd-ipfw@FreeBSD.ORG Thu Jun 24 14:05:06 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 973B2106566C for ; Thu, 24 Jun 2010 14:05:06 +0000 (UTC) (envelope-from cosmic17@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [95.108.130.119]) by mx1.freebsd.org (Postfix) with ESMTP id 29EC08FC17 for ; Thu, 24 Jun 2010 14:05:05 +0000 (UTC) Received: from web126.yandex.ru (web126.yandex.ru [95.108.130.104]) by forward15.mail.yandex.net (Yandex) with ESMTP id 5CFFC4459E42 for ; Thu, 24 Jun 2010 18:05:04 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1277388304; bh=jQjJyMu8315Ez+2H1Db06k7Ko6IoaS80ipMcXbvwEWQ=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=F91xTE4tb52OyZOObs9RuLlkZPvpRLoWcqW4dEWyuShg46O+oY8k7EBwyy7n/AuKb rk57aaVv8k0/tvJ0m/BxCf8n8ytnd6vd/28BC8klPisHZz80g7JuaTLUt1nvwmFS2Z dOBYSF3jp/1bbHz792i/msEkOSHkGe4pDRqHD6fY= Received: from localhost (localhost.localdomain [127.0.0.1]) by web126.yandex.ru (Yandex) with ESMTP id 5B153A803D for ; Thu, 24 Jun 2010 18:05:04 +0400 (MSD) X-Yandex-Spam: 1 X-Yandex-Front: web126.yandex.ru X-Yandex-TimeMark: 1277388304 Received: from 32.100.vltele.com (32.100.vltele.com [79.174.32.100]) by mail.yandex.ru with HTTP; Thu, 24 Jun 2010 18:05:02 +0400 From: =?koi8-r?B?5M3VyMEg7snLz8zByg==?= To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Message-Id: <659031277388303@web126.yandex.ru> Date: Thu, 24 Jun 2010 18:05:02 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-Mailman-Approved-At: Thu, 24 Jun 2010 17:40:06 +0000 Subject: Re: ipfw3 pipe more than 24000Kbit/s X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 14:05:06 -0000 Very strange.... I have this result: if change HZ to 2000 you can shape speed less than 24Mbit/s; if change HZ to 4000 you can shape speed less than 44Mbit/s; But in this theme http://lists.freebsd.org/pipermail/freebsd-ipfw/2010-June/004263.html there are exactly different speed values (250Mbit/s, 3500Mbi/s, etc) Any commets? > Hello. > We have the computer - if_bridge1. > uname -a: > FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #4: Thu May 13 13:08:53 MSD 2010 /usr/src/sys/amd64/compile/MYKERNEL amd64 > There are only ipfw+dummynet on this computer. IPFW was updated to version 3 from Luigi Rizzo because of packet scheduling. > Kernel options for ipfw are: > # IPFW > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT=10 > options IPFIREWALL_DEFAULT_TO_ACCEPT > options DUMMYNET > options HZ=2000 > When we try to shape speed less than 24000Kbit/s - it is OK. But when we try to shape speed more than 24000Kbit/s - we have no result. > /etc/rc.firewall: > $IPFW pipe 27 config bw 32000Kbit/s mask dst-ip 0xffffffff > $IPFW pipe 28 config bw 34000Kbit/s mask src-ip 0xffffffff > ########pipe 27 > $IPFW sched 27 config type QFQ mask dst-ip 0xffffff00 > $IPFW queue 271 config sched 27 weight 10 > $IPFW queue 272 config sched 27 weight 8 > $IPFW queue 273 config sched 27 weight 4 > $IPFW queue 274 config sched 27 weight 1 > $IPFW add queue 271 ip from any to table\(112\) via igb0 out proto udp src-port 5060 > $IPFW add queue 272 ip from any to table\(112\) via igb0 out proto tcp src-port 80,443,8080 > $IPFW add queue 273 ip from any to table\(112\) via igb0 out proto tcp src-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 > $IPFW add queue 273 ip from any to table\(112\) via igb0 out proto udp src-port 53, 5223, 3478, 3479, 3658, 1200, 5000-5009, 6112-6119, 6881-6999, 7777, 7788 > $IPFW add queue 273 ip from any to table\(112\) via igb0 out proto icmp > $IPFW add queue 274 ip from any to table\(112\) via igb0 out > ########pipe 28 > $IPFW sched 28 config type QFQ mask src-ip 0xffffff00 > $IPFW queue 281 config sched 28 weight 10 > $IPFW queue 282 config sched 28 weight 8 > $IPFW queue 283 config sched 28 weight 4 > $IPFW queue 284 config sched 28 weight 1 > $IPFW add queue 281 ip from table\(113\) to any via igb1 out proto udp dst-port 5060 > $IPFW add queue 282 ip from table\(113\) to any via igb1 out proto tcp dst-port 80,443,8080 > $IPFW add queue 283 ip from table\(113\) to any via igb1 out proto tcp dst-port 5223, 2009, 2106, 3724, 6112, 6881-6999, 7777, 27000-27050, 42292 > $IPFW add queue 283 ip from table\(113\) to any via igb1 out proto udp dst-port 53, 5223, 3478, 3479, 3658, 1200, 5000-5009, 6112-6119, 6881-6999, 7777, 7788 > $IPFW add queue 283 ip from table\(113\) to any via igb1 out proto icmp > $IPFW add queue 284 ip from table\(113\) to any via igb1 out > P.S. we have another computer if_bridge2. > uanme -a: > FreeBSD 7.2-STABLE-200906 FreeBSD 7.2-STABLE-200906 #1: Tue Oct 6 10:26:41 MSD 2009 /usr/src/sys/amd64/compile/MYKERNEL amd64 > We have no any problems with ipfw or shaping on this machine. We use this config on it: > $IPFW pipe 27 config bw 32000Kbit/s mask dst-ip 0xffffffff > $IPFW pipe 28 config bw 34000Kbit/s mask src-ip 0xffffffff > $IPFW add pipe 27 ip from any to table\(112\) via igb0 out > $IPFW add pipe 28 ip from table\(113\) to any via igb1 out > $IPFW add pipe 27 ip from any to table\(112\) via igb2 out > $IPFW add pipe 28 ip from table\(113\) to any via igb3 out > $IPFW add allow ip from any to table\(112\) > $IPFW add allow ip from table\(113\) to any > We try to shape speed on if_bridge1 with config like on if_bridge2 - but the problem repeated. > Maybe you deal with this problem? > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > úÄÅÓØ ÓÐÁÍÁ ÎÅÔ http://mail.yandex.ru/nospam/sign From owner-freebsd-ipfw@FreeBSD.ORG Thu Jun 24 17:45:16 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26F201065680 for ; Thu, 24 Jun 2010 17:45:16 +0000 (UTC) (envelope-from andykinney@advantagecom.net) Received: from mail.advantagecom.net (mail.advantagecom.net [66.29.143.155]) by mx1.freebsd.org (Postfix) with ESMTP id EA97B8FC14 for ; Thu, 24 Jun 2010 17:45:15 +0000 (UTC) Received: from scsi-monster (scsi-monster.advantagecom.net [66.29.154.200]) by mail.advantagecom.net (8.11.6/8.11.6) with ESMTP id o5OHjFv15886 for ; Thu, 24 Jun 2010 10:45:15 -0700 From: "Andrew Kinney" Organization: Advantagecom Networks, Inc. To: freebsd-ipfw@freebsd.org Date: Thu, 24 Jun 2010 10:44:43 -0700 MIME-Version: 1.0 Message-ID: <4C23371B.8097.6652DFB2@localhost> Priority: normal In-reply-to: <4C11099D.16213.1F4F72C6@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Antivirus: avast! (VPS 100611-1, 06/11/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: ipfw dyn_buckets relation to dyn_max X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andykinney@advantagecom.net List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 17:45:16 -0000 Since this is not seeing any kind of response, let's try some different questions that could lead me to the answer. Any answers to any of these questions will help. If any of my presumptions are wrong, *please* correct me. First, here is my current understanding of how buckets are used with dynamic rules. After doing some reading on hash tables and buckets, it sounds to me that the srcip/srcport-dstip/dstport data combo is hashed and that hash value is placed in a particular bucket. The number of buckets means that there are a certain number of memory locations or slots that hash values can drop into. More buckets roughly means fewer entries per bucket given the same number of hash values. More buckets to search, but fewer hash entries per bucket to search for matches. Each hash value is a list member and each bucket contains a list. 1. What size buckets are used by ipfw dynamic rules? I'm looking for something I can match up to "vmstat -z". 2. Are buckets fixed in size or do they grow as needed? If I know the size, I know the number of entries each bucket can hold. 3. If they're fixed in size, what is that size? 4. If they can grow as needed, is there a maximum size? I know the distribution between buckets will not be even simply because IP addresses, ports, and traffic volume are not random, but knowing a little more about the buckets will give me at least some rudimentary values to work from for estimating when/if things will break as the number of dynamic rules grows. With a 64 bit kernel, I would hope that kernel memory allocation is only limited by kmem (512GiB on FreeBSD 8.0 release?), physical memory, and the amount of processing power you can throw at it. It would appear that is the case, but I'm new to the 64 bit FreeBSD kernel (familiar with the old 4.x 32 bit kernel) and am uncertain which of the old memory allocation limitations have been removed. Am I on the right track here? Should I be asking different questions? Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net phone: 509-522-3696 ext. 101