Questions about WebRTC on [Desktop]

[baikal]

Iirc, there used to be the indication 'WebRTC' on the header bar of a connect "Desktop", if certain conditions where met, like:

• WebRTC enabled in server-config
• Machines in same LAN or somehow reachable otherwise
• ...

I do not have seen that for a quite a while, so did something change or is just that indication no longer shown? I do remember that at some point, WebRTC was switched on by default (this is not reflected in the sample-config.json, btw - and what are the WebRtConfig.iceServers settings for?).

How could I test, if the setting is really on and why it is not setting in?

[krayon007]

Which browser are you using? Are your machines multihomed? It works well with Chrome and the chromium based Edge browser. It works on Firefox as long as you aren't multihomed, as Firefox doesn't always advertise on the correct interface.

I have also seen some versions of windows have the firewall set to block all inbound UDP packets. The next agent update will have code to allow inbound UDP by the agent binary, to address that on Windows.

If it isn't one of the above issues, then I'm not sure, as I use webrtc all the time...

[Ylianst]

Also, right now if you turn on the desktop multiplexor ("desktopmultiplex":true in settings) this will disable WebRTC (but may fix this in the future).

[baikal]

@krayon007 Browser Chrome (on Linux/Ubuntu), multihomed - no (well maybe having two IPs from the same LAN as of Ethernet+WLAN) - will try with again unplugging Ethernet everywhere to be sure, and different browsers ...

[baikal]

after restarting MC server with WebRTC explicitly on, no DesktopMultiplex and only one IP (besides 127.0.0.1) on "Remote" (Win 10) and "Local" (Ubuntu 19.04) and MC-Server (that one not in same LAN):

• Chrome: no WebRTC
• Firefox: no WebRTC
• Chromium: with WebRTC

which kind of tracing to enable to see whats going on?

[krayon007]

That particular logging functionality is only compiled into the debug build, so if you unzip the attached agent, and and then grab the .msh file from your setup, and place them into the same folder somewhere.... Then run the agent with the following command line switches: MeshAgent --disableUpdate=1 --enableILibRemoteLogging=9095

(You can use any port number, just substitute it above instead of 9095) After the agent starts in console mode, just point a browser on the local machine to localhost:9095 or whatever port you used.

Then click on the 'Selected Modules' tab, and select all three webrtc items. You should see a message added to the log with every item you select. Each of the three items is color coded, so you'll see which log entry goes to which one. (Leave verbosity at the default setting of '1' for now)

Then use the agent as normal, and try to connect desktop... You should see all the pertinent logs for WebRTC. The ones of interest are the WebRTC offer. It will contain the IPAddress and port that the browse wants the agent to send STUN packets to... You should also see the STUN packets, and hopefully the DTLS/SCTP packets.

Attached is what a successful session looks like:

MeshAgent.zip

[baikal]

Hi @krayon007 Thank you. I noticed that it probably should be MeshAgent connect --disableUpdate=1 --enableILibRemoteLogging=9095 right? I did get the logging going, now to figure out what all means... Is the 'Set ICE/Offer' what the Agents sends to the Client/Browser and 'Return ICE/Response' what the Browser sends back? (in your log, I did only see IPs in the Response). Or the other way round?

[krayon007]

In this case the set offer is what the browser sent, and the response is what the agent sent back.

I just noticed the browser didn't send any candidates. In this case it still worked because the browser sent packets to the agent, and the agent responded (which is why the initial packet said no valid candidates)

This means it wouldn't work across the internet unless the browser sent valid candidates. The stun server the browser is configured with must not be working... I'll see if I can verify that.

[ghost]

@krayon007 @Ylianst Can you please clarify exactly which TCP/UDP ports have to be open in the firewall of the MeshCentral server and the MeshAgent client for this feature to work? I've been trying to establish a WebRTC connection for about an hour without success. The provided debug build's web interface doesn't output any information for me when I enable the three options and connect to the agent. Also, WebRTC is enabled in my config.json file and desktop multiplexing is disabled.

