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

Re: problem changing target interface with reply-to

Hi Daniel
> 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)
Yep, suspected that would be exactly what we are trying to prevent.  I
saw the recent loop detection change went into -stable but will
give -current a go.
> 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).
As I don't know off hand exactly what happens with each interface type
and the mbuf's when ipsec encapsulation, etc, occurs, can you answer
quickly and/or point me where to look - three quick questions:
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?
Is there something that can happen along the way to an mbuf that will
break things when this happens?
Would doing this break more things than just dropping upon seeing the
mbuf the second time on any interface does?
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.
> 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.
In the real (non-test) case, we're actually trying to confirm that we
have bidirectional comms on a backup link that will be failed over to
via RIP if the primary link goes down.  A single external monitoring
host pings both its interface address and the primary link's interface
address periodically.  As we only have one route back to that host, the
replies go back via the primary link whenver it's up.  This effectively
confirms we can receive on the backup link but doesn't say anything
about whether we can send packets back.  So, I was trying to set this up
to demonstrate to our network provider (without shutting down our
primary link) that we are having real intermittent problems in our
outgoing direction on the backup link - as well as enhancing the
monitoring that will happen on that link when it's unused(once we have
this ICMP going, I can effectively route some of our subnets down it
permanently to aggravate the problem).