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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 22 December 2020 00:31 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 19FC63A13A2 for <opsawg@ietfa.amsl.com>; Mon, 21 Dec 2020 16:31:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 FSggGkA5rFoY for <opsawg@ietfa.amsl.com>; Mon, 21 Dec 2020 16:31:46 -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 906303A139C for <opsawg@ietf.org>; Mon, 21 Dec 2020 16:31:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C84C9389B7; Mon, 21 Dec 2020 19:31:50 -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 3fbr4BJs4GtZ; Mon, 21 Dec 2020 19:31:49 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8AC26389B4; Mon, 21 Dec 2020 19:31:49 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 43B2C9A; Mon, 21 Dec 2020 19:31:42 -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
X-Attribution: mcr
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: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 21 Dec 2020 19:31:42 -0500
Message-ID: <12531.1608597102@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/sdjMYN7wj2nzXmSpy0pIlu3uCtI>
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 00:31:49 -0000

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



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