Wireshark-bugs: [Wireshark-bugs] [Bug 2527] Display filter should accept alternate IPv4 address
Date: Wed, 7 May 2008 23:25:07 -0700 (PDT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2527


Stephen Fisher <stephentfisher@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|Minor                       |Enhancement
         OS/Version|Windows XP                  |All
           Platform|PC                          |All
            Summary|Numeric IP addresses not    |Display filter should accept
                   |interpreted correctly       |alternate IPv4 address
                   |                            |formats




--- Comment #3 from Stephen Fisher <stephentfisher@xxxxxxxxx>  2008-05-07 23:25:06 GMT ---
(In reply to comment #0)
> Numeric IP addresses in the Display Filter are not processed correctly.
> Entering an address of 10.3 for example will not work.

The display filter is correctly processing IP addresses per the current design
of Wireshark, so I am changing this to an enhancement request and changing the
title to more accurately reflect the issue.

> Apparently, you are not using the standard conversion functions which have been
> in existence since the inception of the BSD networking code. These functions
> provide a rich format for IP address-compliant input.
>
> These functions are inet_aton() and the functional equivalent inet_addr(). 

You are correct in that we do not use those functions to convert exotic IPv4
address formats to standard format before turning them into single 32-bit
integers for comparison.

> These provide the proper interpretation of each dotted component, allow varying
> numeric formats and understand the short forms such as used in 10.3,
> 10.16000010,  172.16.3824, 172.16.65001, 10.0x3d10b or 0xac.16.5 for example.
> It will even allow for the most simplified format of a single hex number such
> as 0x7b3d9e13.
>
> So, please use these standard conversion functions and allow us the freedom to
> use these powerful and efficient input formats. 

I must say that in my 13 years of networking experience, I've never seen
someone use formats other than x.x.x.x for IPv4 addresses other than in a spam
e-mail to disguise a site's address (and that died off years ago).

> Obviously the change is trivial since it means the removal of whatever you do now and replace it with 
> a single call to inet_aton().

it isn't so trivial - we also need to update the display filter syntax checking
engine for IPv4 addresses to accept these other formats as valid.


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.