0

I'm using an online CRC-32 calculator to check that my output is correct however it seems that Wireshark has a different expected FCS for the ethernet packet.

message2 is the ethernet frame minus the FCS as seen in Wireshark

#include <stdio.h>
#include <stdint.h>

unsigned int crc32b(unsigned char *message) {
   int i, j;
   unsigned int byte, crc, mask;

   i = 0;
   crc = 0xFFFFFFFF;
   while (message[i] != 0) {
      //printf("%i %x \n\n", i, message[i]);
      byte = message[i];            
      crc = crc ^ byte;
      for (j = 7; j >= 0; j--) {  
         mask = -(crc & 1);
         crc = (crc >> 1) ^ (0xEDB88320 & mask);
      }
      i = i + 1;
   }
   return ~crc;
}

int main(void)
{
    unsigned char * message = "hello test";
    unsigned char * message2 = "aabbccddeeff5cb9017c5a53080000000000000000000000000000";
    unsigned int res = crc32b(message2);
    printf("%x\n", res);
    return 0;
}

I've tried using different Polynomials as defined in [1 - subsection CRC-32 IEEE 802.3], however the result does not match Wireshark.

Output using 0xED Polynomial: 0xd81e4af3

Wireshark FCS expected: 0xa8cd3084

I'd really like to code in the FCS for my ethhdr packet, I guess when creating a software packet, the FCS isn't entered by the NIC...

Sources:

[1] - http://crppit.epfl.ch/documentation/Hash_Function/WiKi/Cyclic_redundancy_check.htm

Danny Watson
  • 165
  • 5
  • 24
  • Could be checksum offloading? https://wiki.wireshark.org/CaptureSetup/Offloading – Spencer Mar 14 '20 at 16:01
  • @Spencer - I turned it off, I also validated on a remote host that the checksum is (blank) in this case – Danny Watson Mar 14 '20 at 16:02
  • 1
    With `crc = (crc >> 1) ^ (0xEDB88320 & mask);` I'd use `crc, mask` as `uint32_t` to avoid problems when `int` is not 32. – chux - Reinstate Monica Mar 14 '20 at 17:02
  • @DannyWatson: I have validated the output with my used implementation. The output `0xd81e4af3` is definitely correct. The output from wireshark isn't correct. You can read this in my last sentence of my answer. I will improve my answer as soon as possible. –  Mar 22 '20 at 00:02
  • Up-voted: The code could be improved, but it produces the correct result. It's an configuration issue. –  Mar 22 '20 at 01:01

3 Answers3

6

Your implementation is definitively correct (for NUL terminated C strings). It's a maybe a wrong configuration of the network interface. In default mode Wireshark doesn't get a FCS from the network driver. If you use Linux and the driver supports this, then you must enable this with ethtool to get the FCS.

Unfortunately, on my system this only works for receiving frames:

$ ethtool -K eth0 rx-fcs on

See this for details.

I use a slightly different algorithm in my embedded (for AVR microcontrollers) projects and it works perfectly for me:

#define CRC_POLY    0xEDB88320

uint32_t crc32_calc(uint8_t *data, int len)
{
    int i, j;
    uint32_t crc;

    if (!data)
        return 0;

    if (len < 1)
        return 0;

    crc = 0xFFFFFFFF;

    for (j = 0; j < len; j++) {
        crc ^= data[j];

        for (i = 0; i < 8; i++) {
             crc = (crc & 1) ? ((crc >> 1) ^ CRC_POLY) : (crc >> 1);
        }
    }

    return (crc ^ 0xFFFFFFFF);
}

A real world example:

The Ethernet frame in Wireshark (with ethtool rx-fcs on):

wireshark frame

The test with my used implementation:

uint8_t frame[] = { 0x20, 0xcf, 0x30, 0x1a, 0xce, 0xa1, 0x62, 0x38, 
                    0xe0, 0xc2, 0xbd, 0x30, 0x08, 0x06, 0x00, 0x01, 
                    0x08, 0x00 ,0x06 ,0x04 ,0x00 ,0x01 ,0x62 ,0x38, 
                    0xe0 ,0xc2 ,0xbd ,0x30 ,0x0a, 0x2a, 0x2a, 0x01, 
                    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0a, 0x2a, 
                    0x2a, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
                    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
                    0x00, 0x00, 0x00, 0x00 };


