Parent Confusion Error

Carter Bullard carter at qosient.com
Fri Nov 17 09:01:06 EST 2000


Gentle People,
   It seems that we are still getting parent confusion
errors, although the number has gone down considerably.
We have fixed some really major problems in the
process of snaking this issue down, such as a deadlock
condition, packet alignment problems, and some nits
with invalid lengths.

   Our parent confusion error happens during this type
of scenario.  When we get a packet that has a zero offset,
but the More Fragments bit is set, indicating that we should
expect that fragments for this packet are coming, we update
the main flows statistics for the packet and then we put
down a cache for the fragments that we expect to come.  The
problem is that when we go to create the fragment cache, one
already exists (this is OK since we can fragments out of
order) but there is already a parent pointer for the fragment,
and its pointing at a flow cache that is different than the
one we're currently looking at.

   There are two possibilities that I can imagine where
this can happen.  The parent that the pointer is referencing
has timed out and we deleted it.  The current packet causes
us to recreate the parent flow, but its pointer is different
from the cached parent flow.  That is the scenario that I've
been working with.

   The other possibility is that how we lookup fragments is
causing us to get the wrong fragment cache.

   Well neither of these is suppose to happen.  William
has reported that he's seeing that most of the problem packets
are fragmented ICMP packets.  Because I don't have any of
these types of packets on my network, I can't reconstruct the
problem.

   If anyone has parent confusion errors, and happens to
capture a tcpdump log that has some fragmented ICMP packets,
would you consider donating to the cause and send them
to me (ftp://qosient.com/incoming) so we can nip this thing?


Thanks!!!

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 17A
New York, New York  10022

carter at qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426


-----Original Message-----
From: Mark Poepping [mailto:poepping at cmu.edu]
Sent: Friday, November 17, 2000 8:10 AM
To: Carter Bullard
Subject: RE: Updated Argus-2.0.0A



Had some frag confusion overnight on A, but there was something nasty going
on (haven't
looked yet) since the argus file is 2-3x larger than normal..  Otherwise
it's stayed up since
2am..

hmm, coincidentally, UUNet was out for a few hours, that might have been an
issue..
from the restart log..
Fri Nov 17 01:13:07 EST 2000
Fri Nov 17 01:14:05 EST 2000
Fri Nov 17 01:14:06 EST 2000
Fri Nov 17 01:14:07 EST 2000
Fri Nov 17 01:16:38 EST 2000
Fri Nov 17 01:58:54 EST 2000
Fri Nov 17 02:11:51 EST 2000
Fri Nov 17 02:12:29 EST 2000
-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Carter Bullard
Sent: Friday, November 17, 2000 7:57 AM
To: 'Neil Long'
Cc: Argus (E-mail)
Subject: RE: Updated Argus-2.0.0A




Hey Neil,
   Thanks for the note.  It seemed like all was lost for a
moment there ;o)  I will move on to "B" today, and possibly
we'll have better luck given its a Friday.
Carter


-----Original Message-----
From: Neil Long [mailto:neil.long at computing-services.oxford.ac.uk]
Sent: Friday, November 17, 2000 3:41 AM
To: Carter Bullard
Subject: Re: Updated Argus-2.0.0A


Just for your peace of mind - latest 'A' configures and builds fine on
Solaris.
The new argus is happy reading 1.8 argus data files and ra will read
from a 1.8 argus server port. All just a quick test but with luck I
will find some round tuits later to do something more thorough.
Cheers
Neil
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Dr Neil J Long, Computing Services, University of Oxford
 13 Banbury Road, Oxford, OX2 6NN, UK Tel:+44 1865 273232 Fax:+44 1865
273275
 EMail:       Neil.Long at computing-services.oxford.ac.uk
 PGP:    ID 0xE88EF71F    OxCERT: oxcert at ox.ac.uk PGP: ID 0x4B11561D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20001117/351169b4/attachment.html>


More information about the argus mailing list