Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 43069: /trunk/epan/dfilter/ /trunk/e
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-
> bounces@xxxxxxxxxxxxx] 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.
