KS-Soft. Network Management Solutions
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister    ProfileProfile    Log inLog in 

URL Request test works intermittently

 
Post new topic   Reply to topic    KS-Soft Forum Index -> Bug reports
View previous topic :: View next topic  
Author Message
serverteam



Joined: 28 Jun 2010
Posts: 6

PostPosted: Mon Jun 28, 2010 1:46 pm    Post subject: URL Request test works intermittently Reply with quote

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
View user's profile Send private message
KS-Soft



Joined: 03 Apr 2002
Posts: 12792
Location: USA

PostPosted: Mon Jun 28, 2010 1:56 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
serverteam



Joined: 28 Jun 2010
Posts: 6

PostPosted: Mon Jun 28, 2010 1:58 pm    Post subject: Reply with quote

The status is 'No answer'.

Running Windows Server 2003 Web Edition SP2 R2 with IE 7.
Back to top
View user's profile Send private message
serverteam



Joined: 28 Jun 2010
Posts: 6

PostPosted: Tue Jun 29, 2010 8:38 am    Post subject: Reply with quote

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
View user's profile Send private message
KS-Soft



Joined: 03 Apr 2002
Posts: 12792
Location: USA

PostPosted: Tue Jun 29, 2010 12:13 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
KS-Soft



Joined: 03 Apr 2002
Posts: 12792
Location: USA

PostPosted: Wed Jun 30, 2010 12:05 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    KS-Soft Forum Index -> Bug reports All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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

KS-Soft Forum Index