printf("0x%x\n", crc32_calc(frame, sizeof(frame)));

The output:

$ ./fcs-test 
0x6026b722
$

You can see, Wireshark reports 0x22bf2660 as correct FCS. Here is only a different output because of the byte-order. But the CRC calculation algorithm is correct.

EDIT:

I have modified your code:

uint32_t crc32b(uint8_t *message, int len) {
    int i, j;
    uint32_t crc, mask;
    uint8_t byte;

    crc = 0xFFFFFFFF;

    for (j = 0; j < len; j++) {
        byte = message[j];
        crc = crc ^ byte;
        for (i = 7; i >= 0; i--) {
            mask = -(crc & 1);
            crc = (crc >> 1) ^ (0xEDB88320 & mask);
        }
    }

    return ~crc;
}

I added a length argument, because your implementation only works correct when message is a NUL terminated C string. If your input is a byte array, then you get a incorrect CRC value.

See the differences (Array and C string):

uint8_t msg_arr[] = { 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff, 0x5c, 0xb9, 0x01, 0x7c, 0x5a, 0x53, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

char *msg_str = "aabbccddeeff5cb9017c5a53080000000000000000000000000000";

printf("0x%x\n", crc32b(msg_arr, sizeof(msg_arr)));
printf("0x%x\n", crc32b(msg_str, strlen(msg_str)));

Output:

$
0x3422dd71
0xd81e4af3
$
1

There are a number of problems with your code. There are also plenty of existing implementations you could compare (eg, this one linked from the real Wikipedia page on CRC).

  1. unsigned char * message2 = "aabbccddeeff5cb9017c5a53080000000000000000000000000000";

    Are you hoping that this will be the octet sequece 0xAA 0xBB 0xCC ... as you see them in Wireshark? Because that isn't at all what you have.

    This string actually contains 0x61 0x61 0x62 0x62 ... (assuming your platform uses ASCII encoding) because it is a character string and not an octet string.

    • specifically, here: byte = message[i]; you assume the first 8 bits of your message are an octet, and again I assume since you didn't say, that you expected this to be 0xAA. It will actually be 0x61.

     

    If you want this to work correctly, translate each pair of characters into an integer value using strtoul(pair, NULL, 16) or similar.

  2. You have a loop for (j = 7; j >= 0; j--) but never use j inside it. You do use the integer constant 1 in an odd-looking way: is there supposed to be a (1 << j) or something?

I suggest fixing the obvious errors, and then writing some self-contained tests before you try comparing whole frames with Wireshark. The code you posted has some basic errors that should be tested, identified and fixed before you get to this point.

Useless
  • 64,155
  • 6
  • 88
  • 132
0

Im not sure about your question, but if you want calculate a checksum of a network packet, you have to deploy the data in it's proper structure.

Please make sure your problem is not related with endianness. The network byte-order is big-endian, here is the point that the things getting a little bit harder.

Little-Endian mostly used in PCs but may vary by hardware and manufacturer.

2byte integer (16 bit integer) with value 255.

  • Little Endian: FF00
  • Big Endian: 00FF

Im not sure what kind of checksum you are trying to match with, but checksum not only for data field, mostly it contains all flags and options, issued at last step thats why the implementation require the corresponding data structure.

About checksums, there are a lot of case when you get an invalid checksum with wireshark, it could cause kernel, virtual adapter, accelerated network, dedicated CPU in your NIC, etc...

Example for TCP header:

/* include/linux/tcp.h */
struct tcphdr {
    __u16   source;
    __u16   dest;
    __u32   seq;
    __u32   ack_seq;
#if defined(__LITTLE_ENDIAN_BITFIELD)
    __u16   res1:4,
        doff:4,
        fin:1,
        syn:1,
        rst:1,
        psh:1,
        ack:1,
        urg:1,
        ece:1,
        cwr:1;
#elif defined(__BIG_ENDIAN_BITFIELD)
    __u16   doff:4,
        res1:4,
        cwr:1,
        ece:1,
        urg:1,
        ack:1,
        psh:1,
        rst:1,
        syn:1,
        fin:1;
#else
#error  "Adjust your <asm/byteorder.h> defines"
#endif  
    __u16   window;
    __u16   check;
    __u16   urg_ptr;
};
NPULSENET
  • 191
  • 4