You might want to consider changing the '.' version of the byte string ( and mac address string )
to recognize ffff.ffff.ffff. Since this is the syntax Cisco routers use to represent the mac
addresses in most cases. The lack of this interpretation makes cutting and pasting from
the output of show commands on Cisco routers sort of a pain as one must go through and
properly 'colonize' them by hand.
Just my 2c :)
Ed
Gilbert Ramirez wrote:
Right now there are three ways to express multi-byte byte-strings in Ethereal's display-filter syntax.... using periods, colons, or hyphens:
ff.ff.ff.ff.ff.ff ff-ff-ff-ff-ff-ff ff:ff:ff:ff:ff:ff
I'm working on some changes to the dfilter code, and would like to have the scanner create some of the basic types. But floating point 0.7 looks like a byte-string equivalent to 00:07. In order to disambiguate some floating point numbers from two-byte byte-strings, I'd like to remove the option of using a period between bytes in a byte-string.
Sigh. If I had been smart, I would have allowed only one syntax for byte strings. Not 3. Not 2.
I'd like to get a feel for how badly this change would affect people. If breaking this would cause too much hardship, I won't do it. I can work around the 3 syntaxes for byte strings. I'm contemplating this change because it makes it easier and cleaner to implement a "contains" test. I.e., I have the following dfilter syntax working:
http contains "jpg" frame contains 00:07
The "contains" test works on protocols, strings, and byte-strings (and derivatives).
--gilbert
_______________________________________________
Ethereal-dev mailing list
[EMAIL PROTECTED]
http://www.ethereal.com/mailman/listinfo/ethereal-dev
