Wireshark-bugs: [Wireshark-bugs] [Bug 658] Ethereal Filter "ip.dst == 1" (or alike) hangs Ethere
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=658
Ian Schorr <ian.schorr@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ian.schorr@xxxxxxxxx
Severity|Critical |Minor
Status|RESOLVED |REOPENED
Resolution|FIXED |
Version|0.10.14 or older |1.0.4
--- Comment #14 from Ian Schorr <ian.schorr@xxxxxxxxx> 2008-11-02 18:30:35 PDT ---
I don't believe this (at least the problem as described in #4 or #5 and several
of the duplicated bugs) is "fixed" in the latest builds.
I didn't notice this problem until my environment changed, so I can't say if it
was reintroduced, or just never "fixed".
Wireshark doesn't hang completely after typing "ip.addr==" (not sure if the bug
reporter was implying this or not), but do have the same issue Ulf mentioned.
In my environment, certain DNS queries (including all un-resolvable queries)
are forwarded to a geographically remote location, so each lookup can take a
long time (about 300ms, though much longer if there is a single packet loss).
I also have a large number of domain suffixes in to search. So a single name
lookup that scans all domains take take many seconds. Typing out a hostname
may take a minute or two (or worse).
Personally, I never filter using hostnames - always IPs. But the filter logic
appears to kick in as soon as I type the first "." in a dotted-decimal IP
address. As soon as a user enters a ".", we go off and start trying to resolve
what came before the ".". So entering in an IP filter can take 5-60 seconds
(unless I paste in a full IP address at once or do like Ulf suggested in #5).
A few things:
- I don't know how we'd avoid this for hostname entries and still allow
validation to occur. I guess one compromise might be to add logic that avoids
doing the filter evaluation until the user had stopped typing for a short time?
Maybe just for the hostname resolution?
- For IP address entries - why does entering "10" not trigger name resolution,
but "10." causes us to try to look up "10"? And entering "10.200." also does
not trigger name resolution? Perhaps that logic could/should be fixed?
- Some users, like me, never want hostname resolution done in Wireshark, ever.
As a user I expect that turning off Preferences->Name Resolution->Enable
Network Name Resolution would do this (unless there's a specific option to
override this, like some taps do). Does this sound like reasonable
expectation? Should we disable hostname lookups during filter validation if
network name resolution option is turned off (and if so, are there any other
places we do lookups where we should stop)?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
