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

[Guy Harris]

On Aug 25, 2018, at 1:10 PM, Matwey V. Kornilov  
wrote:

> 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.

I suspected that's what the FPGA delivered.

> 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[];
> };

So your code to construct pcap files (or your libpcap module) would shuffle the 
header data around before providing the packet?

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

So we can just point to the USB 2.0 specification.

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

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

[Matwey V. Kornilov]

чт, 23 авг. 2018 г. в 6:11, Guy Harris :
>
> On Aug 22, 2018, at 1:57 AM, Matwey V. Kornilov  
> 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?

Hi,

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
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers