I'll take a look. Gilbert
On Wed, Sep 4, 2013 at 8:04 AM, Maynard, Chris < [email protected]> wrote: > Good ideas! > > I haven't dug too deeply into the display filter logic yet though, so if > someone more familiar with it than I am would like to implement it, then > please do. These new filters could then be removed. > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Evan Huus > Sent: Wednesday, September 04, 2013 6:55 AM > To: Developer support list for Wireshark > Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 51742: > /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-eth.c > packet-ieee80211.c > > On 2013-09-04, at 2:01 AM, Joerg Mayer <[email protected]> wrote: > > > On Tue, Sep 03, 2013 at 03:30:44PM -0700, Guy Harris wrote: > >> > >> On Sep 3, 2013, at 2:20 PM, [email protected] wrote: > >> > >>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=517 > >>> 42 > >>> > >>> User: cmaynard > >>> Date: 2013/09/03 02:20 PM > >>> > >>> Log: > >>> Similar to the IPv4 dissector's hf_ip_dst_host, hf_ip_src_host and > hf_ip_host fields, add to the Ethernet dissector: > >>> > >>> hf_eth_dst_resolved > >>> hf_eth_src_resolved > >>> hf_eth_addr_resolved > >> > >> Would it make sense to allow address types (FT_IPv4, FT_IPv6, FT_ETHER, > etc.) to be treated either as strings representing the host name *or* as > IP/MAC/etc. addresses, with the context indicating which is used? > > > > This sounds right - it would remove the generated/hidden fields and a > > separate filter name to remember. > > > >> E.g. > >> > >> ip.src == 127.0.0.1 > >> > >> would test the "IP address" version of the value, whereas > >> > >> ip.src contains "local" > >> > >> would test the "host name" version of the value? > >> > >> ip.src == localhost > >> > >> is perhaps ambiguous (depending on whether you consider localhost a > string or not), but I'd handle that one as an address comparison. > >> > >> ip.src contains 7f:00 > >> > >> would probably test the "IP address" version (byte string vs. character > string). > > > > To make this unambigous, how about doing namecomparison first if the > > value is in '"', while doing nameresolution first if without '"'? > > If I recall correctly the dfilter syntax already supports function > notation. How about just adding a resolve(field) function that produces the > name for comparison, otherwise it uses the address? > > > ciao > > Jörg > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 >
___________________________________________________________________________ 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
