Nextcloud can't reach Turn Server after update to 20.0.5

ℹ️ Support 💬 Talk (spreed)
1

Hello,

I updated my installation to version 20.0.5 today. Since then, Talk can not reach the turn server that is installed on the same machine. Before that, it worked fine and passed the integrated check. Since the update, it just keeps spinning but does not output an error. I already restarted the turn server as well as the entire machine.

System: Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-1026-raspi aarch64)
Coturn: 4.5.1.1-1.1ubuntu0.20.04.2

If you need any further information please let me know.

Best wishes.

2

I have just rolled back the update and the issue remains unsolved. I have had a look into my last system update.
The following upgrades have been made.

Upgrade: netplan.io:arm64 (0.100-0ubuntu4~20.04.3, 0.101-0ubuntu3~20.04.2), libsystemd0:arm64 (245.4-4ubuntu3.3, 245.4-4ubuntu3.4), udev:arm64 (245.4-4ubuntu3.3, 245.4-4ubuntu3.4), libudev1:arm64 (245.4-4ubuntu3.3, 245.4-4ubuntu3.4), systemd-timesyncd:arm64 (245.4-4ubuntu3.3, 245.4-4ubuntu3.4), systemd-sysv:arm64 (245.4-4ubuntu3.3, 245.4-4ubuntu3.4), libpam-systemd:arm64 (245.4-4ubuntu3.3, 245.4-4ubuntu3.4), systemd:arm64 (245.4-4ubuntu3.3, 245.4-4ubuntu3.4), sosreport:arm64 (4.0-1~ubuntu0.20.04.2, 4.0-1~ubuntu0.20.04.3), libnss-systemd:arm64 (245.4-4ubuntu3.3, 245.4-4ubuntu3.4), libnetplan0:arm64 (0.100-0ubuntu4~20.04.3, 0.101-0ubuntu3~20.04.2), linux-firmware:arm64 (1.187.7, 1.187.8)

Does anyone see a package that might compromise Nextcloud’s ability to connect to my coturn server?

3

I have installed Nextcloud on a Debian machine now (x86_64), set up coturn again, configured everything to the installation guide, and even exposed the entire host to the internet. Different portscans all confirm the ports are open and coturn logs that it can bind to the ports. I have now even tried to just connect two devices in the same local network as ther servers and it will not connect, neither with and without the coturn server enabled in the Talk config. Something is really wrong. What am I missing?

Linux 4.19.0-13-amd64 on x86_64
coturn: 4.5.1.1-1.1+deb10u2

4

same issue with nextcloud 20.0.6 :

screen_2021-01-30-21h25m03
screen_2021-01-30-21h25m031278×202 24.7 KB

worked fine with nextcloud 20.0.4
screen_2021-01-30-21h24m04
screen_2021-01-30-21h24m041297×188 19.9 KB

as you can see same server same secret
you an test it if you want :
194c6d62f4b09dd8f3d073f030525c2980d62e988ed224716ea115c751bd9e5d

i will change the secret in 2 weeks

