Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Have an external website which opens fine on some PC's, yet seems to time out (or symptoms of timing out, but never actually does) on others.

Seems to only affect (some) of our newer HP Pro 3305 MT Workstations. All of which are running Win7 32bit SP1 with all updates. Older PC's (Win7 32bit SP1 & WinXP) are unaffected.

Using Google Chrome & Firefox makes no difference. Opening the website in IE9 Compatibility Mode has exactly the same symptoms.

All PC's are on the same local network (Workgroup) using the same DNS server & gateway (inhouse) on the same internet connection, on the same subnet. There is no proxy server, no content filtering, no load balancing etc etc. Only group policy in effect (locally) is for Update scheduling. Local firewalls are all the same (Kaspersky WP4) and our external facing firewall has no IP specific settings.

I have no control over the external website, traceroute shows the same destination on all PC's. It is a fairly popular website in our industry (Horticulture) and i'm not aware of any other people (even other sites within our sister companies) with the same problem.

Update: Used Fiddler2 to monitor the HTTP request, seems its not getting fulfilled for some reason?!

Request sent:

GET http://www.rhs.org.uk/ HTTP/1.1
Host: www.rhs.org.uk
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Log from Fiddler 2 of the request:

This session is not yet complete. Press F5 to refresh when session is complete for updated statistics.

Request Count:   1
Bytes Sent:      567        (headers:567; body:0)
Bytes Received:  0      (headers:0; body:0)

ACTUAL PERFORMANCE
--------------
ClientConnected:    17:02:33.720
ClientBeginRequest: 17:02:39.118
GotRequestHeaders:  17:02:39.118
ClientDoneRequest:  17:02:39.118
Determine Gateway:  0ms
DNS Lookup:         0ms
TCP/IP Connect: 46ms
HTTPS Handshake:    0ms
ServerConnected:    17:02:39.165
FiddlerBeginRequest:    17:02:39.165
ServerGotRequest:   17:02:39.165
ServerBeginResponse:    00:00:00.000
GotResponseHeaders: 00:00:00.000
ServerDoneResponse: 00:00:00.000
ClientBeginResponse:    00:00:00.000
ClientDoneResponse: 00:00:00.000


RESPONSE BYTES (by Content-Type)
--------------
~headers~:  0

Log of a successful request from a working PC (done this morning, excuse the timestamps being different from above):

Request Count:   1
Bytes Sent:      493        (headers:493; body:0)
Bytes Received:  20,413     (headers:525; body:19,888)

ACTUAL PERFORMANCE
--------------
ClientConnected:    08:22:47.766
ClientBeginRequest: 08:22:47.766
GotRequestHeaders:  08:22:47.766
ClientDoneRequest:  08:22:47.766
Determine Gateway:  0ms
DNS Lookup:         26ms
TCP/IP Connect: 30ms
HTTPS Handshake:    0ms
ServerConnected:    08:22:47.828
FiddlerBeginRequest:    08:22:47.828
ServerGotRequest:   08:22:47.828
ServerBeginResponse:    08:22:48.905
GotResponseHeaders: 08:22:48.905
ServerDoneResponse: 08:22:48.905
ClientBeginResponse:    08:22:48.905
ClientDoneResponse: 08:22:48.905

    Overall Elapsed:    00:00:01.1388020

RESPONSE BYTES (by Content-Type)
--------------
text/html:  19,888
~headers~:  525

So my question has evolved into:

What is the difference between the 2 requests and how do I determine why 1 PC is not getting a reply to it's GET request?

Update 2:

See my answer below. I may well accept it in the future, but without being able to reproduce the problem (or the fix) I'd like to leave this question open.

share|improve this question
    
Do you have some HP 3305's that ARE working normally or are they all exp. the problem? –  Paul Ackerman Jul 6 '12 at 11:37
    
I've seen MTU problems cause errant surfing behavior but this would likely only occur over a WAN link - not on the same subnet. Still it is the only time I have seen such behavior so I thought I'd mention it in case you're using a smaller MTU and the new boxes didn't get the memo. –  Paul Ackerman Jul 6 '12 at 11:52
    
I have 2 that are working, 4 that are not... The 2 that are working were purchased a month prior to the others which were all from the same order/date... All of them I setup the exact same way?! –  HaydnWVN Jul 6 '12 at 11:53
    
