ICMP records of an unusual size
Carter Bullard
carter at qosient.com
Mon Mar 31 17:35:56 EDT 2014
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
>
>
More information about the argus
mailing list