Date: Mon, 21 May 2012 11:27:50 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Joerg Pulz <Joerg.Pulz@frm2.tum.de> Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-pf@freebsd.org Subject: Re: panic when using pf and route-to (maybe: bad fragment handling?) Message-ID: <20120521092750.GA20007@insomnia.benzedrine.cx> In-Reply-To: <201205210726.q4L7Q6m9064258@hades.admin.frm2> References: <201205210726.q4L7Q6m9064258@hades.admin.frm2>
next in thread | previous in thread | raw e-mail | index | archive | help
It looks like the byte order of ip_len is wrong, htons(334) = 19969, triggering fragmentation (334 < if_mtu, but 19969 > if_mtu). The reason is most likely the recursive pf_route() call: > m_copym() at m_copym+0x280 > ip_fragment() at ip_fragment+0x1e5 > pf_route() at pf_route+0x75c > pf_test() at pf_test+0xc29 > pf_route() at pf_route+0x30a > pf_test() at pf_test+0xc29 > pf_check_out() at pf_check_out+0x3a > pfil_run_hooks() at pfil_run_hooks+0xd2 > ip_output() at ip_output+0x655 i.e. the packet is filtered when going out on some interface, matching a route-to rule. Now the packet is filtered again on the routed-to interface. So far ok, this is expected. But now it matches a route-to rule again, possibly the same one, because it doesn't restrict the interface. Usually, this is not intentional (double route-to), and can be fixed by checking the route-to rule(s) and making them more restrictive. Semantics of such route-to chains are not well defined. There's an mbuf tag to prevent endless loops, but obviously even short chains are not working properly. I'd try to avoid them. Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120521092750.GA20007>