Re: Request for a new DLT for MTP2 with FCS (repost)

      Hello,


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.
This new DLT would be used to validate the FCS, and so to
identify "noise",
or damaged frames, due to bad transmission.
 As I did not find an other way to identify mtp2 frames with
FCS, specially
in case of malformed frame, I think this could be a valuable
argument to
introduce a new DLT.
Once selected on the capture device, this DLT will be used
for all the
frames captured. So we should not have the problem
encountered with the
Ethernet datalink, where the FCS are sometimes present,
sometimes not.

This patch do not change the behaviour of ERF_FCS_BITS, so
it preserves the
backward compatibility.
But now, if the variable ERF_FCS_BITS is not defined, and
only in this
case, the length of the FCS will be determined according to
the linktype.

This has the advantage to be easier for the user, and for
the wireshark
mtp2 dissector.
You just have to choose the datalink, and libpcap will
produce the
corresponding format, that can be fully decoded by wireshark
( I will
provide the modification needed for the MTP2 dissector to
decode the FCS).

The patch is a zipper tar file, based of libpcap-2007.02.12

(See attached file: mtp2_fcs_diff.zip)

Best regards
Florent


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

Florent.Drouinalcatel-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.