Missing sport / dport for Argus 3.0.8

Tue Apr 5 12:35:53 EDT 2016

Hey Kjell,
Not a bug, but a feature.  There is specific code in the ArgusPrintPort() routine that prints a space when the value is zero.  If this is not what you want, you should modify these lines:
    char *tpstr = (port > 0) ? tcpport_string(port) : " ";
and 
    char *upstr = (port > 0) ? udpport_string(port) : " “;

You can set the to these lines:
    char *tpstr = tcpport_string(port);
and
    char *upstr = udpport_string(port);

Because the versions may move the line numbers around, make these changes in the routine ArgusPrintPort, which is in the file ./common/argus_util.c.  For argus-clients-3.0.8.2.rc.2 its at line 8322, and 8342.  Search for “port > 0” and you’ll find the offending code.

I believe that you can assume that if a CSV flow is empty, and the expected value in an int, long or float, then you can assume its zero in the record.  That is the logic we’ve worked with for a while.

If this is really important, I’ll make a configuration option in .rarc so you can configure blank or zero.
Carter

> On Apr 4, 2016, at 3:57 PM, Kjell Tore Fossbakk <kjelltore at gmail.com> wrote:
> 
> Hello Carter.
> 
> Thank you for a quick response.
> 
> The bug we experience are for IPv4 flows.
> 
> To specify our observations. The Argus running 3.0.8 does not produce _any_ CSV flows with sport equal to 0x0000 (for ICMP) or 0 (for TCP/UDP). They are all empty. The problem we are experiencing seems to be very stable and deterministic. At the moment we are "fixing" the problem by forcing 0x0000 if ICMP or 0 if TCP/UDP if the length of sport or dport is less than one. However, we dont like running Argus like this when it should behave differently.
> 
> We will bring another sensor online on the same TAP with 3.0.8.1 of both Argus and the Argus-clients, and correlate our findings with both the 3.0.6.1 and 3.0.8.
> 
> Do you recon this has anything to do with libpcap (reporting differently, and Argus wrong answers which could lead to empty fields), or would it be reasonable to seek the truth inside Argus only?
> 
> I will report back when we have anything to share.
> 
> .Kjell Tore
> 
> 
> 
> 
> 
> On Mon, Apr 4, 2016 at 4:21 PM, Carter Bullard <carter at qosient.com> wrote:
> Hey Kjell,
> argus-3.0.8.1, which is the official version, has fixes for ICMP, but the more recent developers version has specific bug fixes for ICMPv6 that you should be of interest to you.
> 
> http://qosient.com/argus/dev/argus-latest.tar.gz
> http://qosient.com/argus/dev/argus-clients-latest.tar.gz
> 
> These versions have been really stable and you should consider them to be the current versions at this point.
> 
> The source port should represent the ICMP type value, and the destination port should represent the ICMP code value.  At least that is the intended behavior of the tools.
> 
> Carter
> 
> > On Apr 4, 2016, at 9:10 AM, Kjell Tore Fossbakk via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
> >
> > Hello.
> >
> > Im running Argus Version 3.0.8 (same with clients) with libpcap 1.5.3.
> > Previously we ran Argus Version 3.0.6.1 with libpcap 1.1.1.
> >
> > We use ra with DELIMITERS "," and a list of fields, such as sport and dport. If we have an ICMP with sport=0, or TCP/UDP with sport=0/dport=0 and run this through both these Argus versiosn we get the following behavior;
> >
> > Using Argus 3.0.6.1 with libpcap 1.1.1 we get 0x0000 as sport for ICMP.
> > Using Argus 3.0.6.1 with libpcap 1.1.1 we get 0 as sport / dport for TCP/UDP.
> > For 3.0.0.6.1 we would seem to get sport 0 as icmp type=0, and sport 8 as icmp type=8.
> >
> > When Now, when we use the newest version;
> > Using Argus 3.0.8 with libpcap 1.5.3 we get <empty data> as sport for ICMP where we got 0x0000 for 3.0.6.1
> > Using Argus 3.0.8 with libpcap 1.5.3 we get <empty data> as sport/dport for TCP/UDP where we got sport/dport 0 for 3.0.6.1
> >
> > By <empty data> we mean there is nothing between the delimited on the output.
> >
> > I'v tried to read ChangeLogs, CHANGES etc in argus, argus-clients, libpcap. Also did a little "grepping" without much success.
> >
> > So, something must have changed. Question is was the change in Argus or libpcap? Was it deliberate, or is this a bug?
> >
> > Kjell Tore
> 
> 