On Wed, Apr 17, 2002 at 03:23:01PM -0700, Brent Bice wrote:
> I submitted a bug to sourceforge yesterday. 'Not sure if you guys are
> using this or not,
I was not even aware that there *was* a SourceForge entry for Ethereal
until you mentioned it!
It seems fairly empty; did the SourceForge folks automatically create it
because there's a Freshmeat entry for Ethereal? (They're both VA
Research, err, umm, VA Linux Systems, err, umm, VA Software projects - as
is Slashdot, for that matter.)
There isn't one for libpcap or tcpdump, though, and they're also in
Freshmeat.
Perhaps it was moved to SourceForge from Server 51 when they shut Server
51 down?
> so I figured I'd drop an email in the list too. (grin)
>
> I noticed that if I select a POP3 packet (for instance) and drill down
> into the POP3 protocol part and select the POP3 command itself and do a
> Match->Selected, I get a display filter like:
>
> frame[54] == 55:44:33:22
>
> But that display filter doesn't work anymore.
I assume you mean "doesn't work" as in "didn't actually see the packet",
rather than "got a syntax error".
> I found this does work:
> frame[54:4] == 55:44:33:22
>
> I'm not sure if this is a bug in the "Match->Selected" code or in the
> Display filter code or both. Are both the above filters still considered
> syntactically correct?
Well, the Ethereal 0.9.3 man page section on display filters says:
You can use the slice operator on a protocol name, too.
And remember, the "frame" protocol encompasses the entire
packet, allowing you to look at the nth byte of a packet
regardless of its frame type (Ethernet, token-ring, etc.).
token[0:5] ne 0.0.0.1.1
ipx[0:2] == ff:ff
llc[3:1] eq 0xaa
The following syntax governs slices:
[i:j] i = start_offset, j = length
[i-j] i = start_offet, j = end_offset, inclusive.
[i] i = start_offset, length = 1
[:j] start_offset = 0, length = j
[i:] start_offset = i, end_offset = end_of_field
which would indicate that "frame[54]" is valid, but means "the byte
at offset 54".
However, the routine that actually constructs the display filter string,
"proto_alloc_dfilter_string()", never puts in the ":j" part, it just
puts the "i" part in.
The parser for display filter expressions looks as if it supports a
*comma-separated list* of ranges in slices - Gilbert, is that the case?
Does that mean that you could do
frame[1:2,8:2] == 16:88:42:41
to compare byte 1 with 16, byte 2 with 88, byte 8 with 42, and byte 9
with 41? If so, the man page should be updated.
The parser *does* look as if "frame[54]" would, in fact, mean "the byte
at offset 54", so this suggests that "proto_alloc_dfilter_string()"
should put the length in.
I'd expect the expressoin "frame[54] == 55:44:33:22" to get an error;
however, I think that check would be done by
"check_relation_LHS_RANGE()", and the code for checking if the RHS is a
range consists of
/* XXX - check lengths of both ranges */
so it appears the check that would report the error isn't being done.