accepting data that is pushed with ARGUS_OUTPUT_STREAM

Fri Mar 1 14:12:58 EST 2013

Hey Ignas,
Looks like its opening the UDP socket correctly, but seems like its not getting UDP argus records, but something else on the port?
ra() reads 16 bytes from the stream, but it then doesn't parse anything.
Does tcpdump() show something else on that port?  If so try using a port number that is not being used?

I'm still " away from my desk " so I can't test this, myself until later this weekend.
Sorry for any inconvenience,

Carter

Sent from my iPad

On Mar 1, 2013, at 1:48 PM, nenaudoti Ignas Kazlauskas <ignas.linux at gmail.com> wrote:

> Hello,
> 
> here it is:
> 
> [root at prod ~]# ra -S argus-udp://10.4.1.6:561 -D31
> ra[1347.00d7899e337f0000]: 20:30:15.997726 main: reading files completed
> ra[1347.00d7899e337f0000]: 20:30:15.997858 ArgusCalloc (1, 72) returning
> 0x28eb810
> ra[1347.00d7899e337f0000]: 20:30:15.997877 ArgusNewQueue () returning
> 0x28eb810
> ra[1347.00d7899e337f0000]: 20:30:15.997895 ArgusPopQueue (0x28eb190)
> returning 0x7f339e6f6010
> ra[1347.00d7899e337f0000]: 20:30:15.997961 Binding 10.4.1.6:561
> Expecting Argus records
> ra[1347.00d7899e337f0000]: 20:30:16.007722 receiving
> ra[1347.00d7899e337f0000]: 20:30:16.007734 ArgusGetServerSocket
> (0x7f339e6f6010) returning 3
> ra[1347.00d7899e337f0000]: 20:30:16.697300 ArgusReadConnection() read 16
> bytes
> ra[1347.00d7899e337f0000]: 20:30:16.697510 ArgusAddToQueue (0x28eb810,
> 0x7f339e6f6010) returning 1
> ra[1347.00d7899e337f0000]: 20:30:16.697530 ArgusPopQueue (0x28eb190)
> returning (nil)
> ra[1347.00d7899e337f0000]: 20:30:16.697541 ArgusPopQueue (0x28eb810)
> returning 0x7f339e6f6010
> ra[1347.00d7899e337f0000]: 20:30:16.697549 ArgusAddToQueue (0x28eb190,
> 0x7f339e6f6010) returning 1
> ra[1347.00d7899e337f0000]: 20:30:16.697558 ArgusPopQueue (0x28eb810)
> returning (nil)
> ra[1347.00d7899e337f0000]: 20:30:16.697567 ArgusPopQueue (0x28eb810)
> returning (nil)
> ra[1347.00d7899e337f0000]: 20:30:16.697578 ArgusFree (0x28eb810)
> ra[1347.00d7899e337f0000]: 20:30:16.697587 ArgusDeleteQueue (0x28eb810)
> returning
> ra[1347.00d7899e337f0000]: 20:30:16.697600 ArgusShutDown (0)
> ra[1347.00d7899e337f0000]: 20:30:16.697609 RaParseComplete(caught signal 0)
> ra[1347.00d7899e337f0000]: 20:30:16.697618 ArgusPopQueue (0x28eb190)
> returning 0x7f339e6f6010
> ra[1347.00d7899e337f0000]: 20:30:16.697627 ArgusCloseInput(0x9e6f6010)
> closing
> ra[1347.00d7899e337f0000]: 20:30:16.697637
> ArgusWriteConnection(0x9e6f6010, 0x4ad181, 6) returning 6
> ra[1347.00d7899e337f0000]: 20:30:16.697646 ArgusCloseInput(0x9e6f6010) done
> ra[1347.00d7899e337f0000]: 20:30:16.697693 ArgusFree (0x7f339e6f6010)
> ra[1347.00d7899e337f0000]: 20:30:16.697705 ArgusPopQueue (0x28eb190)
> returning (nil)
> ra[1347.00d7899e337f0000]: 20:30:16.697713 ArgusFree (0x28eb190)
> ra[1347.00d7899e337f0000]: 20:30:16.697721 ArgusDeleteQueue (0x28eb190)
> returning
> ra[1347.00d7899e337f0000]: 20:30:16.697729 ArgusPopQueue (0x28eb1e0)
> returning (nil)
> ra[1347.00d7899e337f0000]: 20:30:16.697737 ArgusPopQueue (0x28eb1e0)
> returning (nil)
> ra[1347.00d7899e337f0000]: 20:30:16.697745 ArgusFree (0x28eb1e0)
> ra[1347.00d7899e337f0000]: 20:30:16.697752 ArgusDeleteQueue (0x28eb1e0)
> returning
> ra[1347.00d7899e337f0000]: 20:30:16.697760 ArgusWindowClose () returning
> ra[1347.00d7899e337f0000]: 20:30:16.697777 RaParseComplete(caught signal 0)
> ra[1347.00d7899e337f0000]: 20:30:16.697786 RaParseComplete(caught signal 0)
> ra[1347.00d7899e337f0000]: 20:30:16.697793 ArgusShutDown (0)
> ra[1347.00d7899e337f0000]: 20:30:16.697801 ArgusPopQueue ((nil))
> returning (nil)
> ra[1347.00d7899e337f0000]: 20:30:16.697810 ArgusFree (0x28eb050)
> ra[1347.00d7899e337f0000]: 20:30:16.697819 ArgusDeleteList (0x28eb050,
> 4) returning
> ra[1347.00d7899e337f0000]: 20:30:16.697827 ArgusFree (0x28eb0f0)
> ra[1347.00d7899e337f0000]: 20:30:16.697835 ArgusDeleteList (0x28eb0f0,
> 4) returning
> [root at prod ~]#
> [root at prod ~]# uname -a
> Linux prod.inter.local 2.6.32-279.22.1.el6.x86_64 #1 SMP Wed Feb 6
> 03:10:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> 
> [root at prod ~]# ra -n -r argus.out
> works ok
> 
> Tried stable and latest versios of argus-clients (3.0.6 and 3.0.7.5).
> 
> CentOS 6.3. iptables, SELinux disabled.
> 
> -- 
> Ignas
> 
> On 2013-03-01 18:53, Carter Bullard wrote:
>> Hey Ignas,
>> Looks like a bug.  Why not run with -D12 or higher to see more info?
>> Carter
>> 
>> Sent from my iPad
>> 
>> On Mar 1, 2013, at 10:15 AM, Ignas <ignas.linux at gmail.com> wrote:
>> 
>>> Thank you for a quick response.
>>> 
>>> Testing env:
>>> c01 -  10.4.1.101 - pushes data with ARGUS_OUTPUT_STREAM=argus-udp://10.4.1.6:561
>>> prod - 10.4.1.6   - should accept that data
>>> 
>>> Incoming data as seen on prod:
>>> [root at prod ~]# tcpdump -nn -i any host 10.4.1.101
>>> 16:49:28.573395 IP 10.4.1.101.58883 > 10.4.1.6.561: UDP, length 112
>>> 16:49:28.573401 IP 10.4.1.6 > 10.4.1.101: ICMP 10.4.1.6 udp port 561 unreachable, length 148
>>> ...
>>> 
>>> ra on prod quits instantly (tried multiple variations of this):
>>> [root at prod ~]# ra -S argus-udp://10.4.1.6:561
>>> [root at prod ~]# ra -S argus-udp://10.4.1.6:561 -D 1
>>> ra[26899.0047ad5fcc7f0000]: 16:49:19.701982 main: reading files completed
>>> ra[26899.0047ad5fcc7f0000]: 16:49:19.702147 Binding 10.4.1.6:561 Expecting Argus records
>>> ra[26899.0047ad5fcc7f0000]: 16:49:19.702200 receiving
>>> ra[26899.0047ad5fcc7f0000]: 16:49:19.702210 ArgusGetServerSocket (0x7fcc5f92d010) returning 3
>>> ra[26899.0047ad5fcc7f0000]: 16:49:19.985069 ArgusShutDown (0)
>>> ra[26899.0047ad5fcc7f0000]: 16:49:19.985141 ArgusShutDown (0)
>>> [root at prod ~]#
>>> 
>>> I'm a bit lost here.
>>> 
>>> -- 
>>> Ignas
>>> 
>>> 
>>> On 2013.03.01 15:15, Carter Bullard wrote:
>>>> Hey Ignas,
>>>> All clients can read the udp data.  This should work on your example
>>>>   ra -S argus-udp://1.1.1.1:561
>>>> 
>>>> So if B and C are configured to transmit to the same host and port, the ra() should see all the data.  Make sure that B and C have unique argus source IDs in their argus.conf file.
>>>> 
>>>> We normally recommend a pull model, where your collector 'A' would connect to B and C to collect the data, using TCP.  Lots of reasons for this strategy, but the UDP support is there to be used, so go for it !!
>>>> 
>>>> If you have any problems, do send email !!!!!
>>>> 
>>>> Carter
>>>> 
>>>> On Mar 1, 2013, at 7:59 AM, Ignas <ignas.linux at gmail.com> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> I see that argus is able to push it's data with ARGUS_OUTPUT_STREAM=argus-udp://1.1.1.1:561
>>>>> 
>>>>> I can't find what argus/client tool accepts this data. Or maybe this ARGUS_OUTPUT_STREAM is used only with custom applications? I'm new to this.
>>>>> 
>>>>> Background:
>>>>> I have a simple need to account udp/514 traffic on hosts B and C. It would be great if there is a possibility to push this accounting data to host A, where this data would be stored and analysed, without keeping it on B and C.
>>>>> 
>>>>> Thank you,
>>>>> --
>>>>> Ignas
> 
> 
> 