'No connection could be made because the target machine actively refused it' - c#

I am working on a 'Smart Device Project' using .Net Framework 3.5. I am trying to connect to some Java SOAP services on a remote server.
In order to do that, I added 'Web References' to my project.
When I try to call my web service I get a WebException 'Unable to connect to the remote server' with the inner exception being 'No connection could be made because the target machine actively refused it'.
I searched quite a lot on the Web and StackOverflow and found a lot of ASP configuration and 'Unavaliable port' answers, but as I have another application using the exact same Service successfully, I can't get why the new one isn't getting through (It did sometimes through my tests so I suppose my client implementation isn't that bad)
I tried to look if there was some connection issue on the port by using some TcpClient:
System.Net.Sockets.TcpClient client = new System.Net.Sockets.TcpClient();
try
{
client.Connect("myServerName", 8087);
MessageBox.Show("Success");
} catch (Exception ex)
{
MessageBox.Show("Failure");
}
finally
{
client.Close();
}
This connection succeed.
Here is a sample on how I call my WebService:
WSServiceExtended srv = new WSServiceExtended();
srv.Proxy = new System.Net.WebProxy();
ServeurWSI wsi = new ServeurWSI();
srv.Url = "http://myServerName:8087/myServerApp/services/myService";
wsr = srv.login(wsi);
The service is called 'Extended' because I overrided the auto-generated one in order to add Cookie managment since I am using the Compact Framework. Following the sample in this thread:
https://social.msdn.microsoft.com/Forums/en-US/34d88228-0b68-4fda-a8cd-58efe6b47958/no-cookies-sessionstate-in-compact-framework?forum=vssmartdevicesvbcs
EDIT:
I made some new tests with the Web references and got it to work.
When I add the Web Reference, I have to put some Url to the Web Service. When I set it with the actual hostname instead of the 'localhost' everything is fine.
But then, since I set it manually to the real address just before the call, it shouldn't matter
srv.Url = "http://myServerName:8087/myServerApp/services/myService";
EDIT2:
I might have forgotten some specifics about my environnement.
The Web Services are exposed on my computer on some Tomcat Server.
The application I am working on is also developped on this computer (That's why I can add Web References by putting 'localhost' in the address)
The application is then deployed on a distant device (Windows CE) that will make calls the Web Services through WIFI (There, localhost wouldn't work then)
I tried calling the Web services from other computers successfully.
I'm beginning to think that there might be some differential between the called Url and the one that is set, otherwise, how would I have a difference in behaviour such as the one described in the first edit?
EDIT3:
Well..Seems like it's not a network issue but a .Net compact framework (usage?) issue...
The Url property of the Web Service implementation is simply ignored and the one in the Reference.cs is used in place.
If someone had some idea on how I could troubleshot this, I would really appreciate it.

That error means that you reached a server and the server said "no way". So you're either hitting the wrong server or the wrong port.
I find the telnet client is useful for testing stuff like this. From the command line, you can do:
telnet [servername] [port]
So something like:
telnet myServerName 8087
If it goes to a blank screen, then it connected successfully. If it does not connect, it'll tell you.
The telnet client is no longer installed by default in Windows 7+, so you'll have to install it. See here for instructions: https://technet.microsoft.com/en-ca/library/cc771275
If the connection does open, you could paste in an actual HTTP request to see what happens. A simple GET would look something like this:
GET /myServerApp/services/myService HTTP/1.1
Host: myServerName:8087

One reason for this error can be that the service binds to only a certain IP address. It could well be that the service only listens on the IP that is assigned to the host name, but not on the localhost IP (127.0.0.1).
For example:
If the host myServerName has the public IP 192.168.0.1, your service can choose to listen on all IPs assigned to the host (sometimes specifying 0.0.0.0), or it can specifically listen on 192.168.0.1 only. In that case you will not be able to connect through 127.0.0.1, because the service simply doesn't listen on that IP.
You can "use" this inverse of this feature to make a service accessible only to local clients, not on the public IP-Address, by listening on 127.0.0.1 only, but not on the public IP. This is sometimes used on Linux for example to make MySQL only accessible on the host itself.

I was starting to forget this post but I finally found the problem that was messing things up and it has nothing to do with programmation.
I was doing the calls while the device was connected to the computer via the 'Windows Mobile Device Center' allowing to access the device from Windows.
While connected, the host provided is ignored and all calls on the specified port are handled by the connected computer.
Disconnecting the device allows to communicate properly...

Related

WCF Relay already connected to a listener, but no listeners are connected?

I'm currently attempting to write two applications in C# - a client and a server - which connect to a WCF Relay I've got set up in Azure, but I'm getting a really strange error when I try to run either.
This is a brand new WCF Relay that I've set up which has no naming conflicts with anything else, but every time I try to open a connection to it as a listener with my service, it fails with this exception:
System.ServiceModel.AddressAlreadyInUseException:
Address sb://[MY_RELAY].servicebus.windows.net/[MY_WCF_RELAY] is already in use by an existing listener with different settings.
And when I try to run my client application connecting to the same relay URL, I get this exception:
System.ServiceModel.FaultException:
'50200: There are no listeners connected for the endpoint.
Kind of odd how there's already a listener connected, but at the same time no listeners are connected. I've even checked on the number of active connections to the relay, and it's never jumped past 0.
Anybody have any clue what might be going on here and how I could troubleshoot? Thanks!
Please Check you might have configured a tenant with a service path of ./. Because of this, the root path was taken and then every tenant that tried to register would get the below error "Address sb://[namespace].servicebus.windows.net/[WCF Relay name] is already in use by an existing listener with different settings" .
Try to turn off the bad endpoint then all the other endpoint will able to work again.
If you creating a WCF Relay explicitly in the portal (or with NamespaceManager.CreateRelay[Async]) for this endpoint, If so, then you need the binding's IsDynamic == false.
If you're not pre-creating the endpoint then the binding's IsDynamic must be true.

SignalR on WinForms - Can't connect to any address aside from 127.0.0.1

I've looked up several articles/sources but none of them helped me out.
I have this bizarre issue where i can only connect to my SignalR Server (Self-Hosted, same computer) if the Server itself is configured to run on http://127.0.0.1:8765 and the Client is pointed to that same address. However, if i change the Server to run on any IP such as http://*:8765 and the Client is pointed it to my IP or computername, say: http://192.168.0.1:8765 or http://MyLocalPC:8765, the client throws an Exception after await _hubConnection.Start() with message: No connection could be made because the target machine actively refused it 192.168.0.1:8765.
i have tried below steps to experiment a little but none of them actually helped:
changed the port from :8765 to any port i can think of (that is obviously not occupied), didn't work.
changed from one Network to another, didn't help.
disabled firewall on both Server and Client computer, nope.
tried to run the Client on another computer, same error message.
to show a snippet of the code, see below:
Server (_signalR is an IDisposable object & _serverURI is where http://____:__ is specified):
Client (_hubConnection & _hostAddress is self-explanatory):
i am using C# 7.0 with Microsoft.AspNet.SignalR.Client 2.4.1.0 and Microsoft.AspNet.SignalR.Core 2.4.1.0
i just realized that its because Visual Studio wasn't running with Administrator rights. SignalR required administrative rights to able to run its Server on IPs other than localhost or 127.0.0.1. I wasn't able to fully realize it since i switch laptops about 3 weeks now and forgot setting up running Visual Studio in Administrator Mode.
The reason i was also not able to find any error regarding that is for some reason there's a flaw in my code where i suppressed the exception error and still displayed a message as if it was working properly.

Debugging Akka.NET remote connections (Cant connect - Failed to bind)

Using the example Chat Server/Client project available as part of the Akka.NET source code I have attempted to modify it such that it would successfully work over two computers on my network.
I have two systems that are connected via a router like this
192.168.0.29 (Server) <---------------| Router |---------------> 192.168.0.52 (Client)
I then have two actor systems that are configured like this:
Server:
akka {
actor {
provider = remote #Specify remote provider
}
remote {
dot-netty.tcp {
port = 666 #Akka server port number
hostname = 0.0.0.0 #Bind to all local network interfaces
public-hostname = 192.168.0.29 #Expose public IP to enable correct routing of public messages.
}
}
}
Client:
akka {
actor {
provider = remote
}
remote {
dot-netty.tcp {
port = 0 #Tell Akka that this is a client connection/use random port.
hostname = 192.168.0.29 #Tell Akka.NET which remote instance to connect to
}
}
}
Unfortunately, while I am able to successfully connect to the chat server locally, no matter how I configure my Hocon I cannot seem to get the remote instance to bind to my server actor located on the machine 192.168.0.29.
The specific error message that I receive
[ERROR][27/11/2019 4:58:36 PM][Thread 0004][Akka.Remote.Transport.DotNetty.TcpTransport] Failed to bind to 192.168.0.29:0; shutting down DotNetty transport.
Cause: System.Net.Sockets.SocketException (10049): The requested address is not valid in its context
at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
This error message suggests to me that there is no available socket that Akka.NET can access.
Ironically enough, some time ago I asked a very similar question which at the time helped me resolve my connectivity issues but I never used Akka.NET till recently again.
I note that both machines have their firewalls turned off and can successfully ping each other, I have also played around with all various combinations of settings.
The original source code to the Akka.NET server/client application is located here, my current version of it is here.
Could anyone provide any insight into what I might be doing wrong and how I can improve my debugging of Akka.NET remote connections? For example is there a way that I can verify that the Actor system on server 192.168.0.29 is accessible from 192.168.0.52 externally?
Haha, and literally 5 minutes after posting my question I was finally able to determine the solution (although its not ideal).
The solution was the realisation that when you instantiate the ActorSystem on the client application you are NOT actually connecting the local actor system to the remote system BUT rather creating a local instance of an actor system which itself is listening on a random port.
The remote connection itself occurs when you create an ActorSelection() reference.
So all I needed to do was change my client hocon from
hostname = 192.168.0.29
TO
hostname = 192.168.0.52
However this creates one final (albeit rather small) problem. I now need a different hocon file for an instance running locally vs an instance running remotely. Admittedly this could probably be addressed through code....
I'd be happy to mark as the solution someone who might be able to propose something that addresses this issue.

WCF Endpoint Address using https (WebHttpBinding)

I need to modify a WCF endpoint binding address. Here is some background on the issue:
I have an NT class service (if it matters, not a webservice). It creates a System.ServiceModel.ServiceHost with an Endpoint whose endpoint address is created this way:
var epa = new EndpointAddress(string.Format("https://localhost:{0}/ServiceAPI/", 8181));
The binding used for the ServiceEndpoint is a WebHttpBinding with Mode=WebHttpSecurityMode.Transport (i.e. https).
When the ServiceHost is opened, I can go to a command prompt, and do "Netstat -a" and see the address bound to the Listen as 0.0.0.0:8181.
So far, no problem. However, a large customer has raised a "security issue" with the fact that because the WCF "listen" is on address 0.0.0.0 instead of 127.0.0.1, that a potential attacker can connect to that address from an external machine. The test that they have constructed is to use telnet 8181 from an external machine, and if the connect occurs, then the test fails. The change request is to modify the service to "listen" on 127.0.0.1:8181 so that the only possibility of connecting to that port is from the local machine.
I have done a fair amount of modifications in an attempt to get WCF to "listen" on "127.0.0.1" instead of "0.0.0.0". In all of my attempts the only way to do this is to set HostNameComparisonMode to "Exact" and create the endpoint address in this way:
var epa = new EndpointAddress(string.Format("https://127.0.0.1:{0}/ServiceAPI/", 8181));
(Actually, as an aside, if I use a different binding such as NetTcpBinding, the above EndPointAddress construction will bind to address "127.0.0.1:8181" without altering HostNameComparisonMode. It only switches internally to "0.0.0.0:8181" when I use WebHttpBinding, and fail to set HostNameComparisonMode=Exact.)
However, this (setting HostNameComparisonMode=Exact) causes a breaking complication due to the fact that existing 3rd party code has already been developed that attempts to (onboard the server) connect to "https://localhost:8181/ServiceAPI", and when HostNameComparisonMode is set to "Exact", WCF only ever returns http error 506 to any request due to the difference between "localhost" and "127.0.0.1".
What I am currently looking for is either a means of setting up WCF to bind to "127.0.0.1:8181" (as determined by netstat -a) with the HostNameComparisonMode still set to the default "StrongWildcard" setting. Or barring any possibility of there being a way to do that, another creative suggestion to cause connects coming from external machines to be unable to connect to that port. (The test would be to use "telnet servername 8181" from a different machine, and it fail to connect.)
Any ideas? Thanks!
if i understand you right, you want to connect from remote machine to this address, so can you try BasicHttpBinding? Also you can try to host it at: "https://localhost:{0}/ServiceAPI/", 8181" Correct pls if i understand you wrong.

SignalR on Home Network

Edit/Summary
After a lot of trial and error, Paul Kearney - pk helped lead me to the answer, although I still don't know why this happens, at least I know how to get it to work.
Quick Summary: Clients can connect to port 8080 on my laptop when I'm directly connected to my network at work. Clients cannot connect to port 8080 when I'm on a home network. To solve this, I created a firewall rule (on my laptop) to allow inbound traffic on 8080. I'd really like to know why this is the case. Does my laptop's Windows Firewall service actually change its settings based on the network I'm connected to?
Note: This all works when I'm on my network at work, but it doesn't work on my home network, or someone else's home network. The host computer (my laptop) is the same at both locations.
I have a web app that uses SignalR. Everything works when I run the web app on the same machine as where the SignalR host is running. When I try to connect from a different machine, I get this error:
> GET http://10.0.0.13:8080/signalr/hubs net::ERR_CONNECTION_TIMED_OUT. Cannot read property 'client' of undefined.
That error comes from my index.html page:
<script src="http://10.0.0.13:8080/signalr/hubs"></script>
From the research that I've done, I know that I shouldn't be using localhost in my SignalR URL. So I used an asterisk. This is in my self-hosted SignalR app:
class Program
{
static void Main(string[] args)
{
string url = "http://*:8080";
using (WebApp.Start(url))
{
Console.WriteLine("Server running on {0}", url);
Console.ReadLine();
}
}
}
class Startup
{
public void Configuration(IAppBuilder app)
{
app.UseCors(CorsOptions.AllowAll);
app.MapSignalR();
}
}
public class RaceHub : Hub
{
public void Send(string name, string message)
{
Clients.All.addMessage(name, message);
}
}
And this is my JavaScript to connect:
var signalRUrl = 'http://10.0.0.13:8080/signalr';
$.connection.hub.url = signalRUrl;
var hub = $.connection.raceHub; // proxy reference to hub
// Create a function that the hub can call to broadcast messages.
hub.client.addMessage = function (name, message) {
receiveSignalRMessage(name, message);
};
$.connection.hub.start(); // Start the connection.
Like I said, this all works locally. But it doesn't work from another machine. I do not have Windows Firewall enabled, so that's not the issue. Any ideas?
HTTPS didn't work. It works when I'm on my network at work, but not at home. The configuration is the same. Must have something to do with my home network.
Also, this is what the page looks like when it's working properly:
And this is what happens when it's not working:
(Full disclosure - #BobHorn typed up this answer based on my comments)
There are different firewall settings on your machine, depending on the type of network you are attached to.
Have you ever noticed when you connect to a new network for the very first time, it asks you to define it as "work, private, public, home, etc"?
Whatever you choose for that network is sticky, and the related firewall policy is applied when you are on that type of network.
To check this, you can either completely turn off your firewall, or make sure inbound port 8080 is open for all firewall profiles, especially "home" networks and/or the "home" firewall profile.
ahh.. so you say your windows firewall is off. Are you sure it's not OFF only for the WORK network profile, but enabled for the HOME network profile ?
To troubleshoot this, I would put wireshark on one of the client computers trying to connect to port 8080 at home, and see how/why it's being blocked or cannot connect.
You can also try to telnet to port 8080 from the client machine at home (if the Telnet Client feature is enabled). You'll know right away if the port is open and connection succeeds, or a big fat denied. Quick and easy test. type TELNET ServerIPAddress PortNumber from a command line. If Telnet command not found, you need to turn on the Telnet Client in Windows Features/Components.
Does your network use IP security? You might try using HTTPS instead to see if that alleviates anything.
It looks like your work network is blocking your IP. Try whitelisting your home IP on your work network.
I believe the issue here is that your laptop's IP address changes from one network (i.e. work) to another (i.e. home), but you may not be updating the value of the signalRUrl variable in your javascript file accordingly, thus the client side of your app is looking for a hub at an IP address that doesn't exist on your home network.
When you change networks, you need to update the value of signalRUrl in javascript to reflect the current IP address of the host machine.

Categories