0

from the dmesg we get very strange lines as

[6484420.812643] raid6: using avx2x2 recovery algorithm
[6484420.859086] Btrfs loaded
[6484426.278636] nr_pdflush_threads exported in /proc is scheduled for removal
[6484708.776239] ixgbe 0000:04:00.0: invalid short VPD tag 06 at offset 4
[6900952.098901] perf: interrupt took too long (6247 > 6167), lowering kernel.perf_event_max_sample_rate to 32000
[7372848.819396] Peer 0000:0000:0000:0000:0000:ffff:0a15:f030:1054/8042 unexpectedly shrunk window 3002395993:3002395997 (repaired)
[8139485.039423] Turbo disabled by BIOS or unavailable on processor
[8380300.891343] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380320.890541] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380440.896206] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380460.895001] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380463.207397] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380467.316531] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380468.363352] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380469.332044] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380489.330943] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380509.329849] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380529.328678] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380549.468256] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380569.326474] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380589.340946] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380609.339969] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380619.870472] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380620.964216] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380621.979847] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380641.869255] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380661.883737] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380681.867153] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380701.881531] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380721.864752] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380741.879282] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380761.878160] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380781.876977] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380801.875853] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380821.874754] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380841.873636] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380861.872533] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380881.871408] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380901.870340] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380921.884773] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380956.392645] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380957.392566] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380958.517530] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380978.384846] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8380998.383622] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8381018.387820] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8381038.390564] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8381058.395931] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8381060.052209] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8381061.114504] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8381062.115355] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69
[8381082.053988] UDP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69

is that lines:

DP: bad checksum. From 73.2.33.11:5353 to 82.2.33.1:5353 ulen 69

indicate a serious problem ?

Improve this question
1

Those "UDP errors" is UDP Checksum offloading. The NIC is responsible for the checksum, and so it is not done at CPU level, to save CPU resources. VMWare does it, and I think KVM does it too (and not only). Hence when using tcpdump or looking at system logs, not seeing the right checksums at OS/VM level.

see Segmentation and Checksum Offloading: Turning Off with ethtool

Unfortunately sometimes what we see in Wireshark is not what we expect. One case in which this occurs is when TCP/IP operations are offloaded by the operating system to the Network Interface Card (NIC). Common operations for offloading are segmentation and checksum calculations. That is, instead of the OS using the CPU to segment TCP packets, it allows the NIC to use its own processor to perform the segmentation. This saves on the CPU and importantly cuts down on the bus communications to/from the NIC.

see also Linux Networking: How to disable/enable offload features, RX/TX checksum, scatter, gather and beyond

UDP / TCP Checksum errors in tcpdump output

if you have offload features enabled and you see cksum incorrect in tcpdump output, without any packet errors and your network is working properly: it is nothing to worry about because the checksum is actually calculated on the network adapter and the tcpdump is showing the checksum calculated on kernel level.

From UDP / TCP Checksum errors from tcpdump & NIC Hardware Offloading

After checking active NIC hardware offloading options you can see the obvious

$ sudo ethtool -k eth0 | grep on
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
generic-segmentation-offload: on
generic-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on

After disabling TCO (tcp offloading) for TX/RX on the NIC the problem is gone

$ sudo ethtool -K eth0 tx off rx off

Be sure to turn back on the optimizations after finishing debugging network problems, as you have a small performance hit while they are off.

TLDR Those "errors" are a regular sight on Linux VMs, and nothing to obsess about once you know they are part of your baseline. Also, keep in mind, when looking at logs, or debugging network issues, that what you see at kernel level is not necessarily what will be seen at wire level.

Improve this answer
1
  • After seeing this question, understood the purpose of the other question. Moved the part of the answer dealing with the issue of packet "corruption" to the right question, also for the benefit of future readers. – Rui F Ribeiro May 4 '20 at 9:27
1

You are getting bad checksums from the packets on port 5353 which is used for MDNS or multi-cast DNS. This can be because you have a faulty device(s) such as a router, switch, network card, or something else that is corrupting the packets or because there is a man-in-the-middle attack somewhere.

The 73.2.33.11 address is Comcast and the 82.2.33.1 address is Virgin Media. The best thing to do in your case is to use Tcpdump or Wireshark to examine the packets to see what's happening. You also want to see if the same thing is happening on other systems in your network. That will help you in figuring out what it is.

Improve this answer
0

This is not tcpdump or wireshark output, but a part of dmesg listing.

These messages come directly from the kernel, from the __udp4_lib_rcv() function located in net/ipv4/udp.c in Linux kernel source. The function is aware of hardware offloading features.

As far as I can see, if the checksums are handled in hardware, this message means that the hardware actually detected a bad checksum in a received UDP packet.

UDP/5353 is normally used by MDNS: multicast DNS, a peer-to-peer hostname resolution and service discovery protocol. It is normally usable within a single organization only: normally there should be no need to allow UDP/5353 traffic through the border firewall of your organization, neither in- nor outbound.

If the IP addresses are genuine, the bad packets are coming from a different Internet Service Provider's network. You can't do much for that: at best, you could inspect the traffic to see if the packets match a known attack, and report to the abuse reporting address of the source ISP as necessary.

But the fact that your server is apparently receiving UDP/5353 traffic from Internet might in itself be a cause for concern: it might mean your firewall is leaking, and the MDNS service is needlessly accessible from the internet. If this server is supposed to be protected by an external hardware firewall, double-check its configuration.

If this server is supposed to be protected by its own iptables firewall only, you should adjust the firewall settings to accept MDNS traffic from your organization's own network only, or disable the MDNS service completely if it is not needed.

Improve this answer
3
  • I got a bit carried away in the answer with the "tcpdump" thingy, but indeed in the past I had similar problems and was stumped for a few days debugging my "corrupted" DHCP/DNS packets, and wondering why 20k clients were so "happy" with them. – Rui F Ribeiro May 4 '20 at 14:11
  • 1
    @RuiFRibeiro I've been down that garden path myself :-) But when tcpdump/wireshark shows pretty much all traffic as having bad checksums, one begins to suspect that some piece of the puzzle is missing. A bit of googling set me straight, and since then I've been religiously using the -K option with tcpdump. – telcoM May 4 '20 at 14:12
  • Where in a DMZ with some archaic firewalls and inspectors, and was left wondering what was happening there instead of getting to the bottom of the thing. Actually found and corrected our configurations to escape some bugs, that suppliers were not able to find ;-P – Rui F Ribeiro May 5 '20 at 9:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.