Is there any manual on how to use turnserver_uclient and/or turnserver_peer to check that the server is configured correctly?
113 views
Skip to first unread message
Lockywolf __
Jun 25, 2021, 1:35:27 AM6/25/21
to TURN Server (Open-Source project)
Hello, everyone.
Is there any manual on how to check that the server works?
What I have now:
1) A VPS with a public ipv4 address
2) A turnserver running on it with the following config:
listening-port=3478
tls-listening-port=5349
verbose
fingerprint
use-auth-secret
static-auth-secret=<secret>
realm=my-domain
cert=/etc/ssl/my-domain.crt
pkey=/etc/ssl/turnserver/my-domain.key
log-file=/var/tmp/turn.log
no-stun
max-allocate-timeout=120
mobility
ne=2
3) I am testing it with:
turnutils_uclient vultr-seoul-openbsd.lockywolf.net -W <secret> -v
Is this the right way of testing it? Do I need a turnserver_peer instance in addition?
How do I tell this turnserver_peer instance to connect to the TURN server?
4) Anyway, what I am getting in the logs is:
4.1) On the server side:
453: handle_udp_packet: New UDP endpoint: local addr <vps ip address>:3478, remote addr <client isp address>:51592
453: session 136000000000000012: realm <my-realm> user <>: incoming packet message processed, error 401: Unaut
horized
453: IPv4. Local relay addr: <vps ip address>:52614
453: IPv4. Local reserved relay addr: <vps ip address>:52615
453: session 136000000000000012: new, realm=<my-realm>, username=<1624685301>, lifetime=777
453: session 136000000000000012: realm <my-realm> user <1624685301>: incoming packet ALLOCATE processed, succe
ss
453: session 136000000000000012: refreshed, realm=<my-realm>, username=<1624685301>, lifetime=777
453: session 136000000000000012: realm <my-realm> user <1624685301>: incoming packet REFRESH processed, succes
s
453: handle_udp_packet: New UDP endpoint: local addr <vps ip address>:3478, remote addr <client isp address>:51593
453: session 136000000000000013: realm <my-realm> user <>: incoming packet message processed, error 401: Unaut
horized
453: IPv4. Local relay addr (RTCP): <vps ip address>:52615
453: session 136000000000000013: new, realm=<my-realm>, username=<1624685301>, lifetime=777
453: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet ALLOCATE processed, succe
ss
453: session 136000000000000013: refreshed, realm=<my-realm>, username=<1624685301>, lifetime=777
453: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet REFRESH processed, succes
s
453: handle_udp_packet: New UDP endpoint: local addr <vps ip address>:3478, remote addr <client isp address>:51594
453: session 136000000000000014: realm <my-realm> user <>: incoming packet message processed, error 401: Unaut
horized
453: IPv4. Local relay addr: <vps ip address>:50322
453: IPv4. Local reserved relay addr: <vps ip address>:50323
453: session 136000000000000014: new, realm=<my-realm>, username=<1624685301>, lifetime=777
453: session 136000000000000014: realm <my-realm> user <1624685301>: incoming packet ALLOCATE processed, succe
ss
454: session 136000000000000014: refreshed, realm=<my-realm>, username=<1624685301>, lifetime=777
454: session 136000000000000014: realm <my-realm> user <1624685301>: incoming packet REFRESH processed, succes
s
454: session 136000000000000013: peer 0.0.0.0:3481 lifetime updated: 600
454: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet CHANNEL_BIND processed, s
uccess
454: session 136000000000000013: peer 0.0.0.0:3481 lifetime updated: 600
454: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet CHANNEL_BIND processed, s
uccess
454: session 136000000000000013: peer 0.0.0.0:3481 lifetime updated: 600
454: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet CHANNEL_BIND processed, s
uccess
454: session 136000000000000013: peer 0.0.0.0:3481 lifetime updated: 600
454: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet CHANNEL_BIND processed, s
uccess
455: session 136000000000000014: peer 0.0.0.0:3481 lifetime updated: 600
455: session 136000000000000014: realm <my-realm> user <1624685301>: incoming packet CHANNEL_BIND processed, s
uccess
455: session 136000000000000013: refreshed, realm=<my-realm>, username=<1624685301>, lifetime=600
455: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet REFRESH processed, succes
s
455: session 136000000000000013: peer 0.0.0.0:3481 lifetime updated: 300
455: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet CREATE_PERMISSION process
ed, success
455: session 136000000000000013: peer 0.0.0.0:3481 lifetime updated: 600
455: session 136000000000000013: peer 0.0.0.0:3481 lifetime updated: 600
455: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet CHANNEL_BIND processed, s
uccess
455: session 136000000000000014: refreshed, realm=<my-realm>, username=<1624685301>, lifetime=600
455: session 136000000000000014: realm <my-realm> user <1624685301>: incoming packet REFRESH processed, succes
s
455: session 136000000000000014: peer 0.0.0.0:3481 lifetime updated: 300
455: session 136000000000000014: realm <my-realm> user <1624685301>: incoming packet CREATE_PERMISSION process
ed, success
455: session 136000000000000014: peer 0.0.0.0:3481 lifetime updated: 600
455: session 136000000000000014: realm <my-realm> user <1624685301>: incoming packet CHANNEL_BIND processed, s
uccess
470: session 136000000000000014: refreshed, realm=<my-realm>, username=<1624685301>, lifetime=0
470: session 136000000000000014: realm <my-realm> user <1624685301>: incoming packet REFRESH processed, succes
s
470: session 136000000000000013: refreshed, realm=<my-realm>, username=<1624685301>, lifetime=0
470: session 136000000000000013: realm <my-realm> user <1624685301>: incoming packet REFRESH processed, succes
s
Lots of "Unauthorized" stuff, but those connections are getting usernames later, so I am not too worried.
4.1) On the client
0: IPv4. Connected from: 192.168.43.239:45765
0: IPv4. Connected to: <vps ip address>:3478
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: success
0: IPv4. Received relay addr: <vps ip address>:52614
0: clnet_allocate: rtv=4750228890164577426
0: refresh sent
0: refresh response received:
0: success
0: IPv4. Connected from: 192.168.43.239:43806
0: IPv4. Connected to: <vps ip address>:3478
0: IPv4. Connected from: 192.168.43.239:55600
0: IPv4. Connected to: <vps ip address>:3478
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: success
0: IPv4. Received relay addr: <vps ip address>:52615
0: clnet_allocate: rtv=0
0: refresh sent
1: refresh response received:
1: success
1: allocate sent
1: allocate response received:
1: allocate sent
1: allocate response received:
1: success
1: IPv4. Received relay addr: <vps ip address>:50322
1: clnet_allocate: rtv=7927842473967019605
1: refresh sent
1: refresh response received:
1: success
1: channel bind sent
1: cb response received:
1: success: 0x62fc
1: channel bind sent
1: cb response received:
1: success: 0x62fc
1: channel bind sent
2: cb response received:
2: success: 0x605b
2: channel bind sent
2: cb response received:
2: success: 0x605b
2: channel bind sent
2: cb response received:
2: success: 0x7082
2: Total connect time is 2
2: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
3: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
4: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
5: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
6: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0
7: start_mclient: msz=2, tot_send_msgs=1, tot_recv_msgs=0, tot_send_bytes ~ 100, tot_recv_bytes ~ 0
8: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
9: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
10: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
11: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
12: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
13: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
14: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
15: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
16: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
17: start_mclient: msz=2, tot_send_msgs=10, tot_recv_msgs=0, tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
17: done, connection 0x7f4f2c24e010 closed.
17: done, connection 0x7f4f2c26f010 closed.
17: start_mclient: tot_send_msgs=10, tot_recv_msgs=0
17: start_mclient: tot_send_bytes ~ 1000, tot_recv_bytes ~ 0
17: Total transmit time is 15
17: Total lost packets 10 (100.000000%), total send dropped 0 (0.000000%)
17: Average round trip delay 0.000000 ms; min = 4294967295 ms, max = 0 ms
17: Average jitter -nan ms; min = 4294967295 ms, max = 0 ms
Seems to be a total failure!
Zero bytes received, even though the server does receive something and do something with it!
Is it that I also need a turnserver_peer somewhere?
Or is there some firewall that is restricting the data going out?
Any help would be appreciated.
Giacomo Vacca
Jul 26, 2021, 9:53:36 AM7/26/21
to TURN Server (Open-Source project)
turnutils_uclient should be used either with the '-y' option, which would make it simulate two TURN clients exchanging RTP and RTCP when connected at the same TURN server, or without the '-y' option and turnutils_peer working as a peer (and echoing back all the received UDP packets).
See e.g.:
https://manpages.debian.org/testing/coturn/turnutils_uclient.1.en.htmlThe 401 Unauthorised are just part of the TURN server challenge to a client during an Allocate request, see "Allocations" in RFC 5766 (https://datatracker.ietf.org/doc/html/rfc5766#section-2.2).
It might be useful to take network traces on the host where the TURN server runs: it will allow you to see the network activity beyond what the test client reports.
In general you should see data received on the TURN side being relayed to the peer from the allocated relay transport address, and in the opposite direction.
Giacomo
Reply all
Reply to author
Forward
0 new messages