Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsawg-pcap.txt --- FCS length description
Guy Harris <gharris@sonic.net> Tue, 22 December 2020 09:01 UTC
Return-Path: <gharris@sonic.net>
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 923873A0E9B for <opsawg@ietfa.amsl.com>; Tue, 22 Dec 2020 01:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 7Im9d--rExAX for <opsawg@ietfa.amsl.com>; Tue, 22 Dec 2020 01:01:04 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F053A0E97 for <opsawg@ietf.org>; Tue, 22 Dec 2020 01:01:04 -0800 (PST)
Received: from [192.168.42.85] (173-228-4-241.dsl.dynamic.fusionbroadband.com [173.228.4.241]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id 0BM912aP032231 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 22 Dec 2020 01:01:03 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Guy Harris <gharris@sonic.net>
In-Reply-To: <12531.1608597102@localhost>
Date: Tue, 22 Dec 2020 01:01:01 -0800
Cc: tcpdump-workers <tcpdump-workers@lists.tcpdump.org>, opsawg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <04F170EE-7020-4092-B94D-C09335FE87EE@sonic.net>
References: <12531.1608597102@localhost>
To: Pcap-ng file format <pcap-ng-format@winpcap.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Sonic-CAuth: UmFuZG9tSVaZFSoIGDNGRYf431Z3MZDpP0LtmIiWMd+e14yReUvrCikIFUxK+63+Vu/F7z4dzVC2729ewEqPi9K9pJnftZJ0
X-Sonic-ID: C;eHmANzRE6xG7AOyC/iHpiQ== M;WJbENzRE6xG7AOyC/iHpiQ==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/2HhkvprRAoO4mhK0DK-tkhGO13w>
Subject: Re: [OPSAWG] [pcap-ng-format] 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 09:01:07 -0000
On Dec 21, 2020, at 4:31 PM, Michael Richardson <mcr+ietf@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).
- [OPSAWG] draft-gharris-opsawg-pcap.txt --- FCS le… Michael Richardson
- [OPSAWG] draft-gharris-opsawg-pcap.txt --- FCS le… Michael Richardson
- [OPSAWG] draft-gharris-opsawg-pcap.txt --- IANA c… Michael Richardson
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Guy Harris
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Guy Harris
- Re: [OPSAWG] draft-gharris-opsawg-pcap.txt --- FC… Carsten Bormann
- Re: [OPSAWG] draft-gharris-opsawg-pcap.txt --- FC… Michael Richardson
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Guy Harris
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Guy Harris
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Michael Richardson
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Michael Richardson
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… mohamed.boucadair
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Michael Richardson
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Guy Harris
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Adrian Farrel
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… Michael Richardson
- Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsaw… tom petch