From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 00:51:18 2015 Return-Path: Delivered-To: freebsd-current@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 74270709 for ; Wed, 25 Feb 2015 00:51:18 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 4A7C83DE for ; Wed, 25 Feb 2015 00:51:17 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id BA482977B5 for ; Wed, 25 Feb 2015 00:51:16 +0000 (UTC) Message-ID: <54ED1C88.7020703@freebsd.org> Date: Tue, 24 Feb 2015 19:51:20 -0500 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: pf crash on -current References: <54EBD112.8050705@freebsd.org> <20150224070547.GH2181@vega.codepro.be> <20150224231022.GN2181@vega.codepro.be> In-Reply-To: <20150224231022.GN2181@vega.codepro.be> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6hmb0VvPdUQ850FkwUJJ44bHpSGCJWhPe" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 00:51:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6hmb0VvPdUQ850FkwUJJ44bHpSGCJWhPe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-02-24 18:10, Kristof Provost wrote: > On 2015-02-24 08:05:47 (+0100), Kristof Provost wr= ote: >> On 2015-02-23 17:23:55 (-0800), Davide Italiano w= rote: >>> The bt you posted suggest this could be stack overflow, probably due >>> to infinite recursion. >>> Also, as a wild guess, just looking at the stacktrace, I think this >>> might be related to the recent ipv6 fragment changes. Try to back the= m >>> out, and see if things gets more stable ( r278831 and r278843). >>> >> That's almost certainly what it is. >> > After a bit of fiddling around I've managed to reproduce this locally. >=20 > Essentially we get caught in a loop of defragmenting and refragmenting:= > Fragmented packets come in on one interface and get collected until we > can defragment it. At that point the defragmented packet is handed back= > to the ip stack (at the pfil point in ip6_input(). Normal processing > continues. > Eventually we figure out that the packet has to be forwarded and we end= > up at the pfil hook in ip6_forward(). After doing the inspection on the= > defragmented packet we see that the packet has been defragmented and > because we're forwarding we have to refragment it. That's indicated by > the presence of the PF_REASSEMBLED tag. >=20 > In pf_refragment6() we remove that tag, split the packet up again and > then ip6_forward() the individual fragments. > Those fragments hit the pfil hook on the way out, so they're > collected until we can reconstruct the full packet, at which point we'r= e > right back where we left off and things continue until we run out of > stack. >=20 > There are two reasons Allan is seeing this and no one else has so far. >=20 > The first is that he's scrubbing both on input and output. My own tests= > have always been done with 'scrub in all fragment reassemble', rather > than 'scrub all fragment reassemble' so I didn't see this problem. >=20 > The second is that he's got an internal interface with a higher MTU, > so the refragmentation actually works for him. > There's an open problem where ip6_forward() drops the defragmented > packet before the pfil(PFIL_OUT) hook because it's too big for the > output interface. > If the last patch of my series (https://reviews.freebsd.org/D1815) had > been merged as well more people would have been affected. >=20 > One possible fix for Allan's problem would be to tag the fragments afte= r > refragmentation so that pf ignores them. After all, the defragmented > packet has already been inspected so there's no point in checking the > fragments again. >=20 > I have the feeling there's a way to fix this problem and the issue D181= 5 > tries to fix in one go though. I'll need to think about it a bit more. >=20 > Regards, > Kristof > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 Admittedly, when I switched from using pfSense to vanilla FreeBSD for my firewall, when I got new hardware and wanted to run bhyve as well, i just dumped the rules from my pfsense into a file and then started editing by hand. So the scrub rule was not really a decision I made, but was inherited from the pfsense. It is actually my external interface (point-to-point fibre transport from my basement to the data center) that has the higher MTU (4400), whereas my internal network is all standard 1500 MTU. --=20 Allan Jude --6hmb0VvPdUQ850FkwUJJ44bHpSGCJWhPe 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.0.22 (MingW32) iQIcBAEBAgAGBQJU7RyLAAoJEJrBFpNRJZKfKgAP/Au7s8eDon8h6RN+B+M+6s8V 5/Ol5VQFEi01KQRBDbXe4h+8FPPzXJIhIDISrNQf8CCoNcc1gZXL4/2Z6zpLEFvX UGMPQykiy7/oOFvjyICNzd/UXq4Aq5z/ayVViZQ7xgj9LForjYxbt/lZf7IvkaFr G8AMQ0EV76rycUBsGhKZMU3ZMOZQzP7AfkZ13GgKA4rzuKa7I6+fNvhVK+vyzHgx Vre4HKhYPhCVH8U/5nFDBbOKIIZjX61aXMcX6p09yM19tUgWtM839cSv7PwIYdAA w008LZqP9h72uwp+mq1d8HHSfpUaHAKa3HlkgzAbC1kESFwPbaMTmrqeUA2HcZtI tG1/ZTFWwTnaL+tRHk1EtdPuxSZWJ8kXmcihiCqYILL8xaUZSDaL+t5oqAP2e9Ut ULMkE1Rz+oCIbe6teOAd9HPjYzWAwsD0arPIrOefM06TOKGwz4pYPhz/dtcwU+aa booFxCMTeOV4NZOH6Cdt8UkEocn0naxnqvXlANgqALViP08rJ4c948/ZaPRZRBYJ OO1m+y43/izL1f8gwhaMBDffkAzsw90e/YLcay3H6kdnOIIiXsdkTH5d9kFPDX03 Xf0JpqfmRn9Ja6b2pE7LqRyS0XVZ68Y+VzJ2MvOcu/CPijY7peqGxjdHiCNFZugf lc3cC6l6zuCYRCVBoHBO =q9nr -----END PGP SIGNATURE----- --6hmb0VvPdUQ850FkwUJJ44bHpSGCJWhPe--