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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 22 December 2020 01:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083953A044A for <opsawg@ietfa.amsl.com>; Mon, 21 Dec 2020 17:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKOpYb9xhqAN for <opsawg@ietfa.amsl.com>; Mon, 21 Dec 2020 17:39:30 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13E93A0418 for <opsawg@ietf.org>; Mon, 21 Dec 2020 17:39:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A7780389BA; Mon, 21 Dec 2020 20:39:35 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OfVtFiV5tebw; Mon, 21 Dec 2020 20:39:35 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1C04E389B8; Mon, 21 Dec 2020 20:39:35 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9EE849A; Mon, 21 Dec 2020 20:39:27 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: Pcap-ng file format <pcap-ng-format@winpcap.org>, tcpdump-workers <tcpdump-workers@lists.tcpdump.org>, opsawg@ietf.org
In-Reply-To: <12531.1608597102@localhost>
References: <12531.1608597102@localhost>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Dec 2020 20:39:27 -0500
Message-ID: <28076.1608601167@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/G2Nw8UqKUMnTYZKO0RTyN0zNaVI>
Subject: [OPSAWG] draft-gharris-opsawg-pcap.txt --- FCS length description
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Dec 2020 01:39:32 -0000

{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@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




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