Ethereal-users: Re: [ethereal-users] More "Unable to parse filter string (parse error)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Wed, 6 Sep 2000 05:07:35 -0700
On Wed, Aug 30, 2000 at 02:21:57PM -0700, Gary Taylor wrote:
> I know this has been asked numerous times, but I am trying to get a
> capture filter working and can't figure out what part I'm doing wrong.  I want
> to capture all traffic going to/from 149.82.78.64 and my local box for now,
> just to get anything working.  I've tried various combinations (listed below)
> and I keep getting the message: "Unable to parse filter string"
> 
> I even tried the exact tcpdump example just to see if the filter would save and
> I still get the "Unable to parse filter string" error.
> 
> tcpdump host sundown
> tcpdump host 149.82.78.64
> tcpdump -i ppp0 host 149.82.78.64
> tcpdump -i ppp0 localhost 
> host 149.82.78.64
> host localhost
> tcpdump -i ppp0 127.0.0.1
> host 127.0.0.1
> host speedygt
> tcpdump host speedygt
> tcpdump host 192.168.0.1

All the examples that contain the string "tcpdump" are wrong; you are
supposed to put only the *capture filter* argument that would be passed
to tcpdump, *not* the entire tcpdump command line.

In addition, thanks to libpcap (even the 0.5 version; it's fixed in the
version currently in the tcpdump.org CVS tree) not properly using Flex,
once you've gotten one "Unable to parse filter string" error within one
Ethereal session, you may *continue* to get those errors *even for valid
filter expressions*, so you'd have to exit Ethereal and start it up
again, making sure you use a valid filter expression in the new Ethereal
session (as an invalid expression could get you stuck again).

If you want to capture traffic between 149.82.78.64 and your machine on
some network, the filter expression (for tcpdump *or* Ethereal) would be
something such as

	host 149.82.78.64 and <your host's name or IP address *on the
	    network in question*>

I emphasize "on the network in question" because "localhost" or
"127.0.0.1" should *NOT* be used - those are your host's name and IP
address, respectively, on the *loopback* network, but they're not its
name or IP address on any other network, and thus they won't work if
you're not capturing on the loopback interface.

For example, if your host's address on the ppp0 interface is
192.168.0.1, and the name corresponding to that address is "speedygt",
and if the name corresponding to 149.82.78.64 is "sundown", then

	host sundown and speedygt

would work, as would

	host sundown and 192.168.0.1

or

	host 149.82.78.64 and speedygt

or

	host 149.82.78.64 and 192.168.0.1