From owner-freebsd-ipfw@freebsd.org Wed Sep 16 15:06:01 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A6399CE052; Wed, 16 Sep 2015 15:06:01 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8CFD71E7B; Wed, 16 Sep 2015 15:05:59 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t8GF5obW092775; Thu, 17 Sep 2015 01:05:50 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 17 Sep 2015 01:05:50 +1000 (EST) From: Ian Smith To: Warren Block cc: "O. Hartmann" , Kimmo Paasiala , freebsd-net@freebsd.org, Lev Serebryakov , freebsd-ipfw@freebsd.org Subject: Re: HELP! Mysterious socket 843/tcp listening on CURRENT system In-Reply-To: Message-ID: <20150916235555.F82084@sola.nimnet.asn.au> References: <20150915090658.1e0b9074@freyja.zeit4.iv.bundesimmobilien.de> <20150915094757.3daef42c@freyja.zeit4.iv.bundesimmobilien.de> <20150915201451.L90924@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 15:06:01 -0000 On Tue, 15 Sep 2015 07:51:11 -0600 (MDT), Warren Block wrote: > On Tue, 15 Sep 2015, Ian Smith wrote: > O. Hartmann wrote: > > > But that is an other issue and it is most likely > > > due to the outdated documentation (that doc still uses port 37 for NTP > > > purposes and referes to the outdated divert mechanism using natd, see the > > > recent handbook). The internet is also full of ambigous examples. > > > > Yes, the handbook IPFW section is still crazy after all these years, > > despite ongoing attempts to limit the damage. Best just ignore it. > > Best overall would be to fix the documentation. Oh, absolutely. But it can't be me, for reasons I'll mail you about. I've become reluctant to talk about what I can't fix, but when I see people in trouble due to that section, I'm compelled to so advise. > Given that there seems to be more interest in IPFW lately, it would > be nice if someone well-versed in it would repair or even rewrite the > IPFW handbook section. Rewrites are sometimes less work than fixing > an old section that no longer fits actual usage. Exactly the conclusion I'd come to after an effort last October to correct some of the more egregious errors, including the one Oliver mentions above and quite a lot else. In reviewing that today, I see I got some things wrong myself :) but I'll send it to you anyway. It's nothing more than a start, and only saved-as text, not in doc markup. > I have not used IPFW in years, but would be willing to help with an > edit/rewrite. Well if you're prepared to coordinate efforts, I'll certainly review and contribute as best I can. There was another offer in ipfw@ to assist in a rewrite recently. If you're up for it, I'll shunt that your way too? I've a feeling that the best way to do a lot of this would be by brief sections that mostly just pointed to sections of (online) ipfw(8); e.g. even the basic description is best covered by ipfw(8)'s /DESCRIPTION .. so a good index into that with some extra pointers and tips might work. But we really need some good examples of ipfw + nat with stateful rules that actually work properly. I found one saved good(-looking :) ruleset from 2012 with the sort of multiple interfaces and subnets Oliver needs, by Lev Serebryakov , who's more recently been working on adding new rules to better handle timing/placement of state checking including in NAT scenarios, who I poke occasionally - like now - to provide some worked examples :) I think freebsd-ipfw@ may be a better place to take this now .. cc'd. cheers, Ian From owner-freebsd-ipfw@freebsd.org Fri Sep 18 14:02:11 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AF9A9CEAA1 for ; Fri, 18 Sep 2015 14:02:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E157159D for ; Fri, 18 Sep 2015 14:02:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8IE2BaH034474 for ; Fri, 18 Sep 2015 14:02:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 200169] ipfw table list uses IPv6 format for zero IPv4 addresses Date: Fri, 18 Sep 2015 14:02:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: egypcio@googlemail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 14:02:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200169 egypcio@googlemail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |egypcio@googlemail.com --- Comment #3 from egypcio@googlemail.com --- (In reply to Kurt Jaeger from comment #2) HEAD is okay. # uname -a FreeBSD box 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r287824: Tue Sep 15 14:35:24 BRT 2015 root@box:/usr/obj/panzer/freebsd/base/sys/BOX amd64 # kldload ipfw # ipfw table 123 create # ipfw table 123 add 0.0.0.0/8 added: 0.0.0.0/8 0 # ipfw table 123 list --- table(123), set(0) --- 0.0.0.0/8 0 STABLE/10 still not patched. How to reproduce: # sysctl -n hw.model Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz # fetch ftp://ftp.geo.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.2-STABLE/i386/Latest/FreeBSD-10.2-STABLE-i386.raw.xz FreeBSD-10.2-STABLE-i386.raw.xz 100% of 125 MB 192 kBps 11m06s # xz -d FreeBSD-10.2-STABLE-i386.raw.xz # kldload vmm # /bin/sh /usr/share/examples/bhyve/vmrun.sh -d FreeBSD-10.2-STABLE-i386.raw vm0 [bhyve] root@:~ # uname -a FreeBSD 10.2-STABLE FreeBSD 10.2-STABLE #0 r287435: Thu Sep 3 22:15:32 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 root@:~ # kldload ipfw ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled root@:~ # ipfw table 123 add 0.0.0.0/8 root@:~ # ipfw table 123 list ::/8 0 [/bhyve] -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-ipfw@freebsd.org Fri Sep 18 17:29:50 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D59C9CE19F for ; Fri, 18 Sep 2015 17:29:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A6E61064 for ; Fri, 18 Sep 2015 17:29:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8IHTnO7036143 for ; Fri, 18 Sep 2015 17:29:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 200169] ipfw table list uses IPv6 format for zero IPv4 addresses Date: Fri, 18 Sep 2015 17:29:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 17:29:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200169 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: melifaro Date: Fri Sep 18 17:29:25 UTC 2015 New revision: 287963 URL: https://svnweb.freebsd.org/changeset/base/287963 Log: MFC r266310 Fix wrong formatting of 0.0.0.0/X table records in ipfw(8). Add `flags` u16 field to the hole in ipfw_table_xentry structure. Kernel has been guessing address family for supplied record based on xent length size. Userland, however, has been getting fixed-size ipfw_table_xentry structures guessing address family by checking address by IN6_IS_ADDR_V4COMPAT(). Fix this behavior by providing specific IPFW_TCF_INET flag for IPv4 records. PR: bin/189471,kern/200169 Changes: _U stable/10/ stable/10/sbin/ipfw/ipfw2.c stable/10/sys/netinet/ip_fw.h stable/10/sys/netpfil/ipfw/ip_fw_table.c -- You are receiving this mail because: You are the assignee for the bug.