On Tue, Sep 03, 2002 at 10:26:18AM -0400, Patnaik, Anjela wrote:
> How about a way in tethereal to choose a given
> protocol?
What do you mean by "choose"?
Do you mean "a way to have a capture only save packets for a given
protocol?
If so, then:
> I think my syntax may be wrong. I have
> several GIOP plugins that I have built, but
> want to only display a given kind, named plugin1.
>
> Do a specify "proto giop-plugin1"?
No.
That's a capture filter, and the syntax of capture filters is described
by the tcpdump man page, which says, of "proto", in the current CVS
version of tcpdump:
proto qualifiers restrict the match to a particu-
lar protocol. Possible protos are: ether,
fddi, tr, wlan, ip, ip6, arp, rarp, decnet,
tcp and udp. E.g., `ether src foo', `arp
net 128.3', `tcp port 21'. If there is no
proto qualifier, all protocols consistent
with the type are assumed. E.g., `src foo'
means `(ip or arp or rarp) src foo' (except
the latter is not legal syntax), `net bar'
means `(ip or arp or rarp) net bar' and
`port 53' means `(tcp or udp) port 53'.
[`fddi' is actually an alias for `ether'; the
parser treats them identically as meaning ``the
data link level used on the specified network
interface.'' FDDI headers contain Ethernet-like
source and destination addresses, and often contain
Ethernet-like packet types, so you can filter on
these FDDI fields just as with the analogous Ether-
net fields. FDDI headers also contain other
fields, but you cannot name them explicitly in a
filter expression.
Similarly, `tr' and `wlan' are aliases for `ether';
the previous paragraph's statements about FDDI
headers also apply to Token Ring and 802.11 wire-
less LAN headers. For 802.11 headers, the destina-
tion address is the DA field and the source address
is the SA field; the BSSID, RA, and TA fields
aren't tested.]
The only valid values for "proto" are some that are hardwired in (and
that don't include arbitrary GIOP protocols), TCP or UDP port numbers
(which would require you to know the port number or numbers on which the
GIOP protocol in question would run; Ethereal and Tethereal cannot
magically determine that), or port names as found in the "/etc/services"
file or other service name databases (which would only include
well-known and reserved port numbers).
You would have to use a "read filter" to select your protocol, unless
you know the TCP port number your protocol will be using. A "read
filter" has the syntax of a display filter, so it'd just be the protocol
name you assigned to the protocol your plugin dissects.
See the Tethereal man page for information on how to specify a read
filter.
(And if you're sending mail to ethereal-dev, don't send it directly to
me as well; I'm on ethereal-dev, so sending it directly to me as well
means I get two copies of the mail, which is one more copy than I want.)
