Re: Request for a new DLT for MTP2 with FCS

As a question to the community in general, is it true that
the link
layer checksum is not normally included in libpcap records,
and that
only frames with valid L2 checksums are normally captured?

If so it seems clear that DLT_MTP2 (and other) link types
should not
have the L2 checksum present appended to their records.
Varying from
this practice would cause problems for applications which do
not expect
the extra bytes.

If there is a special case for MTP2 where capturing the L2
checksum is
desirable, then I agree that it makes sense to add a new DLT
value to
distinguish this.

It would only be necessary to add *_FCS DLTs where people
specifically
request the ability to capture the checksum. This would keep
the number
of new DLTs required to the minimum.

Regards,
Stephen

On Thu, 2007-02-08 at 19:44 +0100, Florent.Drouinalcatel-lucent.fr
wrote:
> I agree with you, the problem I am speaking about,
seems to be a common
> problem.
> It is very difficult to differentiate a frame with FCS
(Frame Check
> Sequence) and a frame without, if we are just looking
at the linktype.
> But, with the current libpcap, I do not see other
solutions, than using
> different linktypes.
> 
> Is it really a problem to create new linktypes, just
for such purpose ?
> (I understood that the linktypes are coded on 4 bytes
)
> 
> Regards
> Florent

-- 
------------------------------------------------------------
-----------
    Stephen Donnelly BCMS PhD           email: sfdendace.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.

On Feb 8, 2007, at 1:22 PM, Stephen Donnelly wrote:

> As a question to the community in general, is it true
that the link
> layer checksum is not normally included in libpcap
records,

No.

For example, sometimes a frame in a DLT_EN10MB capture might
have the  
CRC, and other times it might not.  Unfortunately, there's
currently  
no mechanism in libpcap - or in the capture mechanism used
on at least  
one family of OSes where that can happen (BPF) - to indicate
which  
frames have a CRC and which don't, so Wireshark, for
example, has a  
hack^Wheuristic to try to figure it out.

That can't be indicated with a different DLT_ value, because
packets  
that are sent *by* the machine doing the capture don't have
the CRC.   
It has to be done on a per-packet basis.

> and that
> only frames with valid L2 checksums are normally
captured?

That's not necessarily the case, either; I think some BSD
drivers, for  
example, will put the adapter in "accept even bad
packets" mode when a  
BPF ioctl is done to put it in promiscuous mode.

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