ICMP records of an unusual size

[Michael Sanderson]

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