none
Don't understand why I'm getting a "Target machine actively refused" error.

    質問

  • I've got a .NET 3.5 WCF service, using TCP, on a Windows 2003 Server.  I wrote it a few years ago, intending to finish writing a new WPF app to run against it.  Other projects and priorities took over, though, so I wasn't able to get back to it until now.  However, back then I did write some quick apps to test running against it, and they worked fine.

    Now I'm able to start tackling this, but before I do I want to write a console app to test the WCF app, using .NET 4.0.  However, I'm getting the following error:

    Error in PutAsiGeneral[Attempting to open the SvcRef client]: Could not connect to net.tcp://ourserver:9000/ASIService/. The connection attempt lasted for a time s pan of 00:00:02.0260000. TCP error code 10061: No connection could be made becau se the target machine actively refused it {ourserver-IP-address}:9000. ; InnerException: No connection could be made because the target machine actively refused it {ourserver-IP-address}:9000

    (some of the text in there is what I put it, to find out where I was in the code, etc.)

    Anyway, TCP is the correct protocol, port 9000 is the correct port.  I am not using the using statement when instantiating my client.  It is failing on the call to open the client.  There's nothing in the event log on the server telling me anything as to why it's failing.  Why is it failing?  Here's a code snipping including the Open call:

    SvrRef.Service1Client client = new SvrRef.Service1Client("tcp_ASIService");
    if (client.State == System.ServiceModel.CommunicationState.Faulted)
    {
    	client.Abort();
    }
    client.Open();	//it fails on this call
    client.SaveASIGeneral(UseProduction, ds);
    client.Close();
    


    Rod

    2012年3月6日 21:57

回答

  • Run a wireshark trace and post the results back here.  Couple of questions that the trace will answer is 1) Does port 9000 open?  2) Does the client send appropriate data?  3) Does server respond or attempt to get going?  The inner exception seems to indicate that NOT EVEN the 3 way handshake happened.  The fact the timer was 2 seconds is a good indication this side sent a RST after TCP tried to get handshake.

    JP Cowboy Coders Unite!

    • 回答としてマーク Rod at Work 2012年3月9日 21:54
    2012年3月6日 23:15

