Re: request for a DLT value for wireshark DVB-CI

[Martin Kaiser <lists () kaiser cx>]

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.