From owner-freebsd-ipfw@FreeBSD.ORG Mon May 2 11:07:01 2011 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 4A5EF106567C for ; Mon, 2 May 2011 11:07:01 +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 38CB58FC1C for ; Mon, 2 May 2011 11:07:01 +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 p42B714j064120 for ; Mon, 2 May 2011 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p42B70Ka064118 for freebsd-ipfw@FreeBSD.org; Mon, 2 May 2011 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 May 2011 11:07:00 GMT Message-Id: <201105021107.p42B70Ka064118@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, 02 May 2011 11:07:01 -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 bin/156653 ipfw ipfw(8) reports missing file as parameter problem o kern/156410 ipfw [patch][ipfw] tablearg option for ipfw setfib o kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw IPFIREWALL does not allow specify rules with ICMP code p kern/152887 ipfw [ipfw] Can not set more then 1024 buckets with buckets o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/150798 ipfw [ipfw] ipfw2 fwd rule matches packets but does not do o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148157 ipfw [ipfw] IPFW in kernel nat BUG found in FreeBSD 8.1-PRE o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/147720 ipfw [ipfw] ipfw dynamic rules and fwd o kern/145305 ipfw [ipfw] ipfw problems, panics, data corruption, ipv6 so 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/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/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 o kern/122109 ipfw [ipfw] ipfw nat traceroute problem 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 (corr 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 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/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 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 78 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon May 2 12:00:31 2011 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 0E847106571C for ; Mon, 2 May 2011 12:00:31 +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 D72E78FC12 for ; Mon, 2 May 2011 12:00:30 +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 p42C0UaN015698 for ; Mon, 2 May 2011 12:00:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p42C0Uma015690; Mon, 2 May 2011 12:00:30 GMT (envelope-from gnats) Date: Mon, 2 May 2011 12:00:30 GMT Message-Id: <201105021200.p42C0Uma015690@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Andrey V. Elsukov" Cc: Subject: Re: bin/156653: ipfw(8) reports missing file as parameter problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Andrey V. Elsukov" List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 12:00:31 -0000 The following reply was made to PR bin/156653; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-followup@FreeBSD.org, jclear@speakeasy.net Cc: Subject: Re: bin/156653: ipfw(8) reports missing file as parameter problem Date: Mon, 02 May 2011 15:59:16 +0400 Hi, It seems it never worked in the way you are trying. You should use absolute path name for the last argument, e.g. # ipfw -n -p cpp /etc/new.rules -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Mon May 2 22:50:15 2011 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 065111065674 for ; Mon, 2 May 2011 22:50:15 +0000 (UTC) (envelope-from korodev@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7C248FC1A for ; Mon, 2 May 2011 22:50:14 +0000 (UTC) Received: by iwn33 with SMTP id 33so7058565iwn.13 for ; Mon, 02 May 2011 15:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=cRRyfdFeiOCMukijyUVFdbmMxxdFRIRLh8q5oD1A5t0=; b=uqWd6CAZ/D05fKr36KEnweOdOb+k3b7Gct+IrRW/AYCdBOMPDRf0msrwhpJB22I0MU lNwvgK28JVWuNn7eGdyG8W5xjBaT119PMkKkEGCqdAppob/fZmPNXfCNHU4JFr9gfkRG yhzt7/OwWRvz+0Tf1Gp4zX6WdZVlWG1ba7pU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=qs0Gd1eQJJx39pY2u3itgFjdNyZTbd5GzS6xs7MRg82SpumYMbeVDneFKGBpUoXPm2 mwgBSl5UKo1w1TK3AUXoFJyL/+towajkJb1RDcFtXIEMr5dUsPaVmGwMnom2940017RP SNk+EZgMLWseLXxlnJ4j6vGv6B+7BlMBXxTkY= Received: by 10.231.81.18 with SMTP id v18mr6759580ibk.42.1304374792102; Mon, 02 May 2011 15:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.128.140 with HTTP; Mon, 2 May 2011 15:19:32 -0700 (PDT) From: Korodev Date: Mon, 2 May 2011 17:19:32 -0500 Message-ID: To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: IPFW Table Insertion in C, Dummynet, and an interesting problem. 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, 02 May 2011 22:50:15 -0000 Hey guys, I'm currently running some custom C code ,via an output plugin for Snort, which takes an IP and sticks it in an ipfw table. Once the packet enters the box, I'm using dummynet to delay the packet while snort analyzes it and inserts the IP into a table, after the piping delay is complete the rule is reinserted at the appropriate point and checked via a deny table lookup rule. I've done some fairly extensive testing which has led me here. I believe I'm either doing my IPFW insertion wrong, or there's a bug or tuning setting I'm unaware of. I'd be delighted if you guys could take the time to look through my explanation below and let me know if anything comes to mind :) First my physical setup is as follows: Pinger --> { eth 0 --> bridge0 --> eth1 } --> Host #My Freebsd/IPFW setup: FreeBSD 8.2, net.link.bridge.ipfw=1, net.inet.ip.fw.one_pass=0 #IPFW Ruleset 00100 count icmp from any to any 00300 pipe 1 icmp from any to any //pipe is configured with config delay 150ms 00400 deny log ip from any to any src-ip table(0) 00500 count icmp from any to any #IPFW C Insertion Code .... #include #include //data is a custom struct data->s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); data->ent.tbl = 0; data->ent.value = 0; data->ent.masklen = 32; data->ip.s_addr = p->iph->ip_src.s_addr; memcpy(&(data->ent.addr), &(data->ip), sizeof(struct in_addr)); setsockopt(data->s, IPPROTO_IP, IP_FW_TABLE_ADD, &(data->ent), sizeof(data->ent)); ... This is slightly simplified for this test case, but it's important to know the insertion works, just not in less than 150ms. (~200ms actually). I've been talking to the Snort guys a bit, and I won't post my snort conf here, but please take my word that it's quite stripped down. My test case as follows, consisingt of a sending a single ICMP ping packet from Pinger to Host. In theory, Snort, listening passively on eth0 (libpcap 1.1.1), will alert on the ICMP ping to Host insert. . I conducted the following timing tests using tcpdump, Snort's performance profiling, and my own C timing code. Here are my results: tcpdump shows that the packet hits eth0 at 51.647347 seconds, bridge0 at 51.647350 seconds, and the exit interface, eth1, at 51.797320. This (as expected) equates to 149.97300 milliseconds of time. Snort is passively listening on the eth0 interface using the pcap daq module. It's configured to spend a maximum time of 250 microseconds before triggering my output plugin. Using some C timing methods on the output plugin code above says that grabbing the IP and sending it to the IPFW socket (which is cached and already open at that point), takes about 7.8120 milliseconds (1 CPU tick). Since that's where I call setsockopt, the it just sits in the pipe for the remaining time, but upon falling to the next rule (deny src-ip table 0), it misses the check. The count rule following my deny rule verifies that the rule did reach the deny table rule. There's only one untested spot that I can see, and that's the time between I actually make the insertion via setsockopt and the time IPFW "actually" update the table in memory. All of my other operations are executing with testable and consistent speeds, which are FAR less than a 150 millisecond dummynet pipe. Am I inserting the IP into the table correctly? Is there another command I need to call to force IPFW to update the table faster? Or perhaps there's some kernel tuning I'm unaware of? If you've made it this far, then thanks for taking the time to read this and please let me know if you have thoughts on why the IP isn't making it in the table fast enough. If more info is needed, I'll be happy to provide it :) Thanks, \\korodev From owner-freebsd-ipfw@FreeBSD.ORG Mon May 2 23:22:59 2011 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 073B91065676 for ; Mon, 2 May 2011 23:22:59 +0000 (UTC) (envelope-from michael.scheidell@secnap.com) Received: from mx1.secnap.com.ionspam.net (mx1.secnap.com.ionspam.net [204.89.241.253]) by mx1.freebsd.org (Postfix) with ESMTP id C3AB88FC0A for ; Mon, 2 May 2011 23:22:58 +0000 (UTC) Received: from mx1.secnap.com.ionspam.net (mx1.secnap.com.ionspam.net [10.70.1.253]) by mx1.secnap.com.ionspam.net (Postfix) with ESMTP id 8EF0D2B7D36; Mon, 2 May 2011 19:01:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secnap.com; h= mime-version:content-transfer-encoding:content-id:content-type :content-type:content-language:accept-language:in-reply-to :references:message-id:date:date:subject:subject:from:from; s= dkim; t=1304377288; x=1306191688; bh=lj6FPNVxI7yDahzyN054ULX/Rfl VvK+tULxlxkXjIkQ=; b=QogBk/DFmt5tT/yPY5EsLDBTcxCxvBc13teIqYB3bl8 +p1HPVGvGf7brHLwU0W265OIwfZxv2sYYlEq9evfwioCb5hwC3eouZ2MLQHIOOaI hyGbX8N5/1kxY+PFqfLIf/QnWENnT3s45ge9BzKFKpsHeVyP0i3FUcgRJyI8y8mE = X-Amavis-Modified: Mail body modified (using disclaimer) - mx1.secnap.com.ionspam.net X-Virus-Scanned: SpammerTrap(r) VPS-1500 2.14 at mx1.secnap.com.ionspam.net Received: from USBCTDC001.secnap.com (usbctdc001.secnap.com [10.70.1.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.secnap.com.ionspam.net (Postfix) with ESMTPS id 663572B7D34; Mon, 2 May 2011 19:01:28 -0400 (EDT) Received: from USBCTDC001.secnap.com ([10.70.1.1]) by USBCTDC001 ([10.70.1.1]) with mapi; Mon, 2 May 2011 19:01:28 -0400 From: Michael Scheidell To: Korodev , "freebsd-ipfw@freebsd.org" Thread-Topic: IPFW Table Insertion in C, Dummynet, and an interesting problem. Thread-Index: AcwJHN4ZIg8nGnn1Jka7ENACzwR2fQ== Date: Mon, 2 May 2011 23:01:42 +0000 Message-ID: References: <220d2ec0-887b-4b03-a66c-8af7a0b25b13@blur> In-Reply-To: <220d2ec0-887b-4b03-a66c-8af7a0b25b13@blur> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <4ae36c64-b45b-4861-950b-c106aa3ab786> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Subject: Re: IPFW Table Insertion in C, Dummynet, and an interesting problem. 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, 02 May 2011 23:22:59 -0000 WW91IG1pZ2h0IGFsc28gdGFsayB0byBKSiBAIHNvdXJjZWZpcmUuICBXb3JraW5nIG9uIGdldHRp bmcgc25vcnQgaW5saW5lIHRvIHdvcmsgd2l0aCBpZl9icmlkZ2UuDQoNCi0tDQpNaWNoYWVsIFNj aGVpZGVsbA0KQ1RPIFNFQ05BUCBOZXR3b3JrIFNlY3VyaXR5DQo1NjEtOTQ4LTIyNTk8dGVsOjU2 MTk0ODIyNTk+DQoNCg0KLS0tLS1PcmlnaW5hbCBtZXNzYWdlLS0tLS0NCkZyb206IEtvcm9kZXYg PGtvcm9kZXZAZ21haWwuY29tPg0KVG86ICJmcmVlYnNkLWlwZndAZnJlZWJzZC5vcmciIDxmcmVl YnNkLWlwZndAZnJlZWJzZC5vcmc+DQpTZW50OiBNb24sIE1heSAyLCAyMDExIDIyOjUwOjMxIEdN VCswMDowMA0KU3ViamVjdDogSVBGVyBUYWJsZSBJbnNlcnRpb24gaW4gQywgRHVtbXluZXQsIGFu ZCBhbiBpbnRlcmVzdGluZyBwcm9ibGVtLg0KDQpIZXkgZ3V5cywNCg0KSSdtIGN1cnJlbnRseSBy dW5uaW5nIHNvbWUgY3VzdG9tIEMgY29kZSAsdmlhIGFuIG91dHB1dCBwbHVnaW4gZm9yDQpTbm9y dCwgd2hpY2ggdGFrZXMgYW4gSVAgYW5kIHN0aWNrcyBpdCBpbiBhbiBpcGZ3IHRhYmxlLiBPbmNl IHRoZQ0KcGFja2V0IGVudGVycyB0aGUgYm94LCBJJ20gdXNpbmcgZHVtbXluZXQgdG8gZGVsYXkg dGhlIHBhY2tldCB3aGlsZQ0Kc25vcnQgYW5hbHl6ZXMgaXQgYW5kIGluc2VydHMgdGhlIElQIGlu dG8gYSB0YWJsZSwgYWZ0ZXIgdGhlIHBpcGluZw0KZGVsYXkgaXMgY29tcGxldGUgdGhlIHJ1bGUg aXMgcmVpbnNlcnRlZCBhdCB0aGUgYXBwcm9wcmlhdGUgcG9pbnQgYW5kDQpjaGVja2VkIHZpYSBh IGRlbnkgdGFibGUgbG9va3VwIHJ1bGUuICBJJ3ZlIGRvbmUgc29tZSBmYWlybHkgZXh0ZW5zaXZl DQp0ZXN0aW5nIHdoaWNoIGhhcyBsZWQgbWUgaGVyZS4gSSBiZWxpZXZlIEknbSBlaXRoZXIgZG9p bmcgbXkgSVBGVw0KaW5zZXJ0aW9uIHdyb25nLCBvciB0aGVyZSdzIGEgYnVnIG9yIHR1bmluZyBz ZXR0aW5nIEknbSB1bmF3YXJlIG9mLg0KSSdkIGJlIGRlbGlnaHRlZCBpZiB5b3UgZ3V5cyBjb3Vs ZCB0YWtlIHRoZSB0aW1lIHRvIGxvb2sgdGhyb3VnaCBteQ0KZXhwbGFuYXRpb24gYmVsb3cgYW5k IGxldCBtZSBrbm93IGlmIGFueXRoaW5nIGNvbWVzIHRvIG1pbmQgOikNCg0KRmlyc3QgbXkgcGh5 c2ljYWwgc2V0dXAgaXMgYXMgZm9sbG93czoNCg0KUGluZ2VyIC0tPiB7IGV0aCAwIC0tPiBicmlk Z2UwIC0tPiBldGgxIH0gLS0+IEhvc3QNCg0KI015IEZyZWVic2QvSVBGVyBzZXR1cDoNCg0KRnJl ZUJTRCA4LjIsIG5ldC5saW5rLmJyaWRnZS5pcGZ3PTEsIG5ldC5pbmV0LmlwLmZ3Lm9uZV9wYXNz PTANCg0KI0lQRlcgUnVsZXNldA0KDQowMDEwMCBjb3VudCBpY21wIGZyb20gYW55IHRvIGFueQ0K MDAzMDAgcGlwZSAxIGljbXAgZnJvbSBhbnkgdG8gYW55IC8vcGlwZSBpcyBjb25maWd1cmVkIHdp dGggY29uZmlnIGRlbGF5IDE1MG1zDQowMDQwMCBkZW55IGxvZyBpcCBmcm9tIGFueSB0byBhbnkg c3JjLWlwIHRhYmxlKDApDQowMDUwMCBjb3VudCBpY21wIGZyb20gYW55IHRvIGFueQ0KDQojSVBG VyBDIEluc2VydGlvbiBDb2RlDQoNCi4uLi4NCiNpbmNsdWRlIDxuZXQvaWYuaD4NCiNpbmNsdWRl IDxuZXRpbmV0L2lwX2Z3Lmg+DQoNCi8vZGF0YSBpcyBhIGN1c3RvbSBzdHJ1Y3QNCiBkYXRhLT5z ID0gc29ja2V0KEFGX0lORVQsIFNPQ0tfUkFXLCBJUFBST1RPX1JBVyk7DQogZGF0YS0+ZW50LnRi bCA9IDA7DQogZGF0YS0+ZW50LnZhbHVlID0gMDsNCiBkYXRhLT5lbnQubWFza2xlbiA9IDMyOw0K DQpkYXRhLT5pcC5zX2FkZHIgPSBwLT5pcGgtPmlwX3NyYy5zX2FkZHI7DQptZW1jcHkoJihkYXRh LT5lbnQuYWRkciksICYoZGF0YS0+aXApLCBzaXplb2Yoc3RydWN0IGluX2FkZHIpKTsNCnNldHNv Y2tvcHQoZGF0YS0+cywgSVBQUk9UT19JUCwgSVBfRldfVEFCTEVfQURELCAmKGRhdGEtPmVudCks DQpzaXplb2YoZGF0YS0+ZW50KSk7DQouLi4NCg0KVGhpcyBpcyBzbGlnaHRseSBzaW1wbGlmaWVk IGZvciB0aGlzIHRlc3QgY2FzZSwgYnV0IGl0J3MgaW1wb3J0YW50IHRvDQprbm93IHRoZSBpbnNl cnRpb24gd29ya3MsIGp1c3Qgbm90IGluIGxlc3MgdGhhbiAxNTBtcy4gKH4yMDBtcw0KYWN0dWFs bHkpLiBJJ3ZlIGJlZW4gdGFsa2luZyB0byB0aGUgU25vcnQgZ3V5cyBhIGJpdCwgYW5kIEkgd29u J3QgcG9zdA0KbXkgc25vcnQgY29uZiBoZXJlLCBidXQgcGxlYXNlIHRha2UgbXkgd29yZCB0aGF0 IGl0J3MgcXVpdGUgc3RyaXBwZWQNCmRvd24uIE15IHRlc3QgY2FzZSBhcyBmb2xsb3dzLCBjb25z aXNpbmd0IG9mIGEgc2VuZGluZyBhIHNpbmdsZSBJQ01QDQpwaW5nIHBhY2tldCBmcm9tIFBpbmdl ciB0byBIb3N0LiBJbiB0aGVvcnksIFNub3J0LCBsaXN0ZW5pbmcgcGFzc2l2ZWx5DQpvbiBldGgw IChsaWJwY2FwIDEuMS4xKSwgd2lsbCBhbGVydCBvbiB0aGUgSUNNUCBwaW5nIHRvIEhvc3QgaW5z ZXJ0LiAuDQpJIGNvbmR1Y3RlZCB0aGUgZm9sbG93aW5nIHRpbWluZyB0ZXN0cyB1c2luZyB0Y3Bk dW1wLCBTbm9ydCdzDQpwZXJmb3JtYW5jZSBwcm9maWxpbmcsIGFuZCBteSBvd24gQyB0aW1pbmcg Y29kZS4gSGVyZSBhcmUgbXkgcmVzdWx0czoNCg0KdGNwZHVtcCBzaG93cyB0aGF0IHRoZSBwYWNr ZXQgaGl0cyBldGgwIGF0IDUxLjY0NzM0NyBzZWNvbmRzLCBicmlkZ2UwDQphdCA1MS42NDczNTAg c2Vjb25kcywgYW5kIHRoZSBleGl0IGludGVyZmFjZSwgZXRoMSwgYXQgNTEuNzk3MzIwLiBUaGlz DQooYXMgZXhwZWN0ZWQpIGVxdWF0ZXMgdG8gMTQ5Ljk3MzAwIG1pbGxpc2Vjb25kcyBvZiB0aW1l Lg0KDQpTbm9ydCBpcyBwYXNzaXZlbHkgbGlzdGVuaW5nIG9uIHRoZSBldGgwIGludGVyZmFjZSB1 c2luZyB0aGUgcGNhcCBkYXENCm1vZHVsZS4gSXQncyBjb25maWd1cmVkIHRvIHNwZW5kIGEgbWF4 aW11bSB0aW1lIG9mIDI1MCBtaWNyb3NlY29uZHMNCmJlZm9yZSB0cmlnZ2VyaW5nIG15IG91dHB1 dCBwbHVnaW4uIFVzaW5nIHNvbWUgQyB0aW1pbmcgbWV0aG9kcyBvbiB0aGUNCm91dHB1dCBwbHVn aW4gY29kZSBhYm92ZSBzYXlzIHRoYXQgZ3JhYmJpbmcgdGhlIElQIGFuZCBzZW5kaW5nIGl0IHRv DQp0aGUgSVBGVyBzb2NrZXQgKHdoaWNoIGlzIGNhY2hlZCBhbmQgYWxyZWFkeSBvcGVuIGF0IHRo YXQgcG9pbnQpLA0KdGFrZXMgYWJvdXQgNy44MTIwIG1pbGxpc2Vjb25kcyAoMSBDUFUgdGljayku IFNpbmNlIHRoYXQncyB3aGVyZSBJDQpjYWxsIHNldHNvY2tvcHQsIHRoZSBpdCBqdXN0IHNpdHMg aW4gdGhlIHBpcGUgZm9yIHRoZSByZW1haW5pbmcgdGltZSwNCmJ1dCB1cG9uIGZhbGxpbmcgdG8g dGhlIG5leHQgcnVsZSAoZGVueSBzcmMtaXAgdGFibGUgMCksIGl0IG1pc3NlcyB0aGUNCmNoZWNr LiBUaGUgY291bnQgcnVsZSBmb2xsb3dpbmcgbXkgZGVueSBydWxlIHZlcmlmaWVzIHRoYXQgdGhl IHJ1bGUNCmRpZCByZWFjaCB0aGUgZGVueSB0YWJsZSBydWxlLg0KDQpUaGVyZSdzIG9ubHkgb25l IHVudGVzdGVkIHNwb3QgdGhhdCBJIGNhbiBzZWUsIGFuZCB0aGF0J3MgdGhlIHRpbWUNCmJldHdl ZW4gSSBhY3R1YWxseSBtYWtlIHRoZSBpbnNlcnRpb24gdmlhIHNldHNvY2tvcHQgYW5kIHRoZSB0 aW1lIElQRlcNCiJhY3R1YWxseSIgdXBkYXRlIHRoZSB0YWJsZSBpbiBtZW1vcnkuIEFsbCBvZiBt eSBvdGhlciBvcGVyYXRpb25zIGFyZQ0KZXhlY3V0aW5nIHdpdGggdGVzdGFibGUgYW5kIGNvbnNp c3RlbnQgc3BlZWRzLCB3aGljaCBhcmUgRkFSIGxlc3MgdGhhbg0KYSAxNTAgbWlsbGlzZWNvbmQg ZHVtbXluZXQgcGlwZS4NCg0KQW0gSSBpbnNlcnRpbmcgdGhlIElQIGludG8gdGhlIHRhYmxlIGNv cnJlY3RseT8gSXMgdGhlcmUgYW5vdGhlcg0KY29tbWFuZCBJIG5lZWQgdG8gY2FsbCB0byBmb3Jj ZSBJUEZXIHRvIHVwZGF0ZSB0aGUgdGFibGUgZmFzdGVyPyBPcg0KcGVyaGFwcyB0aGVyZSdzIHNv bWUga2VybmVsIHR1bmluZyBJJ20gdW5hd2FyZSBvZj8gSWYgeW91J3ZlIG1hZGUgaXQNCnRoaXMg ZmFyLCB0aGVuIHRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHJlYWQgdGhpcyBhbmQgcGxl YXNlIGxldA0KbWUga25vdyBpZiB5b3UgaGF2ZSB0aG91Z2h0cyBvbiB3aHkgdGhlIElQIGlzbid0 IG1ha2luZyBpdCBpbiB0aGUNCnRhYmxlIGZhc3QgZW5vdWdoLiAgSWYgbW9yZSBpbmZvIGlzIG5l ZWRlZCwgSSdsbCBiZSBoYXBweSB0byBwcm92aWRlDQppdCA6KQ0KDQpUaGFua3MsDQoNClxca29y b2Rldg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmZy ZWVic2QtaXBmd0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCmh0dHA6Ly9saXN0cy5mcmVlYnNk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtaXBmdw0KVG8gdW5zdWJzY3JpYmUsIHNlbmQg YW55IG1haWwgdG8gImZyZWVic2QtaXBmdy11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCg== From owner-freebsd-ipfw@FreeBSD.ORG Mon May 2 23:40:10 2011 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 2A3A2106566B for ; Mon, 2 May 2011 23:40:10 +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 410168FC15 for ; Mon, 2 May 2011 23:40: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 p42Ne7sO016554 for ; Mon, 2 May 2011 23:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p42Ne7pe016553; Mon, 2 May 2011 23:40:07 GMT (envelope-from gnats) Date: Mon, 2 May 2011 23:40:07 GMT Message-Id: <201105022340.p42Ne7pe016553@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Jed Clear Cc: Subject: Re: bin/156653: ipfw(8) reports missing file as parameter problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jed Clear List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 23:40:10 -0000 The following reply was made to PR bin/156653; it has been noted by GNATS. From: Jed Clear To: Andrey V. Elsukov Cc: bug-followup@FreeBSD.org Subject: Re: bin/156653: ipfw(8) reports missing file as parameter problem Date: Mon, 2 May 2011 19:24:24 -0400 Actually when I discovered it, I was using an absolute path. -Jed On May 2, 2011, at 7:59 AM, Andrey V. Elsukov wrote: > Hi, > > It seems it never worked in the way you are trying. > You should use absolute path name for the last argument, e.g. > # ipfw -n -p cpp /etc/new.rules > > -- > WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Tue May 3 03:21:21 2011 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 CCA6D106564A for ; Tue, 3 May 2011 03:21:21 +0000 (UTC) (envelope-from 62mkv@mail.ru) Received: from smtp13.mail.ru (smtp13.mail.ru [94.100.176.90]) by mx1.freebsd.org (Postfix) with ESMTP id 5A7C68FC12 for ; Tue, 3 May 2011 03:21:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:To:Message-ID:Reply-To:From:Date; bh=b0IC93fgx70To9Fp2uECQXLr7WMbSdBYciePxBuYE/M=; b=n4zEZH1XRWO7D3YJM6UhpgVGE5KzlaxY/5yllrFHR6n7WXOaaBIIc2LZLdm+p5tLVH5fNNkAGMvPqy2Ckb2HmVz2eexLlr6uBpikdAqCRStHH6Q/3ZofeHuBhUoA4Xra; Received: from [81.201.246.18] (port=51219 helo=RABBIT) by smtp13.mail.ru with asmtp id 1QH6Ao-0000Hu-00 for freebsd-ipfw@freebsd.org; Tue, 03 May 2011 07:21:19 +0400 Date: Tue, 3 May 2011 10:21:17 +0700 From: 62mkv <62mkv@mail.ru> X-Priority: 3 (Normal) Message-ID: <1707514172.20110503102117@mail.ru> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: please help to solve problems with NATting (IPFW+NATD, FreeBSD 8.1) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 62mkv <62mkv@mail.ru> List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 03:21:21 -0000 Hello Freebsd-ipfw, I have already spent around a week to solve this problem. Evidently I miss something crucial for understanding. I have a FreeBSD 8.1 box, 2 NICs, one per LAN (192.168.0.0/24), another per WAN (static global IP) The box itself operates quite well both on LAN and on WAN. According to the console output at startup, NATD starts up OK. the rules script that I think SHOULD work fine for my needs, misbehaves (at least for me) - none of the application from LAN can get access to WAN sites, not ping, no web, nothing But the "ipfw show" displays only "allow" rules matches, as if everything is working. It is then either routing issue, either NATD, how can I localize and solve the problem ? All (I hope so) relevant info is in the zip-archive http://download81.files.mail.ru/P1TYGH/a1f6972cb51c1587b8bf9ec1d59144fb/IPFW.ZIP, please help ! Thanks a lot ! Best wishes, 62mkv mailto: 62mkv@mail.ru From owner-freebsd-ipfw@FreeBSD.ORG Tue May 3 05:10:10 2011 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 2C00B1065673 for ; Tue, 3 May 2011 05:10:10 +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 EF2DD8FC19 for ; Tue, 3 May 2011 05: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 p435A9FP021956 for ; Tue, 3 May 2011 05:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p435A9QI021954; Tue, 3 May 2011 05:10:09 GMT (envelope-from gnats) Date: Tue, 3 May 2011 05:10:09 GMT Message-Id: <201105030510.p435A9QI021954@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/152887: commit references a PR X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 05:10:10 -0000 The following reply was made to PR kern/152887; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/152887: commit references a PR Date: Tue, 3 May 2011 05:09:11 +0000 (UTC) Author: ae Date: Tue May 3 05:09:02 2011 New Revision: 221359 URL: http://svn.freebsd.org/changeset/base/221359 Log: MFC r220831: ipdn_bound_var() function is designed to bound a variable between specified minimum and maximum. In case when specified default value is out of bounds it does not work as expected and does not limit variable. Check that default value is in range and limit it if needed. Also bump max_hash_size value to 65536 to correspond with manual page. PR: kern/152887 Modified: stable/8/sys/netinet/ipfw/ip_dummynet.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/netinet/ipfw/ip_dummynet.c ============================================================================== --- stable/8/sys/netinet/ipfw/ip_dummynet.c Tue May 3 04:44:50 2011 (r221358) +++ stable/8/sys/netinet/ipfw/ip_dummynet.c Tue May 3 05:09:02 2011 (r221359) @@ -108,6 +108,10 @@ ipdn_bound_var(int *v, int dflt, int lo, { int oldv = *v; const char *op = NULL; + if (dflt < lo) + dflt = lo; + if (dflt > hi) + dflt = hi; if (oldv < lo) { *v = dflt; op = "Bump"; @@ -2129,7 +2133,7 @@ ip_dn_init(void) dn_cfg.red_max_pkt_size = 1500; /* default max packet size */ /* hash tables */ - dn_cfg.max_hash_size = 1024; /* max in the hash tables */ + dn_cfg.max_hash_size = 65536; /* max in the hash tables */ dn_cfg.hash_size = 64; /* default hash size */ /* create hash tables for schedulers and flowsets. _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Tue May 3 11:15:16 2011 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 E0B4C1065670; Tue, 3 May 2011 11:15:16 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B48AF8FC1B; Tue, 3 May 2011 11:15:16 +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 p43BFGra093810; Tue, 3 May 2011 11:15:16 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p43BFF0a093805; Tue, 3 May 2011 11:15:15 GMT (envelope-from ae) Date: Tue, 3 May 2011 11:15:15 GMT Message-Id: <201105031115.p43BFF0a093805@freefall.freebsd.org> To: boris@tagnet.ru, ae@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/152887: [ipfw] Can not set more then 1024 buckets with buckets flag 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, 03 May 2011 11:15:17 -0000 Synopsis: [ipfw] Can not set more then 1024 buckets with buckets flag State-Changed-From-To: patched->closed State-Changed-By: ae State-Changed-When: Tue May 3 11:14:51 UTC 2011 State-Changed-Why: Merged to stable/8. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=152887 From owner-freebsd-ipfw@FreeBSD.ORG Tue May 3 11:44:28 2011 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 D7D22106566C; Tue, 3 May 2011 11:44:28 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AAB1D8FC1A; Tue, 3 May 2011 11:44:28 +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 p43BiSga023555; Tue, 3 May 2011 11:44:28 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p43BiSAX023551; Tue, 3 May 2011 11:44:28 GMT (envelope-from ae) Date: Tue, 3 May 2011 11:44:28 GMT Message-Id: <201105031144.p43BiSAX023551@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions 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, 03 May 2011 11:44:28 -0000 Synopsis: [ipfw] [dummynet] [patch]: performance improvement and several extensions Responsible-Changed-From-To: freebsd-net->freebsd-ipfw Responsible-Changed-By: ae Responsible-Changed-When: Tue May 3 11:42:34 UTC 2011 Responsible-Changed-Why: Seems it is related to ipfw. http://www.freebsd.org/cgi/query-pr.cgi?pr=156770 From owner-freebsd-ipfw@FreeBSD.ORG Tue May 3 12:29:17 2011 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 ADFDF10657DA for ; Tue, 3 May 2011 12:29:17 +0000 (UTC) (envelope-from theultramage@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D18A8FC13 for ; Tue, 3 May 2011 12:29:16 +0000 (UTC) Received: by ewy1 with SMTP id 1so5418ewy.13 for ; Tue, 03 May 2011 05:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=YGfqEbyR267PvuB2cNjwirMqzhaBlom/gAAFb9DaUpk=; b=oOZYqcEeHcTdzh1DUv97G7LKMTI/DVXcG0QrJtX1IPBuFT9FxQe8KiMTx4aaXXLG1V xvrCS/KrsB3fPfQlupKrlvKXUYntGnyX3g+MexjjTJKI3TxUggO0lgjZfJiRrzQuIcgz 4kgCBp1HqGcGTBPdN4TMPPMzXKIOXtnrF+YqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=VMSsOLUgh2KSYQEP/F44xYHurv30qUVY8Azd4ZiModdMv77nMVdf4Q/SdlutNIjbs2 owT09SBlrm9qeFCTPWMtF7v/e+Ye6ZBVA+bDmUNIzYFka1ABVeBii+Bykx6nFLoTTS1B DhETkJg+n0PAkiHdixK09c5Ph5ON0fz0kRZp4= Received: by 10.213.10.143 with SMTP id p15mr1927861ebp.98.1304424394427; Tue, 03 May 2011 05:06:34 -0700 (PDT) Received: from [10.0.0.2] (217-75-87-59.chassco.swan.sk [217.75.87.59]) by mx.google.com with ESMTPS id y18sm15717eeh.1.2011.05.03.05.06.32 (version=SSLv3 cipher=OTHER); Tue, 03 May 2011 05:06:33 -0700 (PDT) Message-ID: <4DBFEFC6.4090702@gmail.com> Date: Tue, 03 May 2011 14:06:30 +0200 From: umage User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.org X-Mailman-Approved-At: Tue, 03 May 2011 12:31:50 +0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ipfw forward to ipv6 addresses 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, 03 May 2011 12:29:17 -0000 Hi, on freebsd 8.2 ipfw assumes when parsing the commandline that the target is an ipv4 address. Therefore, $ipfw add 1000 forward $target ip6 from $source to any out keep-state (to achieve source-based routing on a multihomed machine) will mess up and parse it as 0.0.7.210,3 or whatever. I found 5 year old bugreports on this: http://www.freebsd.org/cgi/query-pr.cgi?pr=104921 http://www.freebsd.org/cgi/query-pr.cgi?pr=117214 I also found this discussion from year 2003: https://www.sixxs.net/forum/?msg=setup-52946 where one of the users actually wrote a patch - for freebsd 4.8 - which is still there, however the code has completely changed so only someone who knows how ipfw is coded can do this. I also checked the sources of ipfw2.c, and found case TOK_FORWARD: { ipfw_insn_sa *p = (ipfw_insn_sa *)action; char *s, *end; NEED1("missing forward address[:port]"); action->opcode = O_FORWARD_IP; action->len = F_INSN_SIZE(ipfw_insn_sa); /* * In the kernel we assume AF_INET and use only * sin_port and sin_addr. Remember to set sin_len as * the routing code seems to use it too. */ p->sa.sin_family = AF_INET; p->sa.sin_len = sizeof(struct sockaddr_in); p->sa.sin_port = 0; Which indicates that no attempt at ipv6 support was made when this was coded. Can this be solved somehow? Thanks. From owner-freebsd-ipfw@FreeBSD.ORG Tue May 3 18:36:37 2011 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 796C5106567B for ; Tue, 3 May 2011 18:36:37 +0000 (UTC) (envelope-from korodev@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 351158FC17 for ; Tue, 3 May 2011 18:36:36 +0000 (UTC) Received: by qyk35 with SMTP id 35so2357011qyk.13 for ; Tue, 03 May 2011 11:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=pl0KmIOlR1qMCIvCirge0MbnGPBq1uCjeyolGv8ybfk=; b=lRLBcOLBu5NEUX4qe63zdQesSE6izDJx7zxX4vaC2nCIwxVL+pv8Yg1Y+UYZc3TqfH kQenreoLXK+8UO6Prp3X46eGPbAI6vUzGfdkhbLNTWQ0ZNWwZ8ZeHPGl0nohfCnbfxtS o6725qxizDK672qZs0gSEnz0fcyfhkb6udV9c= 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 :cc:content-type:content-transfer-encoding; b=XHppfMlrLBekyRoenWwY6K8lCTJjafgxVHXbhusLmgkk0LTC/U3lYiQCwb+H3txiNq r+sCddDwF0LAnHGX9SuV5eWsizqJmNTlBbCOjG/s+Pz+hGs6kGftMHh/QS4sEbtJWwr+ JlBkr/eDxKNp9pfBzCCAXc+75MlHV4Ccflj6s= Received: by 10.52.89.49 with SMTP id bl17mr200955vdb.207.1304447796047; Tue, 03 May 2011 11:36:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.182.67 with HTTP; Tue, 3 May 2011 11:36:16 -0700 (PDT) In-Reply-To: References: <220d2ec0-887b-4b03-a66c-8af7a0b25b13@blur> From: Korodev Date: Tue, 3 May 2011 13:36:16 -0500 Message-ID: To: Michael Scheidell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-ipfw@freebsd.org" Subject: Re: IPFW Table Insertion in C, Dummynet, and an interesting problem. 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, 03 May 2011 18:36:37 -0000 > You might also talk to JJ @ sourcefire. =C2=A0Working on getting snort in= line to work with if_bridge. Thanks for the tip Michael. I started some dialog with him, but it looks like were working on different things as I'm not using IPFW divert. Perhaps there's a better place to ask this question? I'm 90% sure my problem lies in a odd bug or my own misunderstanding with IPFW/Dummynet. \\korodev From owner-freebsd-ipfw@FreeBSD.ORG Tue May 3 19:32:16 2011 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 4151E106566C for ; Tue, 3 May 2011 19:32:16 +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 C16F68FC08 for ; Tue, 3 May 2011 19:32:15 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E19127300B; Tue, 3 May 2011 21:47:30 +0200 (CEST) Date: Tue, 3 May 2011 21:47:30 +0200 From: Luigi Rizzo To: Korodev Message-ID: <20110503194730.GA35032@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Table Insertion in C, Dummynet, and an interesting problem. 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, 03 May 2011 19:32:16 -0000 > Hey guys, > > I'm currently running some custom C code ,via an output plugin for > Snort, which takes an IP and sticks it in an ipfw table. Once the > packet enters the box, I'm using dummynet to delay the packet while > snort analyzes it and inserts the IP into a table, after the piping > delay is complete the rule is reinserted at the appropriate point and > checked via a deny table lookup rule. I've done some fairly extensive > testing which has led me here. I believe I'm either doing my IPFW > insertion wrong, or there's a bug or tuning setting I'm unaware of. I am not aware of any significant delays between the setsockopt and the actual insertion in the table. There might be some locks involved but it is highly unlikely that it takes 150ms. So, a few things to check 1. to test your insertion code, you should check whether the address has ended up into the table, e.g. running ipfw table 0 list from the command line. If the address is not there, you could always try and run system("ipfw -n table 0 add n.n.n.n"); as a temporary workaround. 2. if the insertion code is correct, you could check if there is a timing issue increasing the delay in the pipe to something larger until the filtering works as you want. But i really doubt the problem is here. cheers luigi (rest of the original email below) > I'd be delighted if you guys could take the time to look through my > explanation below and let me know if anything comes to mind :) > > First my physical setup is as follows: > > Pinger --> { eth 0 --> bridge0 --> eth1 } --> Host > > #My Freebsd/IPFW setup: > > FreeBSD 8.2, net.link.bridge.ipfw=1, net.inet.ip.fw.one_pass=0 > > #IPFW Ruleset > > 00100 count icmp from any to any > 00300 pipe 1 icmp from any to any //pipe is configured with config delay 150ms > 00400 deny log ip from any to any src-ip table(0) > 00500 count icmp from any to any ... > #IPFW C Insertion Code > > .... > #include > #include > > //data is a custom struct > data->s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); > data->ent.tbl = 0; > data->ent.value = 0; > data->ent.masklen = 32; > > data->ip.s_addr = p->iph->ip_src.s_addr; > memcpy(&(data->ent.addr), &(data->ip), sizeof(struct in_addr)); > setsockopt(data->s, IPPROTO_IP, IP_FW_TABLE_ADD, &(data->ent), > sizeof(data->ent)); > ... > > This is slightly simplified for this test case, but it's important to > know the insertion works, just not in less than 150ms. (~200ms > actually). I've been talking to the Snort guys a bit, and I won't post > my snort conf here, but please take my word that it's quite stripped > down. My test case as follows, consisingt of a sending a single ICMP > ping packet from Pinger to Host. In theory, Snort, listening passively > on eth0 (libpcap 1.1.1), will alert on the ICMP ping to Host insert. . > I conducted the following timing tests using tcpdump, Snort's > performance profiling, and my own C timing code. Here are my results: > > tcpdump shows that the packet hits eth0 at 51.647347 seconds, bridge0 > at 51.647350 seconds, and the exit interface, eth1, at 51.797320. This > (as expected) equates to 149.97300 milliseconds of time. > > Snort is passively listening on the eth0 interface using the pcap daq > module. It's configured to spend a maximum time of 250 microseconds > before triggering my output plugin. Using some C timing methods on the > output plugin code above says that grabbing the IP and sending it to > the IPFW socket (which is cached and already open at that point), > takes about 7.8120 milliseconds (1 CPU tick). Since that's where I > call setsockopt, the it just sits in the pipe for the remaining time, > but upon falling to the next rule (deny src-ip table 0), it misses the > check. The count rule following my deny rule verifies that the rule > did reach the deny table rule. > > There's only one untested spot that I can see, and that's the time > between I actually make the insertion via setsockopt and the time IPFW > "actually" update the table in memory. All of my other operations are > executing with testable and consistent speeds, which are FAR less than > a 150 millisecond dummynet pipe. > > Am I inserting the IP into the table correctly? Is there another > command I need to call to force IPFW to update the table faster? Or > perhaps there's some kernel tuning I'm unaware of? If you've made it > this far, then thanks for taking the time to read this and please let > me know if you have thoughts on why the IP isn't making it in the > table fast enough. If more info is needed, I'll be happy to provide > it :) > > Thanks, > > \\korodev > _______________________________________________ > 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 Tue May 3 20:44:51 2011 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 18A96106564A for ; Tue, 3 May 2011 20:44:51 +0000 (UTC) (envelope-from korodev@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id C51228FC18 for ; Tue, 3 May 2011 20:44:50 +0000 (UTC) Received: by qyk35 with SMTP id 35so2492763qyk.13 for ; Tue, 03 May 2011 13:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ZLuSoduNxSkWjnJpTNz/ScXSQ7NIoIB1DBdZyIh8T8Y=; b=ieWWPFo1uWWpNmzwhbrdUThKtsh3FC04/toTRbIz0DZESBMsepJeCJmoMJwXDDLz3j wG5kYdFo2cLSS8KeK0Y1636xAXy9FoN6sYATIDuR3uCxp2vSvgx/8oIdU9vYGwfr2BQN STTGRt0dtEiviVkZbko6TlEfYS1K1zcDLN0tU= 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 :cc:content-type:content-transfer-encoding; b=ifbconEWGgFirFgq4LvT3Vj6mDA1WCVG2W5Qe/g2yvJkk6QJMeSs/g9VHojvrwXh5i MOUOHbpODL1BegJjZS0YqDw6Ey7cvjXbb1WKEv3PJEDQtPADpNiQzQY31TaDlqbHHx/S FFmHW9pBVProRIRLp8HVwM3pTsGxtwr4L36xs= Received: by 10.52.67.73 with SMTP id l9mr336550vdt.287.1304455490095; Tue, 03 May 2011 13:44:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.182.67 with HTTP; Tue, 3 May 2011 13:44:30 -0700 (PDT) In-Reply-To: <20110503194730.GA35032@onelab2.iet.unipi.it> References: <20110503194730.GA35032@onelab2.iet.unipi.it> From: Korodev Date: Tue, 3 May 2011 15:44:30 -0500 Message-ID: To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Table Insertion in C, Dummynet, and an interesting problem. 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, 03 May 2011 20:44:51 -0000 Luigi, Thanks for your response! I was hoping you would reply. I was in the middle of writing an update to my testing. Still no avail, but I've been running some more tests and will include my results inline below: > I am not aware of any significant delays between the setsockopt > and the actual insertion in the table. There might be some locks > involved but it is highly unlikely that it takes 150ms. Exactly. I totally agree here. I'm doing the same thing on 6.2 (I know, I know) and it works well. My next step is to try it in 7.4 and see what happens. > So, a few things to check > 1. to test your insertion code, you should check whether the > =C2=A0 address has ended up into the table, e.g. running > =C2=A0 =C2=A0 =C2=A0 =C2=A0ipfw table 0 list > =C2=A0 from the command line. > =C2=A0 If the address is not there, you could always try and run > =C2=A0 =C2=A0 =C2=A0 =C2=A0system("ipfw -n table 0 add n.n.n.n"); > =C2=A0 as a temporary workaround. I've verified the IP does end up in the table via the 'ipfw table 0 list' method, the system("ipfw -n table 0 add *ip*") call, as well as attempting to re-insert it immediately using setsockopt and confirming that errno returns EEXIST. So the IP is definitely making it into the table. > 2. if the insertion code is correct, you could check if there is a timing > =C2=A0 issue increasing the delay in the pipe to something larger until > =C2=A0 the filtering works as you want. But i really doubt the problem > =C2=A0 is here. This is what's baffling. I can get it work when I introduce more latency than I could ever afford, but it's still sporadic. When I have the pipe set to 500ms, it gets blocked every time. It continually gets less consistent going down from there., but it's never quite 100% consistent until it consistently fails at anything under 250ms. An unsuccessful test will show the IP in table 0 and the follow stats when using 'ipfw show': 00100 2 168 count icmp from any to any 00300 2 168 pipe icmp from any to any 00400 2 168 count icmp from any to any 00500 0 0 deny log ip from any to any src-ip table(0) 00600 2 168 count icmp from any to any 65535 2873 609427 allow ip from any to any While a successful test will still show the IP in table 0 and the following stats. (Note the first packet doesn't make it through, so a response is never received, which is why we only see 1 instead of 2 like above). 00100 1 84 count icmp from any to any 00300 1 84 pipe icmp from any to any 00400 1 84 count icmp from any to any 00500 1 84 deny log ip from any to any src-ip table(0) 00600 0 0 count icmp from any to any 65535 2873 609427 allow ip from any to any I'm wondering if IPFW is looking ahead at the table entries and computing the match before it actually gets to the rule. Please let me know what other details I can provide. \\korodev From owner-freebsd-ipfw@FreeBSD.ORG Thu May 5 08:06:07 2011 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 59B7A1065674 for ; Thu, 5 May 2011 08:06:07 +0000 (UTC) (envelope-from 62mkv@mail.ru) Received: from smtp18.mail.ru (smtp18.mail.ru [94.100.176.155]) by mx1.freebsd.org (Postfix) with ESMTP id CB0F38FC13 for ; Thu, 5 May 2011 08:06:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:To:Message-ID:Reply-To:From:Date; bh=CTTC50JxtU8KcmDsrGgXMXZCNrGxuVEjv5nz4PbKuC4=; b=EuoOc2QT6dp1q9mA5gkhRRmkQm6eIMyds/JN0EhJuhUunF4+gwDSVd4/jkSIUB7/B6Rm7W542wy4Upe+fShhL2UA88cb+uBNnF9AkVimtjKtbuqdaIJ3ojiRT5Tm2Uty; Received: from [81.201.246.18] (port=5916 helo=RABBIT) by smtp18.mail.ru with asmtp id 1QHtZU-00055R-00 for freebsd-ipfw@freebsd.org; Thu, 05 May 2011 12:06:04 +0400 Date: Thu, 5 May 2011 15:06:03 +0700 From: 62mkv <62mkv@mail.ru> X-Priority: 3 (Normal) Message-ID: <1188133221.20110505150603@mail.ru> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: bug in IPFW+NATD+keep-state (FreeBSD 8.2, GENERIC) ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 62mkv <62mkv@mail.ru> List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 08:06:07 -0000 Hello Freebsd-ipfw, A was already asking a question to this maillist couple of days ago. as long as nobody answered, I went on and discovered a very strange thing, which definitely is not normal. In short: I am using IPFW+NATD, essentally in the same way as is written in handbook (NAT+Stateful rules, example 1). Everything (I test for simplicity only on ICMP packets) works OK if I use stateless syntax. BUT only I add a "keep-state" option to a "skipto $nat" rule - NATD stops aliasing !!! It just pushes packets "as is" onto a global interface with unregistered source IP !!! It is so much unexpected and goes in contrary with Handbook, so that I decided to post it here. general setup: rl0 - external (WAN) interface, fxp0 - LAN (unregistered) interface. I want to make it possible for a single station from LAN (192.168.0.2) make pings and get replies of course, to global WAN addresses. for this I use IPFW and NATD. IPFW setup 0 (stateless): ipfw show: 00001 11 660 divert 1000 ip from any to any in via rl0 00002 0 0 check-state 00005 0 0 allow ip from any to me via fxp0 00006 0 0 allow ip from me to any via fxp0 00010 0 0 allow ip from any to any via lo0 00011 15 900 allow icmp from 192.168.0.2 to any in via fxp0 00012 15 900 skipto 20 icmp from 192.168.0.2 to any out via rl0 00013 0 0 allow ip from any to me via fxp0 00016 11 660 deny log logamount 5 icmp from any to any 00019 49 5670 deny ip from any to any 00020 15 900 divert 1000 ip from any to any via rl0 00040 11 660 allow ip from any to any 65535 0 0 deny ip from any to any natd.log (I had to type it in manually, because with ">" or "| tee" redirections I cannot get logs of natd (probably when I terminate him with Ctrl-C, it loses its buffered output) -is there a workaround for this ?) : Out {default}[ICMP] [ICMP] 192.168.0.2 -> 81.201.246.17 8(0) aliased to [ICMP] 81.201.146.94 -> 81.201.246.17 8(0) In {default}[ICMP] [ICMP] 81.201.246.17 -> 81.201.246.94 0(0) aliased to [ICMP] 81.201.246.17 -> 192.168.0.2 0(0) ... natd is run as follows: natd -p -1000 -v -n rl0 tcpdump on rl0: 13:54:11.419747 IP 81.201.246.94 > 81.201.246.17: ICMP echo request, id 512, seq 46601, length 40 13:54:11.420345 IP 81.201.246.17 > 81.201.246.94: ICMP echo reply, id 512, seq 46601, length 40 13:54:16.919819 IP 81.201.246.94 > 81.201.246.17: ICMP echo request, id 512, seq 46857, length 40 13:54:16.920352 IP 81.201.246.17 > 81.201.246.94: ICMP echo reply, id 512, seq 46857, length 40 so, all works fine (except that "replies" are dropped by IPFW because as such they're forbidden, and IPFW ruleset is yet stateless) now IPFW setup 1 (=setup0 + only one keep-state to skipto rule #12): ipfw -d show: 00001 1 60 divert 1000 ip from any to any in via rl0 00002 0 0 check-state 00005 0 0 allow ip from any to me via fxp0 00006 0 0 allow ip from me to any via fxp0 00010 0 0 allow ip from any to any via lo0 00011 15 900 allow icmp from 192.168.0.2 to any in via fxp0 00012 19 1140 skipto 20 icmp from 192.168.0.2 to any out via rl0 keep-state 00016 0 0 deny log logamount 5 icmp from any to any 00019 45 4845 deny ip from any to any 00020 17 1020 divert 1000 ip from any to any via rl0 00040 10 600 allow ip from any to any 65535 1 78 deny ip from any to any ## Dynamic rules (1): 00012 0 0 (1s) STATE icmp 192.168.0.2 0 <-> 81.201.246.17 0 natd.log: Out {default}[ICMP] [ICMP] 192.168.0.2 -> 81.201.246.17 8(0) aliased to [ICMP] 192.168.0.2 -> 81.201.246.17 8(0) Out {default}[ICMP] [ICMP] 192.168.0.2 -> 81.201.246.17 8(0) aliased to [ICMP] 192.168.0.2 -> 81.201.246.17 8(0) tcpdump on rl0: 17:54:13.711016 IP 192.168.0.2 > 81.201.246.17: ICMP echo request, id 512, seq 50443, length 40 17:54:19.211081 IP 192.168.0.2 > 81.201.246.17: ICMP echo request, id 512, seq 50699, length 40 17:54:24.711198 IP 192.168.0.2 > 81.201.246.17: ICMP echo request, id 512, seq 50955, length 40 So, what would it all mean, and what am I doing wrong ? -- Best wishes, 62mkv mailto: 62mkv@mail.ru From owner-freebsd-ipfw@FreeBSD.ORG Fri May 6 07:06:33 2011 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 ADD86106567C; Fri, 6 May 2011 07:06:33 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8605B8FC18; Fri, 6 May 2011 07:06:33 +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 p4676XuY017940; Fri, 6 May 2011 07:06:33 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4676XSq017936; Fri, 6 May 2011 07:06:33 GMT (envelope-from ae) Date: Fri, 6 May 2011 07:06:33 GMT Message-Id: <201105060706.p4676XSq017936@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: bin/156838: [dummynet] ipfw(8): "ipfw pipe show" shows wrong dummynet pipe delay when hz is not 1000 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, 06 May 2011 07:06:33 -0000 Old Synopsis: ipfw(8): "ipfw pipe show" shows wrong dummynet pipe delay when hz is not 1000 New Synopsis: [dummynet] ipfw(8): "ipfw pipe show" shows wrong dummynet pipe delay when hz is not 1000 Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: ae Responsible-Changed-When: Fri May 6 07:05:52 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=156838 From owner-freebsd-ipfw@FreeBSD.ORG Fri May 6 07:14:26 2011 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 4E645106566C; Fri, 6 May 2011 07:14:26 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 260048FC13; Fri, 6 May 2011 07:14:26 +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 p467EQbw028724; Fri, 6 May 2011 07:14:26 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p467EPiq028720; Fri, 6 May 2011 07:14:25 GMT (envelope-from ae) Date: Fri, 6 May 2011 07:14:25 GMT Message-Id: <201105060714.p467EPiq028720@freefall.freebsd.org> To: lijimlee@gmail.com, ae@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: bin/156838: [dummynet] ipfw(8): "ipfw pipe show" shows wrong dummynet pipe delay when hz is not 1000 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, 06 May 2011 07:14:26 -0000 Synopsis: [dummynet] ipfw(8): "ipfw pipe show" shows wrong dummynet pipe delay when hz is not 1000 State-Changed-From-To: open->patched State-Changed-By: ae State-Changed-When: Fri May 6 07:14:05 UTC 2011 State-Changed-Why: Fixed in head/. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=156838 From owner-freebsd-ipfw@FreeBSD.ORG Fri May 6 07:20:11 2011 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 1F01A106566B for ; Fri, 6 May 2011 07:20:11 +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 102D98FC08 for ; Fri, 6 May 2011 07:20:11 +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 p467KAce029559 for ; Fri, 6 May 2011 07:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p467KAMY029558; Fri, 6 May 2011 07:20:10 GMT (envelope-from gnats) Date: Fri, 6 May 2011 07:20:10 GMT Message-Id: <201105060720.p467KAMY029558@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: bin/156838: commit references a PR X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 07:20:11 -0000 The following reply was made to PR bin/156838; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/156838: commit references a PR Date: Fri, 6 May 2011 07:13:43 +0000 (UTC) Author: ae Date: Fri May 6 07:13:34 2011 New Revision: 221521 URL: http://svn.freebsd.org/changeset/base/221521 Log: Convert delay parameter back to ms when reporting to user. PR: 156838 MFC after: 1 week Modified: head/sys/netinet/ipfw/ip_dn_glue.c head/sys/netinet/ipfw/ip_dummynet.c Modified: head/sys/netinet/ipfw/ip_dn_glue.c ============================================================================== --- head/sys/netinet/ipfw/ip_dn_glue.c Fri May 6 03:44:49 2011 (r221520) +++ head/sys/netinet/ipfw/ip_dn_glue.c Fri May 6 07:13:34 2011 (r221521) @@ -624,7 +624,7 @@ dn_c_copy_pipe(struct dn_schk *s, struct /* These 4 field are the same in pipe7 and pipe8 */ pipe7->next.sle_next = (struct dn_pipe7 *)DN_IS_PIPE; pipe7->bandwidth = l->bandwidth; - pipe7->delay = l->delay; + pipe7->delay = l->delay * 1000 / hz; pipe7->pipe_nr = l->link_nr - DN_MAX_ID; if (!is7) { Modified: head/sys/netinet/ipfw/ip_dummynet.c ============================================================================== --- head/sys/netinet/ipfw/ip_dummynet.c Fri May 6 03:44:49 2011 (r221520) +++ head/sys/netinet/ipfw/ip_dummynet.c Fri May 6 07:13:34 2011 (r221521) @@ -808,6 +808,7 @@ copy_obj(char **start, char *end, void * /* Adjust burst parameter for link */ struct dn_link *l = (struct dn_link *)*start; l->burst = div64(l->burst, 8 * hz); + l->delay = l->delay * 1000 / hz; } else if (o->type == DN_SCH) { /* Set id->id to the number of instances */ struct dn_schk *s = _o; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Fri May 6 20:56:04 2011 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 1CA43106566B for ; Fri, 6 May 2011 20:56:04 +0000 (UTC) (envelope-from mh.unet@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id E89428FC12 for ; Fri, 6 May 2011 20:56:03 +0000 (UTC) Received: by pzk27 with SMTP id 27so2087578pzk.13 for ; Fri, 06 May 2011 13:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=NCQiY9zyXZZHJx/RkbAgRobDbfN7xH0PGJO6LEYr1N0=; b=NU6Hj1JRBHYhBouJR+E//a97FDW9HOhzF/iU3hd5RTLKD6INDukYCKjU+c285pGA6h W8fmClyXTqkWWmdlRBnnH7znK/Kahx1v1FNppgAQsKOrgwj6nVWoJzpU/ZzGjpnBS/1e CkQ2OP/muVIaNE5ab1KHFgBu6DqCgYOao2P7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CuNOxnbAEqv48dmUB/yV1s2oMCHSAqO2Jqn3PuScMaJvdb3scnpocKnojdSVdnduvD R3eTr6ANwJWkM91tbrXCYWUb2b4poBgOziknBVcPsEu/0iJd8B6l3rhLFaN0pOEu8Zgo iXN2bVtGEm5Ok1sBPC6GLY+tHSN2UJS233Zes= MIME-Version: 1.0 Received: by 10.142.98.13 with SMTP id v13mr2227487wfb.279.1304713767910; Fri, 06 May 2011 13:29:27 -0700 (PDT) Received: by 10.143.33.3 with HTTP; Fri, 6 May 2011 13:29:27 -0700 (PDT) Date: Fri, 6 May 2011 13:29:27 -0700 Message-ID: From: Mickey Harvey To: freebsd-ipfw@freebsd.org X-Mailman-Approved-At: Fri, 06 May 2011 21:15:45 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: run pf or ipfw within a jail? 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, 06 May 2011 20:56:04 -0000 Is it possible to run pf or ipfw within a jail? I am running 8.2 and have vimage compiled in the kernel. From owner-freebsd-ipfw@FreeBSD.ORG Sat May 7 06:13:31 2011 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 C57FF106566C for ; Sat, 7 May 2011 06:13:31 +0000 (UTC) (envelope-from jack@jarasoft.net) Received: from raats.xs4all.nl (raats.xs4all.nl [82.95.230.43]) by mx1.freebsd.org (Postfix) with ESMTP id 79CB48FC0A for ; Sat, 7 May 2011 06:13:31 +0000 (UTC) Received: from raats.xs4all.nl (orac.jarasoft.net [10.10.10.10]) by raats.xs4all.nl (Postfix) with ESMTP id 892E63D751C; Sat, 7 May 2011 08:01:32 +0200 (CEST) Received: from jarasc430 (raats.xs4all.nl [82.95.230.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by raats.xs4all.nl (Postfix) with ESMTPSA id 3C1263D7422; Sat, 7 May 2011 08:01:32 +0200 (CEST) Message-ID: <80DC3A23AD6C467E8523B68F1F47DC1D@jarasc430> From: "Jack Raats" To: "Mickey Harvey" , References: Date: Sat, 7 May 2011 08:01:12 +0200 Organization: JaRaSoft, Steenbergen, Nederland MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Virus-Scanned: ClamAV using ClamSMTP on orac.jarasoft.net X-Mailman-Approved-At: Sat, 07 May 2011 11:15:40 +0000 Cc: Subject: Re: run pf or ipfw within a jail? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 06:13:31 -0000 Normally you run the firewall on the host machine not in the jail. ----- Original Message ----- From: "Mickey Harvey" To: Sent: Friday, May 06, 2011 10:29 PM Subject: run pf or ipfw within a jail? > Is it possible to run pf or ipfw within a jail? I am running 8.2 and have > vimage compiled in the kernel. > _______________________________________________ > 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"