すべての返信

  • Run a wireshark trace and post the results back here.  Couple of questions that the trace will answer is 1) Does port 9000 open?  2) Does the client send appropriate data?  3) Does server respond or attempt to get going?  The inner exception seems to indicate that NOT EVEN the 3 way handshake happened.  The fact the timer was 2 seconds is a good indication this side sent a RST after TCP tried to get handshake.

    JP Cowboy Coders Unite!

    • 回答としてマーク Rod at Work 2012年3月9日 21:54
    2012年3月6日 23:15
  • I've never heard of Wireshark.  I'll download it and see what I can find out.

    Rod

    2012年3月7日 20:47
  • I've downloaded Wireshark and started to install it.  Early in the installation it informed me that it wanted me to install WinPcap.  What's that?  I know that Wireshark says the version of WinPcap on my system is old and causes it errors, but I'm very hesitate to put something onto my system that has anything to do with monitoring network communication (I've looked up WinPcap on Wikipedia).  I'd like to know what impact upgrading WinPcap will have on my system?  What else uses WinPcap?

    Rod

    2012年3月7日 21:52
  • Just take all the defaults.  WINPCAP is the magic that Wireshark uses to monitor network traffic.  Nothing else uses it that I know...  I've been using Wireshark for about 15 years now (pre wireshark era when it was Etherreal) with NO PROBLEMS at all.

    Once you start it up go to Capture/Interfaces and pick the interface where the traffic is going outbound.  Then recreate the error and stop the trace.  Determine the destaination IP address find it in the trace and right click on that packet and choose Follow TCP Stream.  That will be the entire conversation.


    JP Cowboy Coders Unite!

    • 回答としてマーク Rod at Work 2012年3月9日 21:54
    • 回答としてマークされていない Rod at Work 2012年3月9日 21:54
    2012年3月7日 22:49
  • An alternative to Wireshark is Fiddler. It does the same as WireShark. 

    Just make sure that your windows service is up and running. Also try to enable tracing on your service to know the exact detail on why your service is failing. Even if there is some error when using TCP you get the same error.


    Rajesh S V

    2012年3月8日 9:11
  • An alternative to Wireshark is Fiddler. It does the same as WireShark. 

    Just make sure that your windows service is up and running. Also try to enable tracing on your service to know the exact detail on why your service is failing. Even if there is some error when using TCP you get the same error.


    Rajesh S V

    I've tried using Fiddler, but unless I'm mistaken Fiddler is only for HTTP.  Since I'm using TCP in this instance, it appears to me as though it won't work.

    BTW, I've turn tracing on, at the server, but as far as I know, it doesn't show me anything.  On the other hand, I really don't know what I would look for in the trace log, so I could be missing it.


    Rod

    2012年3月8日 16:59
  • Does it show anything in the trace file or is it empty. You can use the SVCTraceViewer to inspect the trace file.

    Also make sure that no other service or program is using port 9000.


    Rajesh S V

    2012年3月8日 17:17
  • Hi,

    Can you publish your config file and i don't think you need to call Open and Close methods from client proxy.

    SvrRef.Service1Client client = new SvrRef.Service1Client("tcp_ASIService");
    client.SaveASIGeneral(UseProduction, ds);

    Try this code it should work fine if the configuration is proper.


    Welcome to MSDN Forums. Feel free to ask your questions and Please Note to Vote helpful topics and Mark answering posts. Sudhakar

    2012年3月8日 17:52
  • Just take all the defaults.  WINPCAP is the magic that Wireshark uses to monitor network traffic.  Nothing else uses it that I know...  I've been using Wireshark for about 15 years now (pre wireshark era when it was Etherreal) with NO PROBLEMS at all.

    Once you start it up go to Capture/Interfaces and pick the interface where the traffic is going outbound.  Then recreate the error and stop the trace.  Determine the destaination IP address find it in the trace and right click on that packet and choose Follow TCP Stream.  That will be the entire conversation.


    JP Cowboy Coders Unite!

    OK, I've gone ahead and installed Wireshark and updated WinPcap.  I brought up my test app in VS 2010 and started a trace with Wireshark.  It took me a little while to figure out how to find the relevant IP address in the trace to do I right client on it to choose to follow the TCP stream, but I finally did.  Now, I'm lost.  I am no expert at networking stuff; I have no idea what this stuff is telling me.  I saved that followed TCP stream to a .pcap file, and opened it with Notepad++.  I found that it is a binary file, so I've no idea how I could possibly post the results to this forum.  From my limited understanding of what I think this is telling me, here's what I've found:

    • Looks like  there is communication going on between my desktop and the Windows 2003 Server.  I see both IP addresses listed in the trace.
    • I'm not sure what the datetime order is, but I'm assuming that what's on the top is older than what's at the bottom.  If that's the case, then what's at my machine (IP address ..128.178) is sending some message to the server (IP address..128.60).  There's some red lines in the bottom pane in Wireshark.  Red means "warning" to me, so I'm looking at those.  They say, "Expert Info (Error/Checksum): Bad checksum".  Just up from that in the bottom pane, it says, "Header checksum: 0x0000 [incorrect, should be 0xdbb8 (maybe caused by 'IP checksum offload'?)]".  I've no idea what a "IP checksum offload" is.
    • There's some confusing stuff here.  It also says, "[Good: False]" and "[Bad: True]".  Huh?  I would think that "Good" is always true and "Bad" is always false.  Furthermore, why is "Good" and "Bad" even mentioned here?  What's that got to do with anything?
    • Under that line in red, there's a line in blue (does that mean it's OK?), which says, "Transmission Control Protocol, Src Port: 55866 (55866), Dst Port: cslistener (9000), Seq: 0, Len: 0".  Well, I am trying to communicate with port 9000 via TCP on the server, so does this mean that's working OK?
    • The next line, which has a source of ..128.60 (the server port 9000) and a destination of ..128.178 (my PC port 55866), there's no red lines, so I'm thinking that's OK.
    • The 3rd line is from my PC to the server, and it's got red lines.  All that "Bad checksum" stuff.
    • 4th line from the server to my PC, no red lines.
    • 5th line from my PC to the server, red lines, that "Bad checksum" stuff.
    • 6th line from the server to my PC, no red lines.

    And that's it; just 6 lines in that follow TCP stream trace.


    Rod

    2012年3月8日 18:02
  • Ok open the PCAP file back up in Wireshark.

    Each line is a packet and each line contains information for the coversation.  Here's an example:

    This trace is showing a converstation between two machines.  Typically you will see converstation start with SYN, [SYN,ACK], ACK  this starts the communication, from there everything is considered to be "In Session". When sessions end you will see either a FIN or RST in the INFO column. So which side sends the FIN or RST first? How long did the session last?  The error message above states the Target machine actively refused that connection...  I'm guessing you will see the FIN and or RST from the target machine first.  Each packet contains data, do you see any data your recognize?


    JP Cowboy Coders Unite!

    2012年3月8日 19:35
  • OK, looking back at the trace I captured, there's 6 records total; 3 from my machine trying to talk to the server, and 3 responses back from the server to my machine.  Here's what they are:

    My machine is doing the SYN 3 times.  The server responses to RST, ACK each time.


    Rod

    2012年3月8日 20:13
  • Ok because the three way handshake never starts this is a problem on the machine sending the RST back to you.  REASON: If your WCF endpoint configurations are correct, this should never happen.  What it's saying to you is "Go Home" I don't have any ports opened for this.  Espeicially when the reply is just a matter of a few milliseconds. 

    First make sure your configuration is correct for WCF endpoints.   This means that in VS2010 you should be able to add the service reference and test if first for the client side.  If you can't do that you don't have configs set up.

    Second, if you think it is a server side issue it probably means that the deployed WCF host service is also not confirured correctly. 

    And yes it is difficult to get a WCF client/host application that works perfectly in VS2010 deployed.  I think that's your problem. 


    JP Cowboy Coders Unite!

    2012年3月8日 23:39
  • All right, I finally got it fixed.  WooHoo!!  I hope you don't mind my boring you all to death with this, but I'll tell you what I found.

    The reason why the WCF service wasn't listening on port 9000 on the server, was because it wasn't running in the server's Services.  I'd forgotten this fact, but you have to take an extra step when dealing with a Windows 2003  or 2003 R2 Server.  You've got to use the InstallUtil.exe utility to install the Windows service which hosts the WCF service, which I was doing.  The step I'd forgotten about was going into the Windows Services applet and actually starting the service.  (Man, I wish we had Windows 2008 R2 servers here, then I could just put this into IIS and not worry about it.  Oh well.)

    After that there was another problem, but that was an easy fix, so now the WCF service is up and running, I can call it and it saves data fine.  Life's good.


    Rod

    2012年3月9日 21:54
  • Yipee!  who say's us cowboy coders can't do jack?  Good luck Rod at Work.

    JP Cowboy Coders Unite!

    2012年3月9日 23:12