Ethereal-dev: Re: [Ethereal-dev] Filter bug ?

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Mon, 7 May 2001 22:08:48 -0700 (PDT)
> When "match selected " some of my traced files I get an error message
> "0x<value> is not a valid byte string"
> It seems whenever the filter includes "FRAME[] == " it does no longer accept
> 0x to be included in the filter string. 

Correct, it doesn't; "frame" is a byte-string type, and byte strings are
sequences of hex byte values, with no "0x", and with colons separating
the bytes.

However, the code to construct the filter when the selected protocol
tree line *doesn't* correspond to a filterable field treats a 1-byte
value as a special case, and sticks the "0x" in there.

As far as I know, this is an error; removing that special case appears
to fix the problem.  Unless somebody indicates some place where you have
to put that "0x" in, I'm going to check in the code that eliminates the
special case.

> Below I've included a frame from ethereal for demonstration:

...which requires that you either change the NSAP selector for COTP, or
specify that NSDUs should always be decoded as transport PDUs.

Note, though, that...

> >From the ISO 8073 COTP decoding do a match selected on TPDU code: 0xd (CC)
> ethereal will now construct the filterstring frame[81] == 0xd8, which will
> not be accepted as being valid.

...fixing the bug means that if, for example, you select the TPDU code
field of the *first* packet, and do "Match Selected", it also matches
three ISIS packets, because it's blindly matching all frames where the
79th byte (1-origin) has the value hex 80.  Somebody should perhaps look
at making the COTP/CLTP dissector use registered fields, so that you
could, for example, match all frames with a particular TPDU value.

(Note also that there are some fragmented NPDUs; perhaps the
fragment-reassembly stuff in the IP dissector should be transplanted to
the CLNP dissector, and modified as appropriate.  It should, obviously,
also be transplanted to the IPv6 dissector....)