[Gerald Combs <gerald@xxxxxxxxxxxx>]

On Fri, 19 Apr 2002, Guy Harris wrote:

> 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.)

I opened the project last week with the intention of setting up another
download mirror. (Ethereal's popularity is eating up our bandwidth here at
work.)  Initially there was some confusion on the project name - when I
tried to register 'ethereal', it said the name wasn't available even
though no project was using the name at that time.  I asked about it on
the SF bug tracking system, and they evidently reserved a few well-know
project names when SourceForge was initially created.

The end result is that we now "own" both 'ethereal' and 'etherealnpa'
(which I created when 'ethereal' wasn't available).  The 'etherealnpa'
project should probably be removed at some point.



> 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.
> 
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>