ICMP records of an unusual size

Michael Sanderson sanders at cs.ubc.ca
Mon Mar 31 10:12:45 EDT 2014


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
>> 
>> 




More information about the argus mailing list