[Ross Jacobs <rossbjacobs@xxxxxxxxx>]

Hi Tomasz,

My vote is for table lookup along a one-byte boundary as all of the existing CRC checkers in /wsutil currently use one. Notice how in our CRC16 and CRC32 implementations, we bitshift by 8 and 24 respectively. It should be possible to compute any CRC along a one-byte boundary. This article goes over how to implement non-CRC8 algorithms to do just that with a table lookup.

PyCRC was used to generate Wireshark's CRC6, CRC7, and CRC11 algorithms. You may want to take a look at it and see if it can help here. In this case, width=5 and poly=0x05 (assuming CRC5/USB found here).

Cheers,

Ross

On Fri, Jul 19, 2019 at 9:28 AM Tomasz Moń <desowin@xxxxxxxxx> wrote:

Hello,

I am currently working on USB Link Layer dissector. It is supposed to
be used with OpenVizsla FPGA-based USB hardware sniffer. USB Packets
feature two CRC types: CRC-5/USB and CRC-16/USB.

The CRC-16/USB is pretty straightforward. I have implemented it in [1]
and it works fine with my captures.

The CRC-5/USB is not so straightforward as it does not operate on the
byte boundary. The CRC-5/USB is calculated on 11 bits of data. I think
there are two possible approaches to check the CRC-5/USB in Wireshark:
1. Compute the CRC5 bitwise on the 11 bits of data, or
2. Compute the CRC5 with table-based algorithm on 2 bytes (11 bits
data + 5 bits CRC) and relying on the CRC properties expect fixed
output.

Which approach would be preferred?

Best Regards,
Tomasz Moń

[1] https://code.wireshark.org/review/#/c/34016/
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe