Problem with source labels

David lists at edeca.net
Fri Dec 6 16:21:42 EST 2013


On 05/12/2013 20:03, Carter Bullard wrote:
> Hey David,
> Its not the client code, they will do the right thing if argus identifies the format of the source id correctly.
> Do you have an /etc/argus.conf file that defines the source id ?
> If you run argus this way, does it get better ?
> 
>    argus -Xe \”1234\” -w - | ra -s +srcid
> 
> The X tells argus not to parse the /etc/argus.conf file.

Carter,

This isn't the problem.  It appears to be a behaviour (perhaps bug) in
argus itself, rather than the clients.

This works:

argus -X -e '"1234"' -i eth0 -w - | ra -s srcid

This does not:

argus -X -i eth0 -e '"1234"' -w - | ra -s srcid

  ArgusWarning: 06 Dec 13 17:49:15.373979 started
  ArgusWarning: 06 Dec 13 17:49:15.393885 ArgusGetInterfaceStatus:
interface eth0 is up
             SrcId
       50.49.66.65

That is if the -i option precedes -e then srcid labels are printed
incorrectly.  Above the srcid of AB12 is printed as 50.49.66.65.

When I first looked I assumed it was being interpreted as an IP address,
but a closer look shows that these are actually the decimal values of
the ASCII characters (reversed).

Looking in common/argus_client.c it switches on
trans->hdr.argus_dsrvl8.qual (line ~1850).  This is correctly set to
0x21 (ARGUS_TYPE_STRING) in the working example but is 0 when the
interface argument comes first.

Adding debug messages for ArgusUpdateBasicFlow() in argus/ArgusModeler.c
shows:

# Working
06 Dec 13 21:10:47.177515 ArgusUpdateBasicFlow() device->idtype: 33

# Non-working
06 Dec 13 21:11:27.867861 ArgusUpdateBasicFlow() device->idtype: 0

Because this is set to 0 the switch statement in the clients falls
through to the default and is treated as an integer, see below debug
output from ra:

ra[31960]: 17:47:29.816258 In case ARGUS_TYPE_IPV4, value 842089025
ra[31960]: 17:47:29.816274 String would be: AB12
       50.49.66.65

So when the -i option is provided before -e it appears that the srcid
type is being incorrectly set to 0, which does not appear to be a valid
ARGUS_TYPE_* value.

I have tested this on x86 and x64 and dropped gcc to -O2 just to be
sure.  Using argus-3.0.7.5 and argus-clients-3.0.7.18.

Is the above expected behaviour?

David



More information about the argus mailing list