ICMP redirects with bad chksum

asked 2018-01-15 10:31:52 +0000

markj

flag of United Kingdom of Great Britain and Northern Ireland

1 ●1 ●2

updated 2018-01-15 10:55:15 +0000

grahamb

23835 ●4 ●975 ●227 https://www.wireshark.org

Hello, I have a customer who is showing errors increasing on mgmt port on Other Errors Rcvd counter and CRC Errors Rcvd.

Malware Gateway         : DEFAULT
SCSVRATD001> show intfport mgmt
Total Packets Received  : 51629543
Total Packets Sent      : 8509101
Total CRC Errors Rcvd   : 4663
Total Other Errors Rcvd : 570632
Total CRC Errors Sent   : 0
Total Other Errors Sent : 0

IP Address              : 192.168.131.195
Netmask                 : 255.255.252.0
MAC Address             : a4:bf:01:1d:a1:86
Malware Interface Port  : YES
Malware Gateway         : DEFAULT

In the pcaps I'm seeing chksum errors for some packets, but they look like they are outgoing?, so should be Tx errors, not the Rx errors he's seeing.

17:22:48.677154 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.131.195.https > 192.168.122.38.62329: Flags [S.], cksum 0x7f61 (incorrect -> 0x9bbb), seq 321591542, ack 834703075, win 29200, options [mss 1460, nop,nop,sackOK,nop,wscale 8], length 0

17:22:48.677312 IP (tos 0x0, ttl 64, id 23981, offset 0, flags [DF], proto ICMP (1), length 56) 192.168.129.4 > 192.168.131.195: ICMP redirect 192.168.122.38 to host 192.168.130.208, length 36 IP (tos 0x0, ttl 64, id 30961, offset 0, flags [DF], proto TCP (6), length 60, bad cksum 42a4 (->4290)!) 192.168.131.195.https > 192.168.122.38.62326: [|tcp]

17:22:48.677685 IP (tos 0x0, ttl 64, id 23982, offset 0, flags [DF], proto ICMP (1), length 56) 192.168.129.4 > 192.168.131.195: ICMP redirect 192.168.122.38 to host 192.168.130.208, length 36 IP (tos 0x0, ttl 64, id 30962, offset 0, flags [DF], proto TCP (6), length 212, bad cksum 420b (->41f7)!) 192.168.131.195.https > 192.168.122.38.62326: [|tcp]

17:22:48.677713 IP (tos 0x0, ttl 64, id 23983, offset 0, flags [DF], proto ICMP (1), length 56) 192.168.129.4 > 192.168.131.195: ICMP redirect 192.168.122.38 to host 192.168.130.208, length 36 IP (tos 0x0, ttl 64, id 2351, offset 0, flags [DF], proto TCP (6), length 60, bad cksum b266 (->b252)!) 192.168.131.195.https > 192.168.122.38.62325: [|tcp]

I'm not entirely sure, but it looks to me like 192.168.129.4 is sending ICMP packets to 192.168.131.195 (which is the ATD's mgmt IP), which is telling the ATD to redirect ping packets to somewhere else which is failing a chksum?.

Which doesn't explain this one where the header is too short:

17:22:48.695626 IP (tos 0x0, ttl 64, id 23992, offset 0, flags [DF], proto ICMP (1), length 56) 192.168.129.4 > 192.168.131.195: ICMP redirect 192.168.122.38 to host 192.168.130.208, length 36 IP (tos 0x0, ttl ...

(more)

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2018-01-15 14:46:07 +0000

Jaap

13742 ●711 ●115

Multiple questions here. Seems you're somewhat new in networking?

First off network interface statistics, these have to do with layer 1 being the physical connection. Bad cabling and connectors can cause these kind of problems. Unmatched interfaces as well.

Then the packet checksums, these have to do with layer 4 being the transport layer. Outgoing packets get captured before they arrive at the network card, of which the better ones are known to take on the task of checksum calculation. So when packets arrive at the capture interface these have not been calculated, hence most likely incorrect.

Then the ICMP reported errors. These packets have the first 28 bytes of the initiating packet as payload, which has more often than not an incomplete transport layer. The transport layer dissector doesn't like that and throws out an error indication.

edit flag offensive delete link

Comments

Thanks for your answer Jaap. I'm not exactly new in networking LOL. I understand the errors are being reported on L1. My question is really, would these packets in the pcap show in these lines in the stats?

Total CRC Errors Rcvd   : 4663
Total Other Errors Rcvd : 570632

The customer wants to know what's causing them. We have changed cables, ports and even the switch that is connected to the management port, set the negotiation, but these errors still show up and increasing over time. It's a bit of a mystery to me what else can cause those stats to increase. I would say it's a problem elsewhere in his network but I'm just trying to eliminate things and pin it down if I can. Everything seems to be working OK , he just wants to know if there is a fault in the device before ...(more)

markj ( 2018-01-15 14:56:14 +0000 )edit

Errors reported at the physical layer are flagged by the hardware. These cause the descriptors related to that frame to be flagged as error'ed, This is what's collected and reported by the network driver, and thus shows up in these statistics. These frames are dropped, there's no reason to push these flawed frames into the network stack, hence don't show up in a capture file. The protocols running over this network link are then responsible for recovering of the failed frame transmission.

Jaap ( 2018-01-15 20:54:33 +0000 )edit

just an additional clarification - while the flawed frames are not stored in the pcap file, the statistics provided by the interface is.

sindy ( 2018-01-16 07:24:51 +0000 )edit

add a comment

answered 2018-01-15 10:45:45 +0000

Jasper
24103 ●5 ●111 ●292 Düsseldorf, Germany

I guess the "bad checksums" in the output lines are for the quoted TCP following the ICMP header. Those quotes are usually truncated, so calculating a checksum for TCP will not work. I may be wrong, but it's a little hard to say without a pcap...

So I would ignore these CRC errors if they are for the quoted TCP protocol.

edit flag offensive delete link

add a comment