|
View previous topic :: View next topic |
Author |
Message |
serverteam
Joined: 28 Jun 2010 Posts: 6
|
Posted: Mon Jun 28, 2010 1:46 pm Post subject: URL Request test works intermittently |
|
|
I have configured a URL Request test to test a website's URL. This site is internal to the Hostmon server (they are on the same network, gigabit) and response times are very fast (less than a second or so). When I specify a timeout period of say 45 seconds, I can get the to fail every few tests or more. When I specify to use default Windows time-out, however, I can never get the test to fail with no response.
When I do specify a time-out of say 45 seconds and I manually refresh the test, I do notice that when it fails, it fails almost immediately. It is as if it got a response, but was unable to parse it. Never does it seem to actually take 45 seconds to fail. I have tried to set the time-out really high, say 600 seconds, and I get the same results.
HostMon Version: 8.02
URL Request does test for contents, should contain one word. Nothing special. It is an https URL test and does allow code 302 redirects. |
|
Back to top |
|
|
KS-Soft
Joined: 03 Apr 2002 Posts: 12795 Location: USA
|
Posted: Mon Jun 28, 2010 1:56 pm Post subject: |
|
|
Could you please explain what exactly means "fail"? What is test status? No answer? Bad? Unknown? Bad contents?
What Windows do you use? Service Pack? IE version?
Regards
Alex |
|
Back to top |
|
|
serverteam
Joined: 28 Jun 2010 Posts: 6
|
Posted: Mon Jun 28, 2010 1:58 pm Post subject: |
|
|
The status is 'No answer'.
Running Windows Server 2003 Web Edition SP2 R2 with IE 7. |
|
Back to top |
|
|
serverteam
Joined: 28 Jun 2010 Posts: 6
|
Posted: Tue Jun 29, 2010 8:38 am Post subject: |
|
|
I took the liberty of performing a packet capture on the hostmon server to see if I could see what was going on. In each case, success or failure, the TCP stream was identifiable. For instance the below packet capture is an exchange when hostmon reported 'No answer'. Each time I got a 'No answer', the packet exchange look like the following.
Code: |
No. Time Source Destination Protocol Info
2 3.576499 192.168.0.5 192.168.0.100 TCP nav-port > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
3 3.576630 192.168.0.100 192.168.0.5 TCP https > nav-port [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
4 3.576643 192.168.0.5 192.168.0.100 TCP nav-port > https [ACK] Seq=1 Ack=1 Win=65535 Len=0
5 3.577098 192.168.0.5 192.168.0.100 TLSv1 Client Hello
6 3.577399 192.168.0.100 192.168.0.5 TLSv1 Server Hello, Certificate, Server Hello Done
7 3.577985 192.168.0.5 192.168.0.100 TLSv1 Client Key Exchange, Change Cipher Spec, Finished
8 3.580416 192.168.0.100 192.168.0.5 TLSv1 Change Cipher Spec, Finished
9 3.581985 192.168.0.5 192.168.0.100 HTTP GET /index.cfm HTTP/1.1
10 3.585461 192.168.0.100 192.168.0.5 SSL [SSL segment of a reassembled PDU]
11 3.585586 192.168.0.100 192.168.0.5 TCP [TCP segment of a reassembled PDU]
12 3.585605 192.168.0.5 192.168.0.100 TCP nav-port > https [ACK] Seq=438 Ack=3292 Win=65535 Len=0
13 3.585624 192.168.0.100 192.168.0.5 TCP [TCP segment of a reassembled PDU]
14 3.585637 192.168.0.100 192.168.0.5 TCP [TCP segment of a reassembled PDU]
15 3.585647 192.168.0.5 192.168.0.100 TCP nav-port > https [ACK] Seq=438 Ack=6212 Win=64915 Len=0
16 3.585660 192.168.0.5 192.168.0.100 TCP [TCP Dup ACK 15#1] nav-port > https [ACK] Seq=438 Ack=6212 Win=64915 Len=0
17 3.585741 192.168.0.100 192.168.0.5 TCP [TCP segment of a reassembled PDU]
18 3.585754 192.168.0.100 192.168.0.5 SSL [SSL segment of a reassembled PDU]
19 3.585767 192.168.0.5 192.168.0.100 TCP nav-port > https [ACK] Seq=438 Ack=7836 Win=65535 Len=0
20 3.585782 192.168.0.100 192.168.0.5 TCP https > nav-port [FIN, ACK] Seq=7836 Ack=438 Win=63803 Len=0
21 3.585796 192.168.0.5 192.168.0.100 TCP nav-port > https [ACK] Seq=438 Ack=7837 Win=65535 Len=0
|
Below is what an exchange looked like when it saw that the host was alive. The stream always looked like this when I set the time-out to use the windows time-outs.
Code: |
No. Time Source Destination Protocol Info
42 10.597455 192.168.0.5 192.168.0.100 TCP ovsam-d-agent > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
43 10.597841 192.168.0.100 192.168.0.5 TCP https > ovsam-d-agent [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
44 10.597855 192.168.0.5 192.168.0.100 TCP ovsam-d-agent > https [ACK] Seq=1 Ack=1 Win=65535 Len=0
45 10.598301 192.168.0.5 192.168.0.100 TLSv1 Client Hello
46 10.598791 192.168.0.100 192.168.0.5 TLSv1 Server Hello, Certificate, Server Hello Done
47 10.599371 192.168.0.5 192.168.0.100 TLSv1 Client Key Exchange, Change Cipher Spec, Finished
48 10.601791 192.168.0.100 192.168.0.5 TLSv1 Change Cipher Spec, Finished
49 10.603369 192.168.0.5 192.168.0.100 HTTP GET /index.cfm HTTP/1.1
50 10.606415 192.168.0.100 192.168.0.5 SSL [SSL segment of a reassembled PDU]
51 10.606545 192.168.0.100 192.168.0.5 TCP [TCP segment of a reassembled PDU]
52 10.606563 192.168.0.5 192.168.0.100 TCP ovsam-d-agent > https [ACK] Seq=438 Ack=3292 Win=65535 Len=0
53 10.606580 192.168.0.5 192.168.0.100 TCP ovsam-d-agent > https [RST, ACK] Seq=438 Ack=3292 Win=0 Len=0
54 10.606604 192.168.0.100 192.168.0.5 TCP [TCP segment of a reassembled PDU]
55 10.606624 192.168.0.5 192.168.0.100 TCP ovsam-d-agent > https [RST] Seq=438 Win=0 Len=0
56 10.606642 192.168.0.100 192.168.0.5 TCP [TCP segment of a reassembled PDU]
57 10.606654 192.168.0.5 192.168.0.100 TCP ovsam-d-agent > https [RST] Seq=438 Win=0 Len=0
58 10.606759 192.168.0.100 192.168.0.5 TCP [TCP segment of a reassembled PDU]
59 10.606778 192.168.0.5 192.168.0.100 TCP ovsam-d-agent > https [RST] Seq=438 Win=0 Len=0
60 10.606805 192.168.0.100 192.168.0.5 SSL [SSL segment of a reassembled PDU]
61 10.606814 192.168.0.5 192.168.0.100 TCP ovsam-d-agent > https [RST] Seq=438 Win=0 Len=0
|
If the time-out was set to use a defined time-out (i.e., 45 seconds) then I would get the sessions that looked like the first code block when it failed (No answer) and sessions like the second code block when it succeeded. Again, when I changed to use the windows time-out, it consistently succeeded and all sessions looked as they do in the second code block.
Note, I used the latest version of Wireshark (1.2.9) and used it's ability to decrypt the SSL stream to produce the packet captures that you see. If you need any more information, let me know. |
|
Back to top |
|
|
KS-Soft
Joined: 03 Apr 2002 Posts: 12795 Location: USA
|
Posted: Tue Jun 29, 2010 12:13 pm Post subject: |
|
|
We rechecked and tested our code - no mistake there.
HostMonitor uses Windows winhttp.dll for HTTPS protocol so may be there is some mistake in Windows API.
We will try to find some information about this problem...
Regards
Alex |
|
Back to top |
|
|
KS-Soft
Joined: 03 Apr 2002 Posts: 12795 Location: USA
|
Posted: Wed Jun 30, 2010 12:05 pm Post subject: |
|
|
We tested several HTTPS servers on Windows Server 2003 R2 with IE 7 and we cannot reproduce the problem.
What version of winhttp.dll is installed on your system?
Do you have installed some antivirus monitors, personal firewall, content monitoring software? Non stanard winsock components?
Does it happens with single web server or you see the same problem with several servers?
Regards
Alex |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|