> -----Original Message-----
> From: [email protected] [mailto:wireshark-dev-
> [email protected]] On Behalf Of Jakub Zawadzki
> Sent: Thursday, June 07, 2012 2:59 AM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 43069:
> /trunk/epan/dfilter/ /trunk/epan/dfilter/: gencode.c semcheck.c
>
> On Wed, Jun 06, 2012 at 09:55:10PM -0400, Maynard, Chris wrote:
> > Just wanted to say that this is a really cool new feature. Thanks
> for adding it!
>
> It's not really new, it was broken in r10829[1] (bracket missing),
> but... it was broken 8 years ago (Ethereal-times), so yeah in wireshark
> it's new feature ;-)
I suspect this will continue to be a source of confusion[2] since both fc and
ff are protocol abbreviations, in addition to being hexadecimal byte values, so
a filter such as the following will fail with, "Protocol ("ff") cannot appear
on right-hand side of comparison.":
data.data[13] == ff
... whereas this filter will work:
data.data[13] == ff:
I'm not sure how to avoid that except for reserving fc and ff and renaming the
fc and ff protocol abbreviations to something else.
> > ... which is not to say that other new features aren't equally cool -
> > it just so happens that a colleague of mine wanted to do this type of
> > filtering recently and couldn't ... but now he can and it greatly
> simplifies his work.
>
> Please share any interesting filters ;) (and segmentation fault
> stacks).
Well, I'm not sure how interesting this filter is to others, but this is the
filter my colleague used:
nhrp && !(nhrp.src.prot.addr == nhrp.dst.prot.addr)
RFC2332[3] indicates in section 5.2.3 that:
The NHRP Registration Request is used to register an NHC's NHRP
information with its NHSs. If an NHC is configured with the protocol
address of a serving NHS then the NHC may place the NHS's protocol
address in the Destination Protocol Address field of the NHRP
Registration Request common header otherwise the NHC must place its
own protocol address in the Destination Protocol Address field.
We found that it's better/safer to make them both source and destination the
same as it avoids potential human mistakes in entering yet another parameter in
a growing list of them. Unfortunately, the destination protocol address field
was still available for modification and sometimes when configuring the
devices, the installers mistakenly changed it to an invalid address, which can
cause huge problems in some cases depending on the invalid address used and
also due to a certain vendor's router not doing something sane with the
misconfigured packet, like discarding it, for example. The above filter allows
us to more easily spot those devices that were misconfigured.
Of course you can use tshark to pull out those fields and compare them that way
too, but I find that for many people, they tend to shy away from the
command-line tools and try to do everything in the GUI. Anyway, this makes it
more convenient, and then I don't have to waste my time explaining how to use
tshark to do this. ;)
> [1] http://anonsvn.wireshark.org/viewvc?view=revision&revision=10829
[2]:
http://ask.wireshark.org/questions/7724/problem-while-filtering-framex-ff-or-fc?page=1#7725
[3]: http://tools.ietf.org/html/rfc2332
CONFIDENTIALITY NOTICE: The information contained in this email message is
intended only for use of the intended recipient. If the reader of this message
is not the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this communication in error, please immediately delete it from
your system and notify the sender by replying to this email. Thank you.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
