Closed lapineige closed 3 years ago
I searched a bit about the server configuration files, and it happens that there is no STUN/TURN server configured (as described here https://galene.org/README.html). Maybe that's the issue ?
Yes, I have it working with ice-servers.json configured according to coturn.conf shipped with Synapse app for Yunohost. Thanks a lot !! 🚀
You mean we can reuse that coturn server ? That's good news :) (it avoid duplicates, I guess)
Where do you find that config (file) ?
Nice, @raspoutnik do you mind sharing your ice-servers.json
setting.
I guess it can be reused... Config file is /etc/matrix-synapse/coturn.conf But I'm leaving another call with someone else, and he didn't manage to have my webcam, while I had both, his and mine. Maybe have to configure STUN server too ? Also, I reproduced the previously successful combination and now face the same issue.
Here is my /opt/yunohost/galene/data/ice-servers.json
[ { "urls": [ "turn:MY_SYNAPSE_DOMAIN:5349", "turn:MY_SYNAPSE_DOMAIN:5349?transport=tcp" ], "username": "galene", "credential": "STATIC_AUTH_SECRET_AS_IN_COTURN.CONF", "credentialType": "hmac-sha1" } ]
It works !! 🚀
Maybe have to configure STUN server too ?
I'm clearly not an expert, but I believe a TURN server should include STUN server use cases, so I don't think that the issue… but this has to be confirmed. Maybe there is an issue with synapse using the TURN server too ?
ping @Josue-T, you might have some clue here.
I moved from Firefox to Chrome on my Android with LTE connection and have it working bothsides with Firefox on my desktop computer again. Further STUN tweaks do not change anyting...
With Firefox on Android I face these types of logs from galene.service :
Jan 11 18:47:45 galene[2869]: 2021/01/11 18:47:45 Read RTCP: io: read/write on closed pipe Jan 11 18:47:47 galene[2869]: 2021/01/11 18:47:47 sendSR: io: read/write on closed pipe Jan 11 18:47:51 *** galene[2869]: 2021/01/11 18:47:51 sendSR: io: read/write on closed pipe
I had the issue yesterday, I did kill TURN server and launch it back, now the issue is gone… strange…
If someone as some time to try, there is a Galène version with COTURN in here : https://github.com/YunoHost-Apps/galene_ynh/tree/COTURN. Still work to do. (restore not working yet.)
I upgraded to that version (by forcing it, as it's the same manifest version):
cp: cannot create regular file '/etc/galene/coturn.conf': No such file or directory
And then :
Could not upgrade galene: This action broke dpkg/APT (the system package managers)... You can try to solve this issue by connecting through SSH and running
sudo apt install --fix-broken
and/orsudo dpkg --configure -a
.
😅
Now even getcwd()
fails 😅
edit: I fixed it. Install works.
It doesn't work. Turn server is running, but no stream is shared with the server.
New version in master. I will advice not to do a single upgrade but to reinstall the app as a lot of code have been added.
In this new version:
/relay-test
in the chat box; if the TURN server is properly configured, you should see a message saying that the relay test has been successful. (you have to connect first with you operator account)GROUPNAME.json
Thanks in advance for testing!
PS. I open the Discussions
tab (on the right of Pull Requests
). For general matters we should us it and leave the Issues
for actual bug report.
Relay test failed: Error: timeout
:(
I don't know how where to check for logs…
edit: ok, it was simply in /var/log/galene/turnserver.log
0: Trying to bind fd 41 to <127.0.0.1:3478>: errno=98
0: Fatal final failure: cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478
0: Cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478
0: Fatal final failure: cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478
I will advice not to do a single upgrade but to reinstall the app as a lot of code have been added.
Ok thanks for the tip :+1: (and it's super easy to manually backup both groups and ice configuration, just a few files to copy)
PS. I open the Discussions tab (on the right of Pull Requests). For general matters we should us it and leave the Issues for actual bug report.
Oh, I did not know that feature… that could be useful indeed :)
Hi, thank you !
I tried the new version, I also have timeout error. I lose the stream sharing when switching to 4G network, but have it inside LAN. I checked open ports on my ISP box (5350 and new 5351), tried to change to 5351, 5352 in both config files, supposing 5350 may conflict with Synapse's Coturn configuration... but no luck.
I do not have abnormal warnings in /var/log/galene/turnserver.log, it seems to have initialized normally.
I got back to Synapse-linked configuration, this time with both 5349 and 5350 ports, TCP and UDP, and it also works, relay-test ok.
It looks like the second coturn server is unreachable from the outside...
I tried the new version, I also have timeout error. I lose the stream sharing when switching to 4G network, but have it inside LAN.
Then indeed it's really a NAT / TURN server issue…
@Josue-T maybe you might have some input here ? (based on your Synapse packaging experience)
On my VPS server, TURN is working with Galène. It also worked alongside Synapse. You can also test if you turn server is running with this https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Not sure about how that site work, but "gather candidates" doesn't give me any result.
I've synapse installed too.
The most conclusive result I had with this tool, using "turn:galene.domain:5351?transport=tcp" for example, is that there is no clear indication that a relay has been detected, neither where, but an execution time and the word "Done", instead of "Not Reachable ?" with wrong parameters, either when switching to IceTransports value fixed to "relay". The same applies with turn:synapse.domain:5349 and 5350. So I guess it is reachable.
But /relay-test still fails with default galene ice-servers.conf, and succeeds with synapse's parameters...
I upgraded to #14, it still fails 😢
If you're running Galène 0.3, you may test your TURN server by typing /relay-test
in the chat. (No need to be administrator, you just need to be logged in.)
That's what I did we previous versions and now with 0.3, but it always gives me an (instantaneous) timeout.
edit : @ericgaspar I just realised that my 3478 port is closed, is that a problem ? It tries to access 127.0.0.1 so I suppose the port doesn't need to be opened for localhost ?
The TURN port must be accessible to the client, so it must be open.
Then maybe we found the issue… it should be opened https://github.com/YunoHost-Apps/galene_ynh/blob/testing/scripts/install#L93 (and I tried with a fresh install)
Galène used TURN over plain TCP and UDP, not over TLS (Galène's traffic is already encrypted, so contacting the TURN server over TLS is not useful). Coturn accepts plain TCP connections on the TLS port, so it happens to work, but I find your configuration confusing.
Currently, galene.org uses the built-in TURN server, but here's my TURN configuration on another instance of Galène that still uses coturn:
listening-port=1194
lt-cred-mech
user=xxx:yyy
realm=irif.fr
syslog
Then I wonder why I have this error with /relay-test in the log : https://github.com/YunoHost-Apps/galene_ynh/issues/10#issuecomment-760019960
Disclaimer: I'm a total TURN noob, so I might be completely off-topic.
0: Trying to bind fd 41 to <127.0.0.1:3478>: errno=98 0: Fatal final failure: cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478 0: Cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478 0: Fatal final failure: cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478
Errno=98 indicates that somebody else has already bound port 3478. Please run netstat -apn
as root in order to find out who.
I just checked with latest version (0.3, with a lot of changes in turn server config since my previous test), I don't have this error in the log.
I see some logs about turn server creation (8 times):
[…] IO method (general relay thread): epoll (with changelist) turn server id=4 created Total General servers: 8
And something about the relay:
relay SOME_IP_ADDRESS initialization... relay SOME_IP_ADDRESS initialization done Relay ports initialization done
I'll try to open the port.
@lapineige You may want to test the version with build-in TURN server :
sudo yunohost app install https://github.com/YunoHost-Apps/galene_ynh/tree/without-turn-0.3
Oh ok, when I saw the name of the PR I thought it was a special version with no TURN server at all… I was wondering what it was :sweat_smile:
I'll try it :)
Oh ok, when I saw the name of the PR I thought it was a special version with no TURN server at all… I was wondering what it was 😅
Galène 0.2 relied on an external TURN server. It turned out that installing coturn was a major stumbling block for many users.
Galène 0.3 includes a built-in TURN server which is started automatically if no ice-servers.json file is found. This can be controlled explicitly using the -turn command-line option.
The built-in TURN server does not have all of the features of coturn (it cannot do IPv6 and it implements the protocol incorrectly in some cases), but it works well enough in practice. Please report bugs here:
Galène 0.2 relied on an external TURN server. It turned out that installing coturn was a major stumbling block for many users.
I'm not surprised (and that was something that gave a lot of work to @ericgaspar for this Yunohost package), so thanks a lot, that's a great addition.
Current Git master goes further, automatically generating a self-signed certificate if none is found under the data/ directory. Let me know if this feature is useful for you and you want me to tag a release.
We do generate a self-signed certificate. Adding a built-in TURN server and generating a self-signed certificate are great additions. This simplifies the package. If you have the time to post a tag release, I'll make sure to update the package!
You may want to test the version with build-in TURN server :
Relay test successful in 245ms, RTT 18ms
and it works out of the box ! 🎉 🚀
That's great !
What are the limitations of using this built-in TURN server ? I wonder if we could integrate only that server, or if we should propose an option (or other branch / a tutorial ?) for the full TURN server if needed.
We've been running it in production for a few weeks, and it works well enough for our students. I think you should switch to using the built-in TURN server, it's simpler and works well enough in practice.
The main limitations are that it doesn't do IPv6 and that error-handling is not up to spec. I'm planning on fixing that at some point, but it's a pretty low priority.
IPv6 might be an issue, so I believe we need an alternative. But I don't think that should prevent us from using the integrated server by default. Maybe we could keep the other server in a separate branch from the moment ?
What do you think @ericgaspar ?
IPv6 might be an issue, so I believe we need an alternative.
Galène will still work with IPv6 — it's only the TURN server that doesn't:
Since clients with IPv6 available don't usually need to go through a TURN server, it should not be a problem in practice.
@ericgaspar,
We do generate a self-signed certificate.
I see. Switching to current head master would allow you to remove this block of code, and to remove a dependency on the OpenSSL CLI, at the price of not having a stable fingerprint (the certificate would be regenerated every time Galène is restarted).
Please give me a few days, I want to tweak the code some more before I make a release.
@lapineige
What do you think @ericgaspar ?
My plan is to push the build-in TURN server version in master. The version with additional coturn installation will go to another branch and need to be reworked, but the idea is to get coturn out of the package and put the effort on maintaining coturn_ynh instead (TURN server is also needed for other apps Nextcloud, XMPP...).
Sounds good :) And we will have a working version by default :tada:
Closing this, as it's fixed by #20
generating a self-signed certificate are great additions. This simplifies the package. If you have the time to post a tag release, I'll make sure to update the package!
I've just tagged 0.3.1. A self-signed certificate will be generated if neither cert.pem nor key.pem are found.
(Install works well, thanks a lot for that package ! :rocket:)
I tried to use it (from several browsers, internet connection, and PC + phone), by sharing sounds+camera and/or screen, those streams are shown in the local browser, but not shared to others participants.
Here is the output of galene service status:
I can't reproduce that message, so I don't know if it's linked.
Also there is no bandwidth indication at the bottom of each stream frame, which might indicate that nothing is sent ? :thinking: