Hello,
Guess I could chip in here, as the author of crc16.c ...
Stig Bjørlykke wrote:
Hi.
I am developing a dissector for a new protocol (an extension found in
STANAG 4406 Ed. 2 Annex E) which specifies usage of the CCITT-16
mechanism described in ITU-T X.25. As I want this dissector to be
included in Wireshark I want to implement the checksum checking the
correct way, by using the functions found in epan/crc16.c.
My problem is that this checksum routine does not match the routine
we have used in our prototype implementation of the protocol.
The question is which routine is the "correct" to use (I do not know
anything about CRC routines), and if they both are correct should I
add another table to use with the crc16_ccitt* functions?
The difference between your table and the one in crc16.h is the setting
of the "reverse" flag - essentially whether bits are shifted right or
left as the crc calculation progresses.
http://www.repairfaq.org/filipg/LINK/F_crc_v34.html#CRCV_001 explains
the difference.
The algorithm in crc16_ccitt() was written for, and works with, a
dissector for ITU H.223 (which claims to be the same as that used in ITU
V.42). However, as the document you link to notes, there does seem to be
a variety of possible interpretations of "the" ITU 16-bit crc. So it's
quite possible your protocol needs a different implementation, (and in
particular, it seems you need one with REVERSE=FALSE), in which case,
you'll need new functions in crc16.c.
In short, you need:
- A new table
- Uncomment crc16_unreflected
- A new entry point, like the existing crc16_ccitt, which uses your
table and crc16_unreflected instead of crc16_ccitt_table and
crc16_reflected.
I'm not sure how that document claims one particular use of the
CCITT/ITU 16-bit CRC polynomial to be the "usual" implementation. You'd
better make sure that you make it clear what standard you are
implementing for!
HTH,
Richard
--
Richard van der Hoff <richardv@xxxxxxxxxxxxx>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com
