Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 51742: /trunk/epan/dissectors/ /trun
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: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] 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 <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=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.