I'd see ping/DNS problems with anything MTU related wouldn't I? –  HaydnWVN Jul 6 '12 at 11:54
1  
I'm going to throw a bit of insider information into the mix here. I'm one of the devs in the online team at the RHS (the team that looks after the main website). About once every couple of months or so we get a request like this and try to fix it, but the user generally stops responding before we find out what's going on. I'm 99% sure it's a Windows 7 issue, but other than that we're stumped. –  Piers Karsenbarg Aug 6 '12 at 13:58

7 Answers 7

If you want to know the difference in the HTTP GET request, download the ZAP (Zed Attack Proxy) from OWASP or some other proxy that will allow you to inspect each packet before it is sent to the server. This will answer the question of "what is the difference between the 2 requests".

If the requests are the same try another NIC.

Most likely your NIC is on-board. Try installing a PCI NIC with appropriate drivers and see if you can get there. Sounds like hardware/driver issue at this point.

share|improve this answer
    
I can't figure out how to use ZAP to monitor HTTP GET requests. Don't have alot of time to 'fix' this as my work-around is quite a popular 'fix' at the moment! –  HaydnWVN Jul 30 '12 at 10:36

I've never used Fiddler before, but based on the "ServerGotRequest" being un-set in the failure scenario implies one of three things:

  1. The server hasn't received the full request from the workstation (i.e. the HTTP GET hasn't completed)
  2. The server received the request but didn't reply due to an error or other problem on the sever.
  3. The server replied, but the reply packet didn't make it back.

I know this is a hosted server, do you have access to look at server logs or the ability to run a sniffer on it (i.e. WireShark) to capture data while you're testing? If so, watch the server log files for any errors, and run the sniffer until you get a failure scenario at the workstation then look and see if the server received the full response and tried to respond.

After that, check the Kapersky firewall logs to see if it dropped any packets. Is it possible to setup a sniffer in front of the firewall and see if the response from the server is making it back that far? If it makes it to the firewall, and Kaspersky doesn't note dropping anything it's probably safe to assume it made it through.

During these tests, I'd suggest running WireShark on one of the machines that fails. It will show the out-bound connections, plus it should also show any responses the NIC receives. If it is a NIC issue, the sniffer trace should show the packet being received and from there you can determine if that warrants a NIC and/or driver update.

Since you are unable to attach a sniffer to the outside of your firewall, you'll need to work with your ISP to have them setup monitoring for the packets leaving your router, but never receiving a response.

Once the ISP has confirmed or refuted your hypothesis about where the packets are going, there are two options: Option 1: The packet makes it to the firewall but does NOT go out to the ISP during a failed web connect attempt. Option 2: The packet makes it through the firewall onto the ISP network, but the response never comes.

Option 1 might be easiest to replace and/or re-install the firewall if possible. If it is an ISP provided device, you'll want to have them save the current config but apply a very basic configuration on the new system to ensure it's not a configuration related problem.

Option 2 would be nice because it puts the problem on them to fix, but if they don't have the time to look into it then you're stuck with their answer. In this case, it could be that it leaves their network and goes out to their Internet provider - that gets into a whole other can of worms trying to track down where a packet died.

share|improve this answer
    
Wireshark shows the GET request leaving the machine, but the machine never gets anything in reply. Odd thing is that it doesn't time out either?! I have no access to the webserver, it's not mine! It's just a website that some users occasionally need access to! –  HaydnWVN Aug 6 '12 at 16:16
    
So, if you put a WireShark sniffer outside your firewall do you see the GET request going out? If not, then your problem is internal and just needs to be tracked down. If it goes out, then you'll need to work with your ISP and hope they will work with you. –  dan_linder Aug 7 '12 at 17:01
    
I can't monitor the outgoing data outside the firewall as it's built into our router. We only have the 1 connection. Why would I need to work with my ISP? All GET requests (successful and unsuccessful) are over the same connection, on the same external facing IP to the same destination IP. This isn't a routing issue. –  HaydnWVN Aug 8 '12 at 13:49
    
I agree that it doesn't look like a routing issue, but it's quite possible that it's a packet dropping issue. By using a packet sniffer on the outside of the firewall you can show that the GET requests that ultimately fail did leave the network. You would then have some data points to prove that it's not a problem on your network. –  dan_linder Aug 9 '12 at 20:37
    
If this were the case wouldn't we see odd behaviour with other sites/e-mails going missing and corrupt data? This website is the only one with an issue. –  HaydnWVN Aug 10 '12 at 9:07

