[Question] About problems with WebRTC and it's current state

SEsternO commented 2 years ago

First I gotta say, I can't thank you, guys from MeshCentral team, enough for this ambitious and fully open-source project and for how it made my life much easier. Truly outstanding work!

I wanted to know if current implementation of WebRTC is stable and reliable enough for use in production environment, as I tried to use it, but had some issues that I can't undestand if it's on my side or not.

I have some agents installed on machines under the different network configurations:

some of them have heavily or moderately firewalled ports behind the organisation servers (mostly with shorewall)
others are connected to the consumer grade routers with default settings and their routers external ip is visible on the internet
and I also have my home network where my router doesn't have visible exernal ip and NATed by my mobile provider.

I enabled WebRTC in config.json. I've got a coturn based TURN server, and it works fine, at least with my Nextcloud Talk instance. Here's some important for the question lines of config.json:

  "settings": {
    "WANonly": true,
    "port": 4430,
    "aliasPort": 443,
    "redirPort": 800,
    "redirAliasPort": 80,
    "TlsOffload": "127.0.0.1",
    "_DesktopMultiplex": false,
    "WebRTC": true,
    "webrtcConfig": {
      "iceServers": [
        { "urls": "stun:stun.services.mozilla.com" },
        { "urls": "stun:stun.l.google.com:19302" },
        {
            "urls": "turn:turn.mydomain.org:3478",
            "credentials": "secretkey"
        }
      ]
    }
  },

The main problem is, when I try to connect to any organisations machine, it doesn't seem to establish WebRTC connection, at least it doesn't show it near the "Connect" button. And looking through the firewall logs, it doesn't seem that any related connections have been blocked. It does connect through WebRTC though, when I'm connecting to my machines in the same home network, which again, is NATed by my provider. But even though it does work this way, after some time in remote session, or after multiple connections to the machine, the session picture just freezes and doesn't update with the input (the input still registers). All of my tested home machines have Windows 10 21H2 x64 OS.

So I wanted to ask if I might have done something wrong, and is it worth it to use WebRTC at this time anyways, as I saw some semi-recent tickets about corruption bug with WebRTC and one opened ticket about WebRTC problems without much information (https://github.com/Ylianst/MeshCentral/issues/2863). I'm also ready to provide any necessary logs or other useful info if needed.

Server: 0.9.68 with Debian 11 and node.js v16.13.1, tested in Chrome and Firefox browsers.

also, if my english is atrocious - i am very very sorry

krayon007 commented 2 years ago

I'm not aware of any current issues, as I have fixed the corruption issues I was seeing before. I'll have to consolidate the older tickets. In your testing, how much time elapsed before you saw the freeze? Were you actively using the session when it froze, or was it idle and you found it frozen when you returned?

SEsternO commented 2 years ago

@krayon007 session was idle, it was in the other tab and after I returned to it, it was frozen. Recconecting and page refreshing didn't help. Then I restarted MeshAgent service on the remote machine and it did help. But only for some time, as the same situation repeated again. I didn't count the time precicely, but from the top of my head I can say it was 10-15 minutes after starting the session. Then I started tinkering a little with the other remote machine and I found out that I can reproduce the freeze by connecting and reconnecting to the machines continiously. The amount of connect-disconnect actions is inconsistent, it can be 3 times reconnect as well as it can be 15, and each time you need to restart MeshAgent service to unfreeze the session. The problem doesn't seem to occur by relaying the session without WebRTC.

SEsternO commented 2 years ago

Some minor detail, I just found out that if I restart the server when the session is frozen, the machine won't appear as connected in MeshCentral. MeshAgent service still shows as it's running, but doesn't seem to reconnect?..

SEsternO commented 2 years ago

I'm still tinkering with my TURN configurations and suspect that something isn't right in my config.json, as removing my TURN server from ICE servers doesn't make a difference. I use the line "credentials": "secretkey", and for my "secretkey" I use "static-auth-secret" value from turnserver.conf. Is this the right way, or for static secret key it should be parameter other than "credentials"?

Ylianst commented 2 years ago

Hi. We need to separate a few things.

Agent WebRTC. The Mesh Agent has a limited data-only WebRTC stack. Then you click connect on the remote desktop, the session starts over WebSockets, then, the browser and agent will try to switch to using WebRTC in UDP mode only. TURN is not used. So, if WebRTC with UDP can't be established, the session will stay with WebSockets.
MeshMessenger WebRTC. This is the WebRTC used between two browsers for audio/video conference. This will use the STUN/TURN settings configured in config.json.

WIth MeshAgent, we don't use TURN because WebSocket does the same work as TURN, so no need to switch to TURN. If the MeshAgent WebRTC UDB mode freezes, that is really not good. I would turn off using "WebRTC": false and we need to look at what is causing the agent to freeze.

SEsternO commented 2 years ago

@Ylianst thank you for your answer, it cleared a couple of things for me. I really thought that WebRTC and TURN would always be used for remote sessions when configured. That made me thinking if there may be a use case where you may want to have MeshCentral instance on one server, but relay sessions through another server with WebRTC and TURN... maybe for traffic management? Would it make any sense, and is it possible at all? I may not understand some things, so I'm not really sure.

Regarding the agent freeze, if there is anything I can do to help you, say for example give you some logs while reproducing the issue - feel free to ask. For now though I only see MeshAgent.log file in Program Files\Mesh Agent catalog, and it wasn't updated since the agent installation.

jacotec commented 2 years ago

@Ylianst As you've mentioned the Desktop quality is massively better using WebRTC.

I don't understand why MeshCentral can't use a TURN server here (or relay the WebRTC via the MC server). I have a TURN server up and running which works perfectly for Bigbluebutton, Jitsi and Nextcloud Talk in all scenarios. And that's all WebRTC as well. So why not use it to work around such issues?

si458 commented 1 week ago

im just tagging onto this as an update for 2024

webrtc WORKS for local use and local devices that can talk to each other this included across vlans and networks, so long as your device can access the remote device by its IP address

currently the meshagent DOESNT support using STUN, it only retrieves the devices ip addresses and offers them

HOWEVER the function ILibWrapper_WebRTC_Connection_SetStunServers is already in the source code of the meshagent!

so all we need to do is implement the function into the duktape functions, then this will allow us to access it from the javascript, which will then allow the admins of there servers to specify what stun servers to use and it will add them for use!

i also dont want to just tell the meshagent to ALWAYS use 2 default stun servers, incase they block access to them,

so doing it the way explained above is a better solution!

ALSO this will allow us to add in TURN servers to relay data through other servers instead of your meshcentral server

Ylianst / MeshCentral

[Question] About problems with WebRTC and it's current state #3463