I think the real bug in the manual is that Table 6.3 is missing a
fundamental type - the byte string. (I think that an Ethernet address
which is there is possibly a special case of a byte string. Certainly
colons, ":", in ethernet addresses can be exchanged with period, ".",
and dash, "-")
I think if this type is added to the table and one says that a substring
(or slice as referred to in the manual) can be compared against either a
byte-string or a text string then I think it should be fairly clear on
what is required.
The filter man page has a pretty clear description of byte-string.
Martin Visser, CISSP
Network and Security Consultant
Consulting & Integration
Technology Solutions Group - HP Services
410 Concord Road
Rhodes NSW 2138
Australia
Mobile: +61-411-254-513
Fax: +61-2-9022-1800
E-mail: martin.visserAThp.com
This email (including any attachments) is intended only for the use of
the individual or entity named above and may contain information that is
confidential, proprietary or privileged. If you are not the intended
recipient, please notify HP immediately by return email and then delete
the email, destroy any printed copy and do not disclose or use the
information in it.
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: Monday, 24 October 2005 6:19 PM
To: Ethereal development
Subject: Re: [Ethereal-dev] decimals not accepted in substrings -can
youconfirm a bug?
Visser, Martin wrote:
> The fieldds ip.src,ip.dst and ip.addr are "special" and can't be
> indexed directly.
Actually, that's true of any IPv4 address, as well as being true of
integral types. "ip.src", "ip.dst", and "ip.addr" aren't different from
any other IPv4 address fields, they just happen to have a type (IPv4
address) that doesn't support "slicing".
IPv6 addresses, however, are "sliceable"; I'm not sure there's a strong
reason to forbid it on IPv4 addresses (or perhaps even on any of the
integral data types).
> Unfortunately (and the manual isn't all that clear on this) though
> integers are able to be represented by "decimal, octal, or
> hexadecimal", this doesn't apply to the byte values in the substring.
> These have to be hex (also shown above)
The manual should probably be fixed to make that clear. If there's a
bug (and I'd argue that there is), that's the bug - the manual doesn't
indicate that it's the numbers in the index expression, not the numbers
in a byte string, that can be in decimal, octal, or hex.
(In any case, as noted, the right way to do subnet comparisons is with
"{IPv4 field} == {addr}/{subnet bits}"; that can do more than comparing
particular bytes of an IPv4 address can, *and* it's arguably closer to
the way most people would express it, and more convenient to express as
a result.)
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
