Herbert Xu wrote:
Andi Kleen <[EMAIL PROTECTED]> wrote:Badness in ip_finish_output2 at /home/lsrc/quilt/linux/net/ipv4/ip_output.c:203 Call Trace: <ffffffff8034284f>{ip_finish_output2+419} <ffffffff80343dfa>{ip_fragment+1512} <ffffffff803426ac>{ip_finish_output2+0} <ffffffff80344ff9>{ip_mc_output+521} <ffffffff8034423d>{ip_push_pending_frames+877} <ffffffff8035b307>{udp_push_pending_frames+558} <ffffffff8035bc6b>{udp_sendmsg+1357} <ffffffff8031f8dd>{sock_sendmsg+209} <ffffffff8013a140>{autoremove_wake_function+0} <ffffffff80145683>{find_get_page+12} <ffffffff8031edbe>{move_addr_to_user+56} <ffffffff8031f978>{sockfd_lookup+12} <ffffffff8031ed76>{move_addr_to_kernel+34} <ffffffff80320204>{sys_sendto+235} <ffffffff80321b9d>{sk_free+184} <ffffffff80338b3e>{netlink_release+542} <ffffffff8013a23a>{wake_up_bit+14} <ffffffff8010e4ee>{system_call+126} ip_finish_output2: No header cache and no neighbour!My current guess is that this is caused by an SNAT rule that turns a local outgoing multicast packet into something that has a foreign source address.
I can't figure out how this can happen. If a local outgoing multicast packet would have been SNATed to a non-local IP, ip_route_input would have been used by ip_route_me_harder. In that case we should see ip_output instead of ip_mc_output in the backtrace. But it definitely looks related to the rerouting changes in the NAT code. Anyway, I'm trying to reproduce the problem now. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
