On 2013-09-04, at 2:01 AM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
> 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 '"'?
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 <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.
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe