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