From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 7 12:13:05 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 91C4D1065672 for ; Sun, 7 Mar 2010 12:13:05 +0000 (UTC) (envelope-from mate@netblok.pl) Received: from netblok.pl (mail.netblok.pl [217.153.243.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2938FC16 for ; Sun, 7 Mar 2010 12:13:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by netblok.pl (Postfix) with ESMTP id 45C5D3AF0D4 for ; Sun, 7 Mar 2010 12:57:09 +0100 (CET) Received: from netblok.pl ([127.0.0.1]) by localhost (mail.netblok.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFeiO-lYtBrc for ; Sun, 7 Mar 2010 12:57:09 +0100 (CET) Received: from [127.0.0.1] (unknown [192.168.83.220]) by netblok.pl (Postfix) with ESMTP id 003103AF0D3 for ; Sun, 7 Mar 2010 12:57:08 +0100 (CET) Message-ID: <4B9394BC.8070704@netblok.pl> Date: Sun, 07 Mar 2010 12:57:48 +0100 From: Mateusz Janik User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: dummynet problem: dummynet: OUCH! pipe should have been idle! 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: Sun, 07 Mar 2010 12:13:05 -0000 Hello, I installed Release 8.0 from ISO and not upgraded to any newer version (I gave up with upgrading system to 8.0 stable or head version because of problems with recompiling kernel after upgrade). I recompiled kernel with additional options: ============================================ options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=500 options IPFIREWALL_FORWARD options IPDIVERT options TCPDEBUG options IPFILTER options IPFILTER_LOG options IPSTEALTH options DUMMYNET options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_PRIQ ============================================ in order to use ipfilter + ipfw/dummynet on router with NAT enabled. i also recompiled ipfilter with LARGE_NAT option enabled. My rules for ipfw looks like: ============================================ add 00100 allow ip from any to any via lo0 add 00200 deny ip from any to 127.0.0.0/8 add 00300 deny ip from 127.0.0.0/8 to any pipe 80 config bw 512Kbit/s queue 40 add 40000 pipe 80 icmp from any to any in add 50000 allow ip from any to any via em0 pipe 100 config add 60000 pipe 100 ip from any to me in recv em1 add 60001 pipe 100 ip from me to any out xmit em1 pipe 2 config bw 35000Kbit/s queue 1024Kbytes queue 22 config pipe 2 weight 6 queue 256Kbytes mask dst-ip 0xffffffff add 65202 queue 22 udp from any to any out xmit em1 queue 23 config pipe 2 weight 7 queue 512Kbytes mask dst-ip 0xffffffff add 65203 queue 23 tcp from any 22,25,53,443,80,110,119,5060,3724 to any out xmit em1 queue 24 config pipe 2 weight 3 queue 256Kbytes mask dst-ip 0xffffffff add 65204 queue 24 ip from any to any out xmit em1 pipe 3 config bw 35000Kbit/s queue 1024Kbytes queue 32 config pipe 3 weight 6 queue 256Kbytes mask src-ip 0xffffffff add 65302 queue 32 udp from any to any in recv em1 queue 33 config pipe 3 weight 7 queue 512Kbytes mask src-ip 0xffffffff add 65303 queue 33 tcp from any to any 22,25,53,443,80,110,119,5060,3724 in recv em1 queue 34 config pipe 3 weight 3 queue 256Kbytes mask src-ip 0xffffffff add 65304 queue 34 ip from any to any in recv em1 add 65500 allow ip from any to any ============================================ Everything works fine until I plug in em1 interface (LAN) cable. When LAN traffic starts to flow I get dummynet messages: Mar 7 12:07:04 urke kernel: dummynet: OUCH! pipe should have been idle! Mar 7 12:07:05 urke kernel: dummynet: OUCH! pipe should have been idle! Mar 7 12:07:05 urke kernel: dummynet: OUCH! pipe should have been idle! Mar 7 12:07:07 urke kernel: dummynet: OUCH! pipe should have been idle! Mar 7 12:07:09 urke kernel: dummynet: OUCH! pipe should have been idle! Mar 7 12:07:16 urke kernel: dummynet: OUCH! pipe should have been idle! Mar 7 12:07:18 urke kernel: dummynet: OUCH! pipe should have been idle! Mar 7 12:07:18 urke kernel: dummynet: OUCH! pipe should have been idle! Mar 7 12:07:18 urke kernel: dummynet: OUCH! pipe should have been idle! Mar 7 12:07:18 urke kernel: dummynet: OUCH! pipe should have been idle! I noticed that Oleg Bulyzhin made patch for ip_dummynet.c and i applied these changes to sys/netinet/ipfw/ip_dummynet.c. But problem still occurs. Next, I downloaded ip_dummynet.c from Freebsd cvs including even newer changes to this file - problem still exists. Does anyone know what causes the problem? -- Thanks, Mat. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 8 11:07:00 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 60F1F1065697 for ; Mon, 8 Mar 2010 11:07:00 +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 3AA748FC0A for ; Mon, 8 Mar 2010 11:07:00 +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 o28B70D9073728 for ; Mon, 8 Mar 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o28B6x7Q073724 for freebsd-ipfw@FreeBSD.org; Mon, 8 Mar 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Mar 2010 11:06:59 GMT Message-Id: <201003081106.o28B6x7Q073724@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, 08 Mar 2010 11:07:00 -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/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 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 bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form 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 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 66 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 9 14:36:33 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 26D5F1065674 for ; Tue, 9 Mar 2010 14:36:33 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id A37F38FC14 for ; Tue, 9 Mar 2010 14:36:32 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o29EaFpr048888; Tue, 9 Mar 2010 15:36:30 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o29EaFQi048887; Tue, 9 Mar 2010 15:36:15 +0100 (CET) (envelope-from olli) Date: Tue, 9 Mar 2010 15:36:15 +0100 (CET) Message-Id: <201003091436.o29EaFQi048887@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 09 Mar 2010 15:36:30 +0100 (CET) Cc: Subject: Small problem with "ipfw list" 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: Tue, 09 Mar 2010 14:36:33 -0000 Hi, Just a question: Is the output from "ipfw list" supposed to be in the same rule format that is accepted as input? If that's the case, then there is a small bug: # ipfw add 100 allow ip from any to '{' 1.1.1.1 or 2.2.2.2 '}' 00100 allow ip from any to '{' 1.1.1.1 or dst-ip 2.2.2.2 '}' # ipfw list 100 00100 allow ip from any to '{' 1.1.1.1 or dst-ip 2.2.2.2 '}' # ipfw add 200 allow ip from any to '{' 1.1.1.1 or dst-ip 2.2.2.2 '}' ipfw: hostname ``dst-ip'' unknown So it inserts the word "dst-ip" in the output when an "or" block is used, but that word isn't accepted as input. I think the output from "ipfw list" should be valid rule format that could be fed back as input to ipfw(8). In fact that's exactly what I need to do in a script that I've written recently, and the "dst-ip" problem bit me. I had to work around it with sed(1). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 9 16:36:39 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 C6F86106564A for ; Tue, 9 Mar 2010 16:36:39 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8EBE18FC1A for ; Tue, 9 Mar 2010 16:36:39 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A2CA5730A1; Tue, 9 Mar 2010 17:46:11 +0100 (CET) Date: Tue, 9 Mar 2010 17:46:11 +0100 From: Luigi Rizzo To: Oliver Fromme Message-ID: <20100309164611.GB53491@onelab2.iet.unipi.it> References: <201003091436.o29EaFQi048887@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003091436.o29EaFQi048887@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: Small problem with "ipfw list" 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: Tue, 09 Mar 2010 16:36:39 -0000 On Tue, Mar 09, 2010 at 03:36:15PM +0100, Oliver Fromme wrote: > Hi, > > Just a question: Is the output from "ipfw list" supposed > to be in the same rule format that is accepted as input? it is not, partly due to backward compatibility. If you try "ipfw -c show" then you might have better luck though. cheers luigi > If that's the case, then there is a small bug: > > # ipfw add 100 allow ip from any to '{' 1.1.1.1 or 2.2.2.2 '}' > 00100 allow ip from any to '{' 1.1.1.1 or dst-ip 2.2.2.2 '}' > # ipfw list 100 > 00100 allow ip from any to '{' 1.1.1.1 or dst-ip 2.2.2.2 '}' > # ipfw add 200 allow ip from any to '{' 1.1.1.1 or dst-ip 2.2.2.2 '}' > ipfw: hostname ``dst-ip'' unknown > > So it inserts the word "dst-ip" in the output when an "or" > block is used, but that word isn't accepted as input. > > I think the output from "ipfw list" should be valid rule > format that could be fed back as input to ipfw(8). > > In fact that's exactly what I need to do in a script that > I've written recently, and the "dst-ip" problem bit me. > I had to work around it with sed(1). > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "Python is an experiment in how much freedom programmers need. > Too much freedom and nobody can read another's code; too little > and expressiveness is endangered." > -- Guido van Rossum > _______________________________________________ > 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" From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 11:20:50 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 E634F1065670 for ; Wed, 10 Mar 2010 11:20:50 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7C38FC21 for ; Wed, 10 Mar 2010 11:20:50 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o2ABKXGS002323; Wed, 10 Mar 2010 12:20:49 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o2ABKXoa002322; Wed, 10 Mar 2010 12:20:33 +0100 (CET) (envelope-from olli) Date: Wed, 10 Mar 2010 12:20:33 +0100 (CET) Message-Id: <201003101120.o2ABKXoa002322@lurza.secnetix.de> From: Oliver Fromme To: freebsd-ipfw@FreeBSD.ORG, rizzo@iet.unipi.it In-Reply-To: <20100309164611.GB53491@onelab2.iet.unipi.it> X-Newsgroups: list.freebsd-ipfw User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 10 Mar 2010 12:20:49 +0100 (CET) Cc: Subject: Re: Small problem with "ipfw list" 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, 10 Mar 2010 11:20:51 -0000 Luigi Rizzo wrote: > On Tue, Mar 09, 2010 at 03:36:15PM +0100, Oliver Fromme wrote: > > Just a question: Is the output from "ipfw list" supposed > > to be in the same rule format that is accepted as input? > > it is not, partly due to backward compatibility. I see. > If you try "ipfw -c show" then you might have better luck though. Unfortunately that makes things even worse. The "dst-ip" word is still there, and additionally any rules containing "from any to any" are shortened, which is also not accepted as input to ipfw(8). What do you think about adding a new option that lists the rules in a format that can be fed back as input to ipfw(8)? There are several tools with similar options, for example "stty -g". So far -g is not used in ipfw(8), so ... Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 11:34:55 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 E7B061065674 for ; Wed, 10 Mar 2010 11:34:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id ADFC98FC22 for ; Wed, 10 Mar 2010 11:34:55 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 67C83730A1; Wed, 10 Mar 2010 12:44:29 +0100 (CET) Date: Wed, 10 Mar 2010 12:44:29 +0100 From: Luigi Rizzo To: Oliver Fromme Message-ID: <20100310114429.GB65396@onelab2.iet.unipi.it> References: <20100309164611.GB53491@onelab2.iet.unipi.it> <201003101120.o2ABKXoa002322@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201003101120.o2ABKXoa002322@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: Small problem with "ipfw list" 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, 10 Mar 2010 11:34:56 -0000 On Wed, Mar 10, 2010 at 12:20:33PM +0100, Oliver Fromme wrote: > Luigi Rizzo wrote: > > On Tue, Mar 09, 2010 at 03:36:15PM +0100, Oliver Fromme wrote: > > > Just a question: Is the output from "ipfw list" supposed > > > to be in the same rule format that is accepted as input? > > > > it is not, partly due to backward compatibility. > > I see. > > > If you try "ipfw -c show" then you might have better luck though. > > Unfortunately that makes things even worse. The "dst-ip" > word is still there, and additionally any rules containing > "from any to any" are shortened, which is also not accepted > as input to ipfw(8). ok this means that i need to fix the output so that it is in a form acceptable to be fed back to ipfw. I'll try to come up with a patch soon (possibly using -g as an alias for -c if needed) cheers luigi > What do you think about adding a new option that lists the > rules in a format that can be fed back as input to ipfw(8)? > There are several tools with similar options, for example > "stty -g". So far -g is not used in ipfw(8), so ... > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > I suggested holding a "Python Object Oriented Programming Seminar", > but the acronym was unpopular. > -- Joseph Strout > _______________________________________________ > 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" From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 14:58: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 C41251065674 for ; Wed, 10 Mar 2010 14:58:15 +0000 (UTC) (envelope-from andrey.kropachev@gmail.com) Received: from mx.kirovnet.ru (taurus.kirovnet.ru [92.39.64.230]) by mx1.freebsd.org (Postfix) with ESMTP id 7DD238FC2D for ; Wed, 10 Mar 2010 14:58:15 +0000 (UTC) Received: from [192.168.2.68] by mx.kirovnet.ru with esmtp (Exim 4.69) (envelope-from ) id 1NpMjQ-0001JG-C2 for freebsd-ipfw@FreeBSD.ORG; Wed, 10 Mar 2010 17:17:53 +0300 Message-ID: <4B97AA08.6010102@gmail.com> Date: Wed, 10 Mar 2010 17:17:44 +0300 From: Andrey Kropachev User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.ORG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Dummynet tuning X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrey.kropachev@gmail.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 14:58:15 -0000 Hi, I'm trying to tune dummynet to shape a lot of traffic. I saw some opinions that the following patch will improve dummynet performance: in /sys/netinet/ipfw/ip_dummynet.c -#define HASHSIZE 16 -#define HASH(num) ((((num) >> 8) ^ ((num) >> 4) ^ (num)) & 0x0f) +#define HASHSIZE 256 +#define HASH(num) ((((num) >> 8) ^ ((num) >> 4) ^ (num)) & 0xff) The question is: will it increase dummynet performance? What will it actually do internally (luigi, question for you :) ? Best regards, Andrey Kropachev From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 15:43:00 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 42F4A106564A for ; Wed, 10 Mar 2010 15:43:00 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4E98FC0C for ; Wed, 10 Mar 2010 15:42:59 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.151.83.249] by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZ200FVAOZKMI30@asmtp029.mac.com> for freebsd-ipfw@freebsd.org; Wed, 10 Mar 2010 07:42:59 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003100123 From: Chuck Swiger In-reply-to: <20100310114429.GB65396@onelab2.iet.unipi.it> Date: Wed, 10 Mar 2010 07:42:56 -0800 Message-id: References: <20100309164611.GB53491@onelab2.iet.unipi.it> <201003101120.o2ABKXoa002322@lurza.secnetix.de> <20100310114429.GB65396@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1077) Cc: freebsd-ipfw@freebsd.org Subject: Re: Small problem with "ipfw list" 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, 10 Mar 2010 15:43:00 -0000 Hi-- On Mar 10, 2010, at 3:44 AM, Luigi Rizzo wrote: > ok this means that i need to fix the output so that it is in a form acceptable to be fed back to ipfw. +1... > I'll try to come up with a patch soon (possibly using -g as an alias for -c if needed) ...and thanks for being willing to spend the time fixing this. Regards, -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 15:54:40 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 E99EE106564A for ; Wed, 10 Mar 2010 15:54:40 +0000 (UTC) (envelope-from dado@cnt.korolev-net.ru) Received: from cnt.korolev-net.ru (mail.web-korolev.ru [89.222.188.140]) by mx1.freebsd.org (Postfix) with ESMTP id 989ED8FC08 for ; Wed, 10 Mar 2010 15:54:39 +0000 (UTC) Received: by cnt.korolev-net.ru (Postfix, from userid 100) id 1088F2ABC3F; Wed, 10 Mar 2010 18:33:04 +0300 (MSK) Date: Wed, 10 Mar 2010 18:33:04 +0300 From: Evgenii Davidov To: freebsd-ipfw@freebsd.org Message-ID: <20100310153303.GB62866@korolev-net.ru> References: <20091027074022.GE88744@korolev-net.ru> <20091027162924.GF88744@korolev-net.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20091027162924.GF88744@korolev-net.ru> User-Agent: Mutt/1.4.2.1i Subject: Re: dummynet cpu usage 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, 10 Mar 2010 15:54:41 -0000 úÄÒÁ×ÓÔ×ÕÊÔÅ, got the same problem again, now on freebsd8: rebuilded kernel today, and after it, on the same configuration dummunet began to eat a lot of cpu: 0 root -68 0 0K 72K - 0 119:34 0.78% {dummynet} 0 root -68 0 0K 72K - 0 119:39 6.98% {dummynet} 0 root -68 0 0K 72K - 1 220:31 0.10% {dummynet} 0 root -68 0 0K 72K - 0 220:34 0.59% {dummynet} 0 root -68 0 0K 72K - 0 220:38 0.68% {dummynet} 0 root -68 0 0K 72K - 1 0:00 7.47% {dummynet} 0 root -68 0 0K 72K - 0 0:01 57.08% {dummynet} 0 root -68 0 0K 72K - 1 0:02 63.87% {dummynet} 0 root -68 0 0K 72K - 0 0:03 42.87% {dummynet} 0 root -68 0 0K 72K - 1 0:03 46.29% {dummynet} 0 root -68 0 0K 72K - 0 0:04 76.17% {dummynet} (it's a log of a top -SHI every minute) the previous kernel was build a month ago last pid: 28398; load averages: 0.27, 0.30, 0.25 up 0+00:21:25 18:30:57 95 processes: 3 running, 74 sleeping, 18 waiting CPU: 0.0% user, 0.0% nice, 31.6% system, 0.4% interrupt, 68.0% idle Mem: 20M Active, 8176K Inact, 94M Wired, 36K Cache, 52M Buf, 1874M Free Swap: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 171 ki31 0K 16K CPU0 0 17:48 87.35% {idle: cpu0} 0 root -68 0 0K 72K - 1 0:23 80.57% {dummynet} 10 root 171 ki31 0K 16K RUN 1 18:23 13.57% {idle: cpu1} 0 root -68 0 0K 72K - 1 1:05 6.98% {em0 taskq} 0 root -68 0 0K 72K - 0 0:55 6.15% {em1 taskq} 12 root 45 - 0K 16K sleep 0 0:36 4.05% {ng_queue0} 12 root 46 - 0K 16K sleep 0 0:37 3.37% {ng_queue1} 11 root -32 - 0K 144K WAIT 0 0:08 0.39% {swi4: clock} 00030 1474643 388398833 pipe 6 ip from table(111) to any out xmit em0 00040 3227399 2094305856 pipe tablearg ip from any to table(2) in recv em0 net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.io_pkt_drop: 115551 net.inet.ip.dummynet.io_pkt_fast: 2441423 net.inet.ip.dummynet.io_pkt: 6603235 net.inet.ip.dummynet.io_fast: 1 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 12622 net.inet.ip.dummynet.tick_adjustment: 8425 net.inet.ip.dummynet.tick_delta_sum: 354 net.inet.ip.dummynet.tick_delta: 5 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.max_chain_len: 16 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.search_steps: 6642096 net.inet.ip.dummynet.searches: 6603196 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 32 net.inet.ip.dummynet.hash_size: 64 50089: 1.600 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail burst: 0 Byte 50074: 1.610 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 202 ip 0.0.0.0/0 XX.XX.X89.119/0 11 1531 0 0 0 50072: 800.000 Kbit/s 0 ms 50 sl. 5 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 194 ip 0.0.0.0/0 10.168.53.146/0 144 9523 0 0 0 225 ip 0.0.0.0/0 XX.XX.X85.92/0 1 404 0 0 0 232 ip 0.0.0.0/0 XX.XX.X85.85/0 21212 25934528 0 0 0 254 ip 0.0.0.0/0 XX.XX.X85.67/0 7 384 0 0 0 322 ip 0.0.0.0/0 10.168.110.18/0 2517 2510688 0 0 0 50073: 1.084 Mbit/s 0 ms 50 sl. 2 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 101 ip 0.0.0.0/0 XX.XX.X89.216/0 193 23799 0 0 0 464 ip 0.0.0.0/0 XX.XX.X90.109/0 2 128 0 0 0 00006: 1.000 Mbit/s 0 ms 50 sl. 124 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 6 ip 10.168.171.87/0 0.0.0.0/0 21710 26516193 0 0 9 12 ip 10.168.169.82/0 0.0.0.0/0 310 49148 0 0 0 14 ip 10.168.108.83/0 0.0.0.0/0 973 172353 0 0 0 16 ip 10.168.166.92/0 0.0.0.0/0 1064 307728 0 0 0 24 ip 10.168.175.88/0 0.0.0.0/0 4452 487482 0 0 0 26 ip 10.168.169.89/0 0.0.0.0/0 74 3974 0 0 0 32 ip 10.168.168.68/0 0.0.0.0/0 23143 1472809 0 0 0 34 ip 10.168.172.69/0 0.0.0.0/0 1428 239405 0 0 0 36 ip 10.168.173.70/0 0.0.0.0/0 114 4956 0 0 0 44 ip 192.168.64.66/0 0.0.0.0/0 12 659 0 0 0 46 ip 10.168.166.67/0 0.0.0.0/0 3806 542384 0 0 0 48 ip 10.168.168.76/0 0.0.0.0/0 34 2584 0 0 0 50 ip 10.168.175.77/0 0.0.0.0/0 3142 742559 0 0 0 54 ip 10.168.161.79/0 0.0.0.0/0 1 84 0 0 0 58 ip 10.168.172.73/0 0.0.0.0/0 2435 309554 0 0 0 60 ip 10.168.163.74/0 0.0.0.0/0 2154 270684 0 0 0 62 ip 10.168.163.75/0 0.0.0.0/0 41 2430 0 0 0 64 ip 10.168.107.116/0 0.0.0.0/0 1 1480 0 0 0 66 ip 10.168.62.117/0 0.0.0.0/0 97 16562 0 0 0 76 ip 192.168.108.114/0 0.0.0.0/0 21 868 0 0 0 78 ip 10.168.62.115/0 0.0.0.0/0 358 41897 0 0 0 84 ip 10.168.178.126/0 0.0.0.0/0 3920 714536 0 0 0 96 ip 10.168.62.100/0 0.0.0.0/0 162297 78738170 22 4535 474 98 ip 10.168.168.101/0 0.0.0.0/0 1096 162238 0 0 0 106 ip 10.168.164.97/0 0.0.0.0/0 2 130 0 0 0 108 ip 10.168.51.98/0 0.0.0.0/0 1 46 0 0 0 112 ip 10.168.168.108/0 0.0.0.0/0 5149 635296 0 0 0 114 ip 10.168.161.109/0 0.0.0.0/0 15205 1900010 0 0 0 118 ip 10.168.63.111/0 0.0.0.0/0 450 64446 0 0 0 120 ip 10.168.63.104/0 0.0.0.0/0 157 9816 0 0 0 122 ip 10.168.167.105/0 0.0.0.0/0 286 35607 0 0 0 124 ip 10.168.165.106/0 0.0.0.0/0 1202 63037 0 0 0 126 ip 10.168.161.107/0 0.0.0.0/0 704 130523 0 0 0 128 ip 10.168.53.20/0 0.0.0.0/0 10 591 0 0 0 130 ip 10.168.173.21/0 0.0.0.0/0 118 32675 0 0 0 132 ip 10.168.173.22/0 0.0.0.0/0 14760 710311 0 0 0 134 ip 192.168.137.23/0 0.0.0.0/0 16472 1471421 0 0 0 136 ip 10.168.161.16/0 0.0.0.0/0 19 1191 0 0 0 138 ip 192.168.135.17/0 0.0.0.0/0 126 12077 0 0 0 140 ip 10.168.109.18/0 0.0.0.0/0 19 26540 5 7000 0 142 ip 10.168.53.19/0 0.0.0.0/0 305 61187 0 0 0 144 ip 10.168.169.28/0 0.0.0.0/0 3813 409256 0 0 0 148 ip 10.168.36.30/0 0.0.0.0/0 194 21713 0 0 0 152 ip 192.168.65.24/0 0.0.0.0/0 3259 410087 0 0 0 160 ip 10.168.52.4/0 0.0.0.0/0 315 14138 0 0 0 162 ip 192.168.141.5/0 0.0.0.0/0 9 437 0 0 0 166 ip 10.168.167.7/0 0.0.0.0/0 3513 205802 0 0 0 172 ip 192.168.135.2/0 0.0.0.0/0 6 304 0 0 0 172 ip 10.168.54.2/0 0.0.0.0/0 3 2994 0 0 0 174 ip 192.168.141.3/0 0.0.0.0/0 4 550 0 0 0 176 ip 10.168.105.12/0 0.0.0.0/0 18 6656 0 0 0 178 ip 10.168.105.13/0 0.0.0.0/0 2121 407658 0 0 0 180 ip 10.168.175.14/0 0.0.0.0/0 1502 293575 0 0 0 182 ip 10.168.163.15/0 0.0.0.0/0 89 7538 0 0 0 188 ip 10.168.163.10/0 0.0.0.0/0 6 372 0 0 0 190 ip 10.168.7.11/0 0.0.0.0/0 4335 280542 0 0 0 192 ip 10.168.175.52/0 0.0.0.0/0 715 123542 0 0 0 194 ip 10.168.167.53/0 0.0.0.0/0 809 106893 0 0 0 196 ip 10.168.168.54/0 0.0.0.0/0 18824 2345495 0 0 0 198 ip 10.168.175.55/0 0.0.0.0/0 469 57382 0 0 0 200 ip 10.168.178.48/0 0.0.0.0/0 7786 456544 0 0 0 204 ip 192.168.61.50/0 0.0.0.0/0 9 2251 1 568 0 206 ip 10.168.176.51/0 0.0.0.0/0 1255 272736 0 0 0 210 ip 10.168.164.61/0 0.0.0.0/0 44 2180 0 0 0 216 ip 10.168.100.56/0 0.0.0.0/0 8743 922685 0 0 0 220 ip 10.168.171.58/0 0.0.0.0/0 27496 19087748 29 16819 5 224 ip 10.168.104.36/0 0.0.0.0/0 1457 483577 0 0 0 226 ip 192.168.58.37/0 0.0.0.0/0 1 40 0 0 0 228 ip 10.168.164.38/0 0.0.0.0/0 2175 304876 0 0 0 232 ip 10.168.175.32/0 0.0.0.0/0 2321 338316 0 0 0 234 ip 10.168.160.33/0 0.0.0.0/0 198529 8633319 0 0 0 236 ip 10.168.104.34/0 0.0.0.0/0 197 7948 0 0 0 244 ip 192.168.58.46/0 0.0.0.0/0 118 7567 0 0 0 248 ip 10.168.100.40/0 0.0.0.0/0 42 6665 0 0 0 256 ip 10.168.178.212/0 0.0.0.0/0 19 760 0 0 0 266 ip 10.168.175.209/0 0.0.0.0/0 3168 476517 0 0 0 268 ip 10.168.108.210/0 0.0.0.0/0 372 26884 0 0 0 270 ip 10.168.57.211/0 0.0.0.0/0 160 11037 0 0 0 274 ip 10.168.162.221/0 0.0.0.0/0 11554 995768 0 0 0 278 ip 10.168.171.223/0 0.0.0.0/0 2844 444676 0 0 0 284 ip 10.168.173.218/0 0.0.0.0/0 66564 29789404 0 0 0 286 ip 10.168.175.219/0 0.0.0.0/0 2620 393254 0 0 0 288 ip 192.168.107.196/0 0.0.0.0/0 112 6274 0 0 0 292 ip 10.168.162.198/0 0.0.0.0/0 182 16174 0 0 0 294 ip 10.168.171.199/0 0.0.0.0/0 144 114495 0 0 0 300 ip 10.168.28.194/0 0.0.0.0/0 1 50 0 0 0 302 ip 10.168.28.195/0 0.0.0.0/0 917 155977 0 0 0 304 ip 192.168.107.204/0 0.0.0.0/0 475 171482 0 0 0 312 ip 192.168.107.200/0 0.0.0.0/0 4354 785046 0 0 78 314 ip 10.168.178.201/0 0.0.0.0/0 4650 451310 0 0 0 332 ip 192.168.109.242/0 0.0.0.0/0 13737 2013414 0 0 0 364 ip 10.168.66.226/0 0.0.0.0/0 1 40 0 0 0 370 ip 10.168.166.237/0 0.0.0.0/0 338 42868 0 0 0 384 ip 10.168.51.148/0 0.0.0.0/0 59 4169 0 0 0 390 ip 10.168.166.151/0 0.0.0.0/0 171 18899 0 0 0 396 ip 10.168.53.146/0 0.0.0.0/0 3 187 0 0 0 400 ip 10.168.180.156/0 0.0.0.0/0 2 80 0 0 0 412 ip 10.168.179.154/0 0.0.0.0/0 544 79628 0 0 0 416 ip 10.168.57.132/0 0.0.0.0/0 1 131 0 0 0 420 ip 10.168.57.134/0 0.0.0.0/0 701 28040 0 0 0 426 ip 10.168.165.129/0 0.0.0.0/0 5028 201318 0 0 0 428 ip 192.168.64.130/0 0.0.0.0/0 1748 899563 16 5376 157 430 ip 192.168.64.131/0 0.0.0.0/0 122 10855 0 0 0 432 ip 10.168.164.140/0 0.0.0.0/0 2 117 0 0 0 434 ip 10.168.170.141/0 0.0.0.0/0 20 1769 0 0 0 436 ip 10.168.177.142/0 0.0.0.0/0 45995 2208494 0 0 0 440 ip 10.168.169.136/0 0.0.0.0/0 26 2012 0 0 0 442 ip 10.168.161.137/0 0.0.0.0/0 2620 266936 0 0 0 444 ip 10.168.176.138/0 0.0.0.0/0 914 130061 0 0 0 448 ip 192.168.11.180/0 0.0.0.0/0 7962 756952 0 0 0 456 ip 10.168.161.176/0 0.0.0.0/0 180287 68998026 0 0 16966 458 ip 10.168.164.177/0 0.0.0.0/0 1681 185688 0 0 0 460 ip 10.168.178.178/0 0.0.0.0/0 1238 159772 0 0 0 462 ip 192.168.28.179/0 0.0.0.0/0 297 65830 0 0 0 474 ip 10.168.167.185/0 0.0.0.0/0 25 4573 0 0 0 476 ip 10.168.167.186/0 0.0.0.0/0 4722 840376 0 0 0 478 ip 10.168.173.187/0 0.0.0.0/0 1969 303362 0 0 0 480 ip 10.168.175.164/0 0.0.0.0/0 3310 162385 0 0 0 484 ip 10.168.175.166/0 0.0.0.0/0 98 9528 0 0 0 490 ip 10.168.168.161/0 0.0.0.0/0 262504 84051847 28 9012 13067 492 ip 10.168.28.162/0 0.0.0.0/0 646 111064 0 0 0 496 ip 10.168.173.172/0 0.0.0.0/0 180 29295 0 0 0 498 ip 10.168.173.173/0 0.0.0.0/0 1005 100857 0 0 0 504 ip 10.168.52.168/0 0.0.0.0/0 1591 254922 0 0 0 50096: 2.100 Mbit/s 0 ms 50 sl. 65 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 1 ip 0.0.0.0/0 XX.XX.X87.188/0 261 27329 0 0 0 9 ip 0.0.0.0/0 XX.XX.X89.180/0 5 3128 0 0 0 12 ip 0.0.0.0/0 XX.XX.X89.177/0 163 20836 0 0 0 16 ip 0.0.0.0/0 XX.XX.X87.173/0 13 719 0 0 0 19 ip 0.0.0.0/0 XX.XX.X89.174/0 37 2304 0 0 0 23 ip 0.0.0.0/0 XX.XX.X87.170/0 3 396 0 0 0 28 ip 0.0.0.0/0 XX.XX.X89.161/0 31810 38707082 0 0 87 36 ip 0.0.0.0/0 XX.XX.X89.153/0 95985 9187516 0 0 340 40 ip 0.0.0.0/0 XX.XX.X89.149/0 53 2991 0 0 0 41 ip 0.0.0.0/0 XX.XX.X87.148/0 9 856 0 0 0 46 ip 0.0.0.0/0 XX.XX.X87.147/0 14 1392 0 0 0 49 ip 0.0.0.0/0 XX.XX.X85.140/0 46 5956 0 0 0 52 ip 0.0.0.0/0 XX.XX.X87.137/0 208 24697 0 0 0 61 ip 0.0.0.0/0 XX.XX.X87.128/0 102 5559 0 0 0 85 ip 0.0.0.0/0 XX.XX.X89.232/0 3 160 0 0 0 91 ip 0.0.0.0/0 XX.XX.X89.230/0 17 1075 0 0 0 101 ip 0.0.0.0/0 10.168.175.52/0 59 17640 0 0 0 102 ip 0.0.0.0/0 10.168.175.55/0 360 36747 0 0 0 104 ip 0.0.0.0/0 XX.XX.X87.213/0 5585 596327 0 0 0 112 ip 0.0.0.0/0 XX.XX.X87.205/0 1 64 0 0 0 113 ip 0.0.0.0/0 XX.XX.X89.204/0 4 224 0 0 0 114 ip 0.0.0.0/0 XX.XX.X87.207/0 1 64 0 0 0 123 ip 0.0.0.0/0 XX.XX.X87.198/0 253 31147 0 0 0 140 ip 0.0.0.0/0 XX.XX.X89.49/0 6 384 0 0 0 141 ip 0.0.0.0/0 XX.XX.X89.48/0 1871 228845 0 0 0 142 ip 0.0.0.0/0 XX.XX.X87.51/0 4 275 0 0 0 158 ip 0.0.0.0/0 XX.XX.X89.35/0 165 18499 0 0 0 169 ip 0.0.0.0/0 XX.XX.X85.20/0 6 352 0 0 0 177 ip 0.0.0.0/0 XX.XX.X87.12/0 70 4576 0 0 0 192 ip 0.0.0.0/0 XX.XX.X89.125/0 134 10545 0 0 0 193 ip 0.0.0.0/0 XX.XX.X89.124/0 2 88 0 0 0 204 ip 0.0.0.0/0 XX.XX.X87.113/0 14250 2633693 0 0 0 207 ip 0.0.0.0/0 XX.XX.X87.114/0 27 1620 0 0 0 221 ip 0.0.0.0/0 10.168.165.140/0 425 341799 0 0 0 222 ip 0.0.0.0/0 XX.XX.X89.99/0 16 1806 0 0 0 223 ip 0.0.0.0/0 XX.XX.X85.98/0 286 76977 0 0 0 226 ip 0.0.0.0/0 XX.XX.X89.95/0 655 73194 0 0 0 229 ip 0.0.0.0/0 10.168.177.180/0 21 2571 0 0 0 234 ip 0.0.0.0/0 XX.XX.X87.87/0 37 5297 0 0 0 239 ip 0.0.0.0/0 XX.XX.X89.82/0 92 6596 0 0 0 242 ip 0.0.0.0/0 XX.XX.X87.79/0 47111 8117882 0 0 0 245 ip 0.0.0.0/0 XX.XX.X87.72/0 10 504 0 0 0 246 ip 0.0.0.0/0 XX.XX.X87.75/0 1 90 0 0 0 268 ip 0.0.0.0/0 XX.XX.X90.177/0 5 351 0 0 0 293 ip 0.0.0.0/0 10.168.166.116/0 70772 56995616 0 0 0 303 ip 0.0.0.0/0 XX.XX.X90.146/0 798 53427 0 0 0 308 ip 0.0.0.0/0 XX.XX.X90.137/0 134 8827 0 0 0 373 ip 0.0.0.0/0 192.168.58.37/0 2431 2023647 0 0 0 375 ip 0.0.0.0/0 XX.XX.X90.202/0 2 128 0 0 0 388 ip 0.0.0.0/0 XX.XX.X90.57/0 4234 481139 0 0 0 407 ip 0.0.0.0/0 10.168.162.198/0 5262 4960804 0 0 2 411 ip 0.0.0.0/0 XX.XX.X90.38/0 153 8753 0 0 0 413 ip 0.0.0.0/0 XX.XX.X90.32/0 2 128 0 0 0 424 ip 0.0.0.0/0 XX.XX.X90.21/0 37 1874 0 0 0 440 ip 0.0.0.0/0 XX.XX.X90.5/0 6 436 0 0 0 453 ip 0.0.0.0/0 10.168.176.148/0 355 125768 0 0 0 454 ip 0.0.0.0/0 XX.XX.X90.123/0 822 39860 0 0 0 461 ip 0.0.0.0/0 10.168.180.156/0 30707 38445056 0 0 378 477 ip 0.0.0.0/0 10.168.178.140/0 2867 2387110 0 0 0 483 ip 0.0.0.0/0 XX.XX.X90.94/0 5 320 0 0 0 485 ip 0.0.0.0/0 XX.XX.X90.88/0 71 9027 0 0 0 490 ip 0.0.0.0/0 XX.XX.X90.87/0 3801 3997088 0 0 0 495 ip 0.0.0.0/0 XX.XX.X90.82/0 11 703 0 0 0 507 ip 0.0.0.0/0 XX.XX.X90.70/0 3 198 0 0 0 510 ip 0.0.0.0/0 XX.XX.X90.67/0 6 367 0 0 0 50097: 5.200 Mbit/s 0 ms 50 sl. 95 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 1 ip 0.0.0.0/0 XX.XX.X89.188/0 192 25522 0 0 0 4 ip 0.0.0.0/0 XX.XX.X89.185/0 15 1043 0 0 0 5 ip 0.0.0.0/0 XX.XX.X89.184/0 7 436 0 0 0 6 ip 0.0.0.0/0 XX.XX.X87.187/0 5881 580616 0 0 0 7 ip 0.0.0.0/0 XX.XX.X87.186/0 228 19140 0 0 0 19 ip 0.0.0.0/0 XX.XX.X87.174/0 33 2202 0 0 0 22 ip 0.0.0.0/0 XX.XX.X89.171/0 47 2879 0 0 0 23 ip 0.0.0.0/0 10.168.173.70/0 24294 29852929 0 0 211 25 ip 0.0.0.0/0 XX.XX.X89.164/0 60 3711 0 0 0 26 ip 0.0.0.0/0 XX.XX.X87.167/0 5392 1194755 0 0 0 28 ip 0.0.0.0/0 10.168.175.77/0 3752 2014043 0 0 0 30 ip 0.0.0.0/0 XX.XX.X87.163/0 6 511 0 0 0 32 ip 0.0.0.0/0 XX.XX.X85.157/0 6648 6581531 0 0 0 37 ip 0.0.0.0/0 XX.XX.X87.152/0 722007 429081144 0 0 9778 42 ip 0.0.0.0/0 XX.XX.X89.151/0 7 536 0 0 0 45 ip 0.0.0.0/0 XX.XX.X89.144/0 122 63091 0 0 0 47 ip 0.0.0.0/0 XX.XX.X85.146/0 7 396 0 0 0 48 ip 0.0.0.0/0 XX.XX.X87.141/0 5 611 0 0 0 50 ip 0.0.0.0/0 XX.XX.X87.143/0 97 6383 0 0 0 54 ip 0.0.0.0/0 XX.XX.X85.139/0 8 483 0 0 0 55 ip 0.0.0.0/0 XX.XX.X87.138/0 10125 10027177 0 0 0 56 ip 0.0.0.0/0 XX.XX.X87.133/0 7 727 0 0 0 60 ip 0.0.0.0/0 XX.XX.X89.129/0 23 2615 0 0 0 62 ip 0.0.0.0/0 XX.XX.X87.131/0 7 384 0 0 0 76 ip 0.0.0.0/0 XX.XX.X87.241/0 92 7881 0 0 0 78 ip 0.0.0.0/0 XX.XX.X87.243/0 1 64 0 0 0 82 ip 0.0.0.0/0 XX.XX.X87.239/0 49 3656 0 0 0 84 ip 0.0.0.0/0 XX.XX.X87.233/0 22 2549 0 0 0 86 ip 0.0.0.0/0 XX.XX.X87.235/0 18 888 0 0 0 91 ip 0.0.0.0/0 10.168.101.11/0 17 981 0 0 0 92 ip 0.0.0.0/0 XX.XX.X87.225/0 4 224 0 0 0 97 ip 0.0.0.0/0 XX.XX.X87.220/0 31 1614 0 0 0 99 ip 0.0.0.0/0 XX.XX.X89.222/0 1 64 0 0 0 107 ip 0.0.0.0/0 XX.XX.X89.214/0 184 14781 0 0 0 109 ip 0.0.0.0/0 XX.XX.X87.208/0 1091 743994 0 0 0 112 ip 0.0.0.0/0 XX.XX.X89.205/0 2 128 0 0 0 116 ip 0.0.0.0/0 XX.XX.X87.201/0 30 3635 0 0 0 121 ip 0.0.0.0/0 XX.XX.X87.196/0 28 1741 0 0 0 122 ip 0.0.0.0/0 XX.XX.X89.199/0 30 3477 0 0 0 124 ip 0.0.0.0/0 XX.XX.X87.193/0 12 1359 0 0 0 126 ip 0.0.0.0/0 XX.XX.X89.195/0 37 3111 0 0 0 128 ip 0.0.0.0/0 10.168.175.209/0 3847 2759554 0 0 0 131 ip 0.0.0.0/0 XX.XX.X87.62/0 525 30728 0 0 0 131 ip 0.0.0.0/0 XX.XX.X85.62/0 2 80 0 0 0 132 ip 0.0.0.0/0 XX.XX.X85.57/0 7 797 0 0 0 136 ip 0.0.0.0/0 XX.XX.X89.53/0 33 1805 0 0 0 138 ip 0.0.0.0/0 10.168.175.219/0 3877 3555821 0 0 0 143 ip 0.0.0.0/0 XX.XX.X89.50/0 4 308 0 0 0 144 ip 0.0.0.0/0 XX.XX.X87.45/0 67 3707 0 0 0 145 ip 0.0.0.0/0 XX.XX.X87.44/0 41 2302 0 0 0 147 ip 0.0.0.0/0 XX.XX.X85.46/0 87 7078 0 0 0 149 ip 0.0.0.0/0 XX.XX.X87.40/0 1 404 0 0 0 152 ip 0.0.0.0/0 XX.XX.X85.37/0 334 334185 0 0 0 154 ip 0.0.0.0/0 XX.XX.X89.39/0 6672 6002590 0 0 15 157 ip 0.0.0.0/0 XX.XX.X87.32/0 39 3056 0 0 0 164 ip 0.0.0.0/0 XX.XX.X89.25/0 2547 530546 0 0 0 168 ip 0.0.0.0/0 XX.XX.X85.21/0 77669 5057281 0 0 0 169 ip 0.0.0.0/0 XX.XX.X87.20/0 5 366 0 0 0 173 ip 0.0.0.0/0 XX.XX.X87.16/0 52 3945 0 0 0 175 ip 0.0.0.0/0 XX.XX.X89.18/0 5 288 0 0 0 178 ip 0.0.0.0/0 XX.XX.X89.15/0 1 61 0 0 0 185 ip 0.0.0.0/0 XX.XX.X89.4/0 5 288 0 0 0 192 ip 0.0.0.0/0 XX.XX.X87.125/0 888 47526 0 0 0 198 ip 0.0.0.0/0 XX.XX.X87.123/0 5 320 0 0 0 202 ip 0.0.0.0/0 XX.XX.X87.119/0 10 1355 0 0 0 206 ip 0.0.0.0/0 XX.XX.X89.115/0 35 3284 0 0 0 212 ip 0.0.0.0/0 XX.XX.X87.105/0 4 556 0 0 0 213 ip 0.0.0.0/0 XX.XX.X89.104/0 20 1506 0 0 0 214 ip 0.0.0.0/0 XX.XX.X87.107/0 76 4357 0 0 0 218 ip 0.0.0.0/0 XX.XX.X87.103/0 13 1288 0 0 0 227 ip 0.0.0.0/0 XX.XX.X85.94/0 2 216 0 0 0 233 ip 0.0.0.0/0 XX.XX.X87.84/0 108 6284 0 0 0 243 ip 0.0.0.0/0 XX.XX.X87.78/0 161 10109 0 0 0 251 ip 0.0.0.0/0 XX.XX.X89.70/0 1 64 0 0 0 252 ip 0.0.0.0/0 10.168.173.173/0 2056 559542 0 0 0 254 ip 0.0.0.0/0 XX.XX.X89.67/0 3 213 0 0 0 280 ip 0.0.0.0/0 XX.XX.X90.165/0 1109 922845 0 0 0 302 ip 0.0.0.0/0 XX.XX.X90.147/0 40 2320 0 0 0 313 ip 0.0.0.0/0 XX.XX.X90.132/0 192716 265012580 0 0 135 381 ip 0.0.0.0/0 XX.XX.X90.192/0 16 724 0 0 0 383 ip 0.0.0.0/0 XX.XX.X90.194/0 3 176 0 0 0 406 ip 0.0.0.0/0 XX.XX.X90.43/0 5 346 0 0 0 408 ip 0.0.0.0/0 10.168.178.201/0 6066 7025497 0 0 10 418 ip 0.0.0.0/0 XX.XX.X90.31/0 3865 4015404 0 0 0 426 ip 0.0.0.0/0 XX.XX.X90.23/0 4205 292265 0 0 0 441 ip 0.0.0.0/0 XX.XX.X90.4/0 166 9944 0 0 0 461 ip 0.0.0.0/0 10.168.162.156/0 1023 574733 0 0 0 466 ip 0.0.0.0/0 XX.XX.X90.111/0 12 734 0 0 0 469 ip 0.0.0.0/0 XX.XX.X90.104/0 16 1870 0 0 0 471 ip 0.0.0.0/0 XX.XX.X90.106/0 943 101660 0 0 0 476 ip 0.0.0.0/0 XX.XX.X90.97/0 1 64 0 0 0 487 ip 0.0.0.0/0 XX.XX.X90.90/0 2 468 0 0 0 489 ip 0.0.0.0/0 XX.XX.X90.84/0 54 3590 0 0 0 496 ip 0.0.0.0/0 10.168.168.161/0 456188 275057804 0 0 24395 503 ip 0.0.0.0/0 XX.XX.X90.74/0 223 22045 0 0 0 50098: 10.500 Mbit/s 0 ms 50 sl. 15 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 13 ip 0.0.0.0/0 XX.XX.X89.176/0 500 30829 0 0 0 24 ip 0.0.0.0/0 XX.XX.X89.165/0 8 496 0 0 0 34 ip 0.0.0.0/0 XX.XX.X87.159/0 4 344 0 0 0 48 ip 0.0.0.0/0 XX.XX.X89.141/0 926 55969 0 0 0 55 ip 0.0.0.0/0 XX.XX.X89.138/0 23 1314 0 0 0 84 ip 0.0.0.0/0 XX.XX.X89.233/0 54 6691 0 0 0 100 ip 0.0.0.0/0 XX.XX.X89.217/0 779 85676 0 0 0 113 ip 0.0.0.0/0 XX.XX.X87.204/0 147629 155260631 0 0 0 155 ip 0.0.0.0/0 XX.XX.X87.38/0 188 11483 0 0 0 160 ip 0.0.0.0/0 XX.XX.X87.29/0 8 538 0 0 0 162 ip 0.0.0.0/0 XX.XX.X87.31/0 22371 1520423 0 0 0 164 ip 0.0.0.0/0 XX.XX.X87.25/0 152530 71098115 0 0 0 233 ip 0.0.0.0/0 XX.XX.X85.84/0 4 242 0 0 0 362 ip 0.0.0.0/0 XX.XX.X90.215/0 4 256 0 0 0 436 ip 0.0.0.0/0 XX.XX.X90.9/0 58 3252 0 0 0 50083: 2.176 Mbit/s 0 ms 50 sl. 24 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 11 ip 0.0.0.0/0 XX.XX.X87.182/0 309 18328 0 0 0 14 ip 0.0.0.0/0 XX.XX.X89.179/0 10 900 0 0 0 103 ip 0.0.0.0/0 XX.XX.X89.218/0 59822 4124932 0 0 0 128 ip 0.0.0.0/0 XX.XX.X87.61/0 695 76230 0 0 0 129 ip 0.0.0.0/0 XX.XX.X87.60/0 94 39169 0 0 0 130 ip 0.0.0.0/0 XX.XX.X87.63/0 22 2593 0 0 0 144 ip 0.0.0.0/0 XX.XX.X89.45/0 10 668 0 0 0 151 ip 0.0.0.0/0 XX.XX.X87.42/0 190232 28165562 0 0 0 157 ip 0.0.0.0/0 XX.XX.X89.32/0 2 128 0 0 0 181 ip 0.0.0.0/0 XX.XX.X87.8/0 86 35479 0 0 0 187 ip 0.0.0.0/0 XX.XX.X89.6/0 58 7547 0 0 0 197 ip 0.0.0.0/0 XX.XX.X89.120/0 179 22168 0 0 0 203 ip 0.0.0.0/0 10.168.179.154/0 661 594059 0 0 0 209 ip 0.0.0.0/0 XX.XX.X87.108/0 838 119456 0 0 0 229 ip 0.0.0.0/0 XX.XX.X87.88/0 9915 8859861 0 0 88 253 ip 0.0.0.0/0 XX.XX.X87.64/0 3132 692269 0 0 0 273 ip 0.0.0.0/0 XX.XX.X90.172/0 2 190 0 0 0 290 ip 0.0.0.0/0 XX.XX.X90.159/0 4 308 0 0 0 355 ip 0.0.0.0/0 10.168.176.50/0 2452 2586345 0 0 18 373 ip 0.0.0.0/0 XX.XX.X84.200/0 118830 14030311 0 0 1 389 ip 0.0.0.0/0 10.168.178.212/0 7121 5389020 0 0 0 396 ip 0.0.0.0/0 10.168.162.221/0 24735 28057802 0 0 0 404 ip 0.0.0.0/0 XX.XX.X90.41/0 4 256 0 0 0 449 ip 0.0.0.0/0 XX.XX.X90.124/0 49678 36026830 0 0 0 50099: 17.000 Mbit/s 0 ms 50 sl. 7 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 8 ip 0.0.0.0/0 XX.XX.X89.181/0 5 398 0 0 0 80 ip 0.0.0.0/0 XX.XX.X89.237/0 2197 262727 0 0 0 98 ip 0.0.0.0/0 XX.XX.X89.223/0 7 874 0 0 0 119 ip 0.0.0.0/0 XX.XX.X87.202/0 98 5375 0 0 0 228 ip 0.0.0.0/0 XX.XX.X89.89/0 5 280 0 0 0 241 ip 0.0.0.0/0 XX.XX.X85.76/0 15 909 0 0 0 376 ip 0.0.0.0/0 10.168.100.40/0 49 20308 0 0 0 50065: 392.000 Kbit/s 0 ms 50 sl. 8 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 26 ip 0.0.0.0/0 10.168.163.75/0 36 23393 0 0 0 27 ip 0.0.0.0/0 10.168.163.74/0 2616 2600595 0 0 127 37 ip 0.0.0.0/0 XX.XX.X89.152/0 27 2928 0 0 0 266 ip 0.0.0.0/0 XX.XX.X90.183/0 1 76 0 0 0 281 ip 0.0.0.0/0 XX.XX.X90.164/0 991 677825 0 0 0 353 ip 0.0.0.0/0 10.168.178.48/0 13260 17786593 11 15400 0 364 ip 0.0.0.0/0 10.168.164.61/0 34 5080 0 0 0 383 ip 0.0.0.0/0 XX.XX.X84.194/0 53 4069 0 0 0 50082: 1.140 Mbit/s 0 ms 50 sl. 11 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 71 ip 0.0.0.0/0 10.168.173.22/0 16507 3434230 0 0 0 105 ip 0.0.0.0/0 XX.XX.X87.212/0 3 192 0 0 0 146 ip 0.0.0.0/0 XX.XX.X87.47/0 157 8858 0 0 0 193 ip 0.0.0.0/0 XX.XX.X87.124/0 14 982 0 0 0 213 ip 0.0.0.0/0 XX.XX.X87.104/0 8986 6017498 0 0 49 262 ip 0.0.0.0/0 XX.XX.X90.187/0 35 1881 0 0 0 264 ip 0.0.0.0/0 10.168.176.89/0 1044 1236842 0 0 5 270 ip 0.0.0.0/0 XX.XX.X90.179/0 9 360 0 0 0 294 ip 0.0.0.0/0 XX.XX.X90.155/0 9 1260 0 0 0 317 ip 0.0.0.0/0 XX.XX.X90.128/0 9 524 0 0 0 430 ip 0.0.0.0/0 XX.XX.X90.19/0 17 1163 0 0 0 50070: 536.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 58 ip 0.0.0.0/0 XX.XX.X85.135/0 6 312 0 0 0 50055: 142.000 Kbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 23 ip 0.0.0.0/0 10.168.161.70/0 3507 2710751 0 0 9 50085: 10.500 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 239 ip 0.0.0.0/0 XX.XX.X87.82/0 240 15089 0 0 0 500101: 1.300 Mbit/s 0 ms 50 sl. 21 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 6 ip 0.0.0.0/0 XX.XX.X85.187/0 117304 119748658 0 0 161 10 ip 0.0.0.0/0 XX.XX.X85.183/0 16 640 0 0 0 98 ip 0.0.0.0/0 192.168.61.50/0 2823 2369123 0 0 15 101 ip 0.0.0.0/0 192.168.61.53/0 5 2017 0 0 0 210 ip 0.0.0.0/0 10.168.57.130/0 493 166810 0 0 0 211 ip 0.0.0.0/0 10.168.57.131/0 332 105165 0 0 0 212 ip 0.0.0.0/0 10.168.57.132/0 6949 5114319 0 0 28 214 ip 0.0.0.0/0 10.168.57.134/0 21841 31908796 44 65120 3 215 ip 0.0.0.0/0 XX.XX.X85.106/0 3 192 0 0 0 287 ip 0.0.0.0/0 XX.XX.X84.162/0 503 53924 0 0 0 290 ip 0.0.0.0/0 192.168.108.114/0 355 155198 0 0 0 367 ip 0.0.0.0/0 XX.XX.X84.210/0 62 24848 0 0 0 386 ip 0.0.0.0/0 10.168.104.210/0 5963 7888375 0 0 1 402 ip 0.0.0.0/0 10.168.28.194/0 19162 22434649 0 0 106 403 ip 0.0.0.0/0 10.168.28.195/0 1212 1107705 7 10360 37 411 ip 0.0.0.0/0 XX.XX.X88.38/0 1534 219004 0 0 0 434 ip 0.0.0.0/0 10.168.108.226/0 2080 2660808 0 0 0 439 ip 0.0.0.0/0 XX.XX.X84.10/0 141 16334 0 0 0 495 ip 0.0.0.0/0 XX.XX.X84.82/0 377 43721 0 0 0 497 ip 0.0.0.0/0 XX.XX.X88.76/0 6 384 0 0 0 499 ip 0.0.0.0/0 XX.XX.X84.78/0 1568 1102669 0 0 0 50084: 4.300 Mbit/s 0 ms 50 sl. 8 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 72 ip 0.0.0.0/0 XX.XX.X89.245/0 133 11129 0 0 0 117 ip 0.0.0.0/0 XX.XX.X89.200/0 146523 103707547 0 0 0 208 ip 0.0.0.0/0 XX.XX.X89.109/0 4402 4734739 0 0 0 209 ip 0.0.0.0/0 XX.XX.X85.108/0 189 11233 0 0 0 226 ip 0.0.0.0/0 XX.XX.X87.95/0 1264 121416 0 0 0 260 ip 0.0.0.0/0 XX.XX.X90.185/0 2 128 0 0 0 387 ip 0.0.0.0/0 XX.XX.X90.62/0 15 672 0 0 0 459 ip 0.0.0.0/0 XX.XX.X90.118/0 2 128 0 0 0 500100: 600.000 Kbit/s 0 ms 50 sl. 13 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 34 ip 0.0.0.0/0 10.168.107.114/0 325 97810 0 0 0 36 ip 0.0.0.0/0 10.168.107.116/0 7072 1379622 2 1540 0 61 ip 0.0.0.0/0 XX.XX.X85.128/0 6 384 0 0 0 82 ip 0.0.0.0/0 192.168.115.2/0 4288 4812802 0 0 0 83 ip 0.0.0.0/0 192.168.115.3/0 9085 9614212 0 0 1 131 ip 0.0.0.0/0 10.168.57.211/0 183 17572 0 0 0 151 ip 0.0.0.0/0 XX.XX.X85.42/0 133 10824 0 0 0 162 ip 0.0.0.0/0 192.168.109.242/0 16547 17339117 33 47850 260 219 ip 0.0.0.0/0 XX.XX.X85.102/0 16212 15364608 0 0 213 258 ip 0.0.0.0/0 10.168.64.82/0 14 1281 0 0 0 386 ip 0.0.0.0/0 10.168.108.210/0 1160 99513 0 0 0 395 ip 0.0.0.0/0 XX.XX.X84.54/0 362 39876 0 0 0 459 ip 0.0.0.0/0 XX.XX.X84.118/0 3303 424207 0 0 0 50087: 1.544 Mbit/s 0 ms 50 sl. 0 queues (512 buckets) droptail burst: 0 Byte 500103: 3.100 Mbit/s 0 ms 50 sl. 10 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 11 ip 0.0.0.0/0 XX.XX.X85.182/0 90 3988 0 0 0 41 ip 0.0.0.0/0 XX.XX.X85.148/0 2 112 0 0 0 64 ip 0.0.0.0/0 192.168.135.17/0 137 31308 0 0 0 66 ip 0.0.0.0/0 192.168.19.18/0 11368 10792024 0 0 0 83 ip 0.0.0.0/0 192.168.135.2/0 233260 333545347 49 72040 15023 85 ip 0.0.0.0/0 192.168.135.4/0 46 28950 0 0 0 274 ip 0.0.0.0/0 192.168.64.66/0 10187 9504138 0 0 49 373 ip 0.0.0.0/0 10.168.26.37/0 9476 3523672 0 0 16 443 ip 0.0.0.0/0 XX.XX.X84.6/0 191 22000 0 0 0 479 ip 0.0.0.0/0 XX.XX.X88.98/0 13 784 0 0 0 50086: 1.032 Mbit/s 0 ms 50 sl. 1 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 491 ip 0.0.0.0/0 XX.XX.X84.86/0 977 457890 0 0 0 50069: 316.000 Kbit/s 0 ms 50 sl. 3 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 234 ip 0.0.0.0/0 XX.XX.X85.87/0 2 128 0 0 0 340 ip 0.0.0.0/0 10.168.52.4/0 914 745282 12 16800 0 467 ip 0.0.0.0/0 XX.XX.X88.110/0 13356 17932955 0 0 75 500102: 2.100 Mbit/s 0 ms 50 sl. 8 queues (512 buckets) droptail burst: 0 Byte mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 56 ip 0.0.0.0/0 XX.XX.X85.133/0 4 160 0 0 0 139 ip 0.0.0.0/0 10.168.173.218/0 80668 61705080 0 0 58 322 ip 0.0.0.0/0 10.168.104.18/0 1 305 0 0 0 388 ip 0.0.0.0/0 10.168.112.212/0 16850 21072219 0 0 0 411 ip 0.0.0.0/0 XX.XX.X84.38/0 1 120 0 0 0 475 ip 0.0.0.0/0 XX.XX.X88.102/0 5981 7509277 0 0 0 487 ip 0.0.0.0/0 XX.XX.X84.90/0 4295 1388802 0 0 0 504 ip 0.0.0.0/0 10.168.52.168/0 1762 1473136 0 0 0 -- Evgenii V Davidov From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 17:37:21 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 DCA4A1065677 for ; Wed, 10 Mar 2010 17:37:21 +0000 (UTC) (envelope-from nino80@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 767D58FC1D for ; Wed, 10 Mar 2010 17:37:20 +0000 (UTC) Received: by fxm23 with SMTP id 23so7404217fxm.3 for ; Wed, 10 Mar 2010 09:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=LEiHcfKGpRGr5Luwpth6eSroSl0jYqgFxUBVs0sY1y8=; b=EPr/75Yxzk5i6dh7pUSeDlQ3hq/ke8XDsVnfTLH4zdmRn6PZABq906QxLglcRJkyI9 FwE+TocjF2gbHZKbxhAUNrO1447XmZskIHuLSXCC8So1JSG5onlPclLUMbl6rRuIEBDq OnEnoFAegqdwI0CyzUb1JSXXHZ5pK25gKrTTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=wWPs1KEDexThEqToZYDbrT3K82DwxMY6ZjS6Pkv/6EQdlT1e07URZ92T3W2/Mc2kr5 dkokSN44IYLjklMXtt06JFv+mjIdR82qYheLOS/190csJHj3lBHIRF3am0wc1TtaB5si tUmRkQJTIrQ9esuQxgnBAS5NbKqbO6CZOpDJM= MIME-Version: 1.0 Received: by 10.223.6.156 with SMTP id 28mr1970614faz.33.1268241185343; Wed, 10 Mar 2010 09:13:05 -0800 (PST) From: n j Date: Wed, 10 Mar 2010 18:12:45 +0100 Message-ID: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: IPFIREWALL_FORWARD 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, 10 Mar 2010 17:37:21 -0000 Hello, although this has probably been asked before, could anyone point me to some relevant information about why fwd/forward requires kernel recompile, i.e. it's not been made a kernel module? This prevents me from using freebsd-update and forces me to upgrade from source which - even though we all like and love building from source, ofcourse :) - is quite more complicated than the binary upgrade. Thanks, -- Nino From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 18:48: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 975D9106564A for ; Wed, 10 Mar 2010 18:48:16 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-7.mx.aerioconnect.net [216.240.47.67]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4D58FC0C for ; Wed, 10 Mar 2010 18:48:16 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o2AIPODC022136; Wed, 10 Mar 2010 10:25:24 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 7A5B32D6011; Wed, 10 Mar 2010 10:25:23 -0800 (PST) Message-ID: <4B97E412.1050506@elischer.org> Date: Wed, 10 Mar 2010 10:25:22 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: n j References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> In-Reply-To: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-ipfw@freebsd.org, FreeBSD Net Subject: Re: IPFIREWALL_FORWARD 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, 10 Mar 2010 18:48:16 -0000 n j wrote: > Hello, > > although this has probably been asked before, could anyone point me to > some relevant information about why fwd/forward requires kernel > recompile, i.e. it's not been made a kernel module? This prevents me > from using freebsd-update and forces me to upgrade from source which - > even though we all like and love building from source, ofcourse :) - > is quite more complicated than the binary upgrade. > > Thanks, because when I first committed it I knew that as it broke some expected behaviour and added some instructions to the path for all incoming and outgoing packets, that if I didn't make it an option, I would never be allowed to commit it.. since then the same reasons have continued.. it adds several tests, not all of which are cheap, to the packet path. We could make is dependent on some sysctl or something to take out the most expensive tests.. but we really need to look at the overall picture of 'extensions' and whether there is a general way to handle them. From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 22:40:29 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 EF1631065672 for ; Wed, 10 Mar 2010 22:40:29 +0000 (UTC) (envelope-from chris@smartt.com) Received: from mailout3.smartt.com (mailout3.smartt.com [69.67.187.28]) by mx1.freebsd.org (Postfix) with ESMTP id D60398FC25 for ; Wed, 10 Mar 2010 22:40:29 +0000 (UTC) Received: from [69.31.174.220] (unknown [69.31.174.220]) by mailout3.smartt.com (Postfix) with ESMTPA id 01F7810E45E; Wed, 10 Mar 2010 14:41:03 -0800 (PST) Message-ID: <4B981FE5.5090905@smartt.com> Date: Wed, 10 Mar 2010 14:40:37 -0800 From: Chris St Denis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Julian Elischer References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> <4B97E412.1050506@elischer.org> In-Reply-To: <4B97E412.1050506@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: n j , FreeBSD Net , freebsd-ipfw@freebsd.org Subject: Re: IPFIREWALL_FORWARD 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, 10 Mar 2010 22:40:30 -0000 Julian Elischer wrote: > n j wrote: >> Hello, >> >> although this has probably been asked before, could anyone point me to >> some relevant information about why fwd/forward requires kernel >> recompile, i.e. it's not been made a kernel module? This prevents me >> from using freebsd-update and forces me to upgrade from source which - >> even though we all like and love building from source, ofcourse :) - >> is quite more complicated than the binary upgrade. >> >> Thanks, > > because when I first committed it I knew that as it broke some > expected behaviour and added some instructions to the path for > all incoming and outgoing packets, that if I didn't make it > an option, I would never be allowed to commit it.. > > since then the same reasons have continued.. > it adds several tests, not all of which are cheap, > to the packet path. > > We could make is dependent on some sysctl > or something to take out the most expensive tests.. > but we really need to look at the overall picture of 'extensions' > and whether there is a general way to handle them. Is there some reason why it can't just be made a loadable module? -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses" From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 10 23:18:13 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 AEF84106566B; Wed, 10 Mar 2010 23:18:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-12.mx.aerioconnect.net [216.240.47.72]) by mx1.freebsd.org (Postfix) with ESMTP id 8FAF78FC14; Wed, 10 Mar 2010 23:18:13 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o2ANICaA015437; Wed, 10 Mar 2010 15:18:12 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id A5CBD2D6018; Wed, 10 Mar 2010 15:18:11 -0800 (PST) Message-ID: <4B9828B2.2010903@elischer.org> Date: Wed, 10 Mar 2010 15:18:10 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Chris St Denis References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> <4B97E412.1050506@elischer.org> <4B981FE5.5090905@smartt.com> In-Reply-To: <4B981FE5.5090905@smartt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: n j , freebsd-ipfw@freebsd.org, FreeBSD Net Subject: Re: IPFIREWALL_FORWARD 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, 10 Mar 2010 23:18:13 -0000 Chris St Denis wrote: > Julian Elischer wrote: >> n j wrote: >>> Hello, >>> >>> although this has probably been asked before, could anyone point me to >>> some relevant information about why fwd/forward requires kernel >>> recompile, i.e. it's not been made a kernel module? This prevents me >>> from using freebsd-update and forces me to upgrade from source which - >>> even though we all like and love building from source, ofcourse :) - >>> is quite more complicated than the binary upgrade. >>> >>> Thanks, >> >> because when I first committed it I knew that as it broke some >> expected behaviour and added some instructions to the path for >> all incoming and outgoing packets, that if I didn't make it >> an option, I would never be allowed to commit it.. >> >> since then the same reasons have continued.. >> it adds several tests, not all of which are cheap, >> to the packet path. >> >> We could make is dependent on some sysctl >> or something to take out the most expensive tests.. >> but we really need to look at the overall picture of 'extensions' >> and whether there is a general way to handle them. > Is there some reason why it can't just be made a loadable module? > A loadable module requires a coherent piece of code to implement the functionality, that can be put into the module. This option scatters tiny snippets of code throughout the exisitng TCP/UDP/IP/ipfw code. From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 11 08:47:32 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 589FA106566C for ; Thu, 11 Mar 2010 08:47:32 +0000 (UTC) (envelope-from nino80@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id DA5A68FC19 for ; Thu, 11 Mar 2010 08:47:31 +0000 (UTC) Received: by fxm23 with SMTP id 23so8021550fxm.3 for ; Thu, 11 Mar 2010 00:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=2ewmpRQBouqaUN/EsNq1u5byXKspG5SWAZVeBxAAKyo=; b=veinvRrJDRhIeAN4+mZw471Spzy3K0pZtzhp5EUxnITNR0uQW2Fn8aSoabPJYpVjS+ NFsN2Bpm/W3YwLBfFn5Bl6tNqcsOn/WQ3ahtJZPLm04UcoM85XV12dZa5bBaxNpvIPDx 7sCFJ6sCS6dSSJA7EJLiUq2IjCC2gKVZ7+oO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=AVhzRFN8u5v0KWZ8MsLn2ousxJ6/SYBGBromNyDGX37jisHF2BYpAlK5Jjk/wRpE5z Q/6EyRC3dYGosFJmmVDZlpVe/+dSGHc7/Gfx0TZW3owuYtQsgo8E3B4tZz8/qcgfF5Ft gYeFyiEjuVXLNqpNEqE59HzqEcbXHKp6pXmJ0= MIME-Version: 1.0 Received: by 10.102.169.26 with SMTP id r26mr608269mue.27.1268297250711; Thu, 11 Mar 2010 00:47:30 -0800 (PST) In-Reply-To: <4B9828B2.2010903@elischer.org> References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> <4B97E412.1050506@elischer.org> <4B981FE5.5090905@smartt.com> <4B9828B2.2010903@elischer.org> From: n j Date: Thu, 11 Mar 2010 09:47:10 +0100 Message-ID: <92bcbda51003110047s717bed1bq8bb3eb787eab47f7@mail.gmail.com> To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: IPFIREWALL_FORWARD 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, 11 Mar 2010 08:47:32 -0000 > A loadable module requires a coherent piece of code to implement the > functionality, that can be put into the module. This option > scatters tiny snippets of code throughout the exisitng > TCP/UDP/IP/ipfw code. Is that just a matter of current implementation or is that 'scatter' necessary for forward functionality? -- Nino From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 11 10:19:21 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 2A5C81065672 for ; Thu, 11 Mar 2010 10:19:21 +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 9E4208FC08 for ; Thu, 11 Mar 2010 10:19:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o2BAJHsL005606; Thu, 11 Mar 2010 21:19:18 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 11 Mar 2010 21:19:17 +1100 (EST) From: Ian Smith To: n j In-Reply-To: <92bcbda51003110047s717bed1bq8bb3eb787eab47f7@mail.gmail.com> Message-ID: <20100311195520.W85436@sola.nimnet.asn.au> References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> <4B97E412.1050506@elischer.org> <4B981FE5.5090905@smartt.com> <4B9828B2.2010903@elischer.org> <92bcbda51003110047s717bed1bq8bb3eb787eab47f7@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFIREWALL_FORWARD 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, 11 Mar 2010 10:19:21 -0000 On Thu, 11 Mar 2010, n j wrote: > > A loadable module requires a coherent piece of code to implement the > > functionality, that can be put into the module. This option > > scatters tiny snippets of code throughout the exisitng > > TCP/UDP/IP/ipfw code. > > Is that just a matter of current implementation or is that 'scatter' > necessary for forward functionality? I think what Julian's saying is that adding (ipfw-specific) forwarding code to that many code paths in the stack has been deemed too expensive to have it be costing execution time when it's not being used. If 'the stack' was a monolithic thing that could be loaded as a module, then loading different builds of it may be feasible .. but it isn't :) % grep -RHi IPFIREWALL_FORWARD /sys/ to scope the job of including it. I've no idea how costly wrapping that code with sysctl tests rather than ifdefs might be - maybe worth a test? - but there's always going to be pressure to maximise packet flows .. my 2 bob, Ian From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 11 17:56:59 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 1BC9710657CC for ; Thu, 11 Mar 2010 17:56:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-30.mx.aerioconnect.net [216.240.47.90]) by mx1.freebsd.org (Postfix) with ESMTP id F286B8FC1D for ; Thu, 11 Mar 2010 17:56:58 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o2BHuv2q002022; Thu, 11 Mar 2010 09:56:57 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 7B3DB2D601B; Thu, 11 Mar 2010 09:56:57 -0800 (PST) Message-ID: <4B992EE8.30309@elischer.org> Date: Thu, 11 Mar 2010 09:56:56 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: n j References: <92bcbda51003100912k25facb5cxc9047105c91a4022@mail.gmail.com> <4B97E412.1050506@elischer.org> <4B981FE5.5090905@smartt.com> <4B9828B2.2010903@elischer.org> <92bcbda51003110047s717bed1bq8bb3eb787eab47f7@mail.gmail.com> In-Reply-To: <92bcbda51003110047s717bed1bq8bb3eb787eab47f7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFIREWALL_FORWARD 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, 11 Mar 2010 17:56:59 -0000 n j wrote: >> A loadable module requires a coherent piece of code to implement the >> functionality, that can be put into the module. This option >> scatters tiny snippets of code throughout the exisitng >> TCP/UDP/IP/ipfw code. > > Is that just a matter of current implementation or is that 'scatter' > necessary for forward functionality? it's needed for the functionality. you need to slightly change the behaviour or the existing stack in quite a number of places to handle a forwarded packet. From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 12 15:34:35 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 C81421065673 for ; Fri, 12 Mar 2010 15:34:35 +0000 (UTC) (envelope-from dado@cnt.korolev-net.ru) Received: from cnt.korolev-net.ru (mail.web-korolev.ru [89.222.188.140]) by mx1.freebsd.org (Postfix) with ESMTP id 81A978FC08 for ; Fri, 12 Mar 2010 15:34:34 +0000 (UTC) Received: by cnt.korolev-net.ru (Postfix, from userid 100) id A81FE2AC7C6; Fri, 12 Mar 2010 18:34:29 +0300 (MSK) Date: Fri, 12 Mar 2010 18:34:29 +0300 From: Evgenii Davidov To: freebsd-ipfw@freebsd.org Message-ID: <20100312153429.GA88435@korolev-net.ru> References: <20091027074022.GE88744@korolev-net.ru> <20091027162924.GF88744@korolev-net.ru> <20100310153303.GB62866@korolev-net.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100310153303.GB62866@korolev-net.ru> User-Agent: Mutt/1.4.2.1i Subject: Re: dummynet cpu usage 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: Fri, 12 Mar 2010 15:34:35 -0000 Dear Luigi, i've moved from RELENG_8 to RELENG_8_0 and now have a lot of idle cpu again: 0 root -68 0 0K 72K - 0 0:31 0.00% {dummynet} 00030 2671994 474106017 pipe 6 ip from table(111) to any out xmit em0 00040 4495521 2942321163 pipe tablearg ip from any to table(2) in recv em0 ipfw pipe show | wc -l 504 On Wed, Mar 10, 2010 at 06:33:04PM +0300, Evgenii Davidov ÐÉÛÅÔ: > úÄÒÁ×ÓÔ×ÕÊÔÅ, > > got the same problem again, now on freebsd8: > > rebuilded kernel today, and after it, on the same configuration dummunet began to eat a lot of cpu: > > 0 root -68 0 0K 72K - 0 119:34 0.78% {dummynet} > 0 root -68 0 0K 72K - 0 119:39 6.98% {dummynet} > 0 root -68 0 0K 72K - 1 220:31 0.10% {dummynet} > 0 root -68 0 0K 72K - 0 220:34 0.59% {dummynet} > 0 root -68 0 0K 72K - 0 220:38 0.68% {dummynet} > 0 root -68 0 0K 72K - 1 0:00 7.47% {dummynet} > 0 root -68 0 0K 72K - 0 0:01 57.08% {dummynet} > 0 root -68 0 0K 72K - 1 0:02 63.87% {dummynet} > 0 root -68 0 0K 72K - 0 0:03 42.87% {dummynet} > 0 root -68 0 0K 72K - 1 0:03 46.29% {dummynet} > 0 root -68 0 0K 72K - 0 0:04 76.17% {dummynet} > > (it's a log of a top -SHI every minute) > > the previous kernel was build a month ago > -- Evgenii V Davidov From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 12 15:56:45 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 B0A2B106566C for ; Fri, 12 Mar 2010 15:56:45 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 74D148FC08 for ; Fri, 12 Mar 2010 15:56:44 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id EE001730A1; Fri, 12 Mar 2010 17:06:21 +0100 (CET) Date: Fri, 12 Mar 2010 17:06:21 +0100 From: Luigi Rizzo To: Evgenii Davidov Message-ID: <20100312160621.GA22985@onelab2.iet.unipi.it> References: <20091027074022.GE88744@korolev-net.ru> <20091027162924.GF88744@korolev-net.ru> <20100310153303.GB62866@korolev-net.ru> <20100312153429.GA88435@korolev-net.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100312153429.GA88435@korolev-net.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: dummynet cpu usage 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: Fri, 12 Mar 2010 15:56:45 -0000 On Fri, Mar 12, 2010 at 06:34:29PM +0300, Evgenii Davidov wrote: > Dear Luigi, > > i've moved from RELENG_8 to RELENG_8_0 and now have a lot of idle cpu again: > > 0 root -68 0 0K 72K - 0 0:31 0.00% {dummynet} > > 00030 2671994 474106017 pipe 6 ip from table(111) to any out xmit em0 > 00040 4495521 2942321163 pipe tablearg ip from any to table(2) in recv em0 i am not sure how you can tell the problem is gone since you seem to have the same problem before 8.0 and after 8.0 and there is nothing that i can think of that was added and removed (or vice-versa) just for a brief window around 8.0 This said, a comment on your ruleset: you should put the cheap options (such as "in", "out", "recv" and "xmit") before the expensive ones ("from table(X)" or "to table(X)" ), so you can avoid the latter if one of the previous checks fails. Table lookups are costly (anywhere from 200ns to 1us depending on circumstances), whereas things such as "in" and "out" cost 20-30ns. cheers luigi > ipfw pipe show | wc -l > 504 > > On Wed, Mar 10, 2010 at 06:33:04PM +0300, Evgenii Davidov ?????: > > > ????????????, > > > > got the same problem again, now on freebsd8: > > > > rebuilded kernel today, and after it, on the same configuration dummunet began to eat a lot of cpu: > > > > 0 root -68 0 0K 72K - 0 119:34 0.78% {dummynet} > > 0 root -68 0 0K 72K - 0 119:39 6.98% {dummynet} > > 0 root -68 0 0K 72K - 1 220:31 0.10% {dummynet} > > 0 root -68 0 0K 72K - 0 220:34 0.59% {dummynet} > > 0 root -68 0 0K 72K - 0 220:38 0.68% {dummynet} > > 0 root -68 0 0K 72K - 1 0:00 7.47% {dummynet} > > 0 root -68 0 0K 72K - 0 0:01 57.08% {dummynet} > > 0 root -68 0 0K 72K - 1 0:02 63.87% {dummynet} > > 0 root -68 0 0K 72K - 0 0:03 42.87% {dummynet} > > 0 root -68 0 0K 72K - 1 0:03 46.29% {dummynet} > > 0 root -68 0 0K 72K - 0 0:04 76.17% {dummynet} > > > > (it's a log of a top -SHI every minute) > > > > the previous kernel was build a month ago > > > > -- > Evgenii V Davidov > _______________________________________________ > 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" From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 12 16:50:39 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 8AFCA1065670 for ; Fri, 12 Mar 2010 16:50:39 +0000 (UTC) (envelope-from dado@cnt.korolev-net.ru) Received: from cnt.korolev-net.ru (mail.web-korolev.ru [89.222.188.140]) by mx1.freebsd.org (Postfix) with ESMTP id 444258FC0A for ; Fri, 12 Mar 2010 16:50:38 +0000 (UTC) Received: by cnt.korolev-net.ru (Postfix, from userid 100) id B27792AC6BA; Fri, 12 Mar 2010 19:50:34 +0300 (MSK) Date: Fri, 12 Mar 2010 19:50:34 +0300 From: Evgenii Davidov To: freebsd-ipfw@freebsd.org Message-ID: <20100312165034.GA96357@korolev-net.ru> References: <20091027074022.GE88744@korolev-net.ru> <20091027162924.GF88744@korolev-net.ru> <20100310153303.GB62866@korolev-net.ru> <20100312153429.GA88435@korolev-net.ru> <20100312160621.GA22985@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100312160621.GA22985@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.1i Subject: Re: dummynet cpu usage 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: Fri, 12 Mar 2010 16:50:39 -0000 úÄÒÁ×ÓÔ×ÕÊÔÅ, On Fri, Mar 12, 2010 at 05:06:21PM +0100, Luigi Rizzo ÐÉÛÅÔ: > > i've moved from RELENG_8 to RELENG_8_0 and now have a lot of idle cpu again: > > > > 0 root -68 0 0K 72K - 0 0:31 0.00% {dummynet} > > i am not sure how you can tell the problem is gone since > you seem to have the same problem before 8.0 and after 8.0 > and there is nothing that i can think of that was added and > removed (or vice-versa) just for a brief window around 8.0 i have to say that after that i had to return back to RELENG_8 (ther is a problem with mpd on RELENG_8_0) i have rebuild only kernel, without world and after reboot i see again a zero cpu usage by dummynet..! pipes are working -- i checked it's some kind of magic :( > This said, a comment on your ruleset: thank you very much, i'll think about it! -- Evgenii V Davidov