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

2018-09-12 Thread Guy Harris
On Aug 25, 2018, at 1:27 PM, Guy Harris  wrote:

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

So which would be better:

1) the raw data from


https://github.com/matwey/libopenvizsla/wiki/OpenVizsla-protocol-description

   is what's in the packet in a pcap or pcapng file, and we just note 
that the Size field is redundant (it's the captured length minus 8 for the 
header)

or

2) the simple representation?

We can do either one.
___
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

2018-09-12 Thread Matwey V. Kornilov
сб, 1 сент. 2018 г. в 5:37, Michael Richardson :
>
>
> https://github.com/the-tcpdump-group/libpcap/commit/a69f42f7873db778613bbd5c4238acc2d0c31c89
>
> /*
>   * OpenVizsla http://openvizsla.org is open source USB analyzer hardware.
>   * It consists of FPGA with attached USB phy and FTDI chip for streaming
>   * the data to the host PC.
>   *
>   * Current OpenVizsla data encapsulation format is described here:
>   * 
> https://github.com/matwey/libopenvizsla/wiki/OpenVizsla-protocol-description
>   *
>   */
>  #define LINKTYPE_OPENVIZSLA 278
>
> 
>
> http://www.tcpdump.org/linktypes/LINKTYPE_OPENVIZSLA.html
>
> If you want changes, or if you'd like us to archive the format here,
> then send pull request against:
>  https://github.com/the-tcpdump-group/tcpdump-htdocs

Thank you.

For the reference, the link to the sources:
https://github.com/matwey/libpcap/tree/openvizsla

>
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
>


-- 
With best regards,
Matwey V. Kornilov
___
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

2018-08-25 Thread 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

2018-08-25 Thread 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


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

2018-08-22 Thread 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?

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

2018-08-22 Thread Guy Harris
On Aug 22, 2018, at 10:45 AM, Matwey V. Kornilov  
wrote:

> ср, 22 авг. 2018 г. в 20:31, Guy Harris :
> 
>> So what *does* the data field there contain?
> 
> The data is the captured USB packet starting from PID field.

As specified by:

Chapter 8 "Protocol Layer" of the USB 2.0 specification;

Chapter 8 "Protocol Layer" of the USB 3.1 specification;

and any other USB specifications needed to describe all USB packets for all 
versions of USB, presumably.
___
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

2018-08-22 Thread Matwey V. Kornilov
ср, 22 авг. 2018 г. в 20:31, Guy Harris :
>
> On Aug 22, 2018, at 1:57 AM, Matwey V. Kornilov  
> wrote:
>
> > Unfortunately, data coming from OpenVizsla doesn't fit to any existing
> > USB link layers headers.
> > Current OpenVizsla data encapsulation format is described here:
> > https://github.com/matwey/libopenvizsla/wiki/OpenVizsla-protocol-description
>
> So what *does* the data field there contain?

The data is the captured USB packet starting from PID field.

-- 
With best regards,
Matwey V. Kornilov
___
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

2018-08-22 Thread Guy Harris
On Aug 22, 2018, at 1:57 AM, Matwey V. Kornilov  
wrote:

> Unfortunately, data coming from OpenVizsla doesn't fit to any existing
> USB link layers headers.
> Current OpenVizsla data encapsulation format is described here:
> https://github.com/matwey/libopenvizsla/wiki/OpenVizsla-protocol-description

So what *does* the data field there contain?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers