On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote:
T> On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote:
T> T> I have a vague suspicion on what is happening. Your description of
T> T> the problem looks like if a packet processing in the kernel has entered
T> T> an endless loop.
T> T>
T> T> Looking at pf_route() I see such possibility. From OpenBSD we have
T> T> this protection against endless looping:
T> T>
T> T> if ((*m)->m_pkthdr.pf.routed++ > 3) {
T> T> m0 = *m;
T> T> *m = NULL;
T> T> goto bad;
T> T> }
T> T>
T> T> In our code this transforms to:
T> T>
T> T> if (pd->pf_mtag->routed++ > 3) {
T> T> m0 = *m;
T> T> *m = NULL;
T> T> goto bad;
T> T> }
T> T>
T> T> The root difference between storing the tag on mbuf and on pfdesc
T> T> is that we lose pfdesc, and thus the tag, when we enter pf_test()
T> T> recursively. And pf_route() does this recursion:
T> T>
T> T> if (oifp != ifp) {
T> T> if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) {
T> T> goto bad;
T> T> ....
T>
T> On second look I see that my suspicion may not be true. In the
T> beginning of pf_test() we do pf_get_mtag() which preserves already
T> present tag if there is one.
Further investigation showed that problem exist when route applied
ends in lo0, and packet passes to if_simloop(). There all mtags are
stripped from the mbuf, including the pf mtag. Then packet is again
processed by ip_input() again entering pf(4), if it again matches
a routing rule, then we got an endless loop.
We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id.
--
Totus tuus, Glebius.
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
