We Keep Coding

C# - Port Mapping with .Net Core 5.0

Expected Outcome
I'm attempting to make an ASP.NET Core 5.0 application using Kestrel, and I would like to auto port forward the server's port.
Package
I'm currently using the OpenNat.Core package. I have also tried the regular OpenNat and the same issue arises.
Issue
When port forwarding, the program says it has mapped everything correctly and the map even shows when listing all mapped ports on my router. Yet, when I attempt to view its status via CanYouSeeMe.org it returns a timed out error, and I am unable to access the server outside the network.
What I've Tried
I thought that the port mapping might have been opening after the server started, so I manually opened the port and then restarted the Kestrel server.
I made sure that my router supported UPnP
I also have a Synology NAS that I port forward from, and it works just fine.
I had a friend use ZenMap to check the port.
The port shows that it's filtered but not open (and no service was specified).
Code
using Open.Nat;
using System;
using System.Threading;
using System.Threading.Tasks;
...
public static async Task OpenPort(int port, string description)
{
try
{
NatDiscoverer discoverer = new NatDiscoverer();
CancellationTokenSource cts = new CancellationTokenSource(10000);
NatDevice device = await discoverer.DiscoverDeviceAsync(PortMapper.Upnp, cts);
Mapping map = new(Protocol.Tcp, port, port, description);
await device.CreatePortMapAsync(map);
Console.WriteLine($"Created {map}");
}
catch (Exception e)
{
Console.WriteLine(e.Message);
Console.WriteLine(e.StackTrace);
}
}

Nevermind my firewall was blocking the application. I was able to dynamically add a firewall rule to fix the issue.

Android client cannot connect to C# MQTT Server, error code 32103

I'm developing a really simple MQTT Android client, so I can connect to it with an MQTT Server I created in C# using the MQTTnet library.
I first tested the C# broker with a C# client and Node-RED and it worked just fine.
I also tested the Android Client with CloudMQTT following this tutorial, and it also worked perfectly fine.
But when I tried to connect my Android Client to the C# Server, the Android Client gave me the following error:
Mqtt: Failed to connect to: tcp://localhost:1883 It's not possible to connect to server (32103) - java.net.ConnectException: Connection refused
I'm using BlueStacks as an emulator (I will try to test it in a real Android device asap). I tried to restart the emulator (as said in Paho Mqtt Android connecting to broker fails with (32103)) but it didn't work either.
The code for the Android Client is exactly the same as in the tutorial I mentioned earlier (using the Paho-MQTT library), but changing the serverUri and subscription topic:
final String serverUri = "tcp://localhost:1883";
final String subscriptionTopic = "step/time";
The app only has a TextView where I set the received messages.
As for the C# server, I'm sending a timestamp every 10 seconds. This is my code:
namespace MQTTServerExample
{
class Program
{
static void Main(string[] args)
{
serverAsync();
}
private static async Task serverAsync()
{
// Starting the MQTT Server
var mqttServer = new MqttFactory().CreateMqttServer();
var options = new MqttServerOptions();
//Saving retained application messages
options.Storage = new RetainedMessageHandler();
// Publishing messages
await mqttServer.StartAsync(options);
Console.WriteLine("### SERVER CONNECTED ###");
Console.WriteLine("Press ENTER to exit.");
MqttApplicationMessage message;
#pragma warning disable CS4014
Task.Run(async () =>
{
while (true)
{
message = new MqttApplicationMessageBuilder()
.WithTopic("step/time")
.WithPayload(DateTime.Now.ToString())
.WithExactlyOnceQoS()
.WithRetainFlag(true)
.Build();
await mqttServer.PublishAsync(message);
await Task.Delay(10000); // Every 10 seconds
}
});
#pragma warning restore CS4014
//await mqttServer.PublishAsync(message);
Console.ReadKey();
await mqttServer.StopAsync();
}
}
I'm new to connection protocols and I still don't understand them clearly, so I was hoping you could help me understand this problem.

A java.net.ConnectException: Connection refused exception means that there is no service listening on the host and port you are trying to connect to, for example because the host address or port is wrong, or the service is not started.
Using "tcp://localhost:1883" as server address only works if the server runs on the same machine as the client (i.e. in your case the Android device). You should use the server's name or IP address.

I'm going to guess that your C# broker is only listening on localhost not the external IP address of the machine hosting it.
This would work when ran the C# client on the same machine, but not when you use the external IP address from the Android client.
The other possible option is that you are running a firewall on the broker machine which is stopping the Android client connecting.

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.

What could explain this behavior in UDP multicast via WinRT?

Here is the scenario: I have 5 apps which all share a common DLL which contains P2P networking functionality that I wrote. One of these apps works perfectly every single time, but the others experience the following problem:
On a multicast broadcast our x86 based tablet can send and receive packets fine, but my x64 computer and ARM tablet can only send packets. The only difference is that they use different ports. I thought that must be it, and tried switching the other apps to use the same ports as the working app as a test, but that was a no-go. Here is the relevant portion of code that handles setting up the broadcasting system.
public async Task<bool> Startup() {
if (P2PNetwork.LocalUser == null || this._listenSocket != null)
return false;
ConnectionProfile connection = null;
//See note 1 below
bool gotConnection = TryGetValidNetworkConnection(out connection);
if(!gotConnection)
return false;
this._heartbeatTimer = ThreadPoolTimer.CreatePeriodicTimer(DoHeartbeat, TimeSpan.FromSeconds(10));
var socket = new DatagramSocket();
var stream = await socket.GetOutputStreamAsync(LANBroadcasting.MULTICAST_GROUP_ADDRESS, P2PNetwork.NetworkGroup.SendPort);
this._outStreamWriter = new DataWriter(stream);
this._listenSocket = new DatagramSocket();
this._listenSocket.MessageReceived += OnMessageReceived;
await this._listenSocket.BindServiceNameAsync(P2PNetwork.NetworkGroup.ReceivePort, connection.NetworkAdapter);
this._listenSocket.JoinMulticastGroup(LANBroadcasting.MULTICAST_GROUP_ADDRESS);
DoHeartbeat(HeartbeatFlags.Ping);
return true;
}
NOTE 1: These symptoms were happening before for all 5 applications. At that time I was using the BindServiceNameAsync without any arguments. After extensive research I found a page that suggested that that approach was not good, and that the Windows 8.1 method that takes a connection profile worked more reliably. I checked the profile multiple times and I get the wireless LAN profile, which is correct for both.
In this case (non-working) the tablet's send port is 50011 and its receive port is 50010. The multicast address is ff02::fb (I've tried IPv4 as well, no change) The PC in this case is the reverse of that. I confirmed that the packets are sending via Wireshark.
I also see this line of output via netstat -a on the PC (which is failing to receive)
UDP [::]:50011 *.*
Despite all this looking correct, my PC simply does not get the OnMessageReceived method called (except for the one app which mysteriously works). What should I be looking for that can cause this odd behavior? I tried changing the ports on the working application to see if it would fail but it didn't. I also tried running the app on a different tablet to see if it was just this PC, but I got the same results on the other tablet. Could the app be failing to join the multicast group? How would I know since the method returns void?

