The recipient of the IPv4 packet then creates the checksum of the received header in the same way: Invert¹ 0x2C8B to get the checksum: 0xD374įinally, insert the checksum into the header: 45 00 00 34 5F 7C 40 00 40 06 C0 A8 B2 14 C6 FC CE 19.The leading digit 4 is the carry count, we add this to the rest of the number to get 0x2C8B: bc Let's see how the sender of the packet calculates the header checksum: We can mentally split up this header as a sequence of ten 16-bit values: 0x4500, 0x0034, 0x5F7C, etc. The checksum's value is initially set to zero. The two bytes in square brackets is where the checksum will go. The sender hasn't calculated the checksum yet. These are the twenty bytes of our example packet header: 45 00 00 34 5F 7C 40 00 40 06 C0 A8 B2 14 C6 FC CE 19 Consequently, it should be easy to reproduce the results on Linux by copy-pasting the commands. In the following example, I use bc, printf and here strings to calculate the header checksum and verify it. If you can add some insight i would appreciate it.Here's a complete example with a real header of an IPv4 packet. So here's my attempt to decypher whats going on.Ĭhecksum + b) & 0xFF - this is a bitwise AND ( i thought I knew what this was doing but I don't ) my best guess is adding theġ111 1111 (FF) to what ever the inverse of b is?Ĭhecksum = (((checksum ^ 0xFF) + 1) & 0xFF) - doing the two's compiment on the checksum then adding 1111 1111 to what ever the invers of checksum is? which means that I may be chasing a majic value that someone pulled from the black hat in their pants!!! So everything I do from here on is just to increase the size of MY head. I also just found out from the guys with bigger heads than mine, thatĪlthough this value is required by the listener, it is ignored. However, thanks to Google, I'm slightly more educated on what is going on than I was yesterday. It seems to be working, although I still don't get the same value as the string that works. Private static string GetChecksum( string s)īyte binary = (s) Ĭhecksum = (((checksum ^ 0xFF) + 1) & 0xFF) It is variable length and includes both alpha and numeric charactors. Unfortunately, do to the nature of the industry, I wont be able to include the actuall data in the string. If I substitue a good string for a packet that works, and run it through the code above, I get a different value than i'm expecting. It doesn't match what I have for a good packet that works. Private static string GetChecksum(string s)Ģ. I searched around and found the following code: The Checksum is then represented as four ASCII-Hex The Checksum is initially set to zero and is the 16-bit binary addition (excluding parity if applicable) of all characters after, but not including, the SOH character and through (and including) the ETX character. In fact a ushort would be better.Īlso if you work directly with a byte string instead of a character string, and that byte string contains parity on 7 bit characters you may have to exclude it to satisfy the spec (masking it with &= 0x7F). The routine you have do not exclude the first character (presumed to be the SOH) from the calculation and also it use an int when your spec say to use a short.
0 Comments
Leave a Reply. |