[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 09:56:03PM +1000, Christopher Pascoe wrote:
> What stops us from doing brute-force loop detection by keeping in the
> mbuf tag we add some details of which ifp's pf_route has been called on,
> and dropping the packet only when we get called twice on the same ifp?
That would work as well, but I think it's safer to limit the number of
passes through pf_route() absolutely, for the following reason:
The functions pf_route() and pf_test() call each other recursively in
this case, and this consumes stack memory. Kernel stack memory is very
limited, and when it runs out, the machine spontanously reboots (without
a panic or diagnostic). This can happen for recursion depths of just a
couple of dozen levels (depends on stack size, which is arch dependant).
> Is there something that can happen along the way to an mbuf that will
> break things when this happens?
Some encapsulations might remove any mbuf tags, but this would equally
circumvent the current loop detection. I think we had to explicitely
move the tag onto the new mbuf in at least one case. I suggest keeping
the same tag, only adding data to it (mbuf tags can contain arbitrary
> This would catch the "pass out route-to lo0" case, but not sure how it
> interacts with the other cases.  Looking for PR's to get some ideas of
> other cases that I can analyze.
With 3.5 (not sure if 3.4 had that already), you can also bind states to
interfaces, which is another aspect of using route-to/reply-to across
several interfaces.
There's basically two common ways route-to is used:
  - applying outgoing on the interface with the default gateway,
    to re-route it out to another interface.
  - applying incoming on one side of the firewall, routing directly
    out through the other side, bypassing the stack.
I think reply-to is used in both of these ways, too.
route-to loopback is also used regularly, and there's some weirder
uses on gif and vlan interfaces.
The priorities, IMO, should be
  a) never lock up, even with the most bizarre or evil ruleset
  b) support the basic constructs on real interfaces to support
     using multiple uplinks (load-balancing)
  c) support the more obscure constructs