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

[Guy Harris]

On Dec 21, 2020, at 4:31 PM, Michael Richardson <mcr+ietf at sandelman.ca> wrote:

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

Perhaps that field should be called "LinkTypeandInfo", or something such as that, to indicate that only the lower 16 bits are the link type.  (Link-layer header types are shared by pcap and pcapng, and the link-layer header type in a pcapng Interface Description Block is 16 bits.)

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

0 indicates "no FCS present".

And, yes, the spec should indicate that.

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

Yes, the length of the FCS is in 16-bit units.

And, yes, the spec should indicate that.

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

They were originally intended for use with some stuff NetBSD was doing (I'd have to look into the history of the NetBSD code), but I think NetBSD stopped doing that.

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

Yes.

> 2) some explanation of valid FCS values. Seems to be a multiple of 16-bits.
>   Is 0 valid?

Yes - it means "packets do not contain an FCS".

>  Or would that be indicated by LENGTH_PRESENT(x)==0?

*That* means "the FCS length, or whether there is an FCS, is unknown"; Wireshark does some heuristics to try to guess whether Ethernet packets have an FCS (I added those because, a long time ago, in a galaxy far far away, some Macs delivered Ethernet FCSes when capturing over BPF, and that messed up packet dissection in some cases).