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