[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem changing target interface with reply-to

On Wed, May 05, 2004 at 07:31:34PM +1000, Christopher Pascoe wrote:
> It appears the the PACKET_TAG_PF_ROUTED is to prevent recursive calls of
> pf_route, so I'm not sure what the correct fix is for this.  Moving that
> mbuf tagging after the if (oifp != ifp) makes it do the right thing in
> this test case with respect to the packet on the wire, but probably is
> bad in other ways :).
Yes, it will break other cases. I'm beginning to suspect that there
might be no combination that works for all cases. Whenever we change the
code for one case, we break another. If the choice is between dropping
packets and looping endlessly or crashing, it's simple ;)
I suggest you try with -current, as the loop detection has been adjusted
recently. Since you reconstructed the code path, here's one of the cases
that must be prevented:
  pass out route-to lo0 
  (applying to outgoing packets on lo0, too)
  PR 3736
If you want to suggest a change, you'll have to go through the previous
PRs and test with each of those cases, showing that you can't create a
loop (even with rules crafted just for that purpose, including virtual
interfaces, tunnels, ipsec). It's a non-trivial amount of work, and I'm
still tired from the last time I went there, and won't touch it for at
least a couple of weeks, maybe you just want to add a routing table
entry instead.
I think it was Ryan that suggested putting a depth-counter into the
mbuf tag, and drop the packet if the counter exceeds depth of > n
(for n > 1), which I guess would fix your specific case. But this,
too, would require the testing mentioned before.