From owner-freebsd-ipfw@FreeBSD.ORG Sun Oct 5 02:18:41 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 394D9FA5; Sun, 5 Oct 2014 02:18:41 +0000 (UTC) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by mx1.freebsd.org (Postfix) with ESMTP id 172A4FD5; Sun, 5 Oct 2014 02:18:40 +0000 (UTC) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 0611C1638; Sat, 4 Oct 2014 19:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=saltant.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=saltant.com; bh=LhVrCUdafwZNRtb1vpdbbbPvpOw=; b= UwqxcTFUF/03wc3TRJICZiWOlaorqhHGtYP916bpqUcb2aD72iSIWX+MSieJnyxo eWiNp2BsuwuopFzRYxHXQVclMLEJALGo89tbnqiTuQBWYyC4PtAwtzxls02cH29p HqBsDneoz+V39eSyjEymB31eLfSZU61Dl9pllneG4yY= Received: from omnific.priv.n.saltant.net (drivel.saltant.net [72.78.188.146]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@saltant.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id A5890161C; Sat, 4 Oct 2014 19:18:33 -0700 (PDT) Message-ID: <5430AA75.90700@saltant.com> Date: Sat, 04 Oct 2014 22:18:29 -0400 From: "John W. O'Brien" Organization: Saltant Solutions User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: HEADS UP: Merging projects/ipfw to HEAD References: <542FE9A7.9090208@FreeBSD.org> In-Reply-To: <542FE9A7.9090208@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NkCxxvFK1TVwLgqQv4ubaDtrEIl2LwmXi" Cc: FreeBSD IPFW , Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 02:18:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NkCxxvFK1TVwLgqQv4ubaDtrEIl2LwmXi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/4/14 8:35 AM, Alexander V. Chernikov wrote: > Hi, >=20 > I'm going to merge projects/ipfw branch to HEAD in the middle of next w= eek. >=20 > What has changed: >=20 > [crap ton of awesome stuff] Alexander, Nice work! I'm impressed by the sound of these new capabilities, and look forward to trying them out. Thank you for your efforts. Regards, John --NkCxxvFK1TVwLgqQv4ubaDtrEIl2LwmXi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUMKp5AAoJEORay8JGGICYGwIIAMKM0VaIwR48gwb/fD2Rr3sI zD6nbuV5lemnMtU7f/HCpmlrpLTChtkXnaZ21RS8ekrxuHsm06mFl6itQ62bIirG xSRr81NxJvFHRk0/i32Nd5yw4rHgx9tTTD6wdPTFAVqmAkrCfPHtdTXpkY94agG0 bFKQ8F78yNLSyrZ1wNn4s9x0OTYdqurv3HFl+lzqoSyF+X01BzQT0vtRPgiF06tQ tCEKVvEFQkY/ezSN8KJtXucRCtCAvoclFcYCNtDjjP7icIP0FJdVM4nuzCspabIA y2bORiDrl31drq955G8ibaN9btbMR3AVOcZvUEvs6Q7fp5ARNVCj1XkVyL4a3TQ= =Bgem -----END PGP SIGNATURE----- --NkCxxvFK1TVwLgqQv4ubaDtrEIl2LwmXi-- From owner-freebsd-ipfw@FreeBSD.ORG Sun Oct 5 10:13:56 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95D88BAA; Sun, 5 Oct 2014 10:13:56 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 56F4F174; Sun, 5 Oct 2014 10:13:55 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 2D35C1534DF; Sun, 5 Oct 2014 12:13:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4To-AZG71tn; Sun, 5 Oct 2014 12:13:26 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:442e:e523:bdee:d21f] (unknown [IPv6:2001:4cb8:3:1:442e:e523:bdee:d21f]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id ABB4B1534DD; Sun, 5 Oct 2014 12:13:26 +0200 (CEST) Message-ID: <543119C5.9040201@digiware.nl> Date: Sun, 05 Oct 2014 12:13:25 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: HEADS UP: Merging projects/ipfw to HEAD References: <542FE9A7.9090208@FreeBSD.org> <5430AA75.90700@saltant.com> In-Reply-To: <5430AA75.90700@saltant.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD IPFW X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 10:13:56 -0000 On 5-10-2014 4:18, John W. O'Brien wrote: > On 10/4/14 8:35 AM, Alexander V. Chernikov wrote: >> Hi, >> >> I'm going to merge projects/ipfw branch to HEAD in the middle of next week. Alexander, Nice job.. The change list looks impressive. Really looking forward to start working with the new table styles and options.. It will take time to get a real grasp of what new opportunities have become possible. Not running any HEAD systems at the moment, but looking eagerly for a possible MFC to STABLE. Is that in the start at any point in time? --WjW From owner-freebsd-ipfw@FreeBSD.ORG Sun Oct 5 10:16:44 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0287FCBD for ; Sun, 5 Oct 2014 10:16:44 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (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 B6E9A1B2 for ; Sun, 5 Oct 2014 10:16:43 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XaesS-000Feo-IE; Sun, 05 Oct 2014 10:01:04 +0400 Message-ID: <54311A42.9080506@FreeBSD.org> Date: Sun, 05 Oct 2014 14:15:30 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Willem Jan Withagen Subject: Re: HEADS UP: Merging projects/ipfw to HEAD References: <542FE9A7.9090208@FreeBSD.org> <5430AA75.90700@saltant.com> <543119C5.9040201@digiware.nl> In-Reply-To: <543119C5.9040201@digiware.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD IPFW X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 10:16:44 -0000 On 05.10.2014 14:13, Willem Jan Withagen wrote: > On 5-10-2014 4:18, John W. O'Brien wrote: >> On 10/4/14 8:35 AM, Alexander V. Chernikov wrote: >>> Hi, >>> >>> I'm going to merge projects/ipfw branch to HEAD in the middle of next week. > Alexander, > > Nice job.. > > The change list looks impressive. > Really looking forward to start working with the new table styles and > options.. It will take time to get a real grasp of what new > opportunities have become possible. > > Not running any HEAD systems at the moment, but looking eagerly for a > possible MFC to STABLE. > Is that in the start at any point in time? I plan to merge it in 1 moth after committing to HEAD. > > --WjW > > > From owner-freebsd-ipfw@FreeBSD.ORG Sun Oct 5 14:43:08 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A23620F; Sun, 5 Oct 2014 14:43:08 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDF1AEDD; Sun, 5 Oct 2014 14:43:07 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id fp1so1960611pdb.7 for ; Sun, 05 Oct 2014 07:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nC8aHCvKehL8qJgc9izQpfo4r/Bj1ZWBZChFo/RQfBw=; b=LdyaSPczZQBlHhxNzs+ekAnv1H11GtLVW3M4lLwqgrpIUctfHHkMjNoQFejXIKqVAz 3cTAECW8k/FWU2cD1o+uNksZE47gVYDHaQvtiTbM710yFLxudpxAs3mHVnk2MmT6jvcF klDyH/5sBo493HJc4eFkIRi0QR8ozj6AyID9TTLBYJH9maSoD05SlGlP9NzKB4Xcrsvh Xrci8BBGis7WMJK9/R+Ue9wNgnR4QCffH8BnLMHqOLAYXTvXm2puBoyQZeo+dgCeT9Yk SK4kP/sdIeuEjWzcB78n+fH21pDJKLqaeO7JNSFTMffc/nOUoMsOgPPT4VZ+ClUrTp+l jkAQ== X-Received: by 10.70.36.237 with SMTP id t13mr1609964pdj.134.1412520187414; Sun, 05 Oct 2014 07:43:07 -0700 (PDT) Received: from [192.168.1.100] ([175.156.202.12]) by mx.google.com with ESMTPSA id g6sm8873653pdj.0.2014.10.05.07.43.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Oct 2014 07:43:06 -0700 (PDT) Message-ID: <543158F7.2070505@gmail.com> Date: Sun, 05 Oct 2014 22:43:03 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org Subject: Re: HEADS UP: Merging projects/ipfw to HEAD References: <542FE9A7.9090208@FreeBSD.org> In-Reply-To: <542FE9A7.9090208@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 14:43:08 -0000 On 10/4/14 20:35, Alexander V. Chernikov wrote: > Hi, > > I'm going to merge projects/ipfw branch to HEAD in the middle of next > week. > > What has changed: > > Main user-visible changes are related to tables: > > * Tables are now identified by names, not numbers. There can be up to > 65k tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them > atomically with rules. > * More functionality is supported (swap, lock, limits, user-level > lookup, batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet > fields at once. > * Ability to add different type of lookup algorithms for particular > table type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array > and flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for > different tablearg users > > Some examples (see ipfw(8) manual page for the description): > > 0:02 [2] zfscurr0# ipfw table fl2 create type > flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib > 0:02 [2] zfscurr0# ipfw table fl2 info > +++ table(fl2), set(0) +++ > kindex: 0, type: flow:src-ip,proto,dst-port > valtype: number, references: 0 > algorithm: flow:hash > items: 0, size: 280 > 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 > 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 > 0:02 [2] zfscurr0# ipfw table fl2 list > +++ table(fl2), set(0) +++ > 2a02:6b8::333,6,443 45000 > 10.0.0.92,6,80 22000 > 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 > 80 flow 'table(fl2)' > > ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" > ipfw table mi_test add 10.0.0.8/30 > ipfw table mi_test add 2a02:6b8:b010::1/64 25 > > # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 > added: 1.1.1.1/32 1111 > added: 2.2.2.2/32 2222 > # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 > exists: 2.2.2.2/32 2200 > added: 4.4.4.4/32 4444 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error but keeps inserted items > # ipfw table si list > +++ table(si), set(0) +++ > 1.1.1.1/32 1111 > 2.2.2.2/32 2222 > 4.4.4.4/32 4444 > # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 > 5.5.5.5/32 5555 > added(reverted): 3.3.3.3/32 3333 > exists: 4.4.4.4/32 4400 > ignored: 5.5.5.5/32 5555 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error and reverts added records > > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 bytes > * interface tables uses array of existing ifindexes for faster match > > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & > new binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset > in old binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something > may be broken here. Anyway, this can be fixed for MFC > > Internal changes:. > Changing table ids to numbers resulted in format modification for most > sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, > inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned > IP_FW3-based codes. > * The remaining opcodes were also converted to be able to eliminate > all older opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* > directly to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds > extended data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit > effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time > (eats 512K). > > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and > actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct > ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Hi, Good job, Waiting for your code :) Regards, Bycn82 From owner-freebsd-ipfw@FreeBSD.ORG Sun Oct 5 16:34:04 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1C66A50 for ; Sun, 5 Oct 2014 16:34:04 +0000 (UTC) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 776A9BBF for ; Sun, 5 Oct 2014 16:34:04 +0000 (UTC) Received: from x220.rlwinm.de (p5DC7F1B4.dip0.t-ipconnect.de [93.199.241.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 258E57081 for ; Sun, 5 Oct 2014 18:33:53 +0200 (CEST) Message-ID: <543172CA.80602@rlwinm.de> Date: Sun, 05 Oct 2014 18:33:14 +0200 From: Jan Bramkamp User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: HEADS UP: Merging projects/ipfw to HEAD References: <542FE9A7.9090208@FreeBSD.org> In-Reply-To: <542FE9A7.9090208@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 16:34:04 -0000 On 04.10.2014 14:35, Alexander V. Chernikov wrote: > Hi, > > I'm going to merge projects/ipfw branch to HEAD in the middle of next > week. > > What has changed: > > Main user-visible changes are related to tables: > > * Tables are now identified by names, not numbers. There can be up to > 65k tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them > atomically with rules. > * More functionality is supported (swap, lock, limits, user-level > lookup, batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet > fields at once. > * Ability to add different type of lookup algorithms for particular > table type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array > and flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for > different tablearg users Are IPv6 addresses supported as tablearg (in fwd)? From owner-freebsd-ipfw@FreeBSD.ORG Sun Oct 5 16:45:06 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72FE1E7A for ; Sun, 5 Oct 2014 16:45:06 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (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 34B39CE8 for ; Sun, 5 Oct 2014 16:45:06 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XakwH-000LFN-GY; Sun, 05 Oct 2014 16:29:25 +0400 Message-ID: <54317546.6040308@FreeBSD.org> Date: Sun, 05 Oct 2014 20:43:50 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Jan Bramkamp , freebsd-ipfw@freebsd.org Subject: Re: HEADS UP: Merging projects/ipfw to HEAD References: <542FE9A7.9090208@FreeBSD.org> <543172CA.80602@rlwinm.de> In-Reply-To: <543172CA.80602@rlwinm.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 16:45:06 -0000 On 05.10.2014 20:33, Jan Bramkamp wrote: > On 04.10.2014 14:35, Alexander V. Chernikov wrote: >> Hi, >> >> I'm going to merge projects/ipfw branch to HEAD in the middle of next >> week. >> >> What has changed: >> >> Main user-visible changes are related to tables: >> >> * Tables are now identified by names, not numbers. There can be up to >> 65k tables with up to 63-byte long names. >> * Tables are now set-aware (default off), so you can switch/move them >> atomically with rules. >> * More functionality is supported (swap, lock, limits, user-level >> lookup, batched add/del) by generic table code. >> * New table types are added (flow) so you can match multiple packet >> fields at once. >> * Ability to add different type of lookup algorithms for particular >> table type has been added. >> * New table algorithms are added (cidr:hash, iface:array, number:array >> and flow:hash) to make certain types of lookup more effective. >> * Table value are now capable of holding multiple data fields for >> different tablearg users > Are IPv6 addresses supported as tablearg (in fwd)? Well, _currently_ not. However, it can be done in 1-2 hours of work. You already can specify IPv6 address as one of the value types for tablearg, the only thing that needs to be implemented is runtime code that applies this tablearg. > _______________________________________________ > 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 Mon Oct 6 02:26:40 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83F12F9A; Mon, 6 Oct 2014 02:26:40 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70561C07; Mon, 6 Oct 2014 02:26:39 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id cc10so3226573wib.7 for ; Sun, 05 Oct 2014 19:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=24XaLrHVTJ+lAOxAwwAMMYZOAzuJt9+Bo+/S3T37Jjc=; b=pSzAUlyG8OR+w3qV8PRbJp+IKgKibDSDuA7mnUe5Ny8g2F9/IwhPQ/TRRPxn7SfeR3 Izuo+eZ1z8ckm9OfcOTK1hNLZzA41F9bjvXrwQpHQmXIfk2VsbLWFKm13fuhxyKBrMpl tFnNU3T9tGO/ip3L+D6N6QW6Z0NN6Vau/B58BDp5YCaBTy972hqvxJtLvploNBFzQRFL chxbOPhfJJ4hiU2f91lxgN4lyqXNyNFQITlj1KhNBGxNboxsFm0HUmzYniYKIuTXT8fE DEXLZRWiNNx0fBPu5+vUT/zk7JoQpclVqz5NAQQ+pdEwlkxLPMtIYwj15w+91GeS76Dr VWPw== MIME-Version: 1.0 X-Received: by 10.180.103.131 with SMTP id fw3mr15792406wib.77.1412562397684; Sun, 05 Oct 2014 19:26:37 -0700 (PDT) Received: by 10.216.159.193 with HTTP; Sun, 5 Oct 2014 19:26:37 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: <542FE9A7.9090208@FreeBSD.org> References: <542FE9A7.9090208@FreeBSD.org> Date: Mon, 6 Oct 2014 10:26:37 +0800 Message-ID: Subject: Re: HEADS UP: Merging projects/ipfw to HEAD From: Marcelo Araujo To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-current , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 02:26:40 -0000 Hey Alexander, Very nice work, thank you so much to bring these stuff to us. Best Regards, 2014-10-04 20:35 GMT+08:00 Alexander V. Chernikov : > Hi, > > I'm going to merge projects/ipfw branch to HEAD in the middle of next week. > > What has changed: > > Main user-visible changes are related to tables: > > * Tables are now identified by names, not numbers. There can be up to 65k > tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them > atomically with rules. > * More functionality is supported (swap, lock, limits, user-level lookup, > batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet fields > at once. > * Ability to add different type of lookup algorithms for particular table > type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array and > flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for > different tablearg users > > Some examples (see ipfw(8) manual page for the description): > > 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port > algo flow:hash valtype skipto,fib > 0:02 [2] zfscurr0# ipfw table fl2 info > +++ table(fl2), set(0) +++ > kindex: 0, type: flow:src-ip,proto,dst-port > valtype: number, references: 0 > algorithm: flow:hash > items: 0, size: 280 > 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 > 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 > 0:02 [2] zfscurr0# ipfw table fl2 list > +++ table(fl2), set(0) +++ > 2a02:6b8::333,6,443 45000 > 10.0.0.92,6,80 22000 > 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 > flow 'table(fl2)' > > ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" > ipfw table mi_test add 10.0.0.8/30 > ipfw table mi_test add 2a02:6b8:b010::1/64 25 > > # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 > added: 1.1.1.1/32 1111 > added: 2.2.2.2/32 2222 > # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 > exists: 2.2.2.2/32 2200 > added: 4.4.4.4/32 4444 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error but keeps inserted items > # ipfw table si list > +++ table(si), set(0) +++ > 1.1.1.1/32 1111 > 2.2.2.2/32 2222 > 4.4.4.4/32 4444 > # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 5.5.5.5/32 > 5555 > added(reverted): 3.3.3.3/32 3333 > exists: 4.4.4.4/32 4400 > ignored: 5.5.5.5/32 5555 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error and reverts added records > > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 bytes > * interface tables uses array of existing ifindexes for faster match > > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & new > binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset in > old binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something may > be broken here. Anyway, this can be fixed for MFC > > Internal changes:. > Changing table ids to numbers resulted in format modification for most > sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, > inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned IP_FW3-based > codes. > * The remaining opcodes were also converted to be able to eliminate all > older opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* > directly to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds > extended data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit > effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time (eats > 512K). > > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and > actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct > ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 9 21:02:12 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ED71FE1; Thu, 9 Oct 2014 21:02:12 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (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 ADA92AAA; Thu, 9 Oct 2014 21:02:11 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=[10.0.0.120]) by mail.ipfw.ru with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XcGr8-00033L-DF; Thu, 09 Oct 2014 20:46:22 +0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: HEADS UP: Merging projects/ipfw to HEAD From: Alexander V. Chernikov In-Reply-To: <542FE9A7.9090208@FreeBSD.org> Date: Fri, 10 Oct 2014 01:02:05 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02957253-78AC-4CDF-AD48-86D219667F02@ipfw.ru> References: <542FE9A7.9090208@FreeBSD.org> To: "Alexander V. Chernikov" X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-current@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 21:02:12 -0000 On 04 Oct 2014, at 16:35, Alexander V. Chernikov = wrote: > Hi, >=20 > I'm going to merge projects/ipfw branch to HEAD in the middle of next = week. Merged in r 272840. >=20 > What has changed: >=20 > Main user-visible changes are related to tables: >=20 > * Tables are now identified by names, not numbers. There can be up to = 65k tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them = atomically with rules. > * More functionality is supported (swap, lock, limits, user-level = lookup, batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet = fields at once. > * Ability to add different type of lookup algorithms for particular = table type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array = and flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for = different tablearg users >=20 > Some examples (see ipfw(8) manual page for the description): >=20 > 0:02 [2] zfscurr0# ipfw table fl2 create type = flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib > 0:02 [2] zfscurr0# ipfw table fl2 info > +++ table(fl2), set(0) +++ > kindex: 0, type: flow:src-ip,proto,dst-port > valtype: number, references: 0 > algorithm: flow:hash > items: 0, size: 280 > 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 > 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 > 0:02 [2] zfscurr0# ipfw table fl2 list > +++ table(fl2), set(0) +++ > 2a02:6b8::333,6,443 45000 > 10.0.0.92,6,80 22000 > 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 = flow 'table(fl2)' >=20 > ipfw table mi_test create type cidr algo "cidr:hash masks=3D/30,/64" > ipfw table mi_test add 10.0.0.8/30 > ipfw table mi_test add 2a02:6b8:b010::1/64 25 >=20 > # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 > added: 1.1.1.1/32 1111 > added: 2.2.2.2/32 2222 > # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 > exists: 2.2.2.2/32 2200 > added: 4.4.4.4/32 4444 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error but keeps inserted items > # ipfw table si list > +++ table(si), set(0) +++ > 1.1.1.1/32 1111 > 2.2.2.2/32 2222 > 4.4.4.4/32 4444 > # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 = 5.5.5.5/32 5555 > added(reverted): 3.3.3.3/32 3333 > exists: 4.4.4.4/32 4400 > ignored: 5.5.5.5/32 5555 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error and reverts added records >=20 > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 = bytes > * interface tables uses array of existing ifindexes for faster match >=20 > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & = new binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset = in old binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something = may be broken here. Anyway, this can be fixed for MFC >=20 > Internal changes:. > Changing table ids to numbers resulted in format modification for most = sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, = inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned = IP_FW3-based codes. > * The remaining opcodes were also converted to be able to eliminate = all older opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* = directly to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds = extended data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit = effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time = (eats 512K). >=20 > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and = actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct = ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-ipfw@FreeBSD.ORG Sat Oct 11 14:15:09 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17AAEAF5; Sat, 11 Oct 2014 14:15:09 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 B3924C72; Sat, 11 Oct 2014 14:15:07 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s9BEF5XA046649; Sat, 11 Oct 2014 07:15:05 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s9BEF58c046648; Sat, 11 Oct 2014 07:15:05 -0700 (PDT) (envelope-from david) Date: Sat, 11 Oct 2014 07:15:05 -0700 From: David Wolfskill To: "Alexander V. Chernikov" Subject: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD] Message-ID: <20141011141505.GA46277@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org References: <542FE9A7.9090208@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <542FE9A7.9090208@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , freebsd-current@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 14:15:09 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote: > Hi, >=20 > I'm going to merge projects/ipfw branch to HEAD in the middle of next wee= k. > .... OK; I was able to build & install head @r272938 this morning on my laptop; on reboot, I was greeted by a panic. Now, this is a laptop, so I don't have a serial console -- but I was able to "call doadump", then reboot with the wireless NIC disabled (to avoid the panic) and get the dump & core.txt captured. Here's the first chunk of the core.txt file: localhost dumped core - see /var/crash/vmcore.0 Sat Oct 11 07:02:26 PDT 2014 FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1392 r272938M/272938:= 1100037: Sat Oct 11 05:44:30 PDT 2014 root@g1-235.catwhisker.org:/commo= n/S4/obj/usr/src/sys/CANARY i386 panic: resize_storage() notify failure GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: resize_storage() notify failure cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper(c10ebfd8,d1070720,fc,10000000,1,...) at 0xc0528cdd = =3D db_trace_self_wrapper+0x2d/frame 0xfa0cc508 kdb_backtrace(c12a9e27,0,c111af52,fa0cc5dc,fa0cc598,...) at 0xc0b22180 =3D = kdb_backtrace+0x30/frame 0xfa0cc570 vpanic(c1447c52,100,c111af52,fa0cc5dc,fa0cc5dc,...) at 0xc0ae7b8d =3D vpani= c+0x11d/frame 0xfa0cc5ac kassert_panic(c111af52,fa0cc6f8,223,1e8,c0b71417,...) at 0xc0ae7a6a =3D kas= sert_panic+0xea/frame 0xfa0cc5d0 ipfw_link_table_values(c1518498,fa0cc6f8,25a,fa0cc728,c1469c5c,...) at 0xc0= d25cfd =3D ipfw_link_table_values+0x5ed/frame 0xfa0cc6a0 add_table_entry(c1518498,fa0cc7f0,fa0cc800,0,1,...) at 0xc0d1be78 =3D add_t= able_entry+0x348/frame 0xfa0cc7c8 manage_table_ent_v1(c1518498,fa0cca08,fa0cc870,8,c0d17710,...) at 0xc0d202b= 9 =3D manage_table_ent_v1+0x1c9/frame 0xfa0cc828 ipfw_ctl3(fa0ccbe0,2,fa0ccba8,c0a9ffc4,fa0ccbd0,...) at 0xc0d1834d =3D ipfw= _ctl3+0xacd/frame 0xfa0ccb20 rip_ctloutput(d2432dc0,fa0ccbe0,ffffffff,200007f,1fffff,...) at 0xc0c3cf49 = =3D rip_ctloutput+0x299/frame 0xfa0ccb48 sogetopt(d2432dc0,fa0ccbe0,fa0ccbd0,0,fa0ccbf8,...) at 0xc0b6c670 =3D soget= opt+0xb0/frame 0xfa0ccba8 kern_getsockopt(d03afc40,4,0,30,bfbfd850,...) at 0xc0b71556 =3D kern_getsoc= kopt+0x116/frame 0xfa0ccc0c sys_getsockopt(d03afc40,fa0cccc8,c12ab55e,d5,c1455210,...) at 0xc0b71417 = =3D sys_getsockopt+0x67/frame 0xfa0ccc40 syscall(fa0ccd08) at 0xc0f7c76b =3D syscall+0x31b/frame 0xfa0cccfc Xint0x80_syscall() at 0xc0f665b1 =3D Xint0x80_syscall+0x21/frame 0xfa0cccfc --- syscall (118, FreeBSD ELF32, sys_getsockopt), eip =3D 0x2815a3c7, esp = =3D 0xbfbfd2e4, ebp =3D 0xbfbfd300 --- KDB: enter: panic Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. Loaded symbols for /boot/kernel/iwn5000fw.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols #0 doadump (textdump=3D0) at pcpu.h:233 233 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3D0) at pcpu.h:233 #1 0xc0526acd in db_fncall (dummy1=3D-99826980, dummy2=3D0, dummy3=3D15738= 88,=20 dummy4=3D0xfa0cc2b4 "\036\211\220=C0=B8\026M=C1") at /usr/src/sys/ddb/db_command.c:578 #2 0xc05267ab in db_command (cmd_table=3D) at /usr/src/sys/ddb/db_command.c:449 #3 0xc05264f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xc0528e20 in db_trap (type=3D,=20 code=3D) at /usr/src/sys/ddb/db_main.c:251 #5 0xc0b226f4 in kdb_trap (type=3D,=20 code=3D, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xc0f7ba87 in trap (frame=3D) at /usr/src/sys/i386/i386/trap.c:693 #7 0xc0f6651c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #8 0xc0b21f7d in kdb_enter (why=3D0xc10e77dd "panic",=20 msg=3D) at cpufunc.h:71 #9 0xc0ae7bb1 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:739 #10 0xc0ae7a6a in kassert_panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:634 #11 0xc0d25cfd in ipfw_link_table_values (ch=3D0x0, ts=3D0xfa0cc6f8) at /usr/src/sys/netpfil/ipfw/ip_fw_table_value.c:560 #12 0xc0d1be78 in add_table_entry (ch=3D0xc1518498, tei=3D0xfa0cc800,=20 flags=3D0 '\0', count=3D1) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:6= 20 #13 0xc0d202b9 in manage_table_ent_v1 (op3=3D,=20 sd=3D) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:= 1038 #14 0xc0d1834d in ipfw_ctl3 (sopt=3D0xfa0ccbe0) at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:2723 #15 0xc0c3cf49 in rip_ctloutput (so=3D, sopt=3D0xfa0cc= be0) at /usr/src/sys/netinet/raw_ip.c:583 #16 0xc0b6c670 in sogetopt (so=3D0xd2432dc0, sopt=3D0xfa0ccbe0) at /usr/src/sys/kern/uipc_socket.c:2721 #17 0xc0b71556 in kern_getsockopt (s=3D,=20 level=3D, name=3D,=20 val=3D, valseg=3D,=20 valsize=3D) at /usr/src/sys/kern/uipc_syscalls.c:1= 589 #18 0xc0b71417 in sys_getsockopt (uap=3D0xfa0cccc8) at /usr/src/sys/kern/uipc_syscalls.c:1535 #19 0xc0f7c76b in syscall (frame=3D) at subr_syscall.c= :133 #20 0xc0f665b1 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:269 #21 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb)=20 I'll be happy to poke around more, test patches, .... The "poking" will likely be a bit on the slow side, since I won't have connectivity while the machine is running head (until the issue is circumvented, at least); as I type, it's running stable/9 (also just built today). And yes, since it's a laptop, and it's thus subject to being connected to networks I don't control, I run IPFW on it -- same rulesets & tables whether it's running stable/9, stable/10, or head. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUOTtoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7zp4QAI7bvb/8tCVS7oM9PckTFKf4 79mT4Q6XFvKx55oOx128I/DVHLPkXv/Z6Vtvhb4TVavoMlwsCHju84Wd7pwfUddK ePGY4k4h179xcn3puo2nW2HCrt1JB/EDGEPFOqRu0eegwOA+cHmuL7OLLQ6GrESE iCYXdLtjmYluOplWzuv4jGLgeYtncULumcrWqKbZIMbqLYFTqKMPtyE2cLsTQgwz tEEvz5TQ7KwMJmATLprJMKzd7Y8ZjRCONHd8DGoPz5crI0IN0H7X/wBvSZ+F/F/H 3pJROSdDT5x9uwPQ9U0T/a3iktliX85i5PPT7y2i+Inzd6GD60CcLQF3s7cdw5V8 Sykqt25Y25kMT9K00JTGk7qr2fXcWAZgJx1aPWdHyp6Oy4AgUxh/oIaJmQC1pcHd Pu4tW6xlZpytxdTaUgEDRFJ3vvPdkmrIEmeWLq5btlCWvK/W6A3LsKPxiAqD30Ky 3WF1vAKrOh6wLarQp7WvZK/PBETFYIcACFdawy/4Q6snYz5XayTvvjEUVqGPOKqv 4IbsPJqIqq8z2xATTgumyqOkFAKo1TxMSDR/UeoVYhN8NLDmdw+O8a8amulYIDcK Oy9vWZJC7vFzItYKGoEP+WUP6Hx+saq6Vl1YDA7qRVaOj2ED+Q7aLtI1rknorHQu 4EVLauLiBApu4g1Nn1w1 =QWE5 -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-ipfw@FreeBSD.ORG Sat Oct 11 14:42:38 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2E90221; Sat, 11 Oct 2014 14:42:38 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (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 5B561F16; Sat, 11 Oct 2014 14:42:38 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xctsp-0008IR-RQ; Sat, 11 Oct 2014 14:26:43 +0400 Message-ID: <5439418A.5050903@FreeBSD.org> Date: Sat, 11 Oct 2014 18:41:14 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: David Wolfskill , "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org Subject: Re: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD] References: <542FE9A7.9090208@FreeBSD.org> <20141011141505.GA46277@albert.catwhisker.org> In-Reply-To: <20141011141505.GA46277@albert.catwhisker.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 14:42:38 -0000 On 11.10.2014 18:15, David Wolfskill wrote: > On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote: >> Hi, >> >> I'm going to merge projects/ipfw branch to HEAD in the middle of next week. >> .... > OK; I was able to build & install head @r272938 this morning on my > laptop; on reboot, I was greeted by a panic. Ups. Not the best greeting, definitely. Can you send me ipfw ruleset? > > Now, this is a laptop, so I don't have a serial console -- but I was > able to "call doadump", then reboot with the wireless NIC disabled (to Do you have some hooks to run ipfw on iface-up? > avoid the panic) and get the dump & core.txt captured. > > Here's the first chunk of the core.txt file: > > localhost dumped core - see /var/crash/vmcore.0 > > Sat Oct 11 07:02:26 PDT 2014 > > FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1392 r272938M/272938:1100037: Sat Oct 11 05:44:30 PDT 2014 root@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > > panic: resize_storage() notify failure > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: resize_storage() notify failure > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c10ebfd8,d1070720,fc,10000000,1,...) at 0xc0528cdd = db_trace_self_wrapper+0x2d/frame 0xfa0cc508 > kdb_backtrace(c12a9e27,0,c111af52,fa0cc5dc,fa0cc598,...) at 0xc0b22180 = kdb_backtrace+0x30/frame 0xfa0cc570 > vpanic(c1447c52,100,c111af52,fa0cc5dc,fa0cc5dc,...) at 0xc0ae7b8d = vpanic+0x11d/frame 0xfa0cc5ac > kassert_panic(c111af52,fa0cc6f8,223,1e8,c0b71417,...) at 0xc0ae7a6a = kassert_panic+0xea/frame 0xfa0cc5d0 > ipfw_link_table_values(c1518498,fa0cc6f8,25a,fa0cc728,c1469c5c,...) at 0xc0d25cfd = ipfw_link_table_values+0x5ed/frame 0xfa0cc6a0 > add_table_entry(c1518498,fa0cc7f0,fa0cc800,0,1,...) at 0xc0d1be78 = add_table_entry+0x348/frame 0xfa0cc7c8 > manage_table_ent_v1(c1518498,fa0cca08,fa0cc870,8,c0d17710,...) at 0xc0d202b9 = manage_table_ent_v1+0x1c9/frame 0xfa0cc828 > ipfw_ctl3(fa0ccbe0,2,fa0ccba8,c0a9ffc4,fa0ccbd0,...) at 0xc0d1834d = ipfw_ctl3+0xacd/frame 0xfa0ccb20 > rip_ctloutput(d2432dc0,fa0ccbe0,ffffffff,200007f,1fffff,...) at 0xc0c3cf49 = rip_ctloutput+0x299/frame 0xfa0ccb48 > sogetopt(d2432dc0,fa0ccbe0,fa0ccbd0,0,fa0ccbf8,...) at 0xc0b6c670 = sogetopt+0xb0/frame 0xfa0ccba8 > kern_getsockopt(d03afc40,4,0,30,bfbfd850,...) at 0xc0b71556 = kern_getsockopt+0x116/frame 0xfa0ccc0c > sys_getsockopt(d03afc40,fa0cccc8,c12ab55e,d5,c1455210,...) at 0xc0b71417 = sys_getsockopt+0x67/frame 0xfa0ccc40 > syscall(fa0ccd08) at 0xc0f7c76b = syscall+0x31b/frame 0xfa0cccfc > Xint0x80_syscall() at 0xc0f665b1 = Xint0x80_syscall+0x21/frame 0xfa0cccfc > --- syscall (118, FreeBSD ELF32, sys_getsockopt), eip = 0x2815a3c7, esp = 0xbfbfd2e4, ebp = 0xbfbfd300 --- > KDB: enter: panic > > Reading symbols from /boot/kernel/linux.ko.symbols...done. > Loaded symbols for /boot/kernel/linux.ko.symbols > Reading symbols from /boot/kernel/coretemp.ko.symbols...done. > Loaded symbols for /boot/kernel/coretemp.ko.symbols > Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. > Loaded symbols for /boot/kernel/iwn5000fw.ko.symbols > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. > Loaded symbols for /boot/kernel/tmpfs.ko.symbols > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > Loaded symbols for /boot/kernel/linprocfs.ko.symbols > #0 doadump (textdump=0) at pcpu.h:233 > 233 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=0) at pcpu.h:233 > #1 0xc0526acd in db_fncall (dummy1=-99826980, dummy2=0, dummy3=1573888, > dummy4=0xfa0cc2b4 "\036\211\220À¸\026MÁ") > at /usr/src/sys/ddb/db_command.c:578 > #2 0xc05267ab in db_command (cmd_table=) > at /usr/src/sys/ddb/db_command.c:449 > #3 0xc05264f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 > #4 0xc0528e20 in db_trap (type=, > code=) at /usr/src/sys/ddb/db_main.c:251 > #5 0xc0b226f4 in kdb_trap (type=, > code=, tf=) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xc0f7ba87 in trap (frame=) > at /usr/src/sys/i386/i386/trap.c:693 > #7 0xc0f6651c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 > #8 0xc0b21f7d in kdb_enter (why=0xc10e77dd "panic", > msg=) at cpufunc.h:71 > #9 0xc0ae7bb1 in vpanic (fmt=, ap=) > at /usr/src/sys/kern/kern_shutdown.c:739 > #10 0xc0ae7a6a in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:634 > #11 0xc0d25cfd in ipfw_link_table_values (ch=0x0, ts=0xfa0cc6f8) > at /usr/src/sys/netpfil/ipfw/ip_fw_table_value.c:560 > #12 0xc0d1be78 in add_table_entry (ch=0xc1518498, tei=0xfa0cc800, > flags=0 '\0', count=1) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:620 > #13 0xc0d202b9 in manage_table_ent_v1 (op3=, > sd=) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:1038 > #14 0xc0d1834d in ipfw_ctl3 (sopt=0xfa0ccbe0) > at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:2723 > #15 0xc0c3cf49 in rip_ctloutput (so=, sopt=0xfa0ccbe0) > at /usr/src/sys/netinet/raw_ip.c:583 > #16 0xc0b6c670 in sogetopt (so=0xd2432dc0, sopt=0xfa0ccbe0) > at /usr/src/sys/kern/uipc_socket.c:2721 > #17 0xc0b71556 in kern_getsockopt (s=, > level=, name=, > val=, valseg=, > valsize=) at /usr/src/sys/kern/uipc_syscalls.c:1589 > #18 0xc0b71417 in sys_getsockopt (uap=0xfa0cccc8) > at /usr/src/sys/kern/uipc_syscalls.c:1535 > #19 0xc0f7c76b in syscall (frame=) at subr_syscall.c:133 > #20 0xc0f665b1 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:269 > #21 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > > I'll be happy to poke around more, test patches, .... The "poking" will > likely be a bit on the slow side, since I won't have connectivity while > the machine is running head (until the issue is circumvented, at least); > as I type, it's running stable/9 (also just built today). And yes, > since it's a laptop, and it's thus subject to being connected to > networks I don't control, I run IPFW on it -- same rulesets & tables > whether it's running stable/9, stable/10, or head. > > Peace, > david From owner-freebsd-ipfw@FreeBSD.ORG Sat Oct 11 15:59:55 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7774F555; Sat, 11 Oct 2014 15:59:55 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 2013883F; Sat, 11 Oct 2014 15:59:54 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s9BFxrib047071; Sat, 11 Oct 2014 08:59:53 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s9BFxrXG047070; Sat, 11 Oct 2014 08:59:53 -0700 (PDT) (envelope-from david) Date: Sat, 11 Oct 2014 08:59:53 -0700 From: David Wolfskill To: "Alexander V. Chernikov" Subject: Re: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD] Message-ID: <20141011155953.GY1295@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HQLHrCACpVdwMl/9" Content-Disposition: inline In-Reply-To: <54394728.2090402@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , freebsd-current@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 15:59:55 -0000 --HQLHrCACpVdwMl/9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 11, 2014 at 07:05:12PM +0400, Alexander V. Chernikov wrote: > ... > Whoops. My bad. > It should be fixed in r272940. > ... Confirmed: I'm not running: FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1393 r272938M/272938:= 1100037: Sat Oct 11 08:45:34 PDT 2014 root@localhost:/common/S4/obj/usr= /src/sys/CANARY i386 after having hand-applied the patch in r272940, rebuilt, reinstalled, and rebooted. Thank you for the quick work! :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --HQLHrCACpVdwMl/9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUOVP4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7/O4P/jwuT6lUeZ/L0zMk8fLt9GiT cc0aonyMCSYllZLJbhOXuN0u6aGrV5DZKTRjFLBJgwqwbm25TevVEdxdUlDXseyo 2+nQokAtD+kc4mutk3yKCREZcgnOvavICma5WX85uOHRRvCsDsN8iWSfehEdidcu VGHWwc5/Ny+dy/VYDAR3sUQH5w4P6ngFfL5Ij8JTJdyXQ3gZ2nb+bIpvMy7p8FLw JQBCg8qZObt0+/mtI1DU5tEoPOzDvw4AQL0Jezz+TxDBF5kS8G2g041ZBonpXdVz Qiz0t4TtgdGBFqc/73OFMd517xAHYjzDbTWRvcUDFbccejLuIonGyG3k5yvwlcDY eml6sqRZucZKXdg0eCUd06sKXmE1+jbktrtr6Nv8b9ePPNrWwx0zg2ttWp0Kyvvg HRm1qrUpIeUoEBj6QVt8uVD6q4isWJ83J2/WMUgQ8GWMqY1I22HXNDQd59R2glNI xLCkkpOc74QmGvGX00NA1an7VoveLQ+5gr53ZZ8iOLTfr92lmb+qjP9oyNBfJ5gI g6SINW5mzEzIGbPcqbkxm5aDe4RfVQrrdur+L+KkJtdWOwrhGrI3WW/8xoJxO6o7 AkjwhyD5M5+UVN9AmN3YmZpX9p0dJUtRymyNlGADwnJ+qUbQIu2OrsYvOy9ZJL/E CIsnAbMvelIGEIbFwXBN =Q/2Y -----END PGP SIGNATURE----- --HQLHrCACpVdwMl/9-- From owner-freebsd-ipfw@FreeBSD.ORG Sat Oct 11 20:04:13 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C2A1A69; Sat, 11 Oct 2014 20:04:13 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3DEB17E; Sat, 11 Oct 2014 20:04:11 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9BK3k3s078401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Oct 2014 05:03:57 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s9BK3hj9038084; Sun, 12 Oct 2014 05:03:46 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 12 Oct 2014 05:02:11 +0900 (JST) Message-Id: <20141012.050211.468265599523763400.hrs@allbsd.org> To: smithi@nimnet.asn.au Subject: Re: net.inet{,6}.fw.enable in /etc/rc From: Hiroki Sato In-Reply-To: <20141003025830.D48482@sola.nimnet.asn.au> References: <542155FB.9020801@freebsd.org> <20141002.163913.1611863032602700090.hrs@allbsd.org> <20141003025830.D48482@sola.nimnet.asn.au> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Sun_Oct_12_05_02_11_2014_491)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sun, 12 Oct 2014 05:04:03 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: bu7cher@yandex.ru, julian@freebsd.org, ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 20:04:13 -0000 ----Security_Multipart0(Sun_Oct_12_05_02_11_2014_491)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Oct_12_05_02_11_2014_591)--" Content-Transfer-Encoding: 7bit ----Next_Part(Sun_Oct_12_05_02_11_2014_591)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Smith wrote in <20141003025830.D48482@sola.nimnet.asn.au>: sm> which rules will be flushed when /etc/rc.d/ipfw runs, but should enable sm> DHCP to work? I'm not sure whether those rules are exactly correct or sm> sufficient for DHCP, but principle is to anly allow what's necessary in sm> the circumstances this addresses, vastly reducing vulnerable window. sm> sm> Using such a method, there should be no need to modify rc.d/ipfw? I created an experimental patch based on an idea installing a minimal ruleset. Please review the attached patch. rc.d/ipfw0 script to install such a ruleset is invoked before rc.d/netif. The following two knobs are added: $firewall_minimal_rules_enable Enable/disable installing a minimal ruleset. $firewall_minimal_ruleset Ruleset number to be used for the ruleset. sm> > Does ipfw have rules which depend on interface initialization? If sm> > not, moving rc.d/ipfw to just before rc.d/netif may be a better idea. sm> sm> It can. If using (say) mpd with dialup or ADSL modems, as I do, the sm> interface - here ng0 - needs to preexist, needing an IP address too. sm> sm> I think that by now, many will likely rely on netif preceding ipfw. AFAICC an IPFW rule for ng0 can be installed before the interface is created. Do you have a specific rule which is problematic if IPFW rules are loaded before rc.d/netif runs? I am also using mpd and a lot of cloned interfaces on my router box but it worked fine. -- Hiroki ----Next_Part(Sun_Oct_12_05_02_11_2014_591)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc_ipfw0.20141012-1.diff" Index: etc/defaults/rc.conf =================================================================== --- etc/defaults/rc.conf (revision 272887) +++ etc/defaults/rc.conf (working copy) @@ -116,6 +116,11 @@ wpa_supplicant_conf_file="/etc/wpa_supplicant.conf" # firewall_enable="NO" # Set to YES to enable firewall functionality +firewall_minimal_rules_enable="YES" # Set to YES to temporarily apply + # minimal rules required for interface + # initialization before applying the full rules. +firewall_minimal_ruleset="30" # Ruleset number for minimal rules +firewall_link_enable="NO" # Set to YES to enable L2 filtering firewall_script="/etc/rc.firewall" # Which script to run to set up the firewall firewall_type="UNKNOWN" # Firewall type (see /etc/rc.firewall) firewall_quiet="NO" # Set to YES to suppress rule display Index: etc/rc.firewall =================================================================== --- etc/rc.firewall (revision 272887) +++ etc/rc.firewall (working copy) @@ -42,6 +42,7 @@ ############ # Define the firewall type in /etc/rc.conf. Valid values are: +# minimal - will allow only packets required for interface initialization # open - will allow anyone in # client - will try to protect just this machine # simple - will try to protect a whole network @@ -138,8 +139,14 @@ # ${fwcmd} -f flush -setup_loopback -setup_ipv6_mandatory +case ${firewall_type} in +[Mm][Ii][Nn][Ii][Mm][Aa][Ll]) +;; +*) + setup_loopback + setup_ipv6_mandatory +;; +esac ############ # Network Address Translation. All packets are passed to natd(8) @@ -187,6 +194,51 @@ # Prototype setups. # case ${firewall_type} in +[Mm][Ii][Nn][Ii][Mm][Aa][Ll]) + # + # Temporary rule set for network interface initialization. + # + case $firewall_minimal_ruleset in + [0-9]|[12][0-9]|30) + # Valid if 0-30. + ;; + *) + warn "Invalid ruleset number: $firewall_minimal_ruleset." + false + ;; + esac + $fwcmd -q set disable $firewall_minimal_ruleset + $fwcmd -q delete set $firewall_minimal_ruleset + + _set="set $firewall_minimal_ruleset" + + # DHCPv4 + # DHCPDISCOVER (from 0.0.0.0/32) + # DHCPREQUEST (broadcast) + $fwcmd -q add 65001 $_set allow udp \ + from any to 255.255.255.255/32 \ + mac ff:ff:ff:ff:ff:ff any \ + src-port 68 dst-port 67 layer2 out + + # DHCPREQUEST (unicast) + $fwcmd -q add 65001 $_set allow udp \ + from any to any \ + src-port 68 dst-port 67 layer2 out + + # DHCPOFFER, DHCPACK + $fwcmd -q add 65001 $_set allow udp \ + from any to any \ + src-port 67 dst-port 68 layer2 in + + # TODO: DHCPv6 65002 + + # ICMPv6 DAD + $fwcmd -q add 65003 $_set allow ipv6-icmp from :: to ff02::/16 + + # ICMPv6 link-local communication including ND/NS and RS/RA + $fwcmd -q add 65004 $_set allow ipv6-icmp from fe80::/10 to fe80::/10 + $fwcmd -q add 65004 $_set allow ipv6-icmp from fe80::/10 to ff02::/16 + ;; [Oo][Pp][Ee][Nn]) ${fwcmd} add 65000 pass all from any to any ;; Index: etc/rc.d/ipfw =================================================================== --- etc/rc.d/ipfw (revision 272887) +++ etc/rc.d/ipfw (working copy) @@ -31,6 +31,15 @@ if checkyesno firewall_nat_enable; then required_modules="$required_modules ipfw_nat" fi + if checkyesno firewall_minimal_rules_enable; then + # Remove minimum ruleset. + /sbin/ipfw delete set $firewall_minimal_ruleset + fi + if checkyesno firewall_link_enable; then + ${SYSCTL_W} net.link.ether.ipfw=1 + else + ${SYSCTL_W} net.link.ether.ipfw=0 + fi } ipfw_start() Index: etc/rc.d/ipfw0 =================================================================== --- etc/rc.d/ipfw0 (revision 0) +++ etc/rc.d/ipfw0 (working copy) @@ -0,0 +1,71 @@ +#!/bin/sh +# +# $FreeBSD$ +# + +# PROVIDE: ipfw0 +# REQUIRE: FILESYSTEMS +# BEFORE: netif ipfw +# KEYWORD: nojailvnet + +. /etc/rc.subr +. /etc/network.subr + +name="ipfw0" +desc="Setup minimal firewall rules required for network interface configuration" +rcvar="firewall_enable" +required_modules="ipfw" +start_cmd="${name}_start" +stop_cmd="${name}_stop" + +fwcmd="/sbin/ipfw -q" + +ipfw0_start() +{ + if ! checkyesno firewall_minimal_rules_enable; then + return 1 + fi + case $firewall_minimal_ruleset in + [0-9]|[12][0-9]|30) + # Valid if 0-30. + ;; + *) + warn "Invalid ruleset number: $firewall_minimal_ruleset." + return 1 + ;; + esac + + if /bin/sh /etc/rc.firewall minimal; then + echo "Minimal IPFW ruleset loaded to set" \ + "$firewall_minimal_ruleset." + else + return 1 + fi + + $fwcmd set enable $firewall_minimal_ruleset + # Enable L2 filtering temporarily. + ${SYSCTL_W} net.link.ether.ipfw=1 > /dev/null + + # Enable IPFW temporarily. rc.d/ipfw will remove the ruleset. + ${SYSCTL_W} -qi net.inet.ip.fw.enable=1 > /dev/null + ${SYSCTL_W} -qi net.inet6.ip6.fw.enable=1 > /dev/null +} + +ipfw0_stop() +{ + + $fwcmd delete set $firewall_minimal_ruleset +} + +load_rc_config $name +case $1 in +*start) + if [ "$(${SYSCTL_N} -iq net.inet.ip.fw.enable)" = 1 ] && \ + [ "$($fwcmd list 65535)" = "65535 deny ip from any to any" ] && \ + ! checkyesno firewall_enable; then + warn "firewall_enable=\"NO\" can prevent network interface" \ + "initialization." + fi +;; +esac +run_rc_command $* Property changes on: etc/rc.d/ipfw0 ___________________________________________________________________ Added: svn:executable ## -0,0 +1 ## +* \ No newline at end of property Index: etc/rc.d/Makefile =================================================================== --- etc/rc.d/Makefile (revision 272887) +++ etc/rc.d/Makefile (working copy) @@ -61,6 +61,7 @@ ip6addrctl \ ipfilter \ ipfs \ + ipfw0 \ ipfw \ ipmon \ ipnat \ ----Next_Part(Sun_Oct_12_05_02_11_2014_591)---- ----Security_Multipart0(Sun_Oct_12_05_02_11_2014_491)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlQ5jMMACgkQTyzT2CeTzy0t4gCgvHMIxKo2fhQMZetroavcP4Cd 6bIAn2AyQWVw/MbB42OH0oUKcqIB+/0E =CSYe -----END PGP SIGNATURE----- ----Security_Multipart0(Sun_Oct_12_05_02_11_2014_491)----