[tcpdump-workers] Link-layer header type request for libopenvizsla

Matwey V. Kornilov matwey.kornilov at gmail.com
Sat Aug 25 16:10:46 EDT 2018

чт, 23 авг. 2018 г. в 6:11, Guy Harris <gharris at sonic.net>:
> On Aug 22, 2018, at 1:57 AM, Matwey V. Kornilov <matwey.kornilov at gmail.com> wrote:
> > Current OpenVizsla data encapsulation format is described here:
> > https://github.com/matwey/libopenvizsla/wiki/OpenVizsla-protocol-description
> Why are:
>         the magic header;
>         the size field;
> needed?


Answering your questions and Michael question, the url describes the
data coming from the hardware as is. Its format is defined by the
people developing FPGA firmware, that is currently not quite active:
https://github.com/openvizsla/ov_ftdi/tree/master/software/fpga So it
is unlikely that the format will change dramatically, but I just would
like to follow initial format as close as possible.

However, I agree that we can just use the following simple
representation for pcap:

struct {
  uint32_t timestamp;
  uint16_t flags;
  uint8_t usb_packet[];

OpenVizsla supports only USB 2.0: low, full and high speed.

> The magic number is always the same, so it contains zero bits of information (in the Claude Shannon sense).
> If the size field is just the number of bytes in the Data field, it's just the total packet size (from the "length" field in pcap files, the "Original Packet Length" field in pcapng Packet Blocks, Enhanced Packet Blocks, and Simple Packet Blocks) minus the number of header bytes prepended (which would just be 5, for the flags and timestamp fields, if none of the fields mentioned above are needed).
> Presumably the timestamp field is useful because either
>         it doesn't have to be converted to seconds-and-microseconds or seconds-and-nanoseconds units for pcap or 10^-N/2^-N ticks for pcapng
> or
>         it's a relative timestamp and can't be conveniently converted to an absolute time stamp
> so that it's not redundant with the timestamp field of the pcap record or pcapng block.

With best regards,
Matwey V. Kornilov

More information about the tcpdump-workers mailing list