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
On Jul 19, 2019, at 9:30 AM, Jasper Bongertz wrote:
> so if I get this right you expect to end up with a frame where length of the
> original
> content is less than what ends up in the pcap because meta data is added? This
> usually happens by adding a trailer to the Ethernet frame,
Not
On Jul 19, 2019, at 5:52 AM, Holger Pfrommer wrote:
> Now my question: I would be very useful to use pcap’s caplen and len values
> to report original packet length while a capture device adds additional data
> to a frame, for example a header containing some more details about the frame
>
Hi,
so if I get this right you expect to end up with a frame where length of the
original
content is less than what ends up in the pcap because meta data is added? This
usually happens by adding a trailer to the Ethernet frame, e.g. some TAPs do
that to add high precision timestamps and other
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
Hi,
I was wondering about a fact regarding the reported frame lengths in Wireshark.
The frame dissector states “bytes on wire” and “bytes captured” values.
I understand that these values where initially generated by the values caplen
and len in the pcap packet header as follows:
struct
