From owner-freebsd-pf@FreeBSD.ORG Mon Mar 16 13:52:31 2015 Return-Path: Delivered-To: freebsd-pf@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 407EA9E2; Mon, 16 Mar 2015 13:52:31 +0000 (UTC) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 1C96824D; Mon, 16 Mar 2015 13:52:30 +0000 (UTC) Received: from marvin.lab.vangyzen.net (c-24-125-214-90.hsd1.va.comcast.net [24.125.214.90]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 912DD56467; Mon, 16 Mar 2015 08:52:29 -0500 (CDT) Message-ID: <5506DFFB.7050302@FreeBSD.org> Date: Mon, 16 Mar 2015 09:51:55 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kristof Provost , freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: PF IPv6 fragments handling References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> In-Reply-To: <20150314020500.GW1975@vega.codepro.be> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qr4U7lrVe1SHhDRsKSca87alQaau6r17R" Cc: ae@FreeBSD.org, bz@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 13:52:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qr4U7lrVe1SHhDRsKSca87alQaau6r17R Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/13/2015 22:05, Kristof Provost wrote: > At that point we run into the packet size check, which in ip6_forward()= > is done before the pfil(PFIL_OUT) hook. That means that we'll send an > ICMP6_PACKET_TOO_BIG error rather than forwarding the packet. >=20 > The proposed fix in D1815 is to simply move the size check after the > pfil(PFIL_OUT) hook so pf has the chance to refragment the packet (whic= h > it does in pf_test6() -> pf_refragment6() because the packet has the > PF_REASSEMBLED tag). > That's also what the OpenBSD stack does. >=20 > In the D1815 review Gleb Smirnoff proposed a different solution. Instea= d > of returning a reassembled packet from pfil(PFIL_IN) in ip6_input() we > could change netpfil so we could return multiple packets. That means > we'd reassemble and immediately refragment on the input, and then do th= e > same on the output side. >=20 >=20 > I have a preference for the solution in D1815 for two reasons: > - it's less work for me. It's a relatively small change in ip6_output(= ) > and nothing else. Changing netpfil so it can return multiple packets= > is a more invasive change and will impact other firewalls too. > - it's less work for the kernel when forwarding. Not only do we only > reassemble and refragment once, but we also only need to do > ip6_forward() processing on a single packet, rather than for each > fragment. Here is a brainstorm that might give the best of both: Return the reassembled packet from PFIL_IN, but with the original fragment chain stashed in metadata. Most of the stack operates on the single, reassembled packet. ip6_output() sends the original fragment chain. Sure, it uses more memory, but reduced CPU time might be worth it. I am sure there are numerous challenges. When the stack modifies the packet, it will need to modify the fragment chain to match. Size checks would probably need to look at the fragment chain instead of the reassembled packet. This could be a maintenance problem when people forget to handle the rare case of the fragment chain. Like I said, it is a brainstorm. Treat it accordingly. Eric --qr4U7lrVe1SHhDRsKSca87alQaau6r17R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVBt/7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzRTcwNEY0QTBEMTM0MUU4QkNFNEQ3M0RB RkMxMkExM0VDMjBEQUI4AAoJEK/BKhPsINq4sOsIAIpD3poy5Q9T1lePn0ZO7zMN eXV/hBau+eQ8WygRmMqeGLKhAWVvffqp/fJn29T9zeICXC+/wvUYlCEQkZITtIFC pyKg9grzblufzkYCkGdXihZNqN48BlyubTfsU8xNeCsRwGtu8PpHHBtCbO6YVFA/ tg3WbRdFpwMI9wse5RIA/uE10p3/OGAxCWTkz/SUm9xBUa00uVt09lq0s8kEfApF idruQOPv6VrY2GCkRYlYgK5GVfdHWYzjRcNkxaa89xLuxqROJ8cIlLlL4LINSOQQ HY8J8uUtezuoguS7qoYnKkdTkqgx7OEG/VBRAAZvbdiCHG/jAvrkk6Ov0RIm1IQ= =v9U3 -----END PGP SIGNATURE----- --qr4U7lrVe1SHhDRsKSca87alQaau6r17R-- From owner-freebsd-pf@FreeBSD.ORG Tue Mar 17 01:15:12 2015 Return-Path: Delivered-To: freebsd-pf@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 57B69152; Tue, 17 Mar 2015 01:15:12 +0000 (UTC) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16FCE3C9; Tue, 17 Mar 2015 01:15:11 +0000 (UTC) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 736FE126D5; Tue, 17 Mar 2015 02:15:08 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 2473F78399; Tue, 17 Mar 2015 02:15:08 +0100 (CET) Date: Tue, 17 Mar 2015 02:15:08 +0100 From: Kristof Provost To: Eric van Gyzen Subject: Re: PF IPv6 fragments handling Message-ID: <20150317011507.GC2036@vega.codepro.be> References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> <5506DFFB.7050302@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5506DFFB.7050302@FreeBSD.org> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, bz@FreeBSD.org, ae@FreeBSD.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 01:15:12 -0000 On 2015-03-16 09:51:55 (-0400), Eric van Gyzen wrote: > Here is a brainstorm that might give the best of both: Return the > reassembled packet from PFIL_IN, but with the original fragment chain > stashed in metadata. Most of the stack operates on the single, > reassembled packet. ip6_output() sends the original fragment chain. > Sure, it uses more memory, but reduced CPU time might be worth it. > It's an interesting idea. There are a number of advantages (like not modifying the fragment ID or the sizes of each packet). It won't reduce CPU usage though because we'd have to copy the packet which is something we don't do at the moment. In addition to that there's the concern you pointed out that we'd forget to adapt them both, or that we'd end up checking the wrong one at any point in the stack. Regards, Kristof From owner-freebsd-pf@FreeBSD.ORG Tue Mar 17 14:24:46 2015 Return-Path: Delivered-To: freebsd-pf@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 7F66D727 for ; Tue, 17 Mar 2015 14:24:46 +0000 (UTC) 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 64AB961A for ; Tue, 17 Mar 2015 14:24:46 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2HEOkvY028727 for ; Tue, 17 Mar 2015 14:24:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 185617] pfctl(8): armv6: "pfctl -s state" crashes on BeagleBone Black due to unaligned access Date: Tue, 17 Mar 2015 14:24:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: guyyur@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc rep_platform version 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-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 14:24:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185617 guyyur@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|pfctl(8): 10.0-RC1, armv6: |pfctl(8): armv6: "pfctl -s |"pfctl -s state" crashes on |state" crashes on |BeagleBone Black due to |BeagleBone Black due to |unaligned access |unaligned access Hardware|Any |arm Version|unspecified |11.0-CURRENT --- Comment #2 from guyyur@gmail.com --- Patch that breaks backward compatibility by separating the pfsync and pfioc state structures and uses host order for pfioc fields except for id and creatorid. pfsync_state_import is duplicated to pfioc_state_import. pfioc_state_export is duplicated to pfsync_state_export. pfsync_alloc_scrub_memory is duplicated to pfioc_alloc_scrub_memory. https://github.com/guyyur/freebsd-src_patches/blob/master/pfctl_arm_segbus__ver2_part1.patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-pf@FreeBSD.ORG Tue Mar 17 17:33:23 2015 Return-Path: Delivered-To: freebsd-pf@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 BFCFF633 for ; Tue, 17 Mar 2015 17:33:23 +0000 (UTC) Received: from conker.exetel.com.au (conker-mail2.exetel.com.au [220.233.0.58]) by mx1.freebsd.org (Postfix) with ESMTP id 7DE06E4F for ; Tue, 17 Mar 2015 17:33:22 +0000 (UTC) Received: from phasia.kd.net.au ([220.233.10.47]) by conker.exetel.com.au with esmtp (Exim 4.71) (envelope-from ) id 1YXv4d-00064n-Kk for freebsd-pf@freebsd.org; Wed, 18 Mar 2015 04:14:35 +1100 Received: from aneurin.horsfall.org (unknown [120.146.8.15]) by dermis.kd (Postfix) with ESMTP id 47633CD2E for ; Wed, 18 Mar 2015 04:14:35 +1100 (EST) Received: from aneurin.horsfall.org (localhost [127.0.0.1]) by aneurin.horsfall.org (8.14.9/8.14.9) with ESMTP id t2HHEWeB019854 for ; Wed, 18 Mar 2015 04:14:34 +1100 (EST) (envelope-from dave@horsfall.org) Received: from localhost (dave@localhost) by aneurin.horsfall.org (8.14.9/8.14.9/Submit) with ESMTP id t2HHEVlv019851 for ; Wed, 18 Mar 2015 04:14:32 +1100 (EST) (envelope-from dave@horsfall.org) X-Authentication-Warning: aneurin.horsfall.org: dave owned process doing -bs Date: Wed, 18 Mar 2015 04:14:31 +1100 (EST) From: Dave Horsfall To: FreeBSD PF List Subject: Hints on rate limiting Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) X-Witty-Saying: "chmod 666 the_mode_of_the_beast" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 17:33:23 -0000 FreeBSD 9.3-RELEASE-p5 (GENERIC) #0: Mon Nov 3 22:02:57 UTC 2014 fxp0: (on board) I'm having trouble with getting rate limiting to work i.e. so many connections from the same source in so many seconds (what we in the anti-spam community call "woodpeckers"). Does it actually work on FreeBSD 9? I know that PF doesn't work at all on FreeBSD 8 (at least, with the NIC above), and if it does indeed work then what would be a good starting point? Note that a complicating factor is that I have configured a "greet pause" of 10 seconds i.e. after the connection I wait for that long before issuing the SMTP greeting (and woe betide you if you don't wait in turn). And before anyone asks me why aren't I running 10.x, I will as soon as my new server arrives; the current box is going to fail soon (the electrolytic capacitors are starting to bulge) so it's not worth the hassle. And anyway, I've screwed up the ports area Yet Again from a failure to read simple instructions :-( -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there) From owner-freebsd-pf@FreeBSD.ORG Wed Mar 18 00:59:23 2015 Return-Path: Delivered-To: freebsd-pf@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 4B744338 for ; Wed, 18 Mar 2015 00:59:23 +0000 (UTC) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id 21EF5AAE for ; Wed, 18 Mar 2015 00:59:22 +0000 (UTC) Received: from [10.0.1.2] (static-71-177-216-148.lsanca.fios.verizon.net [71.177.216.148]) (authenticated bits=0) by zoom.lafn.org (8.14.7/8.14.9) with ESMTP id t2I0olVd033161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2015 17:50:48 -0700 (PDT) (envelope-from bc979@lafn.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Hints on rate limiting From: Doug Hardie In-Reply-To: Date: Tue, 17 Mar 2015 17:50:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Horsfall X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98 at zoom.lafn.org X-Virus-Status: Clean Cc: FreeBSD PF List X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 00:59:23 -0000 > On 17 March 2015, at 10:14, Dave Horsfall wrote: >=20 > FreeBSD 9.3-RELEASE-p5 (GENERIC) #0: Mon Nov 3 22:02:57 UTC 2014 >=20 > fxp0: (on board) >=20 > I'm having trouble with getting rate limiting to work i.e. so many=20 > connections from the same source in so many seconds (what we in the=20 > anti-spam community call "woodpeckers"). >=20 > Does it actually work on FreeBSD 9? I know that PF doesn't work at = all on=20 > FreeBSD 8 (at least, with the NIC above), and if it does indeed work = then=20 > what would be a good starting point? >=20 > Note that a complicating factor is that I have configured a "greet = pause"=20 > of 10 seconds i.e. after the connection I wait for that long before=20 > issuing the SMTP greeting (and woe betide you if you don't wait in = turn). >=20 > And before anyone asks me why aren't I running 10.x, I will as soon as = my=20 > new server arrives; the current box is going to fail soon (the=20 > electrolytic capacitors are starting to bulge) so it's not worth the=20= > hassle. And anyway, I've screwed up the ports area Yet Again from a=20= > failure to read simple instructions :-( You might want to provide some details on which approach to rate = limiting you are using. There are at least two that I am aware of. = Also, are your sure that you are having a large number of connections = from each IP, or are they using one connection and trying many different = ids and passwords? I see lots of the latter on several mail servers I = run. I don=E2=80=99t recall seeing one IP making many connection = attempts. Rate limiting won=E2=80=99t help if they are using one = connection.= From owner-freebsd-pf@FreeBSD.ORG Wed Mar 18 02:00:31 2015 Return-Path: Delivered-To: freebsd-pf@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 2F424DEE for ; Wed, 18 Mar 2015 02:00:31 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0050178 for ; Wed, 18 Mar 2015 02:00:30 +0000 (UTC) Received: by qgez64 with SMTP id z64so25776204qge.2 for ; Tue, 17 Mar 2015 19:00:29 -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:subject :content-type; bh=3sSPTM+W36+JvhTDyAndoKtT0vO0AaW4Mqf33fm85xo=; b=fR/vxicfs/G2ED2h1Y2CsR/iLeOm89cDH9+1iH9tKIHwKrj2FuUG5Wkzh5YbIKo48N DrBXUQDrMiSZk1fPCxUk6Zkukg5HKfhXQgDg2k3fTBz+7RDO/eThcsbns+2XdT1xXF2O ihTcYM5ACzlfr6kX4LDwY9lPQMyKHt2u3b0jAqlvlG8xa5hZLeX5TXzuag8ji/dFqyh1 f1WPrrUCALHQ9US1d4YTX/FTKUr+Dd1uDwJIZu1SWjiRaSY7tZvKW5KvqjY9d5iX4IEK 0zJNirj/tfnydLzj/D+oaipCivyOW7CpxSzLO0YjCwW7HQ05fFBEw+xivXkbdgJhz7k9 07Ng== X-Received: by 10.55.54.19 with SMTP id d19mr98485087qka.98.1426644029007; Tue, 17 Mar 2015 19:00:29 -0700 (PDT) Received: from [10.0.0.230] (pool-74-103-59-158.bltmmd.fios.verizon.net. [74.103.59.158]) by mx.google.com with ESMTPSA id u6sm10879009qhd.45.2015.03.17.19.00.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 19:00:27 -0700 (PDT) Message-ID: <5508DC3A.4070603@gmail.com> Date: Tue, 17 Mar 2015 22:00:26 -0400 From: John Jasen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FreeBSD Net Subject: bug in tftp-proxy, unable to write rdr rules Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 02:00:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198674 In FreeBSD 10.1-RELEASE-p6, a rule similar to the below will result in no tftp connection, and entries in /var/log/messages such as: "Mar 17 23:38:28 vm-fbd-fw-02 tftp-proxy[28376]: pf connection lookup failed (no rdr?)" rdr pass log on em0 proto udp from 10.0.0.0/24 to 10.0.0.5 port 69 \ -> 127.0.0.1 port 6969 The error comes from: /usr/src/contrib/pf/tftp-proxy.c: " /* find the un-rdr'd server and port the client wanted */ if (server_lookup((struct sockaddr *)&from, (struct sockaddr *)&proxy, (struct sockaddr *)&server, IPPROTO_UDP) != 0) { syslog(LOG_ERR, "pf connection lookup failed (no rdr?)"); exit(1); } " This did not happen in FreeBSD 10.0. From owner-freebsd-pf@FreeBSD.ORG Thu Mar 19 20:44:17 2015 Return-Path: Delivered-To: freebsd-pf@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 594AB378 for ; Thu, 19 Mar 2015 20:44:17 +0000 (UTC) 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 3E43F664 for ; Thu, 19 Mar 2015 20:44:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2JKiHlC024227 for ; Thu, 19 Mar 2015 20:44:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 198674] [pf] [tftp-proxy] tftp-proxy cannot write rdr rules Date: Thu, 19 Mar 2015 20:44:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords 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-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:44:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198674 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-pf@FreeBSD.org Keywords| |regression -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-pf@FreeBSD.ORG Thu Mar 19 20:46:47 2015 Return-Path: Delivered-To: freebsd-pf@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 DA326540 for ; Thu, 19 Mar 2015 20:46:47 +0000 (UTC) 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 BF446697 for ; Thu, 19 Mar 2015 20:46:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2JKkl9O026372 for ; Thu, 19 Mar 2015 20:46:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 198674] [pf] [tftp-proxy] tftp-proxy cannot write rdr rules Date: Thu, 19 Mar 2015 20:46:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jjasen@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:46:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198674 jjasen@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #1 from jjasen@gmail.com --- Closing bug, user error. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-pf@FreeBSD.ORG Sat Mar 21 22:11:49 2015 Return-Path: Delivered-To: freebsd-pf@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 4852B23F for ; Sat, 21 Mar 2015 22:11:49 +0000 (UTC) Received: from luigi.brtsvcs.net (luigi.brtsvcs.net [IPv6:2607:fc50:1000:1f00::2]) (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 223DE143 for ; Sat, 21 Mar 2015 22:11:48 +0000 (UTC) Received: from chombo.houseloki.net (c-71-59-211-166.hsd1.or.comcast.net [71.59.211.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by luigi.brtsvcs.net (Postfix) with ESMTPSA id 2A6502D4F8D; Sat, 21 Mar 2015 22:11:47 +0000 (UTC) Received: from [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29] (unknown [IPv6:2601:7:2580:181:baca:3aff:fe83:bd29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by chombo.houseloki.net (Postfix) with ESMTPSA id A229C9A2; Sat, 21 Mar 2015 15:11:44 -0700 (PDT) Message-ID: <550DEC94.4040805@bluerosetech.com> Date: Sat, 21 Mar 2015 15:11:32 -0700 From: list_freebsd@bluerosetech.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kristof Provost Subject: Re: PF IPv6 fragments handling References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be> <5506DFFB.7050302@FreeBSD.org> <20150317011507.GC2036@vega.codepro.be> In-Reply-To: <20150317011507.GC2036@vega.codepro.be> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 22:11:49 -0000 On 2015-03-16 18:15, Kristof Provost wrote: > On 2015-03-16 09:51:55 (-0400), Eric van Gyzen wrote: >> Here is a brainstorm that might give the best of both: Return the >> reassembled packet from PFIL_IN, but with the original fragment chain >> stashed in metadata. Most of the stack operates on the single, >> reassembled packet. ip6_output() sends the original fragment chain. >> Sure, it uses more memory, but reduced CPU time might be worth it. >> > It's an interesting idea. There are a number of advantages (like not > modifying the fragment ID or the sizes of each packet). > > It won't reduce CPU usage though because we'd have to copy the packet > which is something we don't do at the moment. Why would you need to copy the packet in order to store a list of fragment IDs and offsets? You need that information anyway for refragmentation because an IPv6 router is not supposed to fragments. I'd interpret that to mean the fragmentation pattern coming out of pf should match what went in. A later hop wouldn't be able to send back a meaningful PTB message otherwise.