Can you confirm if the nic in working machines versus non-working are the same make/model. Also could you confirm that your ipv6 is the same on all machines (on an internal lan I would disable ipv6 altogether). Also as a last check - ensure that there is nothing in the host file that might stop network access (c:\windows\drivers\etc)

The fact that you have ruled out the browser and the hardware (using a live cd) leaves me to think it must be network adapter related.

If all this fails - definitely swap hard disks and see if the problem follows the hard disk or the nic.

share|improve this answer
    
Machines are exactly the same. IP6 has no settings/is disabled (not sure which). Hosts file is empty. –  HaydnWVN Jul 10 '12 at 16:05
    
Did you try swapping the disks? –  PJ42 Jul 11 '12 at 8:56
    
Not yet, these are live machines and using an online (free) web proxy (which i've done as a 'fix') may end up being my solution. It's only 1 website, albeit a regularly visited one. –  HaydnWVN Jul 11 '12 at 16:00
    
Should have asked this before - do you use an internet proxy? If so can you confirm that the same user accounts and being used? –  PJ42 Jul 12 '12 at 13:59
    
As mentioned in my original post - no proxy. –  HaydnWVN Jul 13 '12 at 9:03

I would compare the netmasks and gateway addresses on the problematic systems and compare this to the working systems.

I have seen the problem before and this was the cause -- a wrong (but still somewhat working) gateway address.

share|improve this answer
    
All are the same (ie correct). We only have 1 gateway here and use 255.255.0.0 as subnet mask. Your answer doesn't explain why it should only happen on this 1 website (all others are ok) without any errors. –  HaydnWVN Jul 10 '12 at 16:06
    
Did you check the IP settings of the web server? –  jftuga Jul 10 '12 at 17:04
1  
The web server/host site is totally out of my control. Both machines DNS results for the address resolve to the same destination IP. –  HaydnWVN Jul 11 '12 at 15:58

Start with the basics - you've got two different series of machines that likely have two different series of NIC's. Are both sides set for autonegotiation and, if so, are they agreeing on the appropriate speed? Try hard-coding both sides as an experiment to see if it improves at all (..or if it's hard-coded on either side currently then let both sides negotiate).

share|improve this answer
1  
It's not a hardware issue. Not sure what it is, but it's definitely not that. –  Piers Karsenbarg Aug 6 '12 at 14:24
    
So you've confirmed that the counters on the switch port aren't showing any kind of errors? –  rnxrx Aug 6 '12 at 14:28
    
Hard-coding? Counters on the switch? Elaborate please! –  HaydnWVN Aug 6 '12 at 16:14
    
My comments have to do with the Ethernet switch you're using. If you're able to look at the counters for various errors you may find that the machines in question are seeing these counters rising. This would be indicative of an issue with the configuration of the network interfaces. –  rnxrx Aug 6 '12 at 17:35
    
It's a basic unmanaged switch with no interface for me to check anything like that. What kind of network configuration? And why would it only be with 1 site and nothing else? –  HaydnWVN Aug 7 '12 at 8:50

There's a big gap between

ClientConnected:    17:02:33.720

...and...

ClientBeginRequest: 17:02:39.118

Either you are losing packets or the client side security software is broken. It's trivial to test the former with Wireshark - and even if you don't see packet less (retransmits) you can determine the directionality of the injected latency.

share|improve this answer
    
Will test further, any ideas why this would only be happening with 1 website and nothing else? –  HaydnWVN Aug 7 '12 at 8:49
    
No lost packets from any machines (affected and unaffected). The gap between the Connect and BeginRequest can be anything between 3-9 seconds on either type of PC. What do you mean by "the client side security software is broken"? As I can control/fix that! Any idea what may be broken? –  HaydnWVN Aug 8 '12 at 13:45
    
If you can get the same results with different browsers on affected machines, then this would demonstrate that its you firewall / security software causing the problem - try un-installing it (or better yet a fresh install without the software). –  symcbean Aug 8 '12 at 23:55
up vote 0 down vote accepted

As of this morning this issue is 'fixed'.

I have worked (via email) with Piers Karsenbarg on several different avenues of resolution, all to no avail. Nothing has been changed on the website and nothing has been changed on the machines - except some Windows Updates. Can't thank Piers enough for getting involved with the problem and spending lots of his quality time trying to resolve it!

Piers linked me to this which has all the symptoms (but none of the causes) on these machines in question (ie no Type 1 fonts). But it is possible a Windows Update (or some Adobe update) fixed the issue - I'm thinking replaced or removed the Type 1 fonts . Further information can be found here and here.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.