new argus-2.0.0u more...
Carter Bullard
carter at qosient.com
Sat Nov 4 09:04:08 EST 2000
Hey David,
If you increase the value for the -d option say up to 7
you'll get more information that will tell you if you're
reading data or not. I'm sure that we're reading data, we
probably just are looking for the wrong thing.
In gdb() break in ArgusReadConnection() to see if it
gets any data from the router, and then ArgusReadStream()
to see if the select() returns with any data at all.
OK, Argus clients report src counts/bytes as those
sent by the src, and dst counts/bytes as those sent by
the destination. The src/dst assignments are based on
the protocol types, and so for tcp, the src will be the
originator of the TCP connection. So if you run ra() like this:
ra -ncr argusfile - tcp and dst net 171.64 and dst port 6699
to get Napster transactions, you are saying that a Napster
server is sitting on port 6699 somewhere in the 171.64
network. The dst count/bytes in this situation will represent
traffic from the Napster server, as it was the destination
in the TCP transaction.
Does that help?
Carter
-----Original Message-----
From: David Brumley [mailto:dbrumley at rtfm.stanford.edu]
Sent: Friday, November 03, 2000 5:15 PM
To: Carter Bullard
Subject: Re: new argus-2.0.0u more...
Okay, I got the port released.
Now, I get:
Cnetops-10:# netstat -a | grep 9992
netops-10:# ./ra -d4 -ncCS 172.16.127.1 -P 9992
ra[20600]: 03 Nov 00 14:10:28.384489 ArgusAddHostList (172.16.127.1)
returning 1
ra: Trying 172.16.127.1 port 9992 Expecting Netflow records
ra[20600]: 03 Nov 00 14:10:28.384489 ArgusAuthenticate (4, 0x0)
returning 1
ra: receiving
ra[20600]: 03 Nov 00 14:10:28.384489 ArgusGetServerSocket (0x10b270)
returning 4
ra[20600]: 03 Nov 00 14:10:28.384489 ArgusReadConnection() returning 4
dbrumley at netops-10> netstat -a | grep 9992
flw-clt-master.59104 172.16.127.1.9992 Connected
But no output.
truss shows it polling(), but nothing else.
What would be a good place to start using gdb to find the problem?
Also, I have a side question. In argus 1.8, there is a source stream
and a destination stream. Suppose I want to count napster traffic.
I do:
ra -n -a -r file dst port 6699 and dst net 171.64
I'm interpreting destination traffic count as the amount of traffic
we're serving, i.e. those connecting to dst net 171.64 on napster port
6699 to retrieve files. Is this correct with your experience?
-david
>
> -----Original Message-----
> From: Carter Bullard [mailto:carter at qosient.com]
> Sent: Monday, October 30, 2000 9:15 AM
> To: 'David Brumley'
> Subject: new argus-2.0.0u and netflow
>
>
> Hey David,
> We'll I'll check the socket and bind calls but
> they should be working OK. I uploaded a new "u"
> version this morning that has a lot of debug messages
> that will help, and I tweaked the socket and connect
> calls, so lets test this "u".
> ftp://qosient.com/dev/argus/argus-2.0/argus-2.0.0u.tar.gz
>
> When you tar this, before doing the ./configure, do this
> in the argus root directory:
> % touch .debug
> % ./configure
>
> This will turn on debug printing support. Then after its
> made, run with these options:
>
> ra -d4 -ncCS 172.16.127.1 -P 9992
>
> This should print out some stuff and then be sitting there.
> While this is running, look at what the socket information
> is saying.
>
> netstat | fgrep 9992
>
> This should return at least one for the socket that we
> have opened. It should look something like this:
>
> udp 0 0 hostname:portnum 172.16.127.1:9992 ESTABLISHED
>
> If this is there then we're cool and should be receiving
> records from 172.16.127.1 on that port. If there are
> other sockets around, then we may have a conflict.
>
> Carter
>
>
> -----Original Message-----
> From: David Brumley [mailto:dbrumley at rtfm.stanford.edu]
> Sent: Friday, October 27, 2000 7:01 PM
> To: Carter Bullard
> Subject: Re: argus-2.0.0t
>
>
> > OK, based on the tcpdump output you should be calling
> > ra with:
> >
> > ra -ncCS 172.16.127.1 -P 9992
> >
>
> I still must be doing something wrong.
> netops-10:# ./ra -ncCS 172.16.127.1 -P 9992
> ra: Trying 172.16.127.1 port 9992 Expecting Netflow records
> ra: listening
>
> but nothing more.
>
> netops-10:# /usr/pubsw/sbin/tcpdump -n -q port 9992
> tcpdump: listening on hme0
> 13:45:00.239835 172.16.127.1.9991 > 171.64.24.138.9992: udp 736 (DF)
> 13:45:00.241415 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.242378 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.243373 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.244636 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.245628 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.246615 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.247594 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.248592 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.249574 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.250573 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
> 13:45:00.251553 172.16.127.1.9991 > 171.64.24.138.9992: udp 1168 (DF)
>
>
> The NFCD is still running, but shouldn't ra bail out if it couldn't
> get the port data?
>
>
> thanks,
> david
>
> --
> #+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
> David Brumley - Stanford Computer Security - dbrumley at Stanford.EDU
> Phone: +1-650-723-2445 WWW: http://www.stanford.edu/~dbrumley
> Fax: +1-650-725-9121 PGP: finger dbrumley-pgp at sunset.Stanford.EDU
> #+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
> World to end at 10:00. Symposium to follow.
--
#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
David Brumley - Stanford Computer Security - dbrumley at Stanford.EDU
Phone: +1-650-723-2445 WWW: http://www.stanford.edu/~dbrumley
Fax: +1-650-725-9121 PGP: finger dbrumley-pgp at sunset.Stanford.EDU
#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
World to end at 10:00. Symposium to follow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20001104/40619250/attachment.html>
More information about the argus
mailing list