1

from the dmesg we see the following:

 UDP: bad checksum. From 34.21.56.68:4343 to 32.3.42.22:4343 ulen 20
 UDP: bad checksum. From 34.21.90.186:4343 to 32.3.42.22:4343 ulen 20
 UDP: bad checksum. From 34.21.54.181:4343 to 32.3.42.22:4343 ulen 20
 UDP: bad checksum. From 34.21.90.186:4343 to 32.3.42.22:4343 ulen 20
 UDP: bad checksum. From 34.21.90.186:4343 to 32.3.42.22:4343 ulen 20
 UDP: bad checksum. From 34.21.90.186:4343 to 32.3.42.22:4343 ulen 20
 UDP: bad checksum. From 34.21.90.186:4343 to 32.3.42.22:4343 ulen 20
 net_ratelimit: 16 callbacks suppressed
 UDP: bad checksum. From 34.21.50.188:137 to 34.21.251.239:137 ulen 32
 UDP: bad checksum. From 34.21.50.188:137 to 34.21.251.239:137 ulen 32
 UDP: bad checksum. From 34.21.245.107:137 to 34.21.251.239:137 ulen 32
 UDP: bad checksum. From 34.21.245.107:137 to 34.21.251.239:137 ulen 32

what this info indicate ?

more then then when we transferred to this machines some pkg , then we notice that pkg are corrupted

what is going here?

1
  • Data gets corrupted in the "middle" of the network layer, but for some reason not on the lower layers. Could be anything from "router acting up", "bad RAM in either of the two hosts or the router", or something completely different. Try to isolate the problem by switching components (different source and target host, direct connection, etc.) until you narrow the probably cause down. – dirkt Jun 18 '19 at 6:03
0

You have bit errors in incoming packets. These are detected by cyclic redundancy check (CRC). There is an error detection code stuck on the end of every packet. This code may also be called a 'checksum'. This checksum must be a match for the rest of the packet, otherwise you have a 'bad checksum'.

If you are getting a lot of these warnings (> 10 per second), you might try replacing or bypassing the Ethernet cable and network switch your computer is connected to. Otherwise I wouldn't be too worried about a few bit errors.

3
  • The interesting thing here is that these happen at the UDP layer, and not at the lower layers, so I'd rule out a bad ethernet cable etc. – dirkt Jun 18 '19 at 6:04
  • Oh...sorry. I was mixing up MAC layer checksums, which are checked on every hop including switches, with UDP layer checksums. So the fault could have occurred much earlier while traversing intranet/internet. There would have to be pretty high error rate to get CRC collisions on the MAC layer that only later get detected on the UDP layer. – Andy Jun 19 '19 at 6:44
  • We are also getting same error and i have 400 servers and all running UDP base streaming service and i am seeing same error on all 400 servers, i don't think it network issue or ethernet card issue, this is something related to application or Kernel handling of UDP. – Satish Mar 8 '20 at 18:08

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.