tcpdump mailing list archives
Re: request for a DLT value for wireshark DVB-CI
From: Martin Kaiser <lists () kaiser cx>
Date: Sat, 26 Feb 2011 21:37:47 +0100
Hello Guy, thanks for the feedback, Thus wrote Guy Harris (guy () alum mit edu):
On Feb 13, 2011, at 3:14 PM, Martin Kaiser wrote:
I defined the pcap packet data for the new DLT on http://www.kaiser.cx/pcap-dvbci.html
The "Packet Header" section is pcap-specific; the link-layer type values can also be used in pcap-ng captures. In addition, note that tools that read pcap files - including Wireshark! - will not guarantee that they will interpret the time stamp in pcap records as anything other than UN*X time values, i.e. they won't be interpreted as "from the beginning of the capture", and values of 0 will be interpreted as January 1, 1970, 00:00:00 UTC.
If you want to say "no time stamp", use pcap-ng Simple Packet Blocks:
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionpbs
I think the right way to handle "from the beginning of the capture" time stamps, from my reading of the pcap-ng spec, is to put the capture start time into the Interface Description Block in a pcap-ng file as an if_tsoffset option.
My idea behind this section was to offer flexibility for timestamps so that people can adapt the meaning of the timestamp field to what their capturing hardware can deliver. I understand from your explanation that finally, there must be UN*X timestamps in a pcap capture file. If the hardware can't deliver them, they must be provided by the software that creates the pcap file. I haven't yet looked at pcap-ng to understand the newly added timestamp fields. Anyway, the conclusion seems to be: the timestamp handling for DVB-CI is no different from any other protocol that can be stored in a pcap (or pcap-ng) file and there's no need to say anything about timestamp handling for DVB-CI.
Basically, there'll be a pseudo-header around the bytes that are actually transfered, hardware events can also be logged.
What follows the pseudo-header? The DVB spec you refer to says
6.2 TSI - transport layer
The best starting point in the spec is picture 1 on page 4. The Common Interface consists of the "Transport Stream Interface" and the "Command Interface" (unfortunately called "Control" in this picture). My dissector dissects this command interface. Its layers are explained in figure 4, page 8. The physical layer is only register accesses and accomplishes a data transfer between CI module and host. Therefore the dissector starts with this transfered data, i.e. the link layer. The link layer is defined in Annex A 3.2, page 62. The data following the pseudo-header depends on the pseudo-header's event byte. For dvbci_header.event == DATA_HOST_TO_CAM or DATA_CAM_TO_HOST, the payload data is as follows: If dvbci_header.len == 2 2 bytes "buffer size" (the buffer size protocol is described in annex A.2.2.1.1. The CI module proposes a buffer size (essentially the maximum size for all following LPDUs) by sending two bytes. The host compares this to the maximum size it supports and sends back 2 bytes which will be the buffer size that is used for all subsequent LPDUs (link protocol data unit). If dvbci_header.len >= 3 an LPDU as in figure A.3, page 62. It starts with 1 byte "transport connection id" (a value>0), followed by one byte (0x00 == last, 0x80 == more) and a fragment of a transport layer packet (TPDU). For dvbci_header.event == CIS_READ, the data is a Card Information Structure as defined in the PC-Card specification. This CIS is a list of tuples, each tuple looking like 1 byte tag|1 byte length field|<length field> bytes data the last tuple has the tag 0xff, no len field, no data (my dissector doesn't mind if there's some random data appended to the cis) For dvbci_header.event == COR_WRITE, the data is 2 bytes address of the COR register | 1 byte COR value that was written For dvbci_header.event == HW_EVENT, the data is one of the bytes listed on the website. I hope this makes things clearer. I'll put this additional info on the website within tomorrow. Best regards, Martin - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- request for a DLT value for wireshark DVB-CI dissector Martin Kaiser (Feb 13)
- Re: request for a DLT value for wireshark DVB-CI Martin Kaiser (Feb 16)
- Re: request for a DLT value for wireshark DVB-CI dissector Guy Harris (Feb 25)
- Re: request for a DLT value for wireshark DVB-CI Martin Kaiser (Feb 26)
- Re: request for a DLT value for wireshark DVB-CI Guy Harris (Feb 27)
- Re: request for a DLT value for wireshark DVB-CI Guy Harris (Feb 27)
- Re: request for a DLT value for wireshark DVB-CI Martin Kaiser (Feb 27)
- Re: request for a DLT value for wireshark DVB-CI Guy Harris (Feb 27)
- Re: request for a DLT value for wireshark DVB-CI Martin Kaiser (Feb 27)
- Re: request for a DLT value for wireshark DVB-CI Guy Harris (Mar 01)
- Re: request for a DLT value for wireshark DVB-CI Martin Kaiser (Mar 02)
- Re: request for a DLT value for wireshark DVB-CI Martin Kaiser (Feb 26)