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). Thanks Chris
