wrong source ip addr on aggregation

[Carter Bullard]

Hey Frank,
On further testing, I have been able to replicate your xxxx.yyyy.xxxx.yyyy address error.
I’ll look into this further.
Carter

> On Jun 28, 2018, at 4:22 PM, Carter Bullard <carter at qosient.com> wrote:
> 
> Hey Frank,
> In my tests with some of your data, I’m not seeing racluster.1 generating errant data, but, it could be preserving more bits.  With your data, it looks like racluster.1 is preserving the leading 32 bits, but it should be preserving the leading 56 bits.  Looks that the code wants to preserve in 32-bit chunks, so its 32-bit preserving :O)
> 
>   I get this result for the aggregation of the source address  -   xxxx:yyyy::/32 
>   it could be  xxxx.yyyy.zzzz.ww::/56  …  is this what you expect ???
> 
> Carter
> 
>> On Jun 28, 2018, at 9:04 AM, Carter Bullard <carter at qosient.com> wrote:
>> 
>> Hey Frank,
>> Can you send a data file that replicates the problem ???  It does seem to be a bug.
>> Argus aggreagation of IP addresses uses a ‘longest prefix match’ algorithm,  and printing them as cidr addresses should show what bits are left over.  That is an option in the .rarc file.
>> 
>> Carter
>> 
>>> On Jun 28, 2018, at 8:41 AM, Frank <argus-mailinglist-1524134246 at f-block.org> wrote:
>>> 
>>> hi,
>>> 
>>> i encountered the following issue, resulting in a wrong source ipv6 address:
>>> 
>>> there are several connections to the same ipv6 address, coming from two
>>> different source addresses, which however share the same /48 bits:
>>> 
>>>  11:57:23.766559  e           tcp 1111:22:3333:4444::15.21978     ->
>>> caffe:affe::1.https        48      16800   FIN
>>>  12:03:26.631506  e           tcp 1111:22:3333:4444::15.52620     ->
>>> caffe:affe::1.smtp         47      22007   FIN
>>>  12:03:26.631451  e           tcp 1111:22:3333:4444::15.52620     ->
>>> caffe:affe::1.smtp         47      22007   FIN
>>>  12:05:08.037777  e           tcp 1111:22:3333:4444::15.51150     ->
>>> caffe:affe::1.http         11       1844   FIN
>>>  12:05:08.041924  e ipv6-icmp 1111:22:3333:4444::15.0x0080   <->
>>> caffe:affe::1.0x0000        2        178   ECO
>>>  12:05:08.037777  e           tcp 1111:22:3333:5555::15.51150     ->
>>> caffe:affe::1.http         11       1844   FIN
>>> 
>>> now, with racluster, i get this:
>>> 
>>> racluster -r /tmp/ipv6traffic -m daddr
>>>  08:01:18.051607  e            ip  1111:22:1111:22::          <->
>>> caffe:affe::1           12119    5900614   CON
>>> 
>>> with a wrong source net.
>>> 
>>> 
>>> there is only one icmp connection in /tmp/ipv6traffic (shown above), and
>>> when i strip it, suddenly the output changes to this:
>>> 
>>> racluster -r /tmp/ipv6traffic_stripped -m daddr
>>>  08:01:18.051607  e *         tcp          1111:22::           ->
>>> caffe:affe::1           12117    5900436   FIN
>>> 
>>> with a (more) correct stripped source address.
>>> 
>>> 
>>> btw. is there a way to influence the "ip-stripping" process on
>>> aggregation? e.g. in the last case, i would have expected this source
>>> address: 1111:22:3333::
>>> 
>>> and/or is it possible to somehow indicate on output, if and how many
>>> bits of the source (or destination) address have been stripped?
>>> 
>>> thanks
>>> frank
>>> 
>>> 
>> 
>> 
> 
>