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=51742 >>> >>> 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 > > -- > Joerg Mayer <[email protected]> > We are stuck with technology when what we really want is just stuff that > works. Some say that should read Microsoft instead of technology. > ___________________________________________________________________________ > 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
