argus-clients 3.0.7.1 Cisco V9 flows
Carter Bullard
carter at qosient.com
Mon Oct 8 19:22:05 EDT 2012
Hey Jon,
Going back through the code that I just uploaded, you aren't going to be able to
run argus on live packet streams looking for cisco records like I suggested earlier.
You can read packet files, using the "-r cisco://path/to/the/pcap/file" option, but the "-S"
option isn't going to do anything for you.
I'm adding the decode cisco payload from live packet streams this week, so sorry
for the inconvenience. I wasn't paying enough attention to realize I had gotten
off track, and that the implementation was incomplete.
Very sorry about that.
Carter
On Oct 8, 2012, at 3:15 PM, Carter Bullard <carter at qosient.com> wrote:
> Hey Jon,
> Any success?
> You should be able to just run argus as a daemon without worrying about the gdb stuff,
> to see if they changes make any difference. Then you can just attach to argus to get
> the data to see if it looks ok.
>
> argus -X -S cisco://10.3.55.9:9996 -P 12345 -d
>
> then run something like ra().
>
> ra -S localhost:12345
>
> to see what you get.
>
> Carter
>
>
> On Oct 2, 2012, at 11:24 AM, jdenton at itcglobal.com wrote:
>
>> Hi Carter,
>>
>> Running argus but it is forking in gdb but I am not using -d ?
>> Can run standalone and write to a file.
>> Will write to a file and read with ra.
>>
>> Regards,
>> Jon
>>
>>
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]# gdb bin/argus
>>> GNU gdb (GDB) Fedora (7.2-51.fc14)
>>> Copyright (C) 2010 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "i686-redhat-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /usr/src/argus/argus-3.0.7.1/bin/argus...done.
>>> (gdb)
>>> (gdb) run -S cisco://10.3.55.9:9996 -w - | ra
>>> Starting program: /usr/src/argus/argus-3.0.7.1/bin/argus -S cisco://10.3.55.9:9996 -w - | ra
>>> argus[16611]: 02 Oct 12 10:16:11.293927 started
>>> During startup program exited with code 1.
>>> (gdb)
>>> (gdb)
>>> (gdb) quit
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]# ps -ef | grep argus
>>> root 16611 1 0 10:16 ? 00:00:00 /usr/src/argus/argus-3.0.7.1/bin/argus -S cisco://10.3.55.9:9996 -w -
>>> root 16615 25153 0 10:16 pts/0 00:00:00 grep --color=auto argus
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]# kill -9 16611
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]# gdb bin/argus
>>> GNU gdb (GDB) Fedora (7.2-51.fc14)
>>> Copyright (C) 2010 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "i686-redhat-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /usr/src/argus/argus-3.0.7.1/bin/argus...done.
>>> (gdb)
>>> (gdb)
>>> (gdb) run -S cisco://10.3.55.9:9996 -w argus.9996.arg
>>> Starting program: /usr/src/argus/argus-3.0.7.1/bin/argus -S cisco://10.3.55.9:9996 -w argus.9996.arg
>>> [Thread debugging using libthread_db enabled]
>>> Detaching after fork from child process 16622.
>>> Detaching after fork from child process 16623.
>>> argus[16623]: 02 Oct 12 10:16:52.212914 started
>>>
>>> Program exited normally.
>>> (gdb)
>>> (gdb)
>>> (gdb) quit
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]# ps -ef | grep argus
>>> root 16623 1 0 10:16 ? 00:00:00 /usr/src/argus/argus-3.0.7.1/bin/argus -S cisco://10.3.55.9:9996 -w argus.9996.arg
>>> root 16628 25153 0 10:16 pts/0 00:00:00 grep --color=auto argus
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]#
>>> [root at syslog argus-3.0.7.1]#
>>
>>
>>
>>
>>
>>
>>
>>
>> On 10/01/2012 08:10 PM, Carter Bullard wrote:
>>>
>>> Hey Jon,
>>> Here is a snapshot of the current argus-3.0.7.1. I'm sending this to the list,
>>> rather than posting
>>> it as I still have a few things to put in before I upload (changes, man page
>>> updates etc.....),
>>> a few bug fixes, etc.....I should have that up later this week.
>>>
>>> The netflow v9 parsing code is in this argus, as argus understands processing
>>> packets,
>>> the clients, like ra(), can't deal with pcap formatted files, so argus is our
>>> testbed. The logic
>>> should be the same.
>>>
>>> So if you run argus against your netflow v9 stream:
>>>
>>> argus -S cisco://10.3.55.9:9996 -w - | ra
>>>
>>> That maybe a good test, or at least a different test.
>>>
>>> With the gdb() output that you can generate using ra(), we should printout some
>>> of the variables to see why there is a problem decoding some of the port strings.
>>> Printing out the value of ' i ', ' tp ', ' *tp ' would be very helpful.
>>>
>>> Also running ra() with the -nn option, so that it won't try to print the port string
>>> may also be helpful to understand the bug.
>>>
>>> If you have any problems, send email to the list,
>>> Thanks !!!!
>>>
>>> Carter
>>>
>>>
>>>
>>> On Oct 1, 2012, at 1:23 PM, Carter Bullard <carter at qosient.com
>>> <mailto:carter at qosient.com>> wrote:
>>>
>>> > Hey Jon,
>>> > Sorry for the delay. I'll get that out his evenig as well.
>>> > Keep beating me up on this until I get it done.
>>> > Carter
>>> >
>>> > On Oct 1, 2012, at 12:15 PM, "jdenton at itcglobal.com
>>> > <mailto:jdenton at itcglobal.com>" <jdenton at itcglobal.com
>>> > <mailto:jdenton at itcglobal.com>> wrote:
>>> >
>>> >> Carter,
>>> >>
>>> >> Where can I get argus-3.0.7.1 src to give this a try?
>>> >> Don't see it under ~/argus/dev?
>>> >>
>>> >> Regards,
>>> >> Jon
>>> >>
>>> >>
>>> >> On 09/28/2012 10:12 AM, Carter Bullard wrote:
>>> >>> Hey Jon,
>>> >>> Very curious. argus-3.0.7.1 can read this pcap file, without any problems on my machines, here.
>>> >>> argus-clients and argus are sharing the same code for netflow decoding, or at least similar code.
>>> >>>
>>> >>> Can you do this on your machines to see what is happening?
>>> >>>
>>> >>> argus -r cisco:./Cisco-V9-Flow-10.3.55.9_28Sept2012.pcap -w - | ra
>>> >>>
>>> >>> If this doesn't work on your machine, then that will help, if it does, that will
>>> >>> help as well.
>>> >>>
>>> >>> Carter
>>> >>>
>>> >>> On Sep 28, 2012, at 10:31 AM,"jdenton at itcglobal.com" <jdenton at itcglobal.com> wrote:
>>> >>>
>>> >>>> Carter,
>>> >>>>
>>> >>>> Second run and pcap with ra -D 5 debugging enabled.
>>> >>>>
>>> >>>>
>>> >>>> Regards,
>>> >>>> Jon
>>> >>>>
>>> >>>>
>>> >>>> On 09/27/2012 03:30 PM,jdenton at itcglobal.com wrote:
>>> >>>>> Hi Carter,
>>> >>>>>
>>> >>>>> Here's the dump and the pcap for ra in gdb.
>>> >>>>> Suspect it occurred on packet 314 as it is the only packet fgrep finds 'DstPort:
>>> >>>>> 55284'.
>>> >>>>> Or a HASHNAMESIZE issue beyond the defined 4096 value in argus_util.h??
>>> >>>>>
>>> >>>>> Regards,
>>> >>>>> Jon
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> On 09/27/2012 06:33 AM, Carter Bullard wrote:
>>> >>>>>> Hey Jon,
>>> >>>>>> This looks pretty good until the Segmentation fault (core dumped).
>>> >>>>>> If possible, could you run ra() under gdb(), with the same options, so we
>>> >>>>>> can see where it blowing up?
>>> >>>>>>
>>> >>>>>> To turn on gdb support, if you haven't done this yet, try (in your clients root directory),
>>> >>>>>> % touch .devel .debug
>>> >>>>>> % ./configure
>>> >>>>>> % make clean; make
>>> >>>>>>
>>> >>>>>> % gdb bin/ra
>>> >>>>>> (gdb) run -Scisco://10.3.55.9:9996
>>> >>>>>>
>>> >>>>>> And we'll see where the problem is.
>>> >>>>>>
>>> >>>>>> If at the same time you can capture the port 9996 packet data, we maybe able to
>>> >>>>>> recreate the problems you are getting.
>>> >>>>>>
>>> >>>>>> Thanks !!!!!!!!!
>>> >>>>>>
>>> >>>>>> Carter
>>> >>>>>>
>>> >>>>>> On Sep 26, 2012, at 11:36 PM,jdenton at itcglobal.com wrote:
>>> >>>>>>
>>> >>>>>>> Carter,
>>> >>>>>>>
>>> >>>>>>> Here's the results for running the basic ra -Scisco://host:port.
>>> >>>>>>>
>>> >>>>>>> Regards.
>>> >>>>>>> Jon Denton
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>> [root at syslog bin]# ./ra -Scisco://10.3.55.9:9996
>>> >>>>>>>> ra[31076]: 22:24:15.616074 Binding 10.3.55.9:9996 Expecting Netflow records
>>> >>>>>>>> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport TotPkts TotBytes State
>>> >>>>>>>> 14:29:02.600000 N tcp 74.125.224.70.thpth ?> 10.15.131.2.49839 13 14027 CON
>>> >>>>>>>> 14:29:01.968000 N tcp 10.15.131.2.56016 ?> 206.165.250.94.thpth 3 132 CON
>>> >>>>>>>> 14:29:02.596000 N tcp 10.15.131.2.49840 ?> 74.125.224.70.thpth 13 1454 CON
>>> >>>>>>>> 14:29:02.600000 N tcp 74.125.224.70.thpth ?> 10.15.131.2.49840 18 18766 CON
>>> >>>>>>>> 14:29:18.132000 N tcp 88.208.52.174.thpth ?> 10.15.131.2.56034 17 17716 FIN
>>> >>>>>>>> 14:29:18.132000 N tcp 88.208.52.174.thpth ?> 10.15.131.2.56035 4 401 FIN
>>> >>>>>>>> 14:29:00.052000 N tcp 10.15.131.2.56011 ?> 77.247.179.176.thpth 5 687 FIN
>>> >>>>>>>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56026 51 60034 FIN
>>> >>>>>>>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56027 46 53753 FIN
>>> >>>>>>>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56028 51 60236 FIN
>>> >>>>>>>> 14:29:13.844000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56029 38 44091 FIN
>>> >>>>>>>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56024 37 40468 FIN
>>> >>>>>>>> 14:29:14.680000 N tcp 69.4.225.47.thpth ?> 10.15.131.2.56030 4 872 FIN
>>> >>>>>>>> 14:29:38.504000 N tcp 173.194.56.139.thpth ?> 10.15.131.2.49823 1 79 RST
>>> >>>>>>>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56025 45 50987 RST
>>> >>>>>>>> 14:29:31.864000 N tcp 10.15.131.2.49823 ?> 173.194.56.139.thpth 2 80 RST
>>> >>>>>>>> 14:29:41.880000 N tcp 96.8.80.129.thpth ?> 10.15.131.2.49810 1 40 RST
>>> >>>>>>>> 14:29:22.260000 N tcp 69.4.225.47.thpth ?> 10.15.131.2.56042 4 872 RST
>>> >>>>>>>> 14:29:02.620000 N tcp 10.15.131.2.56018 ?> 8.26.196.126.thpth 69 3829 RST
>>> >>>>>>>> 14:28:58.360000 N tcp 10.15.131.2.56006 ?> 88.208.52.174.thpth 12 1153 RST
>>> >>>>>>>> 14:29:43.376000 N tcp 204.8.40.44.46106 ?> 10.15.131.2.27302 2 1500 RST
>>> >>>>>>>> 14:29:43.376000 N tcp 10.15.131.2.27302 ?> 204.8.40.44.46106 1 40 RST
>>> >>>>>>>> 14:29:44.204000 N tcp 204.8.40.44.43379 ?> 10.15.131.2.timbu* 2 1500 RST
>>> >>>>>>>> 14:29:44.204000 N tcp 10.15.131.2.timbu* ?> 204.8.40.44.43379 1 40 RST
>>> >>>>>>>> 14:29:14.676000 N tcp 10.15.131.2.56031 ?> 69.4.225.47.thpth 2 92 RST
>>> >>>>>>>> 14:29:14.680000 N tcp 69.4.225.47.thpth ?> 10.15.131.2.56031 1 40 RST
>>> >>>>>>>> 14:28:59.716000 N tcp 10.15.131.2.56007 ?> 88.208.52.174.thpth 6 874 CON
>>> >>>>>>>> 14:29:46.948000 N tcp 74.125.224.73.thpth ?> 10.15.131.2.49821 2 120 RST
>>> >>>>>>>> 14:29:15.872000 N tcp 10.15.131.2.56033 ?> 206.165.250.94.thpth 3 132 RST
>>> >>>>>>>> 14:29:47.376000 N tcp 74.125.224.66.thpth ?> 10.15.131.2.49818 2 120 RST
>>> >>>>>>>> 14:29:47.576000 N tcp 74.125.224.66.thpth ?> 10.15.131.2.49824 2 119 RST
>>> >>>>>>>> 14:29:47.676000 N tcp 74.125.224.109.thpth ?> 10.15.131.2.49825 2 120 RST
>>> >>>>>>>> 14:29:47.836000 N tcp 74.125.224.143.thpth ?> 10.15.131.2.49826 2 120 RST
>>> >>>>>>>> 14:29:02.620000 N tcp 10.15.131.2.56019 ?> 8.26.196.126.thpth 3 132 RST
>>> >>>>>>>> 14:29:18.412000 N tcp 10.15.131.2.49842 ?> 96.8.80.129.thpth 5 620 RST
>>> >>>>>>>> 14:29:18.416000 N tcp 96.8.80.129.thpth ?> 10.15.131.2.49842 4 1674 RST
>>> >>>>>>>> Segmentation fault (core dumped)
>>> >>>>>>>> [root at syslog bin]#
>>> >>>>>>> On 09/26/2012 08:07 PM, Jon Denton wrote:
>>> >>>>>>>> Carter,
>>> >>>>>>>>
>>> >>>>>>>> I'll give it a try and send the results.
>>> >>>>>>>> I have a system sending v9 flows as a test.
>>> >>>>>>>> Will check the pcap for template packets.
>>> >>>>>>>>
>>> >>>>>>>> Regards,
>>> >>>>>>>>
>>> >>>>>>>> Jon Denton
>>> >>>>>>>> Director - Technology
>>> >>>>>>>> ITC Global
>>> >>>>>>>>
>>> >>>>>>>> ----- Reply message -----
>>> >>>>>>>> From: "Carter Bullard"<carter at qosient.com>
>>> >>>>>>>> To: "Jon Denton"<jdenton at itcglobal.com>
>>> >>>>>>>> Cc: "<argus-info at lists.andrew.cmu.edu>"<argus-info at lists.andrew.cmu.edu>
>>> >>>>>>>> Subject: [ARGUS] argus-clients 3.0.7.1 Cisco V9 flows
>>> >>>>>>>> Date: Wed, Sep 26, 2012 18:25
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> Hey jdenton,
>>> >>>>>>>> The netflow v9 support in argus-clients-3.0.7.2 , should work fine, but there is
>>> >>>>>>>> one report that indicated failure. However, we never got a packet file that
>>> >>>>>>>> could replicate the problems that were reported.
>>> >>>>>>>>
>>> >>>>>>>> What we need is more testing, and if there are problems, getting a good packet
>>> >>>>>>>> capture of netflow v9 traffic, including the template packets, will help us fix
>>> >>>>>>>> the bugs.
>>> >>>>>>>>
>>> >>>>>>>> This should work with the newest clients:
>>> >>>>>>>> ra -Scisco://host:port
>>> >>>>>>>>
>>> >>>>>>>> Once ra() gets some templates, then it should decode the flows. The host:port
>>> >>>>>>>> would be the same that were used to configure the router to send the flows data.
>>> >>>>>>>>
>>> >>>>>>>> Prior reports had bad timestamps, and core dumping, so it should be pretty
>>> >>>>>>>> obvious if you get the same results.
>>> >>>>>>>>
>>> >>>>>>>> Any help in this area would be greatly appreciated.
>>> >>>>>>>>
>>> >>>>>>>> Carter
>>> >>>>>>>>
>>> >>>>>>>> On Sep 26, 2012, at 1:26 PM,"jdenton at itcglobal.com" <jdenton at itcglobal.com> wrote:
>>> >>>>>>>>
>>> >>>>>>>> > To All,
>>> >>>>>>>> >
>>> >>>>>>>> > Working on Cisco V9 flows with Argus capture and decoding.
>>> >>>>>>>> > Saw a thread on trying to decode, I have a network that is generating
>>> >>>>>>>> > Cisco V9 flows and sending to a local server port 9996.
>>> >>>>>>>> > I can grab the raw stream with tshark to verify receipt but was
>>> >>>>>>>> > looking for direction on tracking down the decoding issue.
>>> >>>>>>>> >
>>> >>>>>>>> > Is anyone working on a debug of this? What is needed to recompile
>>> >>>>>>>> > the argus clients in debug mode so I can use gdb?
>>> >>>>>>>> >
>>> >>>>>>>> > May be able to provide raw pcaps of the traffic after scrubbing the
>>> >>>>>>>> > public IP addresses.
>>> >>>>>>>> >
>>> >>>>>>>> > Our goal is the use argus to capture flows from various networks across a
>>> >>>>>>>> > geographically diverse area, filter and if possible use radium to send
>>> >>>>>>>> > the filtered streams
>>> >>>>>>>> > to a centralized Scrutinizer flow collector.
>>> >>>>>>>> >
>>> >>>>>>>> > Regards,
>>> >>>>>>>> > jdenton
>>> >>>>>>>> >
>>> >>>>>>>> >
>>> >>>> <Cisco-V9-Flow-10.3.55.9_28Sept2012.pcap.gz><ra-cisco_v9-debug_D5_28Sept2012.log>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121008/8cb1f4a6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121008/8cb1f4a6/attachment.bin>
More information about the argus
mailing list