Ethereal-users: Re: [Ethereal-users] Problems with Perl regular expression (PCRE) and tethereal
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Nicholas George <nick.george@xxxxxxxxx>
Date: Fri, 2 Dec 2005 10:30:50 -0500
Hi Guy,
Thank you very much for your help, it was helpful. I will remember to use "echo" in the future - I should've figured it out for myself :P
The reason I got a bit confused is because of this little snippet from the tethereal man page:
"A capture or read filter can either be specified with the -f or -R option, respectively, in which case
the entire filter _expression_ must be specified as a single argument (which means that if it contains
spaces, it must be quoted), or can be specified with command-line arguments after the option arguments,
in which case all the arguments after the filter arguments are treated as a filter _expression_. Capture
filters are supported only when doing a live capture; read filters are supported when doing a live cap-
ture and when reading a capture file, but require Tethereal to do more work when filtering, so you might
be more likely to lose packets under heavy load if you're using a read filter. If the filter is speci-
fied with command-line arguments after the option arguments, it's a capture filter if a capture is being
done (i.e., if no -r flag was specified) and a read filter if a capture file is being read (i.e., if a
-r flag was specified)."
>From my interpretation, it's saying that you don't have to quote filter expressions as long as they are after the option arguments. However from what we've experienced, this doesn't seem to be so. Bummer!
On a completely seperate note, is there any way of getting tethereal to dump the contents of a tcp session (a la "follow tcp stream") to a file? I know this has been discussed before on the mailing list, but because there doesn't seem to be a mailing-list search tool, I can't find a response to this issue. I've been using the tcpflow tool which so far does an excellent job, however it doesn't seem to be under active development (no releases since '03). This either means the tool is so good that it doesn't need to be updated, or there doesn't seem to be much community interest in this kind of tool. It would be awesome if tethereal had this sort of capability.
In answer to your question about what does
Cheers,
Nick
Nicholas George wrote:
After "-r in.dmp", the remaining tokens get glued together into a single string, and that string is parsed; the parsing cuts it back up into tokens, and
isn't valid, as GET is the right-hand argument to the "matches" operator, and the /file\.htm and HTTP/1\.1 are just extra junk.
which would be cut into *three* tokens: "frame", "matches", and "GET /file\\.htm HTTP/1\\.1". The right-hand argument to the "matches" operator is the entire string "GET /file\\.htm HTTP/1\\.1".
This appears to be a \ vs. \\ issue, although I'm not sure why \\ works and \ doesn't.
Thank you very much for your help, it was helpful. I will remember to use "echo" in the future - I should've figured it out for myself :P
The reason I got a bit confused is because of this little snippet from the tethereal man page:
"A capture or read filter can either be specified with the -f or -R option, respectively, in which case
the entire filter _expression_ must be specified as a single argument (which means that if it contains
spaces, it must be quoted), or can be specified with command-line arguments after the option arguments,
in which case all the arguments after the filter arguments are treated as a filter _expression_. Capture
filters are supported only when doing a live capture; read filters are supported when doing a live cap-
ture and when reading a capture file, but require Tethereal to do more work when filtering, so you might
be more likely to lose packets under heavy load if you're using a read filter. If the filter is speci-
fied with command-line arguments after the option arguments, it's a capture filter if a capture is being
done (i.e., if no -r flag was specified) and a read filter if a capture file is being read (i.e., if a
-r flag was specified)."
>From my interpretation, it's saying that you don't have to quote filter expressions as long as they are after the option arguments. However from what we've experienced, this doesn't seem to be so. Bummer!
On a completely seperate note, is there any way of getting tethereal to dump the contents of a tcp session (a la "follow tcp stream") to a file? I know this has been discussed before on the mailing list, but because there doesn't seem to be a mailing-list search tool, I can't find a response to this issue. I've been using the tcpflow tool which so far does an excellent job, however it doesn't seem to be under active development (no releases since '03). This either means the tool is so good that it doesn't need to be updated, or there doesn't seem to be much community interest in this kind of tool. It would be awesome if tethereal had this sort of capability.
In answer to your question about what does
tethereal -r in.dmp 'frame matches "GET /file\\.htm HTTP/1\\.1"'
do? - It works.
Cheers,
Nick
Nicholas George wrote:
I am having a problem searching a pcap dump file using the perl
regular _expression_ syntax for tethereal. I've found the documentation
to be sparse. :(
I would like to do something like:
tethereal -r in.dmp frame matches 'GET /file\.htm HTTP/1\.1'
However, it won't work unless I do:
tethereal -r in.dmp frame matches '"GET /file\\.htm HTTP/1\\.1"'
I don't understand why, aren't these two lines the same? (I'm using
the bash shell
No, they're not:
$ echo -r in.dmp frame matches 'GET /file\.htm HTTP/1\.1'
-r in.dmp frame matches GET /file\.htm HTTP/1\.1
$ echo -r in.dmp frame matches '"GET /file\\.htm HTTP/1\\.1"'
-r in.dmp frame matches "GET /file\\.htm HTTP/1\\.1"
Note the double-quotes in the second line.
The error message I get is:
tethereal: "/" was unexpected in this context
The first command would pass to Tethereal the arguments
-r
tethereal -r in.dmp 'frame matches "GET /file\\.htm HTTP/1\\.1"' in.dmp
frame
matches
GET
/file\.htm
HTTP/1\.1
After "-r in.dmp", the remaining tokens get glued together into a single string, and that string is parsed; the parsing cuts it back up into tokens, and
frame matches GET /file\.htm HTTP/1\.1
isn't valid, as GET is the right-hand argument to the "matches" operator, and the /file\.htm and HTTP/1\.1 are just extra junk.
The second command would pass to Tethereal the arguments
-r
in.dmp
frame
matches
"GET /file\\.htm HTTP/1\\.1"
and the resulting filter string would be
frame matches "GET /file\\.htm HTTP/1\\.1"
which would be cut into *three* tokens: "frame", "matches", and "GET /file\\.htm HTTP/1\\.1". The right-hand argument to the "matches" operator is the entire string "GET /file\\.htm HTTP/1\\.1".
It also doesn't work if I try:
tethereal -r in.dmp frame matches "\"GET /file\\.htm HTTP/1\\.1\""
although this time I get no error message.
$ echo -r in.dmp frame matches "\"GET /file\\.htm HTTP/1\\.1\""
-r in.dmp frame matches "GET /file\.htm HTTP/1\.1"
It DOES work if I try.
tethereal -r in.dmp -R 'frame matches "GET /file\\.htm HTTP/1\\.1"'
$ echo -r in.dmp -R 'frame matches "GET /file\\.htm HTTP/1\\.1"'
-r in.dmp -R frame matches "GET /file\\.htm HTTP/1\\.1"
This appears to be a \ vs. \\ issue, although I'm not sure why \\ works and \ doesn't.
My questions are:
What is the point of the -R?
Perhaps nothing - what does
tethereal -r in.dmp 'frame matches "GET /file\\.htm HTTP/1\\.1"'
do?
- Prev by Date: [Ethereal-users] MMS MATE config
- Next by Date: RE: [Ethereal-users] VoIP?s conversation saved in a file
- Previous by thread: Re: [Ethereal-users] MMS MATE config
- Next by thread: RE: [Ethereal-users] VoIP?s conversation saved in a file
- Index(es):