Argus-info Digest, Vol 86, Issue 35
CS Lee
geek00l at gmail.com
Thu Oct 18 20:02:29 EDT 2012
hi Paul,
The record blob is actually argus binary data which means whatever field
you define in -s, it will be stored along with the mysql data.
Then you can retrieve the argus binary data using rasql command
There are things you need to consider checking carefully, which is the
bandwidth utilization you are monitoring. If you are monitoring high speed
link I suggest you don't use -M cache because it's very expensive to do
flow clustering in real time and you may see your cpu goes up to 100%
easily.
On Fri, Oct 19, 2012 at 5:19 AM, <argus-info-request at lists.andrew.cmu.edu>wrote:
> Send Argus-info mailing list submissions to
> argus-info at lists.andrew.cmu.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
> or, via email, send a message with subject or body 'help' to
> argus-info-request at lists.andrew.cmu.edu
>
> You can reach the person managing the list at
> argus-info-owner at lists.andrew.cmu.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Argus-info digest..."
>
>
> Today's Topics:
>
> 1. Re: Argus-info Digest, Vol 86, Issue 30 (Jesse Bowling)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 18 Oct 2012 17:19:45 -0400
> From: Jesse Bowling <jessebowling at gmail.com>
> Subject: Re: [ARGUS] Argus-info Digest, Vol 86, Issue 30
> To: Paul Schmehl <pschmehl_lists at tx.rr.com>
> Cc: argus-info <argus-info at lists.andrew.cmu.edu>
> Message-ID:
> <
> CAGFhEnmaedcFRVvB4Ex1r3BisNY-4WLb0Khr9pDJGzTwXc-B+g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Paul,
>
> I believe the record blob is the full argus record being described in the
> other fields...So if you've set argus to capture user data, that userdata
> will be in there....
>
> At least, that's my understanding. :)
>
> Cheers,
>
> Jesse
>
> On Thu, Oct 18, 2012 at 4:56 PM, Paul Schmehl <pschmehl_lists at tx.rr.com
> >wrote:
>
> > Thanks, CS. This has been an interesting adventure. :-)
> >
> > Is the record blob the entire record including the total packet? (We
> > capture all 1500 bytes of every packet.) If it is, I *might* want to
> keep
> > it, since it would make searching faster. But there's always the concern
> > about drive space as well.
> >
> >
> > --On October 19, 2012 12:44:44 AM +0800 CS Lee <geek00l at gmail.com>
> wrote:
> >
> > hi Paul,
> >>
> >>
> >> Currently there's how the rasqlinsert works, you can run the command
> >> without -s -record option to create initial table
> >>
> >>
> >> Then stop rasqlinsert, now remove record column in mysql db table
> >>
> >>
> >> Now you can run with -s -record without any complain.
> >>
> >>
> >> In a way I do agree that it shouldn't complain or we should be able to
> >> create the table without record column using rasqlinsert. By the way I'm
> >> recalling all this from memory since I was encountered similar issue you
> >> have here.
> >>
> >>
> >>
> >> On Fri, Oct 19, 2012 at 12:00 AM,
> >> <argus-info-request at lists.**andrew.cmu.edu<
> argus-info-request at lists.andrew.cmu.edu>>
> >> wrote:
> >>
> >> Send Argus-info mailing list submissions to
> >> argus-info at lists.andrew.cmu.**edu<
> argus-info at lists.andrew.cmu.edu>
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://lists.andrew.cmu.edu/**mailman/listinfo/argus-info<
> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info>
> >> or, via email, send a message with subject or body 'help' to
> >> argus-info-request at lists.**andrew.cmu.edu<
> argus-info-request at lists.andrew.cmu.edu>
> >>
> >> You can reach the person managing the list at
> >> argus-info-owner at lists.andrew.**cmu.edu<
> argus-info-owner at lists.andrew.cmu.edu>
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of Argus-info digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >> 1. Re: rasqlinsert -s -record doesn't seem to work (Carter Bullard)
> >> 2. Segfault when using ratop + Ctrl-R to redraw (Jesse Bowling)
> >>
> >>
> >> ------------------------------**------------------------------**
> >> ----------
> >>
> >> Message: 1
> >> Date: Wed, 17 Oct 2012 14:46:00 -0400
> >> From: Carter Bullard <carter at qosient.com>
> >> Subject: Re: [ARGUS] rasqlinsert -s -record doesn't seem to work
> >> To: Paul Schmehl <pschmehl_lists at tx.rr.com>
> >> Cc: Argus List <argus-info at lists.andrew.cmu.**edu<
> argus-info at lists.andrew.cmu.edu>
> >> >
> >> Message-ID: <F5DF6081-E80A-4C87-8C29-**A6AAD6276DE8 at qosient.com<
> F5DF6081-E80A-4C87-8C29-A6AAD6276DE8 at qosient.com>
> >> >
> >> Content-Type: text/plain; charset=us-ascii
> >>
> >> Hey Paul,
> >> Not sure why you are generating the table? What happens when you let
> >> rasqlinsert create the table? If you have multiple argi, you'll have to
> >> add the srcid field.
> >>
> >> Carter
> >>
> >> On Oct 17, 2012, at 10:36 AM, Paul Schmehl <pschmehl_lists at tx.rr.com>
> >> wrote:
> >>
> >> --On October 16, 2012 9:13:25 PM -0400 Carter Bullard
> >>> <carter at qosient.com> wrote:
> >>>
> >>> Hey Paul,
> >>>> Hmmm, what is the RA_FIELD_SPECIFIER set to in your rasqlinsert.conf?
> >>>>
> >>>>
> >>> # grep RA_FIELD rasqlinsert.conf
> >>> # RA_FIELD_SPECIFIER="stime flgs proto saddr sport dir daddr dport
> state
> >>>
> >>> # suser:1500 duser:1500"
> >>> RA_FIELD_SPECIFIER="seq stime saddr daddr sport dport sbytes dbytes
> >>> state:16 proto"
> >>>
> >>> If you've run rasqlinsert() a bunch of times, with different fields
> >>>> defined, you may need to drop your table so that rasqlinsert() will
> >>>> generate the correct schema, once you get your fields the way you want
> >>>> them.
> >>>>
> >>>>
> >>> I've dropped the table numerous times testing out various things.
> >>>
> >>> I just did it again (I substituted tablename for the actual table name
> >>> in this response):
> >>>
> >>> mysql> drop table tablename;
> >>> Query OK, 0 rows affected (0.00 sec)
> >>>
> >>> mysql> source /home/pauls/tablename.sql
> >>> Query OK, 0 rows affected (0.00 sec)
> >>>
> >>> mysql> show columns from tablename;
> >>> +--------+--------------------**--+------+-----+--------------**
> >>> -----+------
> >>> -----------------------+
> >>> | Field | Type | Null | Key | Default
> >>> | | Extra |
> >>> +--------+--------------------**--+------+-----+--------------**
> >>> -----+------
> >>> -----------------------+
> >>> | ts | timestamp | NO | |
> >>> | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | seq | int(12)
> >>> | unsigned | NO | PRI | NULL | | stime |
> >>> | datetime | NO | | NULL
> >>> | | | saddr | varchar(15) | YES | | NULL
> >>> | | | daddr | varchar(15) | YES |
> >>> | | NULL | | sport | smallint(5) unsigned | NO
> >>> | | | NULL | | dport | smallint(5) unsigned
> >>> | | NO | | NULL | | sbytes | smallint(4)
> >>> | unsigned | NO | | NULL | | dbytes |
> >>> | smallint(4) unsigned | NO | | NULL | |
> >>> | state | tinytext | NO | | NULL
> >>> | | | proto | varchar(15) | YES | |
> >>> | NULL | |
> >>> +--------+--------------------**--+------+-----+--------------**
> >>> -----+------
> >>> -----------------------+ 11 rows in set (0.00 sec)
> >>>
> >>>
> >>> Then I ran this command (I've substituted generic terms for the actual
> >>> names):
> >>> # rasqlinsert -Z b -F rasqlinsert.conf -s -record -r
> >>> # /path/to/argus/files/2012-10-**15/argus.log.2012-10-15.16\:00\:00.bz2
> >>> -w
> >>>
> >>> # mysql://user:pass@buttercup4.**utdallas.edu/dbname/tablename<
> http://user:pass@buttercup4.utdallas.edu/dbname/tablename>
> >>>
> >>> And got this result (one for each row):
> >>>
> >>> rasqlinsert[3137]: 2012-10-16 18:51:47 mysql_real_query error Unknown
> >>> column 'record' in 'field list' rasqlinsert[3137]: 2012-10-16 18:51:47
> >>> mysql_real_query error Unknown column 'record' in 'field list'
> >>> rasqlinsert[3137]: 2012-10-16 18:51:47 mysql_real_query error Unknown
> >>> column 'record' in 'field list' rasqlinsert[3137]: 2012-10-16 18:51:47
> >>> mysql_real_query error Unknown column 'record' in 'field list'
> >>> rasqlinsert[3137]: 2012-10-16 18:51:47 mysql_real_query error Unknown
> >>> column 'record' in 'field list' rasqlinsert[3137]: 2012-10-16 18:51:47
> >>> mysql_real_query error Unknown column 'record' in 'field list'
> >>> rasqlinsert[3137]: 2012-10-16 18:51:47 mysql_real_query error Unknown
> >>> column 'record' in 'field list'
> >>>
> >>> The data is in the db:
> >>>
> >>> mysql> select * from tablename limit 20;
> >>> +---------------------+-------**-----+---------------------+--**
> >>> ------------
> >>> --+----------------+-------+--**-----+--------+--------+------**
> >>> ------+-----
> >>> --+
> >>> | ts | seq | stime
> >>> | | saddr | daddr | sport | dport |
> >>> | sbytes | dbytes | state | proto |
> >>> +---------------------+-------**-----+---------------------+--**
> >>> ------------
> >>> --+----------------+-------+--**-----+--------+--------+------**
> >>> ------+-----
> >>> --+
> >>> | 2012-10-17 14:23:02 | 1438262760 | 0000-00-00 00:00:00 |
> 10.200.22.138
> >>> | | 23.21.220.59 | 60396 | 443 | 65535 | 65535 | PA_PA
> >>> | | tcp | 2012-10-17 14:23:03 | 1438262662 | 0000-00-00 00:00:00 |
> >>> | 10.40.128.34 | 10.110.7.64 | 52719 | 2532 | 65535 |
> >>> | 65535 | FSA_FSPA | tcp | 2012-10-17 14:23:03 | 1438262475 |
> >>> | 0000-00-00 00:00:00 | 10.200.201.33 | 99.37.203.177 | 59445 |
> >>> | 7777 | 30268 | 65535 | PA_PA | tcp | 2012-10-17
> >>> | 14:23:03 | 1438262561 | 0000-00-00 00:00:00 | 10.200.201.33 |
> >>> | 99.37.203.177 | 59446 | 7777 | 28004 | 65535 | PA_PA |
> >>> | tcp | 2012-10-17 14:23:03 | 1438262499 | 0000-00-00 00:00:00 |
> >>> | 10.200.201.33 | 99.37.203.177 | 59448 | 7777 | 27830 | 65535
> >>> | | PA_PA | tcp | 2012-10-17 14:23:02 | 1438262624 |
> >>> | 0000-00-00 00:00:00 | 10.110.11.241 | 23.67.221.177 | 62500 |
> >>> | 443 | 5508 | 65535 | PA_PA | tcp | 2012-10-17 14:23:03
> >>> | | 1438262522 | 0000-00-00 00:00:00 | 10.200.201.33 | 99.37.203.177
> >>> | | 59447 | 7777 | 27723 | 65535 | PA_PA | tcp |
> >>> | 2012-10-17 14:23:03 | 1438262489 | 0000-00-00 00:00:00 |
> 10.200.201.33
> >>> | | 99.37.203.177 | 59440 | 7777 | 29599 | 65535 | PA_PA
> >>> | | tcp | 2012-10-17 14:23:02 | 1438262775 | 0000-00-00 00:00:00 |
> >>> | 10.200.201.43 | 69.171.234.21 | 46093 | 443 | 65535 | 5499
> >>> | | PA_PA | tcp | 2012-10-17 14:23:02 | 1438262940 |
> >>> | 0000-00-00 00:00:00 | 213.8.52.92 | 129.110.19.38 | 51043 |
> >>> | 80 | 4732 | 65535 | FSPA_FSPAC | tcp | 2012-10-17 14:23:02 |
> >>> | 1438262526 | 0000-00-00 00:00:00 | 76.185.173.239 | 129.110.10.68 |
> >>> | 50514 | 443 | 22869 | 14229 | PA_PA | tcp |
> >>> | 2012-10-17 14:23:04 | 1438262925 | 0000-00-00 00:00:00 | 10.21.13.1
> >>> | | 198.185.19.46 | 64765 | 80 | 10905 | 65535 | PA_PA
> >>> | | tcp | 2012-10-17 14:23:02 | 1438262785 | 0000-00-00 00:00:00
> >>> | | 10.21.13.1 | 198.81.200.2 | 64864 | 80 | 29792 |
> >>> | 65535 | FSPA_FSPA | tcp | 2012-10-17 14:23:03 | 1438262766 |
> >>> | 0000-00-00 00:00:00 | 99.101.126.204 | 129.110.10.68 | 53529 |
> >>> | 443 | 39552 | 25344 | PA_PA | tcp | 2012-10-17 14:23:02
> >>> | | 1438262679 | 0000-00-00 00:00:00 | 10.110.11.241 | 23.67.253.98
> >>> | | 62516 | 443 | 8657 | 65535 | SPA_SPA | tcp |
> >>> | 2012-10-17 14:23:02 | 1438262595 | 0000-00-00 00:00:00 |
> 10.110.11.241
> >>> | | 23.67.221.177 | 62502 | 443 | 5238 | 65535 | PA_PA
> >>> | | tcp | 2012-10-17 14:23:02 | 1438262950 | 0000-00-00 00:00:00 |
> >>> | 125.16.180.5 | 129.110.10.36 | 17759 | 80 | 2717 |
> >>> | 65535 | PA_PA | tcp | 2012-10-17 14:23:02 | 1438262678 |
> >>> | 0000-00-00 00:00:00 | 10.110.11.241 | 23.67.253.98 | 62517 |
> >>> | 443 | 5785 | 58786 | SPA_SPA | tcp | 2012-10-17 14:23:02
> >>> | | 1438262596 | 0000-00-00 00:00:00 | 10.110.11.241 | 23.67.221.177
> >>> | | 62501 | 443 | 4608 | 65535 | PA_PA | tcp |
> >>> | 2012-10-17 14:23:04 | 1438262687 | 0000-00-00 00:00:00 |
> 10.176.80.248
> >>> | | 38.100.128.106 | 65389 | 554 | 2340 | 65535 | A_PA
> >>> | | tcp |
> >>> +---------------------+-------**-----+---------------------+--**
> >>> ------------
> >>> --+----------------+-------+--**-----+--------+--------+------**
> >>> ------+-----
> >>> --+ 20 rows in set (0.00 sec)
> >>>
> >>>
> >>> So it's throwing errors on the console but not affecting the input to
> >>> the db.
> >>>
> >>> Then I added a record field to the schema, dropped the table and
> >>> recreated it:
> >>>
> >>> mysql> show columns from tablename;
> >>> +--------+--------------------**--+------+-----+--------------**
> >>> -----+------
> >>> -----------------------+
> >>> | Field | Type | Null | Key | Default
> >>> | | Extra |
> >>> +--------+--------------------**--+------+-----+--------------**
> >>> -----+------
> >>> -----------------------+
> >>> | ts | timestamp | NO | |
> >>> | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | seq | int(12)
> >>> | unsigned | NO | PRI | NULL | | stime |
> >>> | datetime | NO | | NULL
> >>> | | | saddr | varchar(15) | YES | | NULL
> >>> | | | daddr | varchar(15) | YES |
> >>> | | NULL | | sport | smallint(5) unsigned | NO
> >>> | | | NULL | | dport | smallint(5) unsigned
> >>> | | NO | | NULL | | sbytes | smallint(4)
> >>> | unsigned | NO | | NULL | | dbytes |
> >>> | smallint(4) unsigned | NO | | NULL | |
> >>> | state | tinytext | NO | | NULL
> >>> | | | proto | varchar(15) | YES | |
> >>> | NULL | | record | blob |
> >>> | YES | | NULL | |
> >>> +--------+--------------------**--+------+-----+--------------**
> >>> -----+------
> >>> -----------------------+ 12 rows in set (0.00 sec)
> >>>
> >>>
> >>> And ran the command again. This time I get no errors on the console,
> >>> and there's also no data in the record field.
> >>>
> >>> mysql> select * from tablename limit 20;
> >>> +---------------------+-------**-----+---------------------+--**
> >>> ------------
> >>> --+----------------+-------+--**-----+--------+--------+------**
> >>> ------+-----
> >>> --+--------+
> >>> | ts | seq | stime
> >>> | | saddr | daddr | sport | dport |
> >>> | sbytes | dbytes | state | proto | record |
> >>> +---------------------+-------**-----+---------------------+--**
> >>> ------------
> >>> --+----------------+-------+--**-----+--------+--------+------**
> >>> ------+-----
> >>> --+--------+
> >>> | 2012-10-17 14:32:06 | 1438262760 | 0000-00-00 00:00:00 |
> 10.200.22.138
> >>> | | 23.21.220.59 | 60396 | 443 | 65535 | 65535 | PA_PA
> >>> | | tcp | NULL | 2012-10-17 14:32:06 | 1438262662 | 0000-00-00
> >>> | 00:00:00 | 10.40.128.34 | 10.110.7.64 | 52719 | 2532 |
> >>> | 36726 | 65535 | SA_SA | tcp | NULL | 2012-10-17
> >>> | 14:32:06 | 1438262475 | 0000-00-00 00:00:00 | 10.200.201.33 |
> >>> | 99.37.203.177 | 59445 | 7777 | 15851 | 65535 | PA_PA |
> >>> | tcp | NULL | 2012-10-17 14:32:06 | 1438262561 | 0000-00-00
> >>> | 00:00:00 | 10.200.201.33 | 99.37.203.177 | 59446 | 7777 |
> >>> | 14148 | 65535 | PA_PA | tcp | NULL | 2012-10-17
> >>> | 14:32:06 | 1438262499 | 0000-00-00 00:00:00 | 10.200.201.33 |
> >>> | 99.37.203.177 | 59448 | 7777 | 13797 | 65535 | PA_PA |
> >>> | tcp | NULL | 2012-10-17 14:32:06 | 1438262624 | 0000-00-00
> >>> | 00:00:00 | 10.110.11.241 | 23.67.221.177 | 62500 | 443 |
> >>> | 5508 | 65535 | PA_PA | tcp | NULL | 2012-10-17
> >>> | 14:32:06 | 1438262522 | 0000-00-00 00:00:00 | 10.200.201.33 |
> >>> | 99.37.203.177 | 59447 | 7777 | 14175 | 65535 | PA_PA |
> >>> | tcp | NULL | 2012-10-17 14:32:06 | 1438262489 | 0000-00-00
> >>> | 00:00:00 | 10.200.201.33 | 99.37.203.177 | 59440 | 7777 |
> >>> | 14620 | 65535 | PA_PA | tcp | NULL | 2012-10-17
> >>> | 14:32:06 | 1438262775 | 0000-00-00 00:00:00 | 10.200.201.43 |
> >>> | 69.171.234.21 | 46093 | 443 | 65535 | 5499 | PA_PA |
> >>> | tcp | NULL | 2012-10-17 14:32:06 | 1438262940 | 0000-00-00
> >>> | 00:00:00 | 213.8.52.92 | 129.110.19.38 | 51043 | 80 |
> >>> | 4732 | 65535 | FSPA_FSPAC | tcp | NULL | 2012-10-17 14:32:06 |
> >>> | 1438262526 | 0000-00-00 00:00:00 | 76.185.173.239 | 129.110.10.68 |
> >>> | 50514 | 443 | 22869 | 14229 | PA_PA | tcp | NULL |
> >>> | 2012-10-17 14:32:06 | 1438262925 | 0000-00-00 00:00:00 | 10.21.13.1
> >>> | | 198.185.19.46 | 64765 | 80 | 8549 | 65535 | PA_PA
> >>> | | tcp | NULL | 2012-10-17 14:32:06 | 1438262785 |
> >>> | 0000-00-00 00:00:00 | 10.21.13.1 | 198.81.200.2 | 64864 |
> >>> | 80 | 29792 | 65535 | FSPA_FSPA | tcp | NULL | 2012-10-17
> >>> | 14:32:06 | 1438262766 | 0000-00-00 00:00:00 | 99.101.126.204 |
> >>> | 129.110.10.68 | 53529 | 443 | 19842 | 13134 | PA_PA |
> >>> | tcp | NULL | 2012-10-17 14:32:06 | 1438262679 | 0000-00-00
> >>> | 00:00:00 | 10.110.11.241 | 23.67.253.98 | 62516 | 443 |
> >>> | 8657 | 65535 | SPA_SPA | tcp | NULL | 2012-10-17 14:32:06
> >>> | | 1438262595 | 0000-00-00 00:00:00 | 10.110.11.241 | 23.67.221.177
> >>> | | 62502 | 443 | 5238 | 65535 | PA_PA | tcp | NULL
> >>> | | 2012-10-17 14:32:06 | 1438262950 | 0000-00-00 00:00:00 |
> >>> | 125.16.180.5 | 129.110.10.36 | 17759 | 80 | 2717 |
> >>> | 65535 | PA_PA | tcp | NULL | 2012-10-17 14:32:06 |
> >>> | 1438262678 | 0000-00-00 00:00:00 | 10.110.11.241 | 23.67.253.98 |
> >>> | 62517 | 443 | 5785 | 58786 | SPA_SPA | tcp | NULL |
> >>> | 2012-10-17 14:32:06 | 1438262596 | 0000-00-00 00:00:00 |
> 10.110.11.241
> >>> | | 23.67.221.177 | 62501 | 443 | 4608 | 65535 | PA_PA
> >>> | | tcp | NULL | 2012-10-17 14:32:06 | 1438262687 | 0000-00-00
> >>> | 00:00:00 | 10.176.80.248 | 38.100.128.106 | 65389 | 554 |
> >>> | 900 | 65535 | A_PA | tcp | NULL |
> >>> +---------------------+-------**-----+---------------------+--**
> >>> ------------
> >>> --+----------------+-------+--**-----+--------+--------+------**
> >>> ------+-----
> >>> --+--------+ 20 rows in set (0.00 sec)
> >>>
> >>>
> >>> So the switch *is* preventing insertion of the record field but throws
> a
> >>> console error if the field doesn't exist in the db. I can live with
> >>> that, but it seems like a bug.
> >>>
> >>> --
> >>> Paul Schmehl, Senior Infosec Analyst
> >>> As if it wasn't already obvious, my opinions
> >>> are my own and not those of my employer.
> >>> *********************************************
> >>> "It is as useless to argue with those who have
> >>> renounced the use of reason as to administer
> >>> medication to the dead." Thomas Jefferson
> >>> "There are some ideas so wrong that only a very
> >>> intelligent person could believe in them." George Orwell
> >>>
> >>>
> >>>
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Wed, 17 Oct 2012 16:21:15 -0400
> >> From: Jesse Bowling <jessebowling at gmail.com>
> >> Subject: [ARGUS] Segfault when using ratop + Ctrl-R to redraw
> >> To: argus-info <argus-info at lists.andrew.cmu.**edu<
> argus-info at lists.andrew.cmu.edu>
> >> >
> >> Message-ID:
> >>
> >> <**CAGFhEnk0gVjgtWL5SJyWr7Pw0xOnn**jBAFK+JVqJshvs3=Ta74w at mail.**
> gmail.com<Ta74w at mail.gmail.com>
> >> >
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> In my continued series of unimportant bugs, I've found that I can
> >> consistently crash ratop using the Ctrl-R keystroke. My poor memory
> >> recalled the redraw command as being Ctrl-R, but in fact it's Ctrl-D.
> >> While
> >> Ctrl-D works fine, Ctrl-R causes a segfault. Running Ubuntu 10.04 on
> >> 2.6.32-44-generic #98-Ubuntu SMP Mon Sep 24 17:27:10 UTC 2012 x86_64.
> >>
> >> Starting program: /usr/local/bin/ratop
> >> [Thread debugging using libthread_db enabled]
> >>
> >> [New Thread 0x7ffff6757700 (LWP
> >> 21221)]
> >> 2012/10/17.15:35:12 EDT
> >> ratop -r
> >>
> >> RaTopLoop() Idle.
> >> (Hit Ctrl-R)
> >> Program received signal SIGSEGV, Segmentation fault.
> >> [Switching to Thread 0x7ffff6757700 (LWP 21221)]
> >> 0x000000000040cfaa in ArgusProcessCommand (parser=0x7ffff7e9e010,
> >> status=40, ch=18) at ./ratop.c:2845
> >> 2845 ./ratop.c: No such file or directory.
> >> in ./ratop.c
> >> (gdb) where
> >> # 0 0x000000000040cfaa in ArgusProcessCommand (parser=0x7ffff7e9e010,
> >>
> >> status=40, ch=18) at ./ratop.c:2845
> >> # 1 0x00000000004096ea in ArgusCursesProcess (arg=0x0) at
> ./ratop.c:1781
> >> # 2 0x00007ffff79439ca in start_thread () from /lib/libpthread.so.0
> >> # 3 0x00007ffff724616d in clone () from /lib/libc.so.6
> >> # 4 0x0000000000000000 in ?? ()
> >> (gdb) up
> >> # 1 0x00000000004096ea in ArgusCursesProcess (arg=0x0) at
> ./ratop.c:1781
> >>
> >> 1781 in ./ratop.c
> >> (gdb) backtrace full
> >> # 0 0x000000000040cfaa in ArgusProcessCommand (parser=0x7ffff7e9e010,
> >>
> >> status=40, ch=18) at ./ratop.c:2845
> >> startline = 0
> >> ns = 0xb8c6a0
> >> retn = 40
> >> x = 0
> >> # 1 0x00000000004096ea in ArgusCursesProcess (arg=0x0) at
> ./ratop.c:1781
> >>
> >> queue = 0xb544b0
> >> tvbuf = {tv_sec = 0, tv_usec = 11956}
> >> tvp = 0x7ffff6756e50
> >> i = 0
> >> ch = 18
> >> in = {__fds_bits = {1, 0 <repeats 15 times>}}
> >> blocked_signals = {__val = {18446744067132882943,
> >> 18446744073709551615 <repeats 15 times>}}
> >> done = 0
> >> # 2 0x00007ffff79439ca in start_thread () from /lib/libpthread.so.0
> >>
> >> No symbol table info available.
> >> # 3 0x00007ffff724616d in clone () from /lib/libc.so.6
> >>
> >> No symbol table info available.
> >> # 4 0x0000000000000000 in ?? ()
> >>
> >> No symbol table info available.
> >>
> >> I'm still using version 3.0.6.2, and haven't yet upgraded to later
> >> versions
> >> or applied the patch you sent earlier. So perhaps the issue has already
> >> been fixed, and shame on me in that case...I'll get the latest clients
> >> tonight and try to replicate the issue.
> >>
> >> Cheers,
> >>
> >> Jesse
> >>
> >> --
> >> Jesse Bowling
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL:
> >> https://lists.andrew.cmu.edu/**mailman/private/argus-info/**
> >> attachments/20121<
> https://lists.andrew.cmu.edu/mailman/private/argus-info/attachments/20121>
> >> 017/26447de1/attachment-0001.**html
> >>
> >> ------------------------------
> >>
> >> ______________________________**_________________
> >> Argus-info mailing list
> >> Argus-info at lists.andrew.cmu.**edu <Argus-info at lists.andrew.cmu.edu>
> >> https://lists.andrew.cmu.edu/**mailman/listinfo/argus-info<
> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info>
> >>
> >>
> >> End of Argus-info Digest, Vol 86, Issue 30
> >> ********************************************
> >>
> >
> >
> >
> > --
> > Paul Schmehl, Senior Infosec Analyst
> > As if it wasn't already obvious, my opinions
> > are my own and not those of my employer.
> > *********************************************
> > "It is as useless to argue with those who have
> > renounced the use of reason as to administer
> > medication to the dead." Thomas Jefferson
> > "There are some ideas so wrong that only a very
> > intelligent person could believe in them." George Orwell
> >
> >
>
>
> --
> Jesse Bowling
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://lists.andrew.cmu.edu/mailman/private/argus-info/attachments/20121018/d43f5c0b/attachment.html
>
> ------------------------------
>
> _______________________________________________
> Argus-info mailing list
> Argus-info at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/argus-info
>
>
> End of Argus-info Digest, Vol 86, Issue 35
> ******************************************
>
--
Best Regards,
CS Lee<geek00L[at]gmail.com>
http://geek00l.blogspot.com
http://defcraft.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121019/c89aa5e7/attachment.html>
More information about the argus
mailing list