1 |
/* |
2 |
* Function for computing CRC32 for the purpose of adding to Ethernet packets. |
3 |
* |
4 |
*/ |
5 |
|
6 |
#include "crc32.h" |
7 |
|
8 |
static const uint32 crc32table[0x100] = { |
9 |
0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, |
10 |
0x076dc419L, 0x706af48fL, 0xe963a535L, 0x9e6495a3L, |
11 |
0x0edb8832L, 0x79dcb8a4L, 0xe0d5e91eL, 0x97d2d988L, |
12 |
0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L, 0x90bf1d91L, |
13 |
0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL, |
14 |
0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, |
15 |
0x136c9856L, 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, |
16 |
0x14015c4fL, 0x63066cd9L, 0xfa0f3d63L, 0x8d080df5L, |
17 |
0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L, 0xa2677172L, |
18 |
0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL, |
19 |
0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, |
20 |
0x32d86ce3L, 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, |
21 |
0x26d930acL, 0x51de003aL, 0xc8d75180L, 0xbfd06116L, |
22 |
0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L, 0xb8bda50fL, |
23 |
0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L, |
24 |
0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, |
25 |
0x76dc4190L, 0x01db7106L, 0x98d220bcL, 0xefd5102aL, |
26 |
0x71b18589L, 0x06b6b51fL, 0x9fbfe4a5L, 0xe8b8d433L, |
27 |
0x7807c9a2L, 0x0f00f934L, 0x9609a88eL, 0xe10e9818L, |
28 |
0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L, |
29 |
0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, |
30 |
0x6c0695edL, 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, |
31 |
0x65b0d9c6L, 0x12b7e950L, 0x8bbeb8eaL, 0xfcb9887cL, |
32 |
0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L, 0xfbd44c65L, |
33 |
0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L, |
34 |
0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, |
35 |
0x4369e96aL, 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, |
36 |
0x44042d73L, 0x33031de5L, 0xaa0a4c5fL, 0xdd0d7cc9L, |
37 |
0x5005713cL, 0x270241aaL, 0xbe0b1010L, 0xc90c2086L, |
38 |
0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL, |
39 |
0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, |
40 |
0x59b33d17L, 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, |
41 |
0xedb88320L, 0x9abfb3b6L, 0x03b6e20cL, 0x74b1d29aL, |
42 |
0xead54739L, 0x9dd277afL, 0x04db2615L, 0x73dc1683L, |
43 |
0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L, |
44 |
0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, |
45 |
0xf00f9344L, 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, |
46 |
0xf762575dL, 0x806567cbL, 0x196c3671L, 0x6e6b06e7L, |
47 |
0xfed41b76L, 0x89d32be0L, 0x10da7a5aL, 0x67dd4accL, |
48 |
0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L, |
49 |
0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, |
50 |
0xd1bb67f1L, 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, |
51 |
0xd80d2bdaL, 0xaf0a1b4cL, 0x36034af6L, 0x41047a60L, |
52 |
0xdf60efc3L, 0xa867df55L, 0x316e8eefL, 0x4669be79L, |
53 |
0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L, |
54 |
0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, |
55 |
0xc5ba3bbeL, 0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, |
56 |
0xc2d7ffa7L, 0xb5d0cf31L, 0x2cd99e8bL, 0x5bdeae1dL, |
57 |
0x9b64c2b0L, 0xec63f226L, 0x756aa39cL, 0x026d930aL, |
58 |
0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L, |
59 |
0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, |
60 |
0x92d28e9bL, 0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, |
61 |
0x86d3d2d4L, 0xf1d4e242L, 0x68ddb3f8L, 0x1fda836eL, |
62 |
0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L, 0x18b74777L, |
63 |
0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL, |
64 |
0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, |
65 |
0xa00ae278L, 0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, |
66 |
0xa7672661L, 0xd06016f7L, 0x4969474dL, 0x3e6e77dbL, |
67 |
0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L, 0x37d83bf0L, |
68 |
0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0x30b5ffe9L, |
69 |
0xbdbdf21cL, 0xcabac28aL, 0x53b39330L, 0x24b4a3a6L, |
70 |
0xbad03605L, 0xcdd70693L, 0x54de5729L, 0x23d967bfL, |
71 |
0xb3667a2eL, 0xc4614ab8L, 0x5d681b02L, 0x2a6f2b94L, |
72 |
0xb40bbe37L, 0xc30c8ea1L, 0x5a05df1bL, 0x2d02ef8dL |
73 |
}; |
74 |
|
75 |
|
76 |
// The previous table could have been built using the following function : |
77 |
|
78 |
/* |
79 |
|
80 |
#define CRC32_POLY 0xedb88320; // this is a 0x04c11db7 reflection |
81 |
|
82 |
void init_crc32() |
83 |
{ |
84 |
int i, j, b; |
85 |
uint32 c; |
86 |
|
87 |
for (i = 0; i < 0x100; i++) { |
88 |
for (c = i, j = 0; j < 8; j++) { |
89 |
b = c & 1; |
90 |
c >>= 1; |
91 |
if (b) |
92 |
c ^= CRC32_POLY; |
93 |
} |
94 |
crc32table[i] = c; |
95 |
} |
96 |
} |
97 |
*/ |
98 |
|
99 |
// With this macro defined, the function runs about 35% faster, but the code is about 3 times bigger : |
100 |
#define RUN_FASTER |
101 |
|
102 |
#define DO_CRC(b) crc = (crc >> 8) ^ crc32table[(crc & 0xff) ^ (b)] |
103 |
|
104 |
uint32 ether_crc(size_t len, const byte *p) |
105 |
{ |
106 |
uint32 crc = 0xffffffff; // preload shift register, per CRC-32 spec |
107 |
|
108 |
for (; len>0; len--) { |
109 |
DO_CRC(*p++); |
110 |
} |
111 |
return ~crc; // transmit complement, per CRC-32 spec |
112 |
} |
113 |
|
114 |
/* |
115 |
* A brief CRC tutorial. |
116 |
* |
117 |
* A CRC is a long-division remainder. You add the CRC to the message, |
118 |
* and the whole thing (message+CRC) is a multiple of the given |
119 |
* CRC polynomial. To check the CRC, you can either check that the |
120 |
* CRC matches the recomputed value, *or* you can check that the |
121 |
* remainder computed on the message+CRC is 0. This latter approach |
122 |
* is used by a lot of hardware implementations, and is why so many |
123 |
* protocols put the end-of-frame flag after the CRC. |
124 |
* |
125 |
* It's actually the same long division you learned in school, except that |
126 |
* - We're working in binary, so the digits are only 0 and 1, and |
127 |
* - When dividing polynomials, there are no carries. Rather than add and |
128 |
* subtract, we just xor. Thus, we tend to get a bit sloppy about |
129 |
* the difference between adding and subtracting. |
130 |
* |
131 |
* A 32-bit CRC polynomial is actually 33 bits long. But since it's |
132 |
* 33 bits long, bit 32 is always going to be set, so usually the CRC |
133 |
* is written in hex with the most significant bit omitted. (If you're |
134 |
* familiar with the IEEE 754 floating-point format, it's the same idea.) |
135 |
* |
136 |
* Note that a CRC is computed over a string of *bits*, so you have |
137 |
* to decide on the endianness of the bits within each byte. To get |
138 |
* the best error-detecting properties, this should correspond to the |
139 |
* order they're actually sent. For example, standard RS-232 serial is |
140 |
* little-endian; the most significant bit (sometimes used for parity) |
141 |
* is sent last. And when appending a CRC word to a message, you should |
142 |
* do it in the right order, matching the endianness. |
143 |
* |
144 |
* Just like with ordinary division, the remainder is always smaller than |
145 |
* the divisor (the CRC polynomial) you're dividing by. Each step of the |
146 |
* division, you take one more digit (bit) of the dividend and append it |
147 |
* to the current remainder. Then you figure out the appropriate multiple |
148 |
* of the divisor to subtract to being the remainder back into range. |
149 |
* In binary, it's easy - it has to be either 0 or 1, and to make the |
150 |
* XOR cancel, it's just a copy of bit 32 of the remainder. |
151 |
* |
152 |
* When computing a CRC, we don't care about the quotient, so we can |
153 |
* throw the quotient bit away, but subtract the appropriate multiple of |
154 |
* the polynomial from the remainder and we're back to where we started, |
155 |
* ready to process the next bit. |
156 |
* |
157 |
* A big-endian CRC written this way would be coded like: |
158 |
* for (i = 0; i < input_bits; i++) { |
159 |
* multiple = remainder & 0x80000000 ? CRCPOLY : 0; |
160 |
* remainder = (remainder << 1 | next_input_bit()) ^ multiple; |
161 |
* } |
162 |
* Notice how, to get at bit 32 of the shifted remainder, we look |
163 |
* at bit 31 of the remainder *before* shifting it. |
164 |
* |
165 |
* But also notice how the next_input_bit() bits we're shifting into |
166 |
* the remainder don't actually affect any decision-making until |
167 |
* 32 bits later. Thus, the first 32 cycles of this are pretty boring. |
168 |
* Also, to add the CRC to a message, we need a 32-bit-long hole for it at |
169 |
* the end, so we have to add 32 extra cycles shifting in zeros at the |
170 |
* end of every message, |
171 |
* |
172 |
* So the standard trick is to rearrage merging in the next_input_bit() |
173 |
* until the moment it's needed. Then the first 32 cycles can be precomputed, |
174 |
* and merging in the final 32 zero bits to make room for the CRC can be |
175 |
* skipped entirely. |
176 |
* This changes the code to: |
177 |
* for (i = 0; i < input_bits; i++) { |
178 |
* remainder ^= next_input_bit() << 31; |
179 |
* multiple = (remainder & 0x80000000) ? CRCPOLY : 0; |
180 |
* remainder = (remainder << 1) ^ multiple; |
181 |
* } |
182 |
* With this optimization, the little-endian code is simpler: |
183 |
* for (i = 0; i < input_bits; i++) { |
184 |
* remainder ^= next_input_bit(); |
185 |
* multiple = (remainder & 1) ? CRCPOLY : 0; |
186 |
* remainder = (remainder >> 1) ^ multiple; |
187 |
* } |
188 |
* |
189 |
* Note that the other details of endianness have been hidden in CRCPOLY |
190 |
* (which must be bit-reversed) and next_input_bit(). |
191 |
* |
192 |
* However, as long as next_input_bit is returning the bits in a sensible |
193 |
* order, we can actually do the merging 8 or more bits at a time rather |
194 |
* than one bit at a time: |
195 |
* for (i = 0; i < input_bytes; i++) { |
196 |
* remainder ^= next_input_byte() << 24; |
197 |
* for (j = 0; j < 8; j++) { |
198 |
* multiple = (remainder & 0x80000000) ? CRCPOLY : 0; |
199 |
* remainder = (remainder << 1) ^ multiple; |
200 |
* } |
201 |
* } |
202 |
* Or in little-endian: |
203 |
* for (i = 0; i < input_bytes; i++) { |
204 |
* remainder ^= next_input_byte(); |
205 |
* for (j = 0; j < 8; j++) { |
206 |
* multiple = (remainder & 1) ? CRCPOLY : 0; |
207 |
* remainder = (remainder >> 1) ^ multiple; |
208 |
* } |
209 |
* } |
210 |
* If the input is a multiple of 32 bits, you can even XOR in a 32-bit |
211 |
* word at a time and increase the inner loop count to 32. |
212 |
* |
213 |
* You can also mix and match the two loop styles, for example doing the |
214 |
* bulk of a message byte-at-a-time and adding bit-at-a-time processing |
215 |
* for any fractional bytes at the end. |
216 |
* |
217 |
* The only remaining optimization is to the byte-at-a-time table method. |
218 |
* Here, rather than just shifting one bit of the remainder to decide |
219 |
* in the correct multiple to subtract, we can shift a byte at a time. |
220 |
* This produces a 40-bit (rather than a 33-bit) intermediate remainder, |
221 |
* but again the multiple of the polynomial to subtract depends only on |
222 |
* the high bits, the high 8 bits in this case. |
223 |
* |
224 |
* The multile we need in that case is the low 32 bits of a 40-bit |
225 |
* value whose high 8 bits are given, and which is a multiple of the |
226 |
* generator polynomial. This is simply the CRC-32 of the given |
227 |
* one-byte message. |
228 |
* |
229 |
* Two more details: normally, appending zero bits to a message which |
230 |
* is already a multiple of a polynomial produces a larger multiple of that |
231 |
* polynomial. To enable a CRC to detect this condition, it's common to |
232 |
* invert the CRC before appending it. This makes the remainder of the |
233 |
* message+crc come out not as zero, but some fixed non-zero value. |
234 |
* |
235 |
* The same problem applies to zero bits prepended to the message, and |
236 |
* a similar solution is used. Instead of starting with a remainder of |
237 |
* 0, an initial remainder of all ones is used. As long as you start |
238 |
* the same way on decoding, it doesn't make a difference. |
239 |
*/ |