Wireshark · Ethereal-dev: Re: [Ethereal-dev] Handling of malformed iee803.3 packets

["Jim Young" <SYSJHY@xxxxxxxxxxxxxxx>]

Hello Joerg,

>>> jmayer@xxxxxxxxx 08/25/05 5:46 AM >>>
> I've a packet that has an incorrect ieee803.3 header: The length field
> is too small to reflect the real packet size. 
>

It looks like before Ethereal even gets to the edp dissector 
it already knows something is wrong.  While in the "eth" 
dissector it generated the item:

  "Frame check sequence: 0x99000004 [incorrect, should be 0xf0e15365]"

Now looking in packet-eth.c this message can only 
occur when the "has_fcs" variable is set and when the 
"fcs != sent_fcs".  

If the "has_fcs" variable is set and "fcs == sent_fcs" 
then the dissector should generate an FCS "[correct]" 
item:

  "Frame check sequence: 0xAABBCCDD [correct]"

But I have NEVER seen any of the FCS "[correct]" messages 
in my traces because none of my ethereal traces appear 
to contain a real FCS value to validate; I believe the real
FCS gets stripped off by the NIC card drivers before we 
ever get a chance to peek at it.  So the fact that we even 
see a frame with an FCS, in the middle of a trace file where
we have no other frames with an FCS, could be a tip off 
that something IS not right with the current frame.  ;-)

When a lower level dissector has detected an anomaly, 
(in this case the "eth" dissector) how can one assume
that any of the higher level dissectors can trust their 
payloads?  At this point we have the potential for a 
cascade of errors.  

With the example trace you sent, the last error message 
seen was [Malformed  Packet: EDP].  But is this really 
a residual effect (or collateral damage) from the earlier 
detected "[incorrect]" FCS?

It looks like the FCS check was triggered in the first place 
because the captured  length was longer than the bogus 
payload length reported in the ethernet header.  I think 
it's the add_etherent_trailer() procedure within 
packet-eth.c that has the heuristics to determine 
whether or not an FCS might be present. 

Coincidentially I also saw a similar incorrect "Frame check 
sequence" a few days ago in some traces I was working 
with.  Unfortunately at the time I was too busy/focused 
on diagnosing a different network problem to investigate 
the reported "incorrect" Frame check sequence.  

But I've now gone back and tried to find traces with
"incorrect" FCS message.  Without any current 
support for an "eth.fcs" and/or "eth.fcs.valid==0" read
filter we can NOT quickly construct a simple read filter 
search such as:

   for i in *.trace; do tethereal -r $i -R 'eth.fcs'; done

Instead I had to expand the protocol tree (with tethereal's
-V option) and grep for the text "Frame check sequence"
to locate these bogus frames.  What's funny is that
many of the frames I've now found that supposedly contain 
an invalid "FCS" actually had no reported errors in the higher 
level protocols!  And upon closer inspection, do NOT have 
an invalid FCS, because the FCS is not in fact available.

To identify these type of frames within Ethereal you can 
use the "Find Packet" dialog (from the Edit menu) and do 
a "String" search for "Frame check sequence" within the 
"Packet details".

If I can ever fix my currently broken ethereal  development 
platform (cygwin) I'd really like to augment packet-eth
dissector with (at least) two new filter variables.  

   eth.fcs: - 32bit unsigned integer
   eth.fcs.valid: - boolean

These proposed variable would give us an easy way to
generate a read filter to help identify these types of suspect 
frames.

FWIW:  Going back over some recent traces I see that
I have a number of IGMP frames flagged as having an 
"incorrect" FCS.  In this case, the frames contain "Trailer" 
bytes to pad the frame to the mandatory ethernet 
minimum length of 64 bytes.    Both the capture and 
packet lengths are reported to be 64 bytes.  The IGMP 
payload ends at offset 0x29.  As reported by Buildbot
Ethernet (SVN 15390) The "Trailer" bytes run from offset 
0x2a to 0x3b, with the final four bytes of the frame, 
offset 0x3c to 0x3f being flagged as the "incorrect" FCS.

I hope someone finds the info useful.

Best regards,

Jim Young