Hello Stephen,
I am not sure to understand your comments. What is worth with this patch ?
Is it to use the network datalink as a linktype and an extension ?
Or is it to indicate the presence of FCS on 1 bit in the extension ?
I did choose to indicate the presence of the FCS on 1 bit, because for
MTP2, there is only 2 possibilities.
Either the FCS are not there, or they are present, on 16 bits.
And, I think, the meaning of the linktype extension, is dependant of the
linktype.
For MTP2, it is used for the FCS presence (and not FCS length), for an
other linktypes, it could be an other kind of information.
I do not know, what is needed for PPP_SERIAL, and for the other existing
and futur linktypes.
So, for me the best is to let the users introduce what they need in this
field, and to let them document the meaning of the extension for each
linktype.
Regards
Florent
Stephen Donnelly
<[EMAIL PROTECTED]> To:
[email protected]
Sent by: cc:
[EMAIL PROTECTED] Subject: Re: [tcpdump-workers]
Request for a new DLT for MTP2 with FCS
tcpdump.org
19/02/2007 21:07
Please respond to
tcpdump-workers
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, [EMAIL PROTECTED]
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
> <[EMAIL PROTECTED]> To:
[email protected]
> Sent by: cc:
> [EMAIL PROTECTED] 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
>
>
>
>
>
> [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
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.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
