Fixing application problems with Wireshark

After reading Jeremy Stretch’s recent blog post at Packetlife regarding a problem he managed to help resolve by analyzing the output of a traffic capture, I too thought I would share my own recent experience.

Recently the desktop support team encountered a group of clerical users who were reluctant to give up their Windows XP desktops and move to Windows 7.  The reason cited was unacceptably slow performance when using a particular business critical application on Windows 7 workstations.  This had been previously reported by a member of the clerical team but at the time that workstation was replaced back with XP which is obviously not a long-term answer.

This particular application was browser based and the ‘slowness’ only occurred when users clicked links within the application, e.g. to open customer records, or browse to a different page.  This led to speculation the problem could be related to browser incompatibility.  Some basic testing soon eliminated this possibility.  The testing also found this did not appear to be a problem on workstations belonging to network administrators, regardless of who was logged on to the workstation or who was logged into the application.

Since the problem seemed to be occurring on nearly all other standard workstations, regardless of location or subnet, I thought it might be useful to take a packet capture to help shed some light on the situation.

I installed and loaded up Wireshark and logged into the application on a suspect workstation.  I started the packet capture and entered the filter ‘ip.addr == 10.0.2.8’, the IP address of the application server.  I then attempted to replicate the issue by clicking any link within the application.  The application paused for around 4 seconds and then the page refreshed.  Jumping back to the packet capture:

If you click the screenshot above, you can see that the application server is making a NetBIOS name query directly to the client workstation 4 times, after which the page appears to load. Then I compared this to an administrators workstation which did not have the slowness problem and found that the server was not making any such requests.

I took at look at the DNS server used by the server and found that the client workstations did not have a pointer record in the reverse lookup zone.  Old XP workstations did, and lo-and-behold, machines used by administrators with static IP addresses did too.

A quick Google search tells us that “The behavior of Client not registering PTR record by default is modified prior to Windows7 (mostly during Vista time) and is the intended behavior.  The Dhcp Server is responsible for performing PTR record registration on behalf of client.” - http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/3a1c9334-54ba-4845-b7c0-ef8ce5454276.  This also helps to explain why workstations with static IP addresses were unaffected.  I put this to the test and manually created some PTR records for a couple of client workstations who were having the application problem and it was resolved straight away.

I’m guessing that a packet capture from the server would have shown a DNS lookup and then a NetBIOS name query, which in hindsight would have helped for a slightly quicker resolution.