From: Jesper Dangaard Brouer <jdb@comx.dk>
Date: Tue, 03 Feb 2009 14:38:20 +0100

quoted text
>   UDP: short packet: From 81.161.2.106:0 44063/1324 to 233.123.173.7:0
>   UDP: short packet: From 81.161.2.106:0 44063/1324 to 233.123.173.7:0
>   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
>   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
>   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
>   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931

The UDP header length field is garbage in all of these packets.

In the first two packets here, the source and dest ports are
both zero.  This is also garbage.,

quoted text
> Tcpdumping the packets, the contents of the packets are correct.

So something corrupts the packet on the way to UDP input.

quoted text
> The next strange thing is that I can make the log messages go away, if I
> setup a static multicast route out another interface.
> 
>   smcroute -a eth52 81.161.2.106 233.123.173.7 eth21

That could be a good clue.

Do you happen to have multicast routing enabled on this machine?  If
the multicast destination is non-local and IN_DEV_FORWARD is set on
the interface, that puts the packet through ip_mr_input.

ip_mr_input() will clone the SKB if it should be delivered locally
as well as be forwarded.

If the packet does get multicast forwarded, there is all kinds of
funny code that mangles the packet, for example ipmr_cache_report().

Any of this could be corrupting what UDP ends up seeing.

To be honest all of the SKB handling in the ipmr.c file is very scary.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html