[pcap-ng-format] draft-gharris-opsawg-pcap.txt --- FCS length description

[Michael Richardson]

{resend due to problems with PGP signatures vs mailman}

Hi, I have reworked the document that Guy put into XML describing the *PCAP*
(not NG) format.   I found the text for LinkType to be confusing, and
frankly, I think wrong.

   *  LinkType (32 bits): an unsigned value that defines, in the lower
      16 bits, the link layer type of packets in the file, and
      optionally indicates the length of the Frame Check Sequence (FCS)
      of packets in the upper 16 bits.  The list of Standardized Link
      Layer Type codes is available in [LINKTYPES].  If bit 5 is set,
      bits 0 through 3 contain the length of the FCS field at the end of
      all packets; if bit 5 is not set, the length of the FCS field at
      the end of all packets is unknown.  Bit 4, and bits 6 through 15,
      SHOULD be filled with 0 by pcap file writers, and MUST be ignored
      by pcap file readers.

The numbering is driven by how the IETF likes to number bits, which has
always been a bit bizarre.

You can see the document at:
    https://datatracker.ietf.org/doc/draft-gharris-opsawg-pcap/
and from the links at:
    https://github.com/pcapng/pcapng
    which are fixed and updated thanks to circleci actions, I hope.

Looking at libpcap's pcap/pcap.h:
   https://github.com/the-tcpdump-group/libpcap/blob/master/pcap/pcap.h#L217

we see:
/*
 * Macros for the value returned by pcap_datalink_ext().
 *
 * If LT_FCS_LENGTH_PRESENT(x) is true, the LT_FCS_LENGTH(x) macro
 * gives the FCS length of packets in the capture.
 */
#define LT_FCS_LENGTH_PRESENT(x)	((x) & 0x04000000)
#define LT_FCS_LENGTH(x)		(((x) & 0xF0000000) >> 28)
#define LT_FCS_DATALINK_EXT(x)		((((x) & 0xF) << 28) | 0x04000000)

this suggests that the FCS length is really only 3 bits (maximum FCS size of
7 bytes?  Or does 0 indicate 8 bytes?  Ethernet is 4...).

I see, however:
   pcap-dag.c:
        p->linktype_ext = LT_FCS_DATALINK_EXT(pd->dag_fcs_bits/16);

I can find no other references.  So I guess Ethernet gets a value of 2 (*16 bits).
I can't find any other uses.
pcap_datalink_ext() is in pcap.c, but no the man page.

The code does not ignore bits 28:16 of the linktype field (the bits numbered
6:15 in the diagram).
Since we are nowhere close to 64K link types, from looking at the pcap
document only, we could make it 28-bits:
         BUT: pcapng has a 16-bit LinkType only, so we really need to limit this to
         16-bits.... OOPS.  I'll fix this in -01.

What I'm looking for in this email is:
1) confirmation that Linktype is 16-bits.
2) some explanation of valid FCS values. Seems to be a multiple of 16-bits.
   Is 0 valid?  Or would that be indicated by LENGTH_PRESENT(x)==0?
   Or is 0 ==> 8 * 16-bits => 128 bits of FCS.

I'm going to propose IANA considerations in a followup email and in -01.

--
Michael Richardson <mcr+IETF at sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




--
Michael Richardson <mcr+IETF at sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide