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 '"'?
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
