Re: [boost] problem with small width CRCs

From: Daryle Walker (darylew_at_[hidden])
Date: 2004-08-28 23:00:40

On 8/15/04 5:34 PM, "Bert Klaps" <bertk_at_[hidden]> wrote:

> On Sat, Aug 14, 2004 at 10:44:48PM -0400, Daryle Walker wrote:
>> On 8/10/04 11:32 AM, "Bert Klaps" <bertk_at_[hidden]> wrote:
>> 
>>> I ran into a problem using the CRC library for SDH LCAS control words
>>> (3-bit CRC) and SDH Trail Trace Identifier messages (7-bit CRC).
>> 
>> Could you provide sample data and answer so a new test case can be added?
> 
> Sure, though in the end I picked random values for
> polynomials etc and found that for CRC width or `Bits' < 8
> and ReflectIn = false crc_basic and crc_optimal give
> different results for those as well - crc_basic is correct
> of course.
> 
> Example #1 is a SDH/SONET Low Order LCAS control word with CRC-3
> taken from ITU-T G.707 (12/03) XIII.2:
> That's a 29 bit word protected by a 3 bit CRC, together
> 32 bits or 4 bytes. The ITU-T text itself has 4 examples which
> include a correct CRC-3. So the answer to these four sequences
> should be zero.
> a. 0x3a 0xc4 0x08 0x06, answer is 0
> b. 0x42 0xc5 0x0a 0x41, answer is 0
> c. 0x4a 0xc5 0x08 0x22, answer is 0
> d. 0x52 0xc4 0x08 0x05, answer is 0
> The LCAS CRC-3 parameters are:
> - polynomial: 0x3 ( x^3 + x + 1 )
> - initial remainder: 0
> - final xor value: 0
> - reflected input: false
> - reflected remainder: false
> 
> Example #2 is a SDH/SONET J0/J1/J2/N1/N2/TR TTI (trace message)
> with CRC-7, o.a. ITU-T G.707 Annex B, G.832 Annex A:
> That's basically calculated over 16 bytes: the first
> input byte is always 0x80, the following 15 bytes are
> printable characters. Some examples:
> a. "\x80""123456789ABCDEF" , answer is 0x62
> b. "\x80""TTI UNAVAILABLE" , answer is 0x23
> The TTI CRC-7 parameters are:
> - polynomial: 0x9 ( x^7 + x^3 + 1 )
> - initial remainder: 0
> - final xor value: 0
> - reflected input: false
> - reflected remainder: false
> 
>> Does anyone know how to add patches to a file?  (It looked like it was in a
>> "diff" format. 
> 
> Plain "diff -c"...

OK, I added the fixes from the original patch, and I added the two test
cases above.  I'm wondering: do the augmented-CRC functions need similar
protection from inappropriate shifting?  When I tried the augmented-CRC
functions with the new tests, I got (right) shifting warnings.  My attempt
to generalize the patch fix to the augmented-CRC functions got simultaneous
left- and right-shift warnings (so I removed that "fix").  I guess I haven't
thought about the problem enough.

The affected files would be "crc.hpp" and "crc_test.cpp".

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com