After a few days of banging my head against the wall, I finally got the answer. If you experience this problem, go to your Windows Firewall Settings and check what kind of network you are connected to. In my case, the Wi-Fi was a Guest / Public network. Apparently this means that it is considered "Internet" by the Windows Runtime and not "Private Network". In Package.appxmanifest I had the "Private Network (Client and Server)" options selected, but only "Internet (Client)" (which provides outbound access only) and not "Internet (Client and Server)" on all but the one application that was working for some reason.
On a side note: this doesn't explain why the one x86 tablet was still able to receive for all apps. I can only assume this is some kind of driver flaw.
This should really trigger some kind of warning message because this simple setting is way too easy to overlook.

Windows Phone 8 External IP vs local hostname

My intention is to receive UDP messages over the internet on a windows phone 8.
-> First question: am I wrong assuming that this is possible?
Test setup:
WIFI switched off, cellular data on
Running NetworkInformation.GetHostNames() I get one host with IANA network code 344, IP Address was "10.146.8.159".
Opening icanhazip.com at the same time in the browser I get an IP Address of "192.230.159.176".
-> Second question: why are these two IP addresses different?
My code is:
public async void Start()
{
m_rxSocket = new DatagramSocket();
m_rxSocket.MessageReceived += MessageReceived;
await m_rxSocket.BindServiceNameAsync("57000");
}
private async void MessageReceived(DatagramSocket sender, DatagramSocketMessageReceivedEventArgs socketEventData)
{
// This is never called
}
The problem is that the method MessageReceived is never called despite:
Sending a UDP message to 10.146.8.159 as well as 192.230.159.176 over the internet
Registering the ID_CAP_NETWORKING
-> Third question: why is no message received by the setup above?
(-> Fourth question: anyone else thinking that wp development with silverlight was superior to this new apis that are smelling C++ all over...?)

Hi i have found what was wrong:
Lack of UDP hole punching was the reason for the behaviour and adding UDP hole punching the solution to make it work.