dmesg - UDP: bad checksum

andy2008 · #1 19th June 2009, 02:29 PM

I'm seeing a lot of messages at the end of dmesg such as:

UDP: bad checksum. From 80.65.16.53:53 to x.x.y.y:12538 ulen 114
UDP: bad checksum. From 80.65.16.53:53 to x.x.y.y:43810 ulen 81
UDP: bad checksum. From 80.65.16.53:53 to x.x.y.y:21657 ulen 81
UDP: bad checksum. From 80.65.16.53:53 to x.x.y.y:44858 ulen 114
UDP: bad checksum. From 80.65.16.53:53 to x.x.y.y:59660 ulen 81
UDP: bad checksum. From 80.65.16.53:53 to x.x.y.y:48552 ulen 81
UDP: bad checksum. From 80.65.16.53:53 to x.x.y.y:18531 ulen 81
UDP: bad checksum. From 80.65.16.53:53 to x.x.y.y:47774 ulen 114
UDP: bad checksum. From 80.65.16.53:53 to x.x.y.y:52890 ulen 81
UDP: bad checksum. From 24.123.63.138:41773 to x.x.y.y:48935 ulen 111
UDP: bad checksum. From 75.72.65.46:12954 to x.x.y.y:1025 ulen 111
UDP: bad checksum. From 201.211.26.114:45498 to x.x.y.y:48935 ulen 111
UDP: bad checksum. From 202.29.106.44:36620 to x.x.y.y:48935 ulen 106
UDP: bad checksum. From 210.50.3.173:53 to x.x.y.y:42055 ulen 337
UDP: bad checksum. From 122.170.6.12:25900 to x.x.y.y:16664 ulen 111

x.x.y.y is my external IP. What could possibly cause this?

stevea · #2 19th June 2009, 02:55 PM

Is your x.x.y.y. address on a common LAN with any of the offending messages ?

I'll suggest ou fireup wireshark and examine the packets.

The message claims that incoming UDP packets are corrupt, that is the IP checksum has the wrong value. This is very odd. You are getting this msg from a lot of distinct sources. Several on port 53 which is used for DNS protocol.

It's possible these are part of some attack vector, but there is no obvious reason why the checksum would be wrong, unless ther is some Windows stack overflow exploit they are attempting to use.

FWIW I did some work for a company that used SBC Ameritech DSL for network connectivity, and we had regular problems with maintaining VPNs and ssh connetions for long periods. I started capturing packets on both ends and finally realized that as the packets were re-written ((when a packet goes through a router, the MACs and TTL change, so the header is revised and the checksum too)) eventually there was an error in that one of the routers re-wrote the source port number too, and this cause the TCP connection to reset. There is a well know TCP attack based on this. The bum-weasels at Ameritech never acknowledged the problem, but it's entirely possible they did this on purpose to disrupt traffic and lower their cost.

Anyway your problem seems to be strictly UDP related in your case. Still it could be that some outside router is mangling your packets on the re-write.

The system 80.65.16.53 ( 53.16.65.80.ip.orionnet.ru)is some Russian net. Any idea why their DNS service is sending messages to your system ?? Normally for an end-user, all you DNS comes from the local router or yourISPs name server.

andy2008 · #3 19th June 2009, 03:33 PM

Thanks for your reply stevea. To answer your questions, no, my x.x.y.y address is not on a common LAN with any of the other IPs.

My server does a whole lot of things, including mail, DNS, http, etc, so it's not unusual that their DNS service is sending messages to my system on port 53.
So, is there some kind of solution to this problem... right now there isn't an actual problem, everything is working fine, but I would definitely like to keep it that way.

stevea · #4 19th June 2009, 05:14 PM

I'm not a DNS protocol expert, but I'm fairly sure that you should NOT be receiving DNS msgs from random places - just from your upstream DNS service. Maybe that's only true for forwarding services - not sure.

The other port numbers where you receive bogus packets aren't DNS - so DNS is not the fundamental cause.

No solution is needed. You are just getting notification that your system is receiving bogus UDP packet from outside.

I meant to mention it, but there is a slight possibility this is due to your network interface driver. If the driver was broken it might garble the checksums . I'm not aware of any such problems, but it might pay to google.com/linux your interface's driver to see if there are any recent problem reports.

andy2008 · #5 19th June 2009, 05:25 PM

Thanks again for your interest in my problem stevea. I'm pretty sure it's not a driver related problem (I might have exaggerated a little, there aren't THAT many "UDP: bad checksum" logs... only about 25 or so in the last 30 days). More so, the server is a very popular IBM server x3650 with two identical gigabit adapters: the Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz, which Fedora handles by default very well.