Dump Mono.NAT in favor of Open.NAT 2

[Mailaender]

https://github.com/lontivero/Open.NAT/wiki/Why-Open.NAT

Closes #7140.
Fixes #8794.
Depends on #10279.

It also deprecates the Settings.Server.NatDeviceAvailable helper variable and always logs into nat.log (so we can get rid of Settings.Server.VerboseNatDiscovery as well) as even in verbose mode it is now pretty readable as Open.NAT only searches for NAT devices, not every other UPnP enabled device in the network.

[abcdefg30]

OpenRA.Game/Network/UPnP.cs:L41: [SA1000] The spacing around the keyword 'catch' is invalid.

[Mailaender]

Fixed.

[pchote]

This doesn't work for my router. Mono.NAT works fine:

Open.NAT Information: 0 : Start Discovery
Open.NAT Information: 0 : Searching for: UpnpSearcher
Open.NAT Error: 0 : Error searching UpnpSearcher - Details:
Open.NAT Error: 0 : System.Net.Sockets.SocketException: The requested address is not valid in this context
  at System.Net.Sockets.Socket.SendTo_nochecks (System.Byte[] buffer, Int32 offset, Int32 size, SocketFlags flags, System.Net.EndPoint remote_end) [0x0003f] in /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.2/mcs/class/System/System.Net.Sockets/Socket.cs:2466 
  at System.Net.Sockets.Socket.SendTo (System.Byte[] buffer, Int32 offset, Int32 size, SocketFlags flags, System.Net.EndPoint remote_end) [0x00028] in /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.2/mcs/class/System/System.Net.Sockets/Socket.cs:2454 
  at System.Net.Sockets.UdpClient.DoSend (System.Byte[] dgram, Int32 bytes, System.Net.IPEndPoint endPoint) [0x0001b] in /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.2/mcs/class/System/System.Net.Sockets/UdpClient.cs:320 
Open.NAT Information: 0 : UPnP Response: Router advertised a 'urn:schemas-upnp-org:service:WANIPConnection:1' service!!!
Open.NAT Information: 0 : Found device at: http://192.168.1.254:58461/rootDesc.xml
Open.NAT Information: 0 : 192.168.1.254:58461: Fetching service list
Open.NAT Information: 0 : Found device at: http://192.168.1.254:58461/rootDesc.xml
Open.NAT Information: 0 : 192.168.1.254:58461: Parsed services list
Open.NAT Information: 0 : 192.168.1.254:58461: Found service: urn:schemas-upnp-org:service:WANIPConnection:1
Open.NAT Information: 0 : 192.168.1.254:58461: Found upnp service at: /ctl/IPConn
Open.NAT Information: 0 : 192.168.1.254:58461: Handshake Complete
Open.NAT Information: 0 : 192.168.1.254:58461: Absolute URI detected. Host address is now: 192.168.1.254:58461
Open.NAT Information: 0 : 192.168.1.254:58461: New control url: /ctl/IPConn
Open.NAT Information: 0 : Stop Discovery
Open.NAT Information: 0 : GetExternalIPAsync - Getting external IP address
Open.NAT Verbose: 0 : SOAPACTION: **GetExternalIPAddress** url:http://192.168.1.254:58461/ctl/IPConn
  at System.Threading.Tasks.Task.ThrowIfExceptional (Boolean includeTaskCanceledExceptions) [0x00014] in /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.2/external/referencesource/mscorlib/system/threading/Tasks/Task.cs:2168 
  at System.Threading.Tasks.Task`1[TResult].GetResultCore (Boolean waitCompletionNotification) <0x1a18960 + 0x0008a> in <filename unknown>:0 
  at System.Threading.Tasks.Task`1[TResult].get_Result () <0x1a188e0 + 0x00038> in <filename unknown>:0 
  at OpenRA.Network.UPnP+<TryNatDiscovery>c__async0.MoveNext () [0x0010c] in /Users/paul/src/OpenRA/OpenRA.Game//Network/UPnP.cs:39 

[pchote]

I suspect I am suffering from lontivero/Open.NAT#26 (I have both WANIPConnection and WANPPPConnection), but the log files in that issue have expired so I can't be certain.

[lontivero]

The opened bug in lontivero/Open.NAT#26 is because of a HTTP 400 - Bad Request. Is this one because of the same problem?

Btw, Mono.Nat raises an event for each device it finds and that means when two are found our event handler is invoked twice, one per device. That means that in many cases it fails with one but it succeeds with the other. Is this one of those cases?

[pchote]

Looks like it is failing on WANIPConnection:1 and succeeding on WANPPPConnection:1.

@Mailaender's integration with OpenRA catches the exception that is generated by the first failure and globally disables NAT, so we don't see the results from the second device. I can hack around the problem locally by removing the WANIPConnection services from Open.Nat.UpnpSearcher.

[Mailaender]

So which exceptions exactly should I catch and which not?

[Mailaender]

Shouldn't I try/catch in general here?

[pchote]

@lontivero: Would you be able to advise on the best way to query the result of GetExternalIPAsync() while ignoring the first error?

[lontivero]

Umm i think there was a misunderstanding here. I was talking about Mono.Nat. @pchote said Mono.Nat works okay and for that reason i detailed how it works (it raises an event for each device it finds).

Open.NAT doesn't raise events, it returns all the devices it finds before timeout and then you should try with them in a foreach loop.

[Mailaender]

Updated to make use of DiscoverDevicesAsync now.

[pchote]

You'll still need a try/catch inside the loops to skip over the errors from the bogus device.

[pchote]

Even with the try/catches I receive the following, and ports are not forwarded:

Open.Nat.MappingException: Error 718: ConflictInMappingEntry

The port that I am trying to forward (tried both 1234 and 1238) are not already forwarded, despite what the error claims.

Edit: Looks like this was just my weird network topology. If I connect directly to my router then it works as expected.

[pchote]

Crash when loading the settings menu:

Exception of type `System.Reflection.TargetInvocationException`: Exception has been thrown by the target of an invocation.
Inner Exception of type `System.InvalidOperationException`: ServerSettings does not contain a preference type VerboseNatDiscovery

[Mailaender]

Updated.

[Mailaender]

Not sure if this is async enough, but neither Start() nor RunSynchronously() will work here.

[pchote]

Not async enough, sorry. Put it in a background thread if you have to, or like I mentioned above at least move it later in the init so it doesn't delay the window creation and load screen display.

[Mailaender]

Rebased and moved it below. I am a bit inexperienced with this async concept.

[Mailaender]

Made a new attempt #11286 based on this pull request.