wrong source ip addr on aggregation

[Carter Bullard]

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