argus-clients 3.0.7.1 Cisco V9 flows
Carter Bullard
carter at qosient.com
Mon Oct 1 21:10:38 EDT 2012
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> 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" <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 -S cisco://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 -S cisco://host:port.
>>>>>>>
>>>>>>> Regards.
>>>>>>> Jon Denton
>>>>>>>
>>>>>>>
>>>>>>>> [root at syslog bin]# ./ra -S cisco://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 -S cisco://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/20121001/34813c64/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: argus-3.0.7.1.tar.gz
Type: application/x-gzip
Size: 834122 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121001/34813c64/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121001/34813c64/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2589 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121001/34813c64/attachment-0001.bin>
More information about the argus
mailing list