Date: Tue, 24 Feb 2015 19:51:20 -0500 From: Allan Jude <allanjude@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: pf crash on -current Message-ID: <54ED1C88.7020703@freebsd.org> In-Reply-To: <20150224231022.GN2181@vega.codepro.be> References: <54EBD112.8050705@freebsd.org> <CACYV=-F0yxR7W7odZYw3UBWR-aYXCm24Qf=hs0fzAJ1gA4Xf-A@mail.gmail.com> <20150224070547.GH2181@vega.codepro.be> <20150224231022.GN2181@vega.codepro.be>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <kristof@sigsegv.be> wr= ote: >> On 2015-02-23 17:23:55 (-0800), Davide Italiano <davide@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54ED1C88.7020703>