on turn log i can see :
when working fine :
38993: : session 002000000000000005: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
38993: : session 000000000000000008: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
38993: : IPv4. tcp or tls connected to: 37.171.82.61:58555
38993: : IPv4. tcp or tls connected to: 37.171.82.61:58563
38993: : session 001000000000000014: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
38993: : IPv4. Local relay addr: 192.168.123.69:52015
38993: : session 002000000000000005: new, realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, lifetime=3600
38993: : session 002000000000000005: realm <gssh.pra.rip> user <1612039643:turn-test-user>: incoming packet ALLOCATE processed, success
38993: : session 000000000000000009: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
38993: : IPv4. Local relay addr: 192.168.123.69:51305
38993: : session 000000000000000008: new, realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, lifetime=3600
38993: : session 000000000000000008: realm <gssh.pra.rip> user <1612039643:turn-test-user>: incoming packet ALLOCATE processed, success
38993: : IPv4. Local relay addr: 192.168.123.69:54188
38993: : session 001000000000000014: new, realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, lifetime=3600
38993: : session 001000000000000014: realm <gssh.pra.rip> user <1612039643:turn-test-user>: incoming packet ALLOCATE processed, success
38993: : IPv4. Local relay addr: 192.168.123.69:49348
38993: : session 000000000000000009: new, realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, lifetime=3600
38993: : session 000000000000000009: realm <gssh.pra.rip> user <1612039643:turn-test-user>: incoming packet ALLOCATE processed, success
38993: : session 002000000000000005: refreshed, realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, lifetime=0
38993: : session 002000000000000005: realm <gssh.pra.rip> user <1612039643:turn-test-user>: incoming packet REFRESH processed, success
38993: : session 000000000000000008: refreshed, realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, lifetime=0
38993: : session 000000000000000008: realm <gssh.pra.rip> user <1612039643:turn-test-user>: incoming packet REFRESH processed, success
38993: : session 001000000000000014: refreshed, realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, lifetime=0
38993: : session 001000000000000014: realm <gssh.pra.rip> user <1612039643:turn-test-user>: incoming packet REFRESH processed, success
38993: : session 000000000000000009: refreshed, realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, lifetime=0
38993: : session 000000000000000009: realm <gssh.pra.rip> user <1612039643:turn-test-user>: incoming packet REFRESH processed, success
38993: : session 001000000000000014: TCP socket closed remotely 37.171.82.61:58555
38993: : session 001000000000000014: usage: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, rp=3, rb=308, sp=3, sb=312
38993: : session 001000000000000014: peer usage: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, rp=0, rb=0, sp=0, sb=0
38993: : session 000000000000000009: TCP socket closed remotely 37.171.82.61:58563
38993: : session 000000000000000009: usage: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, rp=3, rb=308, sp=3, sb=312
38993: : session 001000000000000014: closed (2nd stage), user <1612039643:turn-test-user> realm <gssh.pra.rip> origin <>, local 192.168.123.69:3478, remote 37.171.82.61:58555, reason: TCP connection closed by client (callback)
38993: : session 000000000000000009: peer usage: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, rp=0, rb=0, sp=0, sb=0
38993: : session 000000000000000009: closed (2nd stage), user <1612039643:turn-test-user> realm <gssh.pra.rip> origin <>, local 192.168.123.69:3478, remote 37.171.82.61:58563, reason: TCP connection closed by client (callback)
38993: : session 001000000000000014: delete: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>
38993: : session 000000000000000009: delete: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>
38994: : session 000000000000000008: usage: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, rp=3, rb=308, sp=3, sb=312
38994: : session 000000000000000008: peer usage: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, rp=0, rb=0, sp=0, sb=0
38994: : session 000000000000000008: closed (2nd stage), user <1612039643:turn-test-user> realm <gssh.pra.rip> origin <>, local 192.168.123.69:3478, remote 37.171.82.61:58565, reason: allocation timeout
38994: : session 000000000000000008: delete: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>
38994: : session 002000000000000005: usage: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, rp=3, rb=308, sp=3, sb=312
38994: : session 002000000000000005: peer usage: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>, rp=0, rb=0, sp=0, sb=0
38994: : session 002000000000000005: closed (2nd stage), user <1612039643:turn-test-user> realm <gssh.pra.rip> origin <>, local 192.168.123.69:3478, remote 37.171.82.61:58552, reason: allocation timeout
38994: : session 002000000000000005: delete: realm=<gssh.pra.rip>, username=<1612039643:turn-test-user>

when not working :
39050: : session 003000000000000011: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39050: : session 000000000000000010: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39050: : session 003000000000000011: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39050: : session 000000000000000010: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39051: : session 003000000000000011: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39051: : session 000000000000000010: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39051: : session 003000000000000011: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39051: : session 000000000000000010: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39052: : session 003000000000000011: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39052: : session 000000000000000010: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39053: : session 003000000000000011: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39053: : session 000000000000000010: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39057: : session 003000000000000011: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized
39057: : session 000000000000000010: realm <gssh.pra.rip> user <>: incoming packet message processed, error 401: Unauthorized

seems login not sent

turn server : coturn version 4.5.2-1
i suspect a bug on talk side

5

Can you still establish a connection between two devices in the same network?

7

i can t test
but 2 devices using vpn (same network) don t work with 20.0.6 , working fine with 20.0.4

thank you

pra

8

I tried rolling back to version 20.0.4. before my intial post, but that did not work either.

9

same issue with 20.0.7, but talk version is the same : 10.0.5
@MaxPax i think you are with talk version 10.0.5 should be under , not sure if you can downgrade

10

Yes, I am using Talk 10.0.5. Did you get it working with a previous version?

11

Updating to 20.0.7 got some connections working again. I still have to test whether it can connect to my turn server—Will update.

12

hello, my problem I do not know if it is similar, the errors in the chrome debugging console are these
“signaling.js: 854 Could not connect to server {id:” 1 “, type:” error “, error: {…}} error: {code:” internal_error “, message:” nats: connection closed "} id: “1” type: “error” __ proto__: Object
m.Standalone.helloResponseReceived @ signaling.js: 854
(anonymous) @ signaling.js: 640 "
"signaling.js: 551 WebSocket connection to ‘wss: //signaling.xxx/standalone-signaling/spreed’ failed: WebSocket is closed before the connection is established.
m.Standalone.reconnect @ signaling.js: 551
(anonymous) @ signaling.js: 625 "

This happened after updating talk to 10.05 (I don’t know how to downgrade)
Updating nexcloud to 20.07 did not fix the problem

13

To downgrade you would need a backup of your database and your HTML folder.

14

After having updated to 20.0.7, I was still having issues with some connections, but after reinstalling my Google Chrome those last issues were resolved.

15

@MaxPax not working for me …
worked with build 10.0.4. not in 10.0.5. using nextcloud talk under iphone / ipad with vpn or not

16

Sorry I would love to help you, but I have no idea what exactly did the trick for me.
All I know is that something, while updating my Nextcloud to 20.0.7, updating my Debian Server, and reinstalling my Google Chrome fixed something.

17

no problem

18

with the new build of talk test is ok now

thank you