On Sun, Jul 21, 2019 at 8:05 PM John Sullivan wrote:
> If the internal representation is in the sane order, then it's a
> simple matter to flip the table. (It simplifies the processing a tiny
> bit too.) Here is a version which handles 11 or 19 bit input
I have implemented the CRC-5 calculation
On Sunday, July 21, 2019, 6:37:48 AM, Tomasz Mon wrote:
> On Sat, Jul 20, 2019 at 8:42 PM John Sullivan wrote:
>> But here we have a fixed 11 bit input
> I am sorry, but I have completely missed out there there are two
> places where CRC5 is calculated:
> * In SETUP, OUT, IN, PING and SOF the
On Sat, Jul 20, 2019 at 8:42 PM John Sullivan wrote:
> One of the properties of LFSRs is that a 1 bit in the input toggles a
> completely predictable set of register bits *at any point in the
> future*. This isn't often useful for most CRC caculations on variable
> sized input, as the cost of
On Saturday, July 20, 2019, 9:10:36 AM, Tomasz Mon wrote:
> On Sat, Jul 20, 2019 at 5:37 AM Tomasz Mon wrote:
>> The advantage of 1) over 2) is the ability to be able, if the CRC is
>> incorrect, to tell what the correct CRC should have been.
>> Approach 2) allows only to veify if the CRC is
On Sat, Jul 20, 2019 at 5:37 AM Tomasz Moń wrote:
> The advantage of 1) over 2) is the ability to be able, if the CRC is
> incorrect, to tell what the correct CRC should have been.
> Approach 2) allows only to veify if the CRC is correct - but at the
> advantage of being able to take full bytes
On Sat, Jul 20, 2019 at 2:01 AM Ross Jacobs wrote:
> 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
On Sat, Jul 20, 2019 at 2:35 AM Guy Harris wrote:
> On Jul 19, 2019, at 9:26 AM, Tomasz Moń wrote:
> > 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
On Jul 19, 2019, at 9:26 AM, Tomasz Moń wrote:
> 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
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
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
10 matches
Mail list logo
