https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4891
Jim Young <jyoung@xxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jyoung@xxxxxxx
Summary|Autoscroll turns off in |new_packet_list: Autoscroll
|Wireshark 1.4.0rc1 |turns off in Wireshark
| |1.4.0rc1
--- Comment #3 from Jim Young <jyoung@xxxxxxx> 2010-06-20 00:17:16 PDT ---
Updated subject heading because this problem appears to be limited to the new
packet list. I could not replicate the problem with old packet list using the
steps below.
This problem only happens when a display filter is in place. If the display
filter matches all packets (in other words no packets are excluded) then the
problem will not happen. But if some packets are excluded by the display
filter then sooner or later this problem will occur when one of the excluded
packets is captured.
I used the following steps on a Windows XP workstation to reproduce the
problem:
NOTE: The following assumes that the workstation will ONLY generate ping, arp
and dchp packets during the test. Many XP workstations are very chatty and
will generate lots of crap packets which can make it harder to see what exactly
triggers the problem; but you still should be able to reproduce the problem
using the following steps.
1. Connect the ethernet port of the workstation to a standalone switch or hub
and let the machine assign itself an autoconfigured IP address (e.g. something
in the 169.254.0.0/16 range).
NOTE-1: You want the workstation to be the ONLY device that generates any
packets during this test.
2. Open three (3) copies of Wireshark and start a capture on each instance to
the same ethernet interface and enable the autoscroll feature. Two instances
will be used as controls, the third instance will be used to replicate the
problem.
3. Open two "cmd" windows.
4. In the first "cmd" window create a static ARP entry within the
autoconfigured IP range (169.254.0.0/16) for a non-existant host: e.g.
arp -s 169.254.111.111 aa-bb-cc-dd-ee-ff
5. In this same "cmd" window start a continous ping to the IP address of the
newly created static arp entry:
ping -t 169.254.111.111 -w 1
NOTE-5: This will cause the XP workstation to send ping requests to the
non-existant host at 169.254.111.111. All three instances of Wireshark should
see these ping requests. There should be NO ping replies (or ANY other type of
replies such as ICMP host unreachable or destination unreachable messages) to
the ping requests!
6. In the second "cmd" window start a second continous ping, this time to
another non-existant host within the autoconfigured IP address range
169.254.0.0/16, e.g.:
ping -t 169.254.222.222 -w 1
NOTE-6: Since there should NO arp entry for this second IP address, the
workstation will send arp request. All three instances of Wireshark should see
these arp requests.
7. In the first Wireshark instance do NOT apply any display filter.
8. In the second Wireshark instance apply one of the following display
filters:
ip || arp
or
frame
NOTE-8: The goal of step 8 is to have this instance of Wireshark have a
display filter in place but NOT exclude any packets from being displayed in the
packet-list.
9. In the third Wireshark instance apply one of the following display filters:
ip
or
arp
NOTE-9: The goal of step 9 is to have this instance of Wireshark exclude about
half of the outgoing packets from being displayed in the packet-list.
Eventually the "autoscroll" button will turn itself off in this third Wireshark
instance.
Sometimes "autoscroll" will be disabled immediately, but more likely it will
happen within minute or two. Occasionly it could take longer (perhaps 10
minutes or more) but eventually "autoscroll" will become disabled. The other
two instances of Wireshark will continue to autoscroll.
NOTE: In one test run the third instance of Wireshark crashed, but this was an
exception rather than the norm.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
