rc.35 backward compatibility issues

[Robin Gruyters]

Ok great!

BTW, the -X option works perfectly (for Argus process)

Regards,

Robin Gruyters
Network and Security Engineer
Yirdis B.V.
I: http://yirdis.com
P: +31 (0)36 5300394
F: +31 (0)36 5489119


Quoting Carter Bullard <carter at qosient.com>:

> Hey Phillipp and Robin,
> I've made the changes for this issue, and fixed a few other's, esp
> percent loss,
> and the icmp's (as you pointed out) were also missing.
> Should be up either this afternoon, or on Monday.
>
> Carter
>
>
> On Dec 12, 2006, at 8:50 AM, Philipp E. Letschert wrote:
>
>> Hi,
>>
>> attached patch should fix that issue, tested with 2.0 and 3.0 files  
>>   where loss
>> was recorded. Please confirm that it doesn't break other stuff.
>>
>> I also added the routine to print the total loss percantage    
>> (ploss), that never
>> showed up either for 2.0 or 3.0 files.
>>
>> Then I noticed that there are no routines to report ICMP_IPV6 loss,  
>>   but i didn't
>> touch this.
>>
>>
>> Bye, Philipp
>>
>> On Tue, Dec 12, 2006 at 01:12:31PM +0000, carter at qosient.com wrote:
>>> Hey Robin,
>>> That may not have been addressed, although sometimes, when you fix  
>>>   one bug, you get several as a bonus :o)
>>> If not, I may need some specific test records that express the    
>>> problem, so if anyone sees the issue, or any problems, don't    
>>> hesitate to send a few records my way!!!
>>>
>>> Carter
>>>
>>> Carter Bullard
>>> QoSient LLC
>>> 150 E. 57th Street Suite 12D
>>> New York, New York 10022
>>> +1 212 588-9133 Phone
>>> +1 212 588-9134 Fax
>>>
>>> -----Original Message-----
>>> From: Robin Gruyters <r.gruyters at yirdis.nl>
>>> Date: Tue, 12 Dec 2006 12:21:02
>>> To:argus-info at lists.andrew.cmu.edu
>>> Subject: Re: [ARGUS] rc.35 backward compatibility issues
>>>
>>> Hi ya,
>>>
>>> I have just downloaded .rc36 and was wondering if the backward
>>> compatibility with [s|d]loss was fixed..
>>>
>>> Regards,
>>>
>>> Robin Gruyters
>>> Network and Security Engineer
>>> Yirdis B.V.
>>> I: http://yirdis.com
>>> P: +31 (0)36 5300394
>>> F: +31 (0)36 5489119
>>>
>>>
>>> Quoting Carter Bullard <carter at qosient.com>:
>>>
>>>> Hey Philipp,
>>>> Yes, you are correct, the man record processing may seem  a bit  weird,
>>>> and there is a very long story to explain the current state of
>>>> affairs, that result in client programs not seeing "INIT" man  records.
>>>>
>>>> However, I suspect that we should do something that doesn't generate
>>>> confusion.  So, I'll put in initial man record counting, and    
>>>> we'll see how
>>>> that goes.
>>>>
>>>> I thought we fixed the [s|d]appbytes 2.x processing?  Do you have  a small
>>>> set of records ( >= 1) that shows the error?
>>>>
>>>> And, I'm not aware of the srcid getting screwed up, so if you  have a set
>>>> of records that show that, and what the number is suppose to be,  that
>>>> would be most excellent.
>>>>
>>>> Carter
>>>>
>>>>
>>>> On Nov 18, 2006, at 12:40 PM, Philipp E. Letschert wrote:
>>>>
>>>>> When reading 2.0.6 logfiles with ra 3.x I noticed two oddities:
>>>>>
>>>>> - some of the 'man' records are not read at all, so the number of
>>>>> records is not
>>>>> in sync with the output of racount. It looks that the missed    
>>>>> ones are the
>>>>> first entries, that are generated when argus starts and creates or
>>>>> appends to
>>>>> a logfile.
>>>>> Probably as a result of this, most of the 'srcid' entries are    
>>>>> screwed up.
>>>>> There are addresses like 5.0.0.66, 5.112.0.66, 5.168.0.66 and  so on.
>>>>>
>>>>> - when reading 2.0.6 files with ra 3.x the entries for loss, sloss
>>>>> and dloss are
>>>>> always zero, even when loss was recorded
>>>>>
>>>>> I can live with that - just to let you know...
>>>>>
>>>>>
>>>
>>>
>>>
>>
>> -- 
>>  /-\
>> C oo   "Das beste Werkzeug wird zum Tand in eines tumben Toren Hand."
>> _( ^)                                               Daniel Düsentrieb
>> /   -\
>> <argus_util.c.patch>
>
> Carter Bullard
> CEO/President
> QoSient, LLC
> 150 E. 57th Street Suite 12D
> New York, New York 10022
>
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax