accepting data that is pushed with ARGUS_OUTPUT_STREAM

Fri Mar 1 17:01:11 EST 2013

Thanks. And no hurry, it is a weekend after all.

-- 
Ignas

On 2013-03-01 23:42, Carter Bullard wrote:
> 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
>>>
>>>
>>>
>>
> 