CRC32 calculation not working out

Question

I was trying to understand how the CRC-32 for ethernet works and am having some issues. I looked at an ARP request that had the hex values:

00000024e8cc96beffffffffffff080600010800060400010024e8cc96be0a3307fa0000000000000a3307fb0000000000000000000000000000000000000ff0fdca

and threw that into one of the many online generators and could not get the CRC to match up. It looks to me like the first two bytes (0x00 0x00) are the beginning of the frame, and that the last four bytes (0x0F 0xF0 0xFD 0xCA) are the CRC, but I cannot calculate that when I put the middle bytes into the online generators.

Any idea what I am assuming incorrectly?

Answer 1

I had a mistake in my original post. I was looking at the FPGA's loop-backed response, the real ARP looked like:

0000ffffffffffff0024e8cc96be080600010800060400010024e8cc96be0a3307fa000000000000‌0a3307fb0000000000000000000000000000000000000ff0fdca

(the src and dst mac are swapped). If I put everything after 0000 and before ff0fdca into the second link I had listed in the question, I get 0xCAFDF00F as a CRC, which is the same as originally sent out in the ARP request (just in reverse byte order). So it makes sense if you use the right data from the get go....