Re: Request for a new DLT for MTP2 with FCS

[Stephen Donnelly <stephen () endace com>]

It seems that if it is worth making the change, it is also worth using a
couple of bits to indicate whether a 16 or 32-bit CRC/FCS is present as
Guy suggested. This could then be used on linktypes such as PPP_SERIAL
which can have either length.

Stephen.

On Mon, 2007-02-19 at 19:59 +0100, Florent.Drouin () alcatel-lucent fr
wrote:
>       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.
>
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
-- 
-----------------------------------------------------------------------
    Stephen Donnelly BCMS PhD           email: sfd () endace com
    Endace Technology Ltd               phone: +64 7 839 0540
    Hamilton, New Zealand               cell:  +64 21 1104378
-----------------------------------------------------------------------

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.