你这个应用很有借鉴意义
这不是单纯的CRC问题,这个涉及到以太网在做MAC地址的filter时,到底对地址进行了怎样的操作。
根据协议,在CRC之后,还需要对32位的数据进行reverse,然后取其高6位。所以无论你怎么做CRC,如果你不做翻转,你就不可能得到正确地址。具体需要去看协议。
目前来看,以太网的CRC模块是以字节为单位进行计算的,而CRC模块的计算单位是双字,对于6个字节怎么处理,我还没想到。
送你一段代码:
unsigned char data[] =
{
0x1f, 0x52, 0x41, 0x9c, 0xb6, 0xaf
};
unsigned int crc_table[] =
{
0x4DBDF21C, 0x500AE278, 0x76D3D2D4, 0x6B64C2B0,
0x3B61B38C, 0x26D6A3E8, 0x000F9344, 0x1DB88320,
0xA005713C, 0xBDB26158, 0x9B6B51F4, 0x86DC4190,
0xD6D930AC, 0xCB6E20C8, 0xEDB71064, 0xF0000000
};
for (n=0; n<sizeof(data); n++)
{
crc = (crc >> 4) ^ crc_table[(crc ^ (data[n] >> 0)) & 0x0F]; /* lower nibble */
crc = (crc >> 4) ^ crc_table[(crc ^ (data[n] >> 4)) & 0x0F]; /* upper nibble */
}
算出来的CRC先BIT翻转,再取其高6位,得到0x2c
|