This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

ICMP data field corruption

0

Hello,

my (old) laptop is unable to establish a wireless link over a cardbus WLAN card. After disabling WLAN encryption, I am able to send an echo request and there is an echo response from the server. Using WireShark, I can see that the ICMP checksum is wrong because the ICMP data is corrupted. Typically, 4 bytes "62 63 64 65" are blanked to "00 00 00 00" in the ICMP data field. Always the same locations are blanked:

Echo request ICMP data: 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69

Echo response ICMP data: 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 00 00 00 00 66 67 68 69

The laptop has WinXP SP3 installed. The cardbus card works fine in another laptop.
What can I check next? What kind of tools (freeware) can I use to analyze? Is it possible to view the ICMP data when it is transferred from the network card to the memory?

Thanks for help. manuel

asked 15 Jul '12, 14:52

manuel's gravatar image

manuel
1111
accept rate: 0%


2 Answers:

0

The ICMP checksum is probably not really wrong, and neither is the ICMP data corrupt. What you're doing is capturing on a system that is sending out packets through a network card that helps the system by taking over certain tasks from the CPU. If that happens, the calculation of checksums for IP, TCP, ICMP etc. is done just in that last moment before the packet goes out on to the actual physical medium, which is way after Wireshark has already picked it up. Google for "checksum offloading" or take a look here: http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html

If you don't believe me you can easily check this: only packets going OUT are affected. Capture them at the other node (as incoming packets) and you'll see they'll have perfect checksums.

I guess the cardbus card has some issues when trying to establish an encryption when running on Windows XP (or does the other laptop also run Windows XP? In that case you need to find out what the difference between the two systems is).

If you can't find any other reason you should probably try to talk to the vendor about it.

answered 15 Jul '12, 21:07

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 15 Jul '12, 21:09

Hi Jasper,

Thanks for the reply. I went through the attached link but I'm still not convinced:

Sending OUT an echo request from my laptop is not a problem: I can manually validate the checksum and also Wireshark reports a valid checksum. And: the other node replies with an echo response. So, I can assume that the echo request packet has been correctly sent out by my laptop and also correctly received at the other node (which is a FritzBox).

When receiving the echo response my laptop has a problem: the ICMP data field contains four bytes blanked to zero as described above. I can manually calculate and confirm that Wireshark is correct in reporting 'invalid checksum'. If I replace the four zeros by the four bytes "62 63 64 65" that I actually would expect, the manually calculated checksum matches the received checksum.

So, I think I really can conclude that something goes wrong while receiving the echo response on my laptop. And either there is no checksum offloading to the card because otherwise Wireshark would not even see this broken packet (as described in the link). Or the packet is still correct when it is received by the card and gets corrupted before Wireshark gets access on it.

Now, my question is: is there a way of logging the data transfer from the card to the memory? Or a tool that tells me which process/program is accessing which address in memory? I tried Sysinternals Process Explorer but I did not get this detailed information. What else could I try?

Regards
manuel

(16 Jul '12, 12:41) manuel

I'm not sure if there is a tool that could log data going from card to memory. My approach would be to actually stop capturing on a node taking part in the conversation (which is not a good capture setup anyway). Instead, capture with a 3rd, passive device to see what actually is transmitted on the wire (using a SPAN port, or even better: a TAP). That way you can make sure the packet is correct when it comes in.

(16 Jul '12, 14:10) Jasper ♦♦

0

Typically, 4 bytes "62 63 64 65" are blanked to "00 00 00 00" in the ICMP data field. Always the same locations are blanked:

There should be no data modification in the payload. Sounds like your PCCARD is broken. If the card works in another laptop, your PCCARD slot might be broken (or something else on that laptop). Could be a strange driver problem as well.

Try to boot the laptop with a linux distribution (maybe Ubuntu) and check if the PCCARD works there. The old ones will be detected quite well, if they are not too old ;-)

If it works on linux, it's a driver problem. Try to reinstall the driver. If it's the same on linux, I assume it's a hardware problem (see above).

Regards
Kurt

answered 16 Jul '12, 12:52

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 16 Jul '12, 13:00