Interesting Traces - Wireshark's analysis of ARPs

The following trace is a lab reproduction of a trace captured by Wireshark (Version 0.99.7 (SVN Rev 23910)) while investigating the cause of an FTP performance problem. A host, in this case a PC sends out an ARP request which gets a reply with a bad FCS. AH HA! thats the problem.

But wait a minute. If the ARP reply were bad it should not have been followed by the FTP connection request, we should have seen another ARP request.

No.     Time        Source                Destination           Protocol Info
    352 0.499921    AsustekC_3f:ab:45     Broadcast             ARP      Who has 164.152.77.128?  Tell 164.152.77.50

    Frame 352 (42 bytes on wire, 42 bytes captured)
. . .
0000  ff ff ff ff ff ff 00 0c 6e 3f ab 45 08 06 00 01   ........n?.E....
0010  08 00 06 04 00 01 00 0c 6e 3f ab 45 a4 98 4d 32   ........n?.E..M2
0020  00 00 00 00 00 00 a4 98 4d 80                     ........M.


    353 0.011006    StratusC_42:52:22     AsustekC_3f:ab:45     ARP      164.152.77.128 is at 00:00:a8:42:52:22

    Frame 353 (64 bytes on wire, 64 bytes captured)
. . .
Ethernet II, Src: StratusC_42:52:22 (00:00:a8:42:52:22), Dst: AsustekC_3f:ab:45 (00:0c:6e:3f:ab:45)
. . .
    Trailer: 000000000000000000000000000000000000
    Frame check sequence: 0x6111b8f2 [incorrect, should be 0xcef0a597]
. . .

0000  00 0c 6e 3f ab 45 00 00 a8 42 52 22 08 06 00 01   ..n?.E...BR"....
0010  08 00 06 04 00 02 00 00 a8 42 52 22 a4 98 4d 80   .........BR"..M.
0020  00 0c 6e 3f ab 45 a4 98 4d 32 00 00 00 00 00 00   ..n?.E..M2......
0030  00 00 00 00 00 00 00 00 00 00 00 00 61 11 b8 f2   ............a...

No.     Time        Source                Destination           Protocol Info
    354 0.000007    164.152.77.50         164.152.77.128        TCP      4466 > ftp [SYN] . . .
    355 0.001552    164.152.77.128        164.152.77.50         TCP      ftp > 4466 [SYN, ACK] . . .
    356 0.000094    164.152.77.50         164.152.77.128        TCP      4466 > ftp [ACK] . . .

So what is going on?

Notice that in the ARP request Wireshark reports that 42 bytes were captured and the hex dump of the frame shows 42 bytes but not the FCS bytes. In the ARP reply Wireshark reports 64 bytes captured but now it shows bytes 61-64 as the bad FCS. Why doesn't it show the FCS bytes in the ARP request?

Some experimentation with ARP request packets shows what Wireshark is doing. Using the Colasoft Packet Builder I built and transmitted the following ARP packet. Notice the 30 extra bytes following the Destination IP and the FCS.

The following is what Wireshark captured. Notice that in the ARP request the FCS value is reported as the last 4 bytes of the extra data. In the ARP reply Wireshark again reports the last 4 bytes as the FSC but notice that now the last 4 bytes are the FCS of the ARP request. The host actually replying is programed to take the entire ARP frame, including it appears the FCS bytes, switch the source and destination fields, fill in its MAC address and send the whole thing back out - appending a new FCS on its way out. It appears that Wireshark will take the last 4 bytes of an ARP packet greater than 60 bytes (not including the FCS) and use those 4 bytes as the FCS.

No.     Time        Source                Destination           Protocol Info
    131 0.868412    AsustekC_3f:ab:45     Broadcast             ARP      Who has 164.152.77.128?  Tell 164.156.77.50

Frame 131 (72 bytes on wire, 72 bytes captured)
. . .
Ethernet II, Src: AsustekC_3f:ab:45 (00:0c:6e:3f:ab:45), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
. . .
    Trailer: 112233445566778899AABBCCDDEEFF112233445566778899...
    Frame check sequence: 0xccddeeff [incorrect, should be 0x2ea2341d]
. . .
0000  ff ff ff ff ff ff 00 0c 6e 3f ab 45 08 06 00 01   ........n?.E....
0010  08 00 06 04 00 01 00 0c 6e 3f ab 45 a4 9c 4d 32   ........n?.E..M2
0020  00 00 00 00 00 00 a4 98 4d 80 11 22 33 44 55 66   ........M.."3DUf
0030  77 88 99 aa bb cc dd ee ff 11 22 33 44 55 66 77   w........."3DUfw
0040  88 99 aa bb cc dd ee ff                           ........

No.     Time        Source                Destination           Protocol Info
    132 0.001280    StratusC_42:52:22     AsustekC_3f:ab:45     ARP      164.152.77.128 is at 00:00:a8:42:52:22

Frame 132 (76 bytes on wire, 76 bytes captured)
. . .
Ethernet II, Src: StratusC_42:52:22 (00:00:a8:42:52:22), Dst: AsustekC_3f:ab:45 (00:0c:6e:3f:ab:45)
. . .
    Trailer: 112233445566778899AABBCCDDEEFF112233445566778899...
    Frame check sequence: 0x03d74c37 [incorrect, should be 0xdfd0c503]
. . .
0000  00 0c 6e 3f ab 45 00 00 a8 42 52 22 08 06 00 01   ..n?.E...BR"....
0010  08 00 06 04 00 02 00 00 a8 42 52 22 a4 98 4d 80   .........BR"..M.
0020  00 0c 6e 3f ab 45 a4 9c 4d 32 11 22 33 44 55 66   ..n?.E..M2."3DUf
0030  77 88 99 aa bb cc dd ee ff 11 22 33 44 55 66 77   w........."3DUfw
0040  88 99 aa bb cc dd ee ff 03 d7 4c 37               ..........L7

Now is the OS (Stratus VOS running the Streams TCP/IP stack) sending these long ARP replies in error? I can find nothing that says that an ARP packet must be 64 bytes including the FCS and no problems communicating with other hosts because of ARP errors have been reported so I have to conclude that there is no violation of any standard. But looking at the Wireshark trace and its FCS error reports can make one pause for a few moments.

This page was last modified on 08-03-16

Send comments and suggestions
to ndav1@cox.net