Question about Filtering Argus Data

Chungen Li jiafei427 at gmail.com
Tue Jun 17 01:03:53 EDT 2014


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 <khaqanshati 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 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 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 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/20140617/4e888cc2/attachment.html>


More information about the argus mailing list