[Bug]: WebRTC connection fails

[Azhrei]

Describe the Bug

Player cannot connect to server using WebRTC support. This failure causes the client to block forever until a force-quit is used (so the timeout needs to be shorter for connecting).

To Reproduce

1. Install MT 1.11.5
2. Start a Server, entering a server alias ("Test") and selecting WebRTC.
3. Choose a port number (I used 51235) and enter a password into both fields.
4. Click OK to start the server.
5. Have another person install 1.11.5 on their system (partner was using Windows 10).
6. They should start MT and select Connect to Server (fails using either password).
7. They should check the WebRTC support and double-click your server name in the list.
8. Their system says "Connecting" but ultimately just hangs.

See attached log file.

Expected Behaviour

It works. :)

Screenshots

No response

MapTool Info

No response

Desktop

Server was macOS Big Sur 11.6.2 and client was Windows 10.

Additional Context

This log file is from the client side; it shows an exception curing the connection process:

maptool.log

When the client uses FrontierNet (a fiber optic-based ISP) and their own router, the connection fails as described above. If they switch to using their cellphone as a hotspot, the connection succeeds. If other information regarding their router configuration would be useful, I can try to get more data. (Initial perusal of the log files created by the router don't show anything related to this connection attempt.)

When my partner runs a server, I can connect to them as a client flawlessly. The connection is almost immediate. This is true whether he uses his wired ISP or his cellphone. We've tried various combinations with each of us using hotspots, but his wired outbound connection is the only one that fails.

[thelsing]

Can you connect when your partner runs the server via WebRTC or a normal Socket Server?

The exception in the Log is from a SocketConnection not from the WebRTC one. WebRtc only starts after the "Websocket connected" message.

[thelsing]

After reading up on the different types of NAT on wikipedia I think on the long term we really need an TURN server.

[thelsing]

Depends on RPTools/maptool-server-registry#9

[Phergus]

Would be helpful to know if a regular connection using port-forwarding without WebRTC worked.

[Azhrei]

Would be helpful to know if a regular connection using port-forwarding without WebRTC worked.

It has in the past (he has hosted games when our GM has had connectivity issues in the past).

I'm trying to arrange another test session. I'll create a spreadsheet of different combinations of settings and try each one, keeping the log file for each one. My plan is to do this during the Monday holiday, so hopefully I can post the results that evening.

[Azhrei]

It took me longer than expected to get this written up, but here goes...

There are two systems involved in this series of tests. One is Windows 10, one is macOS 11.6 (Big Sur; latest is one version newer, Monterey). The Windows system is on FrontierNet (fiber optic internet access) and the macOS box is on Spectrum (cable modem).

We edited the Preferences and set both autosaves to "0" (to disable them). The Windows shortcut was edited to include the -d command line option, and the macOS instance executed a macro that turned on the same level of debugging.

The following configurations were tested:

FrontierNet <-> Spectrum
FrontierNet <-> cellular hotspot
Cellular hotspot <-> Spectrum
Cellular hotspot <-> cellular hotspot

In each case, we tested MapTool 1.11.5 as both a server and a client (using port 51235 so that neither of us would have a port forwarding entry already configured).

Tests were done with UPNP turned on and WebRTC off (aka "the old way"). Then UPNP was turned off and the test was done again. And last, with UPNP off, we turned on WebRTC (on both ends). There was never a test done with both UPNP and WebRTC turned on, so that results in just three combinations.

Those three combinations, times the four possible network routes (above), results in 12 log files when one end is server and the other is client. Since we swapped roles and did the tests again, we have a total of 24 log files. Here is a chart showing the various combinations and the names of the associated log files. In all cases, each component of the filename represents an option that was turned on (upnp indicates UPNP was on, etc indicates that WebRTC was turned on, hsc indicates the client was using the cellular hotspot, and hss indicates the server was using the cellular hotspot). In addition, when I am running the server, the -me suffix is added to the filename). There are three logs that include a second file with the suffix of -2. Those are situations where MapTool wouldn't even start when we did our first test; we reboot the server and retested and they worked, so the second logs were attached as well. (This is on the Windows side.)

This char is GitHub's attempt at formatting a table copy/pasted from a spreadsheet. A PDF of this same chart is attached at the bottom because it didn't translate over 100%.

Remote as Server		FrontierNet: Yes		FrontierNet: No(Verizon hotspot)	x
Port 51235		Spectrum: Yes	Spectrum: No(Spectrum/Verizon hotspot)	Spectrum: Yes	Spectrum: No(Spectrum/Verizon hotspot)
Use UPNP	Yes	mt-upnp	mt-upnp-hsc	mt-upnp-hss	mt-upnp-hss-hsc
	No	mt (worked?!)	mt-hsc (worked?!)	mt-hss *	mt-hss-hsc
Use WebRTC	Yes	mt-rtc (start failed)	mt-rtc-hsc (start failed)	mt-rtc-hss	mt-rtc-hss-hsc
	No	-	-	-	-
				*Grasslands map went to black while connecting
Azhrei as Server		FrontierNet: Yes	FrontierNet: No(Verizon hotspot)
Port 51235		Spectrum: Yes	Spectrum: No(Spectrum/Verizon hotspot)	Spectrum: Yes	Spectrum: No(Spectrum/Verizon hotspot)
Use UPNP	Yes	mt-upnp-me	mt-upnp-hsc-me	mt-upnp-hss-me	mt-upnp-hss-hsc-me
	No	mt-me	mt-hsc-me	mt-hss-me	mt-hss-hsc-me
Use WebRTC	Yes	mt-rtc-me (conn failed)	mt-rtc-hsc-me (conn failed)	mt-rtc-hss-me	mt-rtc-hss-hsc-me
	No	-	-	-	-

MapTool Network Testing.numbers-For Printing.pdf

Here is the zip of the various log files. They are broken into directories based on whether the Remote was or was not using FrontierNet (the split is arbitrary and was used by the testers for organizational purposes).

issue3336-logs.zip

[kwvanderlinde]

@Azhrei Can you verify whether this issue still exists in 1.13.2 or if it has been completely fixed?

[Azhrei]

I'll get with my buddy and see about recreating this environment and test again.

[Azhrei]

We have scheduled time on Sunday, so I can give a thumbs up/down by Sunday night, I think.

[Azhrei]

Success! All of the WebRTC tests are now successful!

When my buddy was on a hotspot, the UPNP didn't work when he tried to start a server (of course). But I had already clicked Connect to Server... and I had the wrong password. That produced a sequence of errors. I took a screen recording of it; here are the errors, in the order they appeared:

• Incorrect Password during handshake
• Server has disconnected. : WebSocket closed: (1000)
• You are already running a server.
• Could not restart personal server.\njava.net.ConnectException: Connection refused

(The second one has a period in the message and it shouldn't; the showMessage() function automatically adds the colon.)

The gray overlay on the glassPane is still there and the rest of the MT GUI is non-responsive (which makes sense, since the glassPane is absorbing all events), yet the keyboard still seems to work — I had the chat window focused and key events still went there, which is kind of surprising. Had to quit MT to get out of that mode.

We did not test all of the code paths involved in other connection styles (such as with public/private keys) but I'll try to do that and put the results in an appropriate issue if there are any problems.

[kwvanderlinde]

Thanks @Azhrei. We'll consider the work on this bug done, and we'll address any other issues separately.

Btw, I think what you're seeing is part of the motivation behind this refactoring issue: #3790