[krayon007]

None of the ports need to be opened. The intent of webrtc, is that it does NAT-traversal on it's own. The way it works, is that each endpoint sends an outbound UDP port to the other endpoint. This creates a port-mapping at the router. If the NAT type is a full cone NAT, than any traffic received on that port mapping, will be mapped back to the endpoint. So what the WebRTC offer does, is expose the public IP/Port pair to each side (the candidate pairs), so that two two endpoints can traverse the respective NATs. If the packets are successfully routed, DTLS and SCTP is used to secure the connection.

[krayon007]

The most common problem with WebRTC, is that the NAT type is restrictive, which makes it difficult (sometimes impossible) to create a reliable port-mapping. WebRTC also does not work, if UDP packets cannot be sent across the internet, such as if your network requries a proxy, etc.. In those cases, a TURN (TCP/UDP Relay) needs to be setup. A TURN server is sort of like a socks-5 proxy.

[ghost]

@krayon007 Thank you for the detailed info. I'm not sure why it's not working then because neither the client on which MeshAgent is running nor the server on which MeshCentral is running are behind NAT. I even set up my own TURN server using Coturn earlier today and specified its address in my config.json file, but MeshCentral continues to say "Connected" instead of "Connected, WebRTC". I feel like I must be missing something obvious here because it seems to work fine for everyone else in Chrome/Chromium.

config.json

{
  "$schema": "http://info.meshcentral.com/downloads/meshcentral-config-schema.json",
  "settings": {
    "aliasPort": 443,
    "allowFraming": true,
    "cert": "mesh.datahoarder.dev",
    "dbRecordsEncryptKey": "<redacted>",
    "manageCrossDomain": [ "user//admin" ],
    "minify": true,
    "mongoDb": "mongodb://<redacted>@127.0.0.1:27017/meshcentral",
    "mongoDbCol": "meshcentral",
    "mpsPort": 7448,
    "mpsTlsOffload": true,
    "port": 7450,
    "redirPort": 7449,
    "sessionKey": "<redacted>",
    "sessionTime": 60,
    "tlsOffload": true,
    "trustedProxy": "127.0.0.1",
    "webRTC": true,
    "webrtConfig": {
      "iceServers": [
        { 
          "urls": "stun:stun.datahoarder.dev:3478"
        }
      ]
    }
  },
   "smtp": {
   "host": "mail.datahoarder.dev",
   "port": 465,
   "from": "[email protected]",
   "user": "<redacted>",
   "pass": "<redacted>",
   "tls": true
  },
  "domains": {
    "": {
      "certUrl": "datahoarder.dev:443",
      "newAccounts": true,
      "title": "Project Data Hoarder",
      "title1": "Project Data Hoarder",
      "title2": "",
      "titlePicture": "",
      "agentInviteCodes": true
    }
  }
}

[folosleg]

Remote desktop WebRTC doesn't work for me either. Doesn't even seem to try negotiate WebRTC over the wss control channel. On the other hand WebRTC within chat works fine... I'm lost here. Can anybody elaborate please? (The debug build from 2020 doesn't work anymore)

[krayon007]

There was a change in chromium that broke webrtc data channels for mesh, so we turned off webrtc by default. However, I have since fixed this issue, so it should return in the next agent update that were testing now.

[antibyte]

There was a change in chromium that broke webrtc data channels for mesh, so we turned off webrtc by default. However, I have since fixed this issue, so it should return in the next agent update that were testing now.

On Chrome and Edge i can not get mouse and keyboard working. The Desktop shows but no interaction is possible. Using Firefox everything works as expected. Is there still a problem with WebRTC on Chrome ?

[folosleg]

Actually under Chrome mouse and keyboard input works, just the desktop doesn't refresh... The first full image is downloaded (probably still over ws), but further updated tiles don't (probably after WebRTC setup). That's why it seems like input is broken.

Shall we open a new issue?