linux ipv6 multicast kernel implementation

[Hannes Payer <hpayer@xxxxxxxxxxxxxx>]

Dear oss team,
last week i tryed to ask Alan Cox something about the data link layer
imlplementation in the linux kernel. He gave me your email address and 
therefore i forward you this email and hope, that you can help me.


forwarded message:
Dear Alan Cox,
we are trying to get ipv6 protocol independent multicast working on linux 
routers. We used the ipv6 multicast forwarding patch and the pim6sd daemon of 
Michael Hoerdt (http://clarinet.u-strasbg.fr/~hoerdt/linux_ipv6_mforwarding/, 
http://clarinet.u-strasbg.fr/~hoerdt/pim6sd_linux/). The ipv6 multicast kernel 
implementation is based on the existing ipv4 code and therefore we thought that 
you are the right contact person :-)
The ipv6 patch does not work well and we already found some bugs, we were able 
to correct.
We are not sure about one problem:
When the kernel receives a pim register packet, it decapsulates the packet and 
loops the multicast packet back on the register interface (netif_rx(skb) in 
pim6_rcv() pim6.c). Before the packet is looped back, the kernel sets skb->dst 
= NULL;
Therefore in ip6_input.c ip6_rcv_finish() looks up the unicast routing table 
and gets a matching entry. After that the kernel tries to forward the multicast 
packet, but stops at ip6_mr_forward() in ip6mr.c. The comparison 
vif6_table[vif].dev != skb->dev is true und therefore the packet is droped. 
(The lookup always returns dubios interfaces. It should return in our case the 
registry interface)
Our question: Why should we lookup the unicast routing table in this case? 
Would it satisfy to look up the multicast forwarding cache, where a correct 
entry exists - created by the pim6sd daemon? Would it be a problem if we 
override the lookup result with the regvif device after the lookup in this 
case?

I hope you understand the explanation of our problem.
Thank you for your answer.

Yours faithfully,
Hannes Payer