Question about Filtering Argus Data
Chungen Li
jiafei427 at gmail.com
Tue Jun 17 21:19:56 EDT 2014
Dear Carter,
I just tested your newest version argus-3.0.8.rc.3 and the problem is gone
now :)
Everything works fine for me.
Thank you so much for your help :D
Best Regards!
On Tue, Jun 17, 2014 at 11:57 PM, Carter Bullard <carter at qosient.com> wrote:
> Hey Chungen,
> I did find the bug, took me a while to find a machine that
> replicated it.
>
> Putting radium in front of argus, to avoid an argus compiler bug,
> is a good hack, but not the best way to go, so ...
> If you could do me a favor and test out this latest version
> of argus-3.0.8.rc.3 that I just uploaded, I would appreciate it.
>
> http://qosient.com/argus/dev/argus-latest.tar.gz
>
> And thanks for helping to fix this important bug.
>
> Carter
>
>
> On Jun 17, 2014, at 9:03 AM, Chungen Li <jiafei427 at gmail.com> wrote:
>
> Yes sir :(
>
> On Tuesday, June 17, 2014, Carter Bullard <carter at qosient.com> wrote:
>
>> did you try argus-3.0.8.rc.2 ???
>> Carter
>>
>> On Jun 17, 2014, at 1:51 AM, Chungen Li <jiafei427 at gmail.com> wrote:
>>
>> Dear Carter,
>>
>> Finally it worked out.
>>
>> When I added "Radium" to collect the data from Argus-Server and connect
>> to radium using 'ra' it gave me rational result.
>>
>> Thank you so much for your help.
>>
>> But, I'm just wondering.
>>
>> Why it is not working when argus-client connects to the argus-Server
>> directly.
>>
>> Just asking.
>>
>> Again, Thank you so much for your help.
>>
>> ^____________________________________________^
>>
>>
>> Best Regards!
>>
>>
>> On Tue, Jun 17, 2014 at 2:29 PM, Carter Bullard <carter at qosient.com>
>> wrote:
>>
>>> Hey Chungen Li,
>>> I may have found something that could affect the problem you found.
>>> You will need to use argus-3.0.8.rc.2, which is now on the servers as
>>>
>>> http://qosient.com/argus/dev/argus-latest.tar.gz
>>>
>>> There are new clients that also have the fixes in, and you should use
>>> them as well.
>>>
>>> http://qosient.com/argus/dev/argus-clients-latest.tar.gz
>>>
>>> If this doesn’t work, then I will recommend that you run radium on your
>>> argus
>>> host, collecting all records from argus, and have all your clients
>>> access the
>>> data through radium, assuming that it implements the filters correctly
>>> on
>>> your systems. Until I can figure out what’s up.
>>>
>>> Carter
>>>
>>>
>>> On Jun 17, 2014, at 1:03 AM, Chungen Li <jiafei427 at gmail.com> wrote:
>>>
>>> Dear Carter,
>>>
>>> I just tried as you asked.
>>>
>>> And the results look reasonable, means it works when it read from the
>>> file.
>>>
>>> why is this happening?
>>>
>>>
>>> Best Regards.
>>>
>>>
>>> On Tue, Jun 17, 2014 at 11:44 AM, Carter Bullard <carter at qosient.com>
>>> wrote:
>>>
>>>> Also, do you get this same behavior when reading records from a file ??
>>>>
>>>> ra -S 127.0.0.1:3434 -w /tmp/test.out -N 100
>>>>
>>>> then compare
>>>>
>>>> ra -r /tmp/test.out - bytes lt 100
>>>> ra -r /tmp/test.out - bytes gt 100
>>>>
>>>> Does this look rational ??
>>>>
>>>> Carter
>>>>
>>>> On Jun 16, 2014, at 10:36 PM, Chungen Li <jiafei427 at gmail.com> wrote:
>>>>
>>>> FYI, These are the filtering pseudo code in my argus.
>>>>
>>>> $ ./ra -s +sbytes +dbytes -S 127.0.0.1:3434 -b - bytes lt 100
>>>> (000) ldll dsr[3][12]
>>>> (001) jge #0x64 jt 2 jf 5
>>>> (002) ldll dsr[3][36]
>>>> (003) jge #0x64 jt 4 jf 5
>>>> (004) ret #0
>>>> (005) ret #150
>>>> $ ./ra -s +sbytes +dbytes -S 127.0.0.1:3434 -b - bytes gt 100
>>>> (000) ldll dsr[3][12]
>>>> (001) jgt #0x64 jt 4 jf 2
>>>> (002) ldll dsr[3][36]
>>>> (003) jgt #0x64 jt 4 jf 5
>>>> (004) ret #150
>>>> (005) ret #0
>>>> $ ./ra -s +sbytes +dbytes -S 127.0.0.1:3434 -b - src bytes gt 100
>>>> (000) ldll dsr[3][12]
>>>> (001) jgt #0x64 jt 2 jf 3
>>>> (002) ret #150
>>>> (003) ret #0
>>>>
>>>>
>>>> On Tue, Jun 17, 2014 at 11:29 AM, Chungen Li <jiafei427 at gmail.com>
>>>> wrote:
>>>>
>>>>> Currently, I'm using only one machine for both argus-server and
>>>>> argus-client.
>>>>>
>>>>> Following is my OS and gcc Info:
>>>>>
>>>>> Linux version 2.6.32-279.el6.x86_64 (
>>>>> mockbuild at c6b9.bsys.dev.centos.org)
>>>>>
>>>>> (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) )
>>>>>
>>>>> my argus Info:
>>>>>
>>>>> Argus-Server: argus-3.0.8.rc.1
>>>>>
>>>>> Argus-Client: argus-clients-3.0.7.34
>>>>>
>>>>>
>>>>> I start Argus-Server side using this command
>>>>>
>>>>> "sudo ./argus -P 3434 -m"
>>>>>
>>>>> Then I run the Argus-Client using this command to find data packet
>>>>> that has bytes greater than 100 in both source and destination sides.
>>>>>
>>>>> "./ra -s +sbytes +dbytes -S 127.0.0.1:3434 - bytes gt 100"
>>>>>
>>>>> and it comes with nothing.
>>>>>
>>>>> But, when I add "local" option in it, it works fine.
>>>>>
>>>>> like "./ra -s +sbytes +dbytes - S 127.0.0.1:3434 - local bytes gt
>>>>> 100", I'm wondering what does that "local" option turns on in the
>>>>> filtering option?
>>>>>
>>>>>
>>>>> besides, even if I didn't add that "local" option, the "bytes lt 100"
>>>>> works fine, that's really weird...
>>>>>
>>>>> So when I run the command "./ra -s +sbytes +dbytes -S 127.0.0.1:3434
>>>>> - bytes lt 100" it gives the result with bytes smaller than 100.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 17, 2014 at 10:49 AM, Carter Bullard <carter at qosient.com>
>>>>> wrote:
>>>>>
>>>>>> It seems that you have a problem in your collection strategy, as this
>>>>>> type of filter problem just
>>>>>> doesn’t seem to exist in any version that I’ve tested.
>>>>>>
>>>>>> Can you describe your setup. Argus version, are you using radium,
>>>>>> its version,
>>>>>> and what clients are you using where the filter isn’t working, and
>>>>>> its versions.
>>>>>>
>>>>>> Also, I need to know what hardware platforms you are using, compilers
>>>>>> and
>>>>>> whether the machines are 16, 32 or 64 bit machines.
>>>>>>
>>>>>> Carter
>>>>>>
>>>>>>
>>>>>> On Jun 16, 2014, at 9:42 PM, Chungen Li <jiafei427 at gmail.com> wrote:
>>>>>>
>>>>>> Hey, Carter.
>>>>>>
>>>>>> I tried the version 3.0.8.rc.1, But not helpful.
>>>>>>
>>>>>> So I want to know that is it matter if I use one machine for both
>>>>>> Argus-DataServer and Argus-Client?
>>>>>>
>>>>>> May it cause that kind of problems?
>>>>>>
>>>>>> and what does that mean the "local" option in the filtering part?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards!
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 17, 2014 at 10:30 AM, Carter Bullard <carter at qosient.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Oooops a type. The link is:
>>>>>>>
>>>>>>> http://qosient.com/argus/dev/argus-latest.tar.gz
>>>>>>>
>>>>>>> Sorry about that,
>>>>>>> Carter
>>>>>>>
>>>>>>> On Jun 16, 2014, at 9:01 PM, Chungen Li <jiafei427 at gmail.com> wrote:
>>>>>>>
>>>>>>> Hey, Carter,
>>>>>>>
>>>>>>> The Link shows not available.
>>>>>>>
>>>>>>> Do you have other links?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards.
>>>>>>>
>>>>>>> <image.png>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 16, 2014 at 7:24 PM, Carter Bullard <carter at qosient.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hey Chungen Li,
>>>>>>>> Try argus-3.0.8.rc.1 from here:
>>>>>>>> http://qosient.com/argus/dev/argus-latest-tar.gz
>>>>>>>>
>>>>>>>> Carter
>>>>>>>>
>>>>>>>> On Jun 15, 2014, at 10:07 PM, Chungen Li <jiafei427 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi, Carter,
>>>>>>>>
>>>>>>>> Finally, my problem got a hit for your hint.
>>>>>>>>
>>>>>>>> the "ra -S remoteDataSource - local src bytes gt 100" prints out
>>>>>>>> the right data flow now!
>>>>>>>>
>>>>>>>> you said that I'll need to upgrade my argus data source, but my
>>>>>>>> argus server side is 3.0.6.1 which shows it's latest version from argus
>>>>>>>> official site.
>>>>>>>>
>>>>>>>> How do I "UPGRADE" my argus data source?
>>>>>>>>
>>>>>>>>
>>>>>>>> FYI,
>>>>>>>>
>>>>>>>> My machine type is 64-bit Cent OS.
>>>>>>>>
>>>>>>>> and "ra -b - src bytes gt 100" shows the result:
>>>>>>>>
>>>>>>>> (000) ldll dsr[3][12]
>>>>>>>> (001) jgt #0xa jt 2 jf 3
>>>>>>>> (002) ret #150
>>>>>>>> (003) ret #0
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you so much!
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jun 13, 2014 at 11:18 PM, Carter Bullard <
>>>>>>>> carter at qosient.com> wrote:
>>>>>>>>
>>>>>>>>> Hey Chungen Li,
>>>>>>>>> Yes, that is what I meant. The direction support in the
>>>>>>>>> clients can change the assignment of source and destination.
>>>>>>>>> If you send a filter to the data source that says “ src metric “
>>>>>>>>> and you change the assignment of src and dst, and then
>>>>>>>>> apply the same filter, you may end up rejecting all the flows.
>>>>>>>>>
>>>>>>>>> I tested this problem quite a bit late last night, and I am
>>>>>>>>> not seeing any issues with filtering on bytes, either from
>>>>>>>>> a file or from realtime streaming on my systems here.
>>>>>>>>>
>>>>>>>>> Did you test your filter works when reading argus data files ??
>>>>>>>>>
>>>>>>>>> If you could use the -b option in your client, that will
>>>>>>>>> print out the compiler pseudo code that the client uses
>>>>>>>>> to filter. My clients generate these filters:
>>>>>>>>>
>>>>>>>>> thoth:~ carter$ ra -b - src bytes gt 100
>>>>>>>>> (000) ldll dsr[3][12]
>>>>>>>>> (001) jgt #0x64 jt 2 jf 3
>>>>>>>>> (002) ret #150
>>>>>>>>> (003) ret #0
>>>>>>>>>
>>>>>>>>> thoth:~ carter$ ra -b - not src bytes lt 100
>>>>>>>>> (000) ldll dsr[3][12]
>>>>>>>>> (001) jge #0x64 jt 2 jf 3
>>>>>>>>> (002) ret #150
>>>>>>>>> (003) ret #0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What type of machine is the source and client ??? 32-bit, 64-bit,
>>>>>>>>> 8-bit Atari ?? ;O)
>>>>>>>>>
>>>>>>>>> There are some issues with filter compatibility with legacy
>>>>>>>>> argus data sources, like argus and radium, because the syntax
>>>>>>>>> and semantics have evolved over the years.
>>>>>>>>>
>>>>>>>>> If you suspect that your argus data source is the problem,
>>>>>>>>> use “local” in front of your filter. That will cause the
>>>>>>>>> client to NOT send the filter to the source, but do all
>>>>>>>>> the filtering in the client.
>>>>>>>>>
>>>>>>>>> ra -S remoteDataSource - local src bytes gt 100
>>>>>>>>>
>>>>>>>>> If this behaves differently, then you will need to upgrade your
>>>>>>>>> argus data source.
>>>>>>>>>
>>>>>>>>> Hope this is helpful,
>>>>>>>>>
>>>>>>>>> Carter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jun 13, 2014, at 2:13 AM, Chungen Li <jiafei427 at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> > Since I don't know what you exactly meant by "the direction
>>>>>>>>> commands in your .rarc file"
>>>>>>>>> >
>>>>>>>>> > I commented out the all things with direction in rarc, and it
>>>>>>>>> turns out with nothing.
>>>>>>>>> >
>>>>>>>>> > Following is the part from rarc file that I changed.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> ------------------------------------------------------------------------------------------------------------------
>>>>>>>>> > # Many ra* clients process flow records based on source and
>>>>>>>>> destination
>>>>>>>>> > # properties. TCP and UDP ports values can be used to assign
>>>>>>>>> direction,
>>>>>>>>> > # and are best used for well-known ports (< 1024), values that
>>>>>>>>> > # are in the /etc/services defintions, and the reserved ports (>
>>>>>>>>> 1023, < 49151).
>>>>>>>>> > #
>>>>>>>>> > # The syntax is:
>>>>>>>>> > # RA_PORT_DIRECTION="services"
>>>>>>>>> > # RA_PORT_DIRECTION="services,wellknown"
>>>>>>>>> > # RA_PORT_DIRECTION="services,wellknown,registered"
>>>>>>>>> > #
>>>>>>>>> > # We recommend the wellknown and services options, as they are a
>>>>>>>>> bit more
>>>>>>>>> > # discriminating. If there are ports that you know are services
>>>>>>>>> that are in
>>>>>>>>> > # the registered port range, we suggest that you add them to
>>>>>>>>> your /etc/services
>>>>>>>>> > # file rather than include the registered port range; only
>>>>>>>>> because the
>>>>>>>>> > # registered range is so large. However, this option is applied
>>>>>>>>> only to
>>>>>>>>> > # flow in which the direction is ambiguous, and as such,
>>>>>>>>> corrections based
>>>>>>>>> > # on the logic should have minimum effect on analytics.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > #EDIT HERE
>>>>>>>>> > #RA_PORT_DIRECTION="services,wellknown"
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > # Sites use locality for a number of features, such as access
>>>>>>>>> control,
>>>>>>>>> > # and this support is intended to support visualization, and
>>>>>>>>> analytics.
>>>>>>>>> > #
>>>>>>>>> > # Currently, you can identify a collection of IP addresses that
>>>>>>>>> represent RA_LOCAL,
>>>>>>>>> > # and are specified using an iana-address-file formatted file.
>>>>>>>>> (See ralabel.conf)
>>>>>>>>> >
>>>>>>>>> > #RA_LOCAL=/usr/local/argus/local.addrs
>>>>>>>>> >
>>>>>>>>> > # When locality information is available, programs like ra(), and
>>>>>>>>> > # as the assignement of source when there is ambiguity in the
>>>>>>>>> > # flow record as to who is the actual initiator or receiver of
>>>>>>>>> the flow.
>>>>>>>>> > #
>>>>>>>>> > # When locality information is available, programs like ra(), and
>>>>>>>>> > # ratop() can use that information to make display decisions,
>>>>>>>>> such
>>>>>>>>> > #
>>>>>>>>> > # RA_LOCAL_DIRECTION provides the logic for using the locality
>>>>>>>>> > # information to assign flow direction. You can force the local
>>>>>>>>> > # address to be either the source (src) or the destination (dst).
>>>>>>>>> > #
>>>>>>>>> > # The syntax is:
>>>>>>>>> > # RA_LOCAL_DIRECTION="local:src"
>>>>>>>>> > # RA_LOCAL_DIRECTION="local:dst"
>>>>>>>>> > #
>>>>>>>>> >
>>>>>>>>> > #RA_LOCAL_DIRECTION="suggest:src"
>>>>>>>>> > #EDIT HERE
>>>>>>>>> > #RA_LOCAL_DIRECTION="force:src"
>>>>>>>>> >
>>>>>>>>> ------------------------------------------------------------------------------------------------------------------
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Fri, Jun 13, 2014 at 2:06 PM, Carter Bullard <
>>>>>>>>> carter at qosient.com> wrote:
>>>>>>>>> > Are you using any of the direction commands in your .rarc file
>>>>>>>>> ???
>>>>>>>>> > If you are, turn them off, to see if things get better.
>>>>>>>>> >
>>>>>>>>> > Because you only have unidirectional data, there maybe issues
>>>>>>>>> with
>>>>>>>>> > src and dst operations ???
>>>>>>>>> >
>>>>>>>>> > Carter
>>>>>>>>> >
>>>>>>>>> > On Jun 13, 2014, at 12:29 AM, Chungen Li <jiafei427 at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> >> Hi, Dear Carter,
>>>>>>>>> >>
>>>>>>>>> >> I just downloaded the latest version from your link which is
>>>>>>>>> argus-client-3.0.7.34 and I think the problems are not solved.
>>>>>>>>> >>
>>>>>>>>> >> First, I just added sbytes and dbytes to check whether there
>>>>>>>>> are argus-data that fits the condition "bytes gt 100"
>>>>>>>>> >>
>>>>>>>>> >> Following are the result from ra:
>>>>>>>>> >>
>>>>>>>>> >> $ ra -s +sbytes +dbytes -S 127.0.0.1:3434
>>>>>>>>> >> StartTime Flgs Proto SrcAddr Sport
>>>>>>>>> Dir DstAddr Dport TotPkts TotBytes State SrcBytes
>>>>>>>>> DstBytes
>>>>>>>>> >> 13:10:01.726715 * udp 147.46.66.83.26283
>>>>>>>>> -> 203.218.216.240.27754 2 152 INT 152
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.726943 * tcp 164.125.53.178.sais
>>>>>>>>> -> 74.125.128.94.http 4 1275 CON 1275
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.726981 * tcp 203.250.10.234.54653
>>>>>>>>> -> 173.194.127.230.http 1 58 CON 58
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.727066 * udp 143.248.30.28.20576
>>>>>>>>> -> 223.205.207.168.16471 1 66 REQ 66
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.727144 * udp 203.253.206.11.6881
>>>>>>>>> -> 183.179.233.176.9043 1 368 REQ 368
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.727443 * udp 210.119.13.116.52472
>>>>>>>>> -> 171.6.102.51.24302 2 132 REQ 132
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.727603 * tcp 164.125.53.178.infor*
>>>>>>>>> -> 74.125.128.94.http 5 1158 CON 1158
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.727619 * tcp 147.47.241.31.63705
>>>>>>>>> ?> 173.194.117.217.http 1 58 CON 58
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.727730 * tcp 147.46.17.88.iee-q*
>>>>>>>>> -> 173.194.72.125.xmpp-* 1 59 CON 59
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.727882 * tcp 147.46.6.168.58296
>>>>>>>>> -> 173.194.117.193.https 2 140 RST 140
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.727984 * tcp 164.125.53.178.mloadd
>>>>>>>>> -> 74.125.128.94.http 5 1613 CON 1613
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.728311 * tcp 164.125.129.188.57351
>>>>>>>>> -> 74.125.128.136.https 13 1910 CON 1910
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.728810 * tcp 143.248.60.99.49702
>>>>>>>>> -> 74.125.128.157.http 2 128 CON 128
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.728838 * udp 203.250.1.11.51731
>>>>>>>>> -> 192.221.77.23.domain 1 105 INT 105
>>>>>>>>> 0
>>>>>>>>> >> 13:10:01.728919 * tcp 163.152.3.57.27812
>>>>>>>>> -> 173.194.117.250.http 13 2110 FIN 2110
>>>>>>>>> 0
>>>>>>>>> >>
>>>>>>>>> >> As you can see there are many of them that SrcBytes greater
>>>>>>>>> than 100.
>>>>>>>>> >>
>>>>>>>>> >> So I ran the following command,
>>>>>>>>> >>
>>>>>>>>> >> $ ra -s +sbytes +dbytes -S 127.0.0.1:3434 - src bytes gt 100
>>>>>>>>> >>
>>>>>>>>> >> And it just stuck there without any result.
>>>>>>>>> >>
>>>>>>>>> >> So I checked the argus server side to see the log, and it came
>>>>>>>>> up with nothing.
>>>>>>>>> >>
>>>>>>>>> >> But, here's the weirdest thing.
>>>>>>>>> >>
>>>>>>>>> >> When I use the option "bytes lt 100" it just works like a charm.
>>>>>>>>> >>
>>>>>>>>> >> Here are some result from the command:
>>>>>>>>> >>
>>>>>>>>> >> $ ra -s +sbytes +dbytes -S 127.0.0.1:3434 - src bytes lt 100
>>>>>>>>> >> StartTime Flgs Proto SrcAddr Sport
>>>>>>>>> Dir DstAddr Dport TotPkts TotBytes State SrcBytes
>>>>>>>>> DstBytes
>>>>>>>>> >> 13:26:43.539575 * tcp 210.107.236.96.6901
>>>>>>>>> -> 173.194.127.129.https 1 59 CON 59
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.539988 * tcp 164.125.150.36.50026
>>>>>>>>> -> 74.125.128.19.https 1 58 CON 58
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.540055 * tcp 147.46.238.80.63363
>>>>>>>>> -> 74.125.128.17.https 1 58 CON 58
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.540231 * tcp 164.125.141.132.icpv2
>>>>>>>>> -> 74.125.128.113.https 1 59 CON 59
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.541930 * tcp 143.248.53.100.53629
>>>>>>>>> -> 74.125.128.148.http 1 59 CON 59
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.542199 * tcp 143.248.15.107.60584
>>>>>>>>> -> 74.125.31.104.https 1 59 CON 59
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.543277 * tcp 210.218.201.19.58711
>>>>>>>>> -> 173.194.127.188.http 1 59 CON 59
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.543386 * tcp 147.46.131.85.56737
>>>>>>>>> -> 173.194.117.199.http 1 59 CON 59
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.543612 * tcp 210.125.122.102.51756
>>>>>>>>> ?> 173.194.126.168.https 1 58 FIN 58
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.543727 * tcp 210.125.122.102.51755
>>>>>>>>> ?> 173.194.126.168.https 1 58 FIN 58
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.544334 * tcp 147.46.60.47.icp
>>>>>>>>> -> 74.125.203.94.https 1 59 CON 59
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.544637 * udp 147.46.61.186.62348
>>>>>>>>> -> 42.3.104.118.ansof* 1 66 REQ 66
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.544638 * tcp 168.188.15.212.53359
>>>>>>>>> ?> 74.125.235.150.https 1 58 RST 58
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.544851 * icmp 150.183.95.135.0x0008
>>>>>>>>> -> 130.126.57.173.0x0db0 1 62 ECO 62
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.545332 * tcp 143.248.150.125.50392
>>>>>>>>> -> 74.125.31.125.xmpp-* 1 58 CON 58
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.545535 * udp 155.230.24.235.menta*
>>>>>>>>> -> 74.125.23.127.19302 1 66 REQ 66
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.545731 * tcp 14.44.126.17.60481
>>>>>>>>> ?> 74.125.31.95.https 1 58 CON 58
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.547221 * tcp 203.237.41.198.56537
>>>>>>>>> -> 74.125.128.113.https 1 59 CON 59
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.547258 * udp 134.75.151.8.domain
>>>>>>>>> -> 74.125.186.215.33670 1 95 INT 95
>>>>>>>>> 0
>>>>>>>>> >> 13:26:43.547381 * tcp 209.85.215.36.61758
>>>>>>>>> -> 155.230.11.8.pop3 218 276543 FIN 0
>>>>>>>>> 276543
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> What can I do for the next?
>>>>>>>>> >>
>>>>>>>>> >> Thanks for your help.
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> On Fri, Jun 13, 2014 at 12:09 PM, Carter Bullard <
>>>>>>>>> carter at qosient.com> wrote:
>>>>>>>>> >> Hey Chungen Li,
>>>>>>>>> >> The filter “ bytes gt 10 “ , like all metrics, is decomposed to
>>>>>>>>> “ src bytes gt 10 or dst bytes gt 10”.
>>>>>>>>> >> You should print the sbytes and dbytes fields to see that their
>>>>>>>>> values are either in or out of
>>>>>>>>> >> the filter range.
>>>>>>>>> >>
>>>>>>>>> >> If your filter is not working, what version of argus-clients
>>>>>>>>> are you running ???
>>>>>>>>> >> The best version to use, currently, is argus-clients-3.0.7.34,
>>>>>>>>> which is about
>>>>>>>>> >> to be released as argus-clients-3.0.8. You can get the latest
>>>>>>>>> version here.
>>>>>>>>> >>
>>>>>>>>> >> http://qosient.com/argus/dev/argus-clients-latest.tar.gz
>>>>>>>>> >>
>>>>>>>>> >> When you connect to a remote argus data source, your client
>>>>>>>>> sends its filter to the remote
>>>>>>>>> >> data server where the filtering takes place. As a result,
>>>>>>>>> filter failure may be at the argus data
>>>>>>>>> >> source. argus and argus-clients are designed to detect when
>>>>>>>>> there are filter problems
>>>>>>>>> >> locally or remotely, but it is still a good exercise to check
>>>>>>>>> the logs of the remote
>>>>>>>>> >> argus data source, to see if it reports filter issues.
>>>>>>>>> >>
>>>>>>>>> >> Be sure and upgrade to the latest code, and if you are still
>>>>>>>>> having problems,
>>>>>>>>> >> send more email.
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> Carter
>>>>>>>>> >>
>>>>>>>>> >> On Jun 12, 2014, at 10:11 PM, Chungen Li <jiafei427 at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >>
>>>>>>>>> >>> Hello,
>>>>>>>>> >>>
>>>>>>>>> >>> Now I'm developing a system using the ARGUS Framework and I
>>>>>>>>> got trouble when I try to use the filtering option in the RA (Argus Client).
>>>>>>>>> >>>
>>>>>>>>> >>> Following are some results from RA.
>>>>>>>>> >>>
>>>>>>>>> >>> $ ../../argus/argus-clients-3.0.6.2/bin/ra -S 127.0.0.1:3434
>>>>>>>>> >>> StartTime Flgs Proto SrcAddr Sport
>>>>>>>>> Dir DstAddr Dport TotPkts TotBytes State
>>>>>>>>> >>> 11:01:56.368794 * tcp 147.46.112.192.ici
>>>>>>>>> -> 173.194.72.84.https 1 59 CON
>>>>>>>>> >>> 11:01:56.369780 * s tcp 147.46.208.185.57788
>>>>>>>>> -> 61.239.168.101.16057 6 440 FIN
>>>>>>>>> >>> 11:01:56.370350 * tcp 210.98.16.36.15890
>>>>>>>>> -> 173.194.127.133.https 1 59 CON
>>>>>>>>> >>> 11:01:56.370355 * tcp 163.152.69.238.hpvro*
>>>>>>>>> -> 203.84.208.52.https 1 59 CON
>>>>>>>>> >>> 11:01:56.370415 * tcp 223.195.2.196.59281
>>>>>>>>> -> 173.194.127.73.http 6 593 CON
>>>>>>>>> >>> 11:01:56.370575 * tcp 210.98.50.5.46496
>>>>>>>>> -> 173.194.127.85.https 5 2511 CON
>>>>>>>>> >>> 11:01:56.370666 * tcp 163.152.34.179.54862
>>>>>>>>> -> 74.125.128.139.https 1 59 CON
>>>>>>>>> >>> 11:01:56.370982 * tcp 147.46.188.242.49245
>>>>>>>>> -> 74.125.204.188.hpvro* 1 59 CON
>>>>>>>>> >>> 11:01:56.371008 * udp 147.46.81.23.33782
>>>>>>>>> -> 219.79.58.17.osmos* 3 267 REQ
>>>>>>>>> >>> 11:01:56.371503 * tcp 117.16.196.145.40337
>>>>>>>>> -> 173.194.38.70.http 3 1619 CON
>>>>>>>>> >>> 11:01:56.372168 * tcp 147.46.39.53.qsm-p*
>>>>>>>>> -> 199.59.148.139.https 4 232 CON
>>>>>>>>> >>> 11:01:56.372620 * udp 203.241.84.210.48613
>>>>>>>>> -> 216.239.32.10.domain 1 93 INT
>>>>>>>>> >>> 11:01:56.373037 * tcp 163.152.105.227.43465
>>>>>>>>> -> 74.125.203.95.http 1 70 CON
>>>>>>>>> >>> 11:01:56.373097 * tcp 164.125.174.109.5194
>>>>>>>>> -> 74.125.128.101.https 9 1312 CON
>>>>>>>>> >>> 11:01:56.374016 * tcp 203.247.182.211.35832
>>>>>>>>> -> 173.194.38.71.https 1 59 CON
>>>>>>>>> >>>
>>>>>>>>> >>> Here I just want the Argus record with the packet-bytes
>>>>>>>>> greater than 100, So I set the filtering option at the end of the command
>>>>>>>>> like this
>>>>>>>>> >>>
>>>>>>>>> >>> $ ../../argus/argus-clients-3.0.6.2/bin/ra -S 127.0.0.1:3434
>>>>>>>>> - bytes gt 10
>>>>>>>>> >>>
>>>>>>>>> >>> But this never returns me any results, and I don't know why.
>>>>>>>>> >>>
>>>>>>>>> >>> Plz tell me where did I get wrong with that filtering option.
>>>>>>>>> >>>
>>>>>>>>> >>> Thanks.
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> Chungen, Li
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> --
>>>>>>>>> >> Best Regards
>>>>>>>>> >> Li ChunGen , 李 春根, 리 춘근
>>>>>>>>> >> Department of Computer Science, POSTECH
>>>>>>>>> >> PIRL 323
>>>>>>>>> Mobile : +82-10-7522-5977
>>>>>>>>> >> San 31, Hyoja-dong, Nam-gu Email
>>>>>>>>> : jiafei427 at postech.ac.kr
>>>>>>>>> >> Pohang 790-784, Republic of Korea
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > --
>>>>>>>>> > Best Regards
>>>>>>>>> > Li ChunGen , 李 春根, 리 춘근
>>>>>>>>> > Department of Computer Science, POSTECH
>>>>>>>>> > PIRL 323
>>>>>>>>> Mobile : +82-10-7522-5977
>>>>>>>>> > San 31, Hyoja-dong, Nam-gu Email :
>>>>>>>>> jiafei427 at postech.ac.kr
>>>>>>>>> > Pohang 790-784, Republic of Korea
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Best Regards Li ChunGen , 李 春根, 리 춘근 Department of Computer
>>>>>>>> Science, POSTECH PIRL 323
>>>>>>>> Mobile : +82-10-7522-5977 <%2B82-10-7522-5977> San 31,
>>>>>>>> Hyoja-dong, Nam-gu
>>>>>>>> Email : jiafei427 at postech.ac.kr Pohang 790-784, Republic of Korea*
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Best Regards Li ChunGen , 李 春根, 리 춘근 Department of Computer
>>>>>>> Science, POSTECH PIRL 323
>>>>>>> Mobile : +82-10-7522-5977 <%2B82-10-7522-5977> San 31,
>>>>>>> Hyoja-dong, Nam-gu
>>>>>>> Email : jiafei427 at postech.ac.kr Pohang 790-784, Republic of Korea*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> * Best Regards Li ChunGen , 李 春根, 리 춘근 Department of Computer
>>>>>> Science, POSTECH PIRL 323
>>>>>> Mobile : +82-10-7522-5977 <%2B82-10-7522-5977> San 31,
>>>>>> Hyoja-dong, Nam-gu
>>>>>> Email : jiafei427 at postech.ac.kr Pohang 790-784, Republic of Korea*
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> * Best Regards Li ChunGen , 李 春根, 리 춘근 Department of Computer
>>>>> Science, POSTECH PIRL 323
>>>>> Mobile : +82-10-7522-5977 <%2B82-10-7522-5977> San 31,
>>>>> Hyoja-dong, Nam-gu
>>>>> Email : jiafei427 at postech.ac.kr Pohang 790-784, Republic of Korea*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Best Regards Li ChunGen , 李 春根, 리 춘근 Department of Computer Science,
>>>> POSTECH PIRL 323
>>>> Mobile : +82-10-7522-5977 <%2B82-10-7522-5977> San 31,
>>>> Hyoja-dong, Nam-gu
>>>> Email : jiafei427 at postech.ac.kr Pohang 790-784, Republic of Korea*
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> * Best Regards Li ChunGen , 李 春根, 리 춘근 Department of Computer Science,
>>> POSTECH PIRL 323
>>> Mobile : +82-10-7522-5977 <%2B82-10-7522-5977> San 31,
>>> Hyoja-dong, Nam-gu
>>> Email : jiafei427 at postech.ac.kr Pohang 790-784, Republic of Korea*
>>>
>>>
>>>
>>
>>
>> --
>>
>> * Best Regards Li ChunGen , 李 春根, 리 춘근 Department of Computer Science,
>> POSTECH PIRL 323
>> Mobile : +82-10-7522-5977 <%2B82-10-7522-5977> San 31,
>> Hyoja-dong, Nam-gu
>> Email : jiafei427 at postech.ac.kr Pohang 790-784, Republic of Korea*
>>
>>
>
> --
>
> *Best Regards Li ChunGen , 李 春根, 리 춘근 Department of Computer Science,
> POSTECH PIRL 323
> Mobile : +82-10-7522-5977 <%2B82-10-7522-5977> San 31,
> Hyoja-dong, Nam-gu
> Email : jiafei427 at postech.ac.kr <khaqanshati at postech.ac.kr> Pohang
> 790-784, Republic of Korea*
>
>
>
--
*Best RegardsLi ChunGen, 李 春根, 리 춘근Department of Computer Science, POSTECH
PIRL 323
Mobile : +82-10-7522-5977 San 31, Hyoja-dong, Nam-gu
Email : jiafei427 at postech.ac.kr
<khaqanshati at postech.ac.kr>Pohang 790-784, Republic of Korea*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20140618/9f79a68b/attachment.html>
More information about the argus
mailing list