Open.NAT failing to open a port
NatDiscoverer natdisc = new NatDiscoverer();
NatDevice natdev = natdisc.DiscoverDeviceAsync().Result;
Mapping map = natdev.GetSpecificMappingAsync(Protocol.Tcp, TheServer.Port).Result;
if (map != null)
{
natdev.DeletePortMapAsync(map).Wait();
}
natdev.CreatePortMapAsync(new Mapping(Protocol.Tcp, TheServer.Port, TheServer.Port, "Test")).Wait();
map = natdev.GetSpecificMappingAsync(Protocol.Tcp, TheServer.Port).Result;
SysConsole.Output(OutputType.INIT, "Successfully opened server to public address " + map.PrivateIP + " or " + map.PublicIP + ", with port " + map.PrivatePort + " or " + map.PublicPort + ", as " + map.Description);
This outputs: 192.168.0.9 or 255.255.255.255 with port 28010 or 65535 as Test.
The PublicIP and PublicPort appear to just be their individual maximum values.
Additionally, the port is not open. I connected to it through HTTP to test (The server is configured to respond to that) via http://<my external ip>:28010. This failed to connect, and eventually timed out. http://localhost:28010 functions. I confirmed my server and address choice function fine by temporarily configuring a manual router port forward and then reconnecting, which worked fine.
Any idea what has gone wrong here?
@mcmonkey4eva please download this repository, build it and run the Open.Nat.ConsoleTest project (you can modify it to open the ports that you want). It will create a network.log file with all the info necessary for performing a diagnostic.
That got positive-looking results, and seems to be a fair bit more functional. CanYouSeeMe responds with success on viewing the port where it previously failed. However, 1702 doesn't respond on an HTTP connection (Any TCP socket listening and rejecting connections would normally induce the browser to display an error rather than time out - which I'm not sure applies here, but it was worth trying - edit: yeah the browser can't open 1602 localhost either so that's an irrelevant note)
Of note is that my code also successfully opens the port to CanYouSeeMe, but not to my browser either.
Of further interest is that CanYouSeeMe is able to generate an error message on my test program (Specifically an invalid connection error, exactly as one would expect if software like that was pinging my server by connecting to it... which it is.) So it's able to get through to my computer from CanYouSeeMe, but not from my own web browser?
And, of course, my code still reads the wrong public IP/port value.
Anyway, the console log: http://pastebin.com/R4rrQbHH And the very verbose network.log file: http://pastebin.com/Yz34RfiA
@mcmonkey4eva I didn't find any problem in the log file, in fact it seems to open the ports well. After that, when it requests the list of opened ports it is able to get the previously open ports.
On the other hand, in most cases you cannot use http://<my external ip>:<open port> for accessing to your machines in the LAN. I don't have a link to share with you but it is as i say. What you could do is try from an external (out of your LAN) computer.
UPDATE
You cannot do that because your router doesn't support Hairpinning. Most of the routers that I know do not support this.
Hairpinning is where a machine on the LAN is able to access another machine on the LAN via the external IP address of the LAN/router (with port forwarding set up on the router to direct requests to the appropriate machine on the LAN).
That sounds like a reasonable explanation for why I can't access my own server remotely but other systems can... but what about the PublicPort/PublicIP showing wrong?
@mcmonkey4eva could you share your .cs file with the code to reproduce the problem, please? Also, the Open.NAT version would be helpful.
@lontivero the opening post contains my entire Open.NAT using code (dump it in a console program, swap the SysConsole call to the standard Console, swap TheServer.Port with 28010), and the version is a fresh compile off this github repo.
@mcmonkey4eva the GetSpecificMappingAsync method receives two parameters: the protocol and the external port (PublicPort property) and for that reason it assumes you know the external port (i will treat this as a defect).
GetSpecificMappingEntry service doesn't return the external IP address (PublicIP property) and you should use the GetExternalIPAsync method for getting it. Obviously users don't have the cristal ball to know this and it is clearly an usability issue in the library. At design time the approach was using the Mapping class for everything even when different methods returns a different set of properties.
I've noticed discovery involves a multitude of possible udp socket addresses/ServiceTypes/searchertask combinations run concurrently with a single response locus, the udp MessageReceived handler. There are cancel mechanisms but I've found that the following loop
while (!cancelationToken.IsCancellationRequested)
{
Discover(cancelationToken);
Receive(cancelationToken);
}
required Task.Delay to function properly in the multi-task discovery environment.
Any thought of aligning with STUN imperatives? e.g. that a Full Cone router setup may not require
NAT and only knowledge of external address and mapped port in a received packet to reply.
@grockland this thread is for discussing a defect so please, next time open a new issue. About your question: no, this library is for upnp and pmp. stun is out of scope.