>> It seems to me that before upcalling through pr_input, about four
>> lines from the end of ip6_input, m->m_pkthdr.rcvif should be set to
>> deliverifp.  Am I hallucinating, or is this really a bug?
> it is not a bug.

Then what use is the "faith" argument to in6_pcblookup_*?  Without
changing m_ptkhdr.rcvif, the test in tcp_input() that sets "faith" will
never trip, and the last argument to in6_pcblookup_* will be 0.

If you don't believe me, try adding code to your kernel to print a
message if it ever sees that argument set.  (And if you do, and it *is*
getting set, I really want to know how; I can't see a codepath that
would produce that.)

> i have been running faith daemon on 1.6D without any trouble.

If you will read my message closely, you will see that this is not
surprising, because the bug (or at least I think it's a bug) in
ip6_input is masked by a (mis)feature in in6_pcblookup_*: if the faith
argument is 0 when it should be 1, everything will work, except that a
faith packet might incorrectly match a non-faith socket.  And as I
explained, I doubt this ever has an opportunity to happen, and if it
did happen you might well not notice that it shouldn't.

> ip6_input deliverifp, and m->m_pkthdr.rcvif, have nothing to do with
> TCP packet interception performed by faith(4).

They have nothing to do with looping packets back in ip6_input.  They
have everything to do with getting the "faith" argument to
in6_pcblookup_* set when it should be.

> what you need is an appropriate setup of routing table, like: [...]

That is the cure to a different problem, a problem I do not have, and
is not relevant to the subject of my post.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B