title: Ethernet CRC32 calculation - software vs algorithmic result
body: <p>I'm trying to calculate the Frame Check Sequence (FCS) of an Ethernet packet byte by byte. The polynomial is <code>0x104C11DB7</code>. 
  I did follow the XOR-SHIFT algorithm seen here <a href="http://en.wikipedia.org/wiki/Cyclic_redundancy_check" rel="noreferrer">http://en.wikipedia.org/wiki/Cyclic_redundancy_check</a> or here <a href="http://www.woodmann.com/fravia/crctut1.htm" rel="noreferrer">http://www.woodmann.com/fravia/crctut1.htm</a></p>
  
  <p>Assume the information that is supposed have a CRC is only one byte. Let's say it is 0x03.</p>
  
  <ol>
  <li><p>step:  pad with 32 bits to the right</p>
  
  <p><code>0x0300000000</code></p></li>
  <li><p>align the polynomial and the data at the left hand side with their first bit that is not zero and xor them</p>
  
  <p><code>0x300000000 xor 0x209823B6E =  0x109823b6e</code></p></li>
  <li><p>take remainder align and xor again</p>
  
  <p><code>0x109823b6e xor 0x104C11DB7 = 0x0d4326d9</code></p></li>
  </ol>
  
  <p>Since there are no more bit left the CRC32 of 0x03 should be <code>0x0d4326d9</code></p>
  
  <p>Unfortunately all the software implementations tell me I'm wrong, but what did I do wrong or what are they doing differently?</p>
  
  <p>Python tells me:</p>
  
  <pre><code> "0x%08x" % binascii.crc32(chr(0x03))
   0x4b0bbe37
  </code></pre>
  
  <p>The online tool here <a href="http://www.lammertbies.nl/comm/info/crc-calculation.html#intr" rel="noreferrer">http://www.lammertbies.nl/comm/info/crc-calculation.html#intr</a> gets the same result.
  What is the difference between my hand calculation and the algorithm the mentioned software uses?</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>Turns out there was a similar question already on stack overflow:</p>
  
  <p>You find an answer here <a href="https://stackoverflow.com/questions/5047494/python-crc32-woes">Python CRC-32 woes</a></p>
  
  <p>Although this is not very intuitive. If you want a more formal description on how it is done for Ethernet frames you can look at the <a href="http://standards.ieee.org/getieee802/download/802.3-2008_section1.pdf" rel="noreferrer">Ethernet Standard document 802.3</a> Part 3 - Chapter 3.2.9 Frame Check Sequence Field</p>
  
  <p>Lets continue the example from above:</p>
  
  <ol>
  <li><p>Reverse the bit order of your message. That represents the way they would come into the receiver bit by bit. </p>
  
  <p><code>0x03</code> therefore is <code>0xC0</code></p></li>
  <li><p>Complement the first 32 bit of your message. Notice we pad the single byte with 32 bit again. </p>
  
  <p><code>0xC000000000 xor 0xFFFFFFFF  = 0x3FFFFFFF00</code></p></li>
  <li><p>Complete the Xor and shift method from above again. After about 6 step you get:</p>
  
  <p><code>0x13822f2d</code></p></li>
  <li><p>The above bit sequense is then complemented. </p>
  
  <p><code>0x13822f2d  xor 0xFFFFFFFF  =   0xec7dd0d2</code></p></li>
  <li><p>Remember that we reversed the bit order to get the representation on the Ethernet wire in step one. Now we have to reverse this step and we finally fulfill our quest.</p>
  
  <p><code>0x4b0bbe37</code></p></li>
  </ol>
  
  <p>Whoever came up with this way of doing it should be ...  </p>
  
  <p>A lot of times you actually want to know it the message you received is correct. In order to achieve this you take your received message including the FCS and do the same step 1 through 5 as above. The result should be what they call residue. Which is a constant for a given polynomial. In this case it is <code>0xC704DD7B</code>. </p>
  
  <p>As <em>mcdowella</em> mentions you have to play around with your bits until you get it right, depending on the Application you are using.</p>