ICMP records of an unusual size

Jesse Bowling jessebowling at gmail.com
Tue Apr 1 15:42:17 EDT 2014


Hi,

I got the following when trying to compile argus-3.0.7.3:

gcc -O3 -I. -I/usr/local/include -I./../include  -DHAVE_CONFIG_H -c
ArgusSource.c
In file included from ./ArgusModeler.h:330,
                 from ./argus.h:40,
                 from ArgusSource.c:67:
./ArgusSource.h:893: error: ‘ArgusIpNetPacket’ undeclared here (not in a
function)
make: *** [ArgusSource.o] Error 1

Following this I found:

#ifdef DLT_IPNET
   { ArgusIpNetPacket,   DLT_IPNET,  "ArgusIpNetPacket()" },
#endif

Since this seem to be geared towards Mavericks and not my platform I took a
chance and commented this out:

/*
#ifdef DLT_IPNET
   { ArgusIpNetPacket,   DLT_IPNET,  "ArgusIpNetPacket()" },
#endif
*/

Which seems to have resolved my issue...Is this expected? Michael, did you
encounter this error?

Cheers,

Jesse




On Mon, Mar 31, 2014 at 5:35 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Michael,
> Thanks !!!  That sure does make it a lot easier !!!
> If you don't mind sending a thumbs up or down, say tomorrow, that would be
> huge.  If up, I'll move the latest link to argus-3.0.7.3, probably can do
> that now....  and then warn the Mavericks users that a fix is on the way.
>
> Carter
>
> > On Mar 31, 2014, at 4:28 PM, Michael Sanderson <sanders at cs.ubc.ca>
> wrote:
> >
> > I've been running argus 3.0.7.3 on my capture system for about 3 hours
> without seeing any of the bogus pkts/bytes counts, which were appearing
> within an hour previously.
> >
> >      Michael Sanderson
> >
> >> On Mar 31, 2014, at 7:12 AM, Michael Sanderson <sanders at cs.ubc.ca>
> wrote:
> >>
> >> In my case, clients up to and including 3.0.7.18 can get through.
>  3.0.7.19 and onward have problems reading the bad data. I'll get back to
> you about argus 3.0.7.3.  I was running 3.0.5.10 prior to this.
> >>
> >>     Michael Sanderson
> >>
> >>> On Mar 31, 2014, at 5:13 AM, Carter Bullard <carter at qosient.com>
> wrote:
> >>>
> >>> OK, so with new argus-3.0.7.5 and most argus-clients, we've got bogus
> values poping up for pkts/bytes.  argus-clients-3.0.7.23 has problems
> reading the bad data, but previous clients can at least get through.
> >>>
> >>> Downgrading to 3.0.7.3 fixes the problem for those that have seen it
> ???
> >>>
> >>> I'm traveling this week, but will be working this to fix.  I need to
> try to reproduce the problem, so if anyone has a packet capture that
> generates, that would help !!!
> >>>
> >>> Sorry for the inconvenience !!!
> >>>
> >>> Carter
> >>>
> >>>> On Mar 31, 2014, at 2:59 AM, Michael Sanderson <sanders at cs.ubc.ca>
> wrote:
> >>>>
> >>>> Looking at my data more closely, I'm seeing these unexpectedly large
> pkts/bytes on TCP connections as well, not just ICMP. Haven't seen them
> from UDP, but ....
> >>>>
> >>>>   Michael Sanderson
> >>>>
> >>>>> On Mar 30, 2014, at 11:42 PM, Michael Sanderson <sanders at cs.ubc.ca>
> wrote:
> >>>>>
> >>>>> Jesse/Carter, I also see something similar after an update to argus
> 3.0.7.5 last week.  It is being collected via a radium from clients
> 3.0.7.6.  ra from 3.0.7.6 and from 3.0.7.18 reads the file, displaying the
> apparently bogus pkts/bytes.  The ra from 3.0.7.19 through 3.0.7.23
> displays everything up to the record with the bogus pkts/bytes. Perhaps
> this is the issue Scott McIntyre raised about argus-clients stopping, as he
> also had a 3.0.7.5 argus running.
> >>>>>
> >>>>> I have put a 110K anonymized file called data.anon in
> ftp.qosient.com:/incoming .
> >>>>>
> >>>>>   Michael Sanderson
> >>>>>
> >>>>>> On Mar 30, 2014, at 10:06 AM, Carter Bullard <carter at qosient.com>
> wrote:
> >>>>>>
> >>>>>> Well, these are weird.  Any chance I can get a file with these
> records in them ??
> >>>>>> So, any sense as to how these are generated, are they coming right
> off of argus ??
> >>>>>> Carter
> >>>>>>
> >>>>>>> On Mar 29, 2014, at 8:44 PM, Jesse Bowling <jessebowling at gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> I have some flows with duration zero, but they don't seem to match
> up with the R.U.S:
> >>>>>>>                 StartTime  Proto  Sport   Dir  Dport
>  TotPkts             TotBytes        Dur
> >>>>>>>  03/25/14 11:09:49.460105      1 0x0303   <-> 0x62ea
>      2                   61   0.069073
> >>>>>>>  03/25/14 11:09:49.473637      1 0x0303   <-  0x60ea
> 2182690890685501     2495973268128260   0.028096
> >>>>>>>  03/25/14 11:11:26.413780      1 0x0303   <-  0x68ea
> 1910394259086494     1915658761929220   0.032138
> >>>>>>>  03/25/14 11:11:26.427968      1 0x0303   <-  0x6aea
> 2019091291413663      612496964846084   0.006739
> >>>>>>>  03/25/14 11:11:52.824234      1 0x0303    -> 0x72ea
>      1                   70   0.000000
> >>>>>>>  03/25/14 11:11:52.832111      1 0x0303    -> 0x70ea
>      1                   70   0.000000
> >>>>>>>  03/25/14 11:12:46.868043      1 0x0303    -> 0x78ea
>   1280                34305   0.010306
> >>>>>>>  03/25/14 11:12:46.878386      1 0x0303   <-  0x76ea
> 3837314156567791      167070201545220   0.011786
> >>>>>>>  03/25/14 11:13:02.693644      1 0x0303    -> 0x62ea
>      1                   70   0.000000
> >>>>>>>  03/25/14 11:13:02.693721      1 0x0303    -> 0x64ea
>      1                   70   0.000000
> >>>>>>>
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>>
> >>>>>>> Jesse
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sat, Mar 29, 2014 at 2:51 PM, Carter Bullard <
> carter at qosient.com> wrote:
> >>>>>>> Hey Jesse,
> >>>>>>> What was the duration of these flows ??  If zero, we had a bug a
> while back where splitting records used an uninitialed chunk of memory.
> >>>>>>> If the duration is zero (only one packet) I'm thinking this maybe
> the result of that bug  ??
> >>>>>>>
> >>>>>>> Carter
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Mar 29, 2014, at 1:12 PM, Jesse Bowling <
> jessebowling at gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> I noticed a few odd records in our argus data the other day, and
> I'm a bit stumped as to how they might have gotten there...I see these:
> >>>>>>>>
> >>>>>>>>                 StartTime                 LastTime  Proto  Sport
>   Dir  Dport              TotPkts             TotBytes
> >>>>>>>>  03/25/14 11:09:49.473637 03/25/14 11:09:49.501733      1 0x0303
>   <-  0x60ea     2182690890685501     2495973268128260
> >>>>>>>>  03/25/14 11:11:26.413780 03/25/14 11:11:26.445918      1 0x0303
>   <-  0x68ea     1910394259086494     1915658761929220
> >>>>>>>>  03/25/14 11:11:26.427968 03/25/14 11:11:26.434707      1 0x0303
>   <-  0x6aea     2019091291413663      612496964846084
> >>>>>>>>  03/25/14 11:12:46.878386 03/25/14 11:12:46.890172      1 0x0303
>   <-  0x76ea     3837314156567791      167070201545220
> >>>>>>>>
> >>>>>>>> These records all had the same source and destination address.
> Does anyone have a theory? My guess is either corruption of the data (seems
> unlikely in this case) or perhaps something had issue parsing these
> particular records (racluster, rasplit)?
> >>>>>>>>
> >>>>>>>> Any suggestions from the list on how I might figure out more
> about these records or how they might have been generated?
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>>
> >>>>>>>> Jesse
> >>>>>>>> --
> >>>>>>>> Jesse Bowling
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Jesse Bowling
> >
> >
>



-- 
Jesse Bowling
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20140401/179c4d62/attachment.html>


More information about the argus mailing list