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