tcpdump mailing list archives
Re: Request for a new DLT for MTP2 with FCS (repost)
From: Florent.Drouin () alcatel-lucent fr
Date: Mon, 19 Feb 2007 19:59:11 +0100
Hello Guy, I have made the patch, so the 2 last bytes of the network datalink are now used as an extension of the linktype We can now consider the network datalink (32 bits) as a link type (16bits) and an extension (16 bits). On the extension, I just indicate that the FCS are present with the last bit set to TRUE. For the patch, I did add a mask to get only the 2 lower bytes for the linktype. I don't know if this will not lead to incompatibilities ? You said, NetBSD uses the 16 upper bits, but in libpcap code, I have seen any specific treatment. Did I missed something. Maybe I should use the mask only for a restricted list of DLT to be sure I will not create new problems ? (See attached file: pcap_linktype_ext.zip) I have made the patch for wireshark too, and there is a lot of impact in the structures, like data frame or capture_file. But it works, the FCS are integrated in the pcap file without any configuration from the end users, and the FCS are correctly decoded. Best regards Florent Guy Harris <guy () alum mit edu> To: tcpdump-workers () lists tcpdump org Sent by: cc: tcpdump-workers-owner@lists. Subject: Re: [tcpdump-workers] Request for a new DLT for MTP2 with FCS tcpdump.org (repost) 19/02/2007 05:58 Please respond to tcpdump-workers Florent.Drouin () alcatel-lucent fr wrote:
As requested few days before, I would like to use a new DLT to
distinguish
between MTP2 without FCS (the current DLT_MTP2) and MTP2 with FCS.
Or perhaps the link type value in the file header should be interpreted as having bitfields, with the lower 16 bits being the link layer type, and an indication of whether there's an FCS present being somewhere in the upper 16 bits. NetBSD already uses the upper 16 bits for its own purpose - if the upper 16 bits are 0x0224, the lower 16 bits are a NetBSD address family value. (Given that AF_INET6, for example, has at least 3 different values on various BSD-flavored OSes, 0x0224 should be treated as NetBSD-specific, with other values used for other OSes.) We could, for example, use the uppermost nibble as an FCS length indication, with the bit below it being an indication of whether the FCS length is known or not. That doesn't touch any of the bits in 0x0224. For all current DLT_ values, the bit would be clear, so the FCS length isn't known; that's the case for Ethernet, as not only is it not known whether any given DLT_EN10MB capture has FCSes in the packets or not (some do, some don't), it's not even known which *packets* in a capture that does have FCSes (packets sent by the machine doing the capture don't, but there's not a per-packet way of indicating that). I think it would be possible to make this work with pcap-NG as well. This has the advantage that "what is the link-layer header?" and "do frames have FCSes?" are separate questions, answered in separate bitfields of the link type value. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Attachment:
pcap_linktype_ext.zip
Description:
- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- Re: Request for a new DLT for MTP2 with FCS (repost) Florent . Drouin (Feb 16)
- Re: Request for a new DLT for MTP2 with FCS (repost) Guy Harris (Feb 18)
- Re: Request for a new DLT for MTP2 with FCS (repost) Florent . Drouin (Feb 19)
- Re: Request for a new DLT for MTP2 with FCS Stephen Donnelly (Feb 19)
- Re: Request for a new DLT for MTP2 with FCS Florent . Drouin (Feb 19)
- Re: Request for a new DLT for MTP2 with FCS (repost) Florent . Drouin (Feb 19)
- Re: Request for a new DLT for MTP2 with FCS (repost) Guy Harris (Feb 18)