accepting data that is pushed with ARGUS_OUTPUT_STREAM

Fri Mar 1 16:42:04 EST 2013

Hey Ignas,
I have found a bug in the UDP support, so I'll work on it this weekend.
Several efforts now in the queue, and I'm slow, almost glacially slow,
this week, but I should have something that works by the end of the weekend.

Carter

On Mar 1, 2013, at 2:12 PM, Carter Bullard <carter at qosient.com> wrote:

> 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
>> 
>> 
>> 
> 

-------------- 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/20130301/6e85f962/attachment.bin>