Wireshark-bugs: [Wireshark-bugs] [Bug 658] Ethereal Filter "ip.dst == 1" (or alike) hangs Ethere
Date: Sun, 2 Nov 2008 18:30:37 -0800 (PST)
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.
- Prev by Date: [Wireshark-bugs] [Bug 1827] problem with accentuated letters
- Next by Date: [Wireshark-bugs] [Bug 658] Ethereal Filter "ip.dst == 1" (or alike) hangs Ethereal...
- Previous by thread: [Wireshark-bugs] [Bug 3025] ASN.1: display the real name of SEQUENCE/TYPE OF parameters
- Next by thread: [Wireshark-bugs] [Bug 658] Ethereal Filter "ip.dst == 1" (or alike) hangs Ethereal...
- Index(es):
- Get Wireshark
- Download
- Code of Conduct