Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 51742: /trunk/epan/dissectors/ /trun
On Tue, Sep 03, 2013 at 03:30:44PM -0700, Guy Harris wrote:
>
> On Sep 3, 2013, at 2:20 PM, cmaynard@xxxxxxxxxxxxx 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 '"'?
ciao
Jörg
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
