typpo/rfc5766-turn-server

Automatically exported from code.google.com/p/rfc5766-turn-server

rfc5766-turn-server's Issues

Peer permission is not checked on incoming packets to the relay socket

If you do not set permissions to any peer, you will still be receiving packets 
from the peer. Those packets must be rejected. Found by Roman Lisagor.

Original issue reported on code.google.com by [email protected] on 5 Jun 2013 at 11:53

TCP relay endpoints (RFC 6062) are not supported, yet.

We support UDP, TCP, TLS, DTLS protocols on client-to-TURN side (as in RFC 
5766) but on the relay side only UDP is supported (again, as required by RFC 
5766). But our goal, eventually, is no support TCP on the relay side, too, as 
dscribed in RFC 6062.

Original issue reported on code.google.com by [email protected] on 3 Mar 2013 at 7:46

Incorrect command-line options produce bus error in turnserver process

What steps will reproduce the problem?

$ turnserver -c

What is the expected output? What do you see instead?

Expected is a help text. But it produces a crash.


Reported by John Selbie.

Original issue reported on code.google.com by [email protected] on 12 May 2013 at 4:17

log file is empty

What steps will reproduce the problem?
1. install turn server 1.8.4.0
2. edit /etc/turnserver.conf with followins:-
    no-stdout-log
    log-file=/var/tmp/turn.log
    #syslog
3. start server with command:
    $ turnserver

What is the expected output? 
    no output in the console
    messages logs in the log file
What do you see instead?
    the log printed in the console
    log file created under /var/tmp with empty.

What version of the product are you using? On what operating system?
    turnserver 1.8.4.0, ubuntu 12.04-64

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 16 May 2013 at 8:43

Recovery from Linux overload situation must be more graceful and complete

The problem and the solution is described here:

http://archives.seul.org/libevent/users/Jul-2013/msg00017.html

Original issue reported on code.google.com by [email protected] on 20 Jul 2013 at 6:18

Ability to set TCP connection timeout

Need to add ability to set TCP connection timeout

Now it's 30 seconds and after that client will be disconnected from server

looks like it's #define TURN_MAX_TO_ALLOCATE_TIMEOUT (30)  param in 
ns_turn_server.c

Original issue reported on code.google.com by [email protected] on 11 May 2013 at 10:53

Timestamp in ephemeral username should be expiry timestamp instead of creation timestamp

Currently the timestamp in the ephemeral username is the time at which that 
username was created.  This means that both the web service creating the 
username and the TURN server have to be independently configured with the same 
TTL for everything to work as expected.

I think it would make more sense to put the expiry timestamp in the username, 
so the TURN server just needs to check whether it is in the past.  The web 
service is the only component that needs to be configured with the TTL, so 
you're less likely to see unexpected behaviour due to misconfiguration.

Original issue reported on code.google.com by [email protected] on 4 Jun 2013 at 3:45

turnserver cannot parse correctly config file values in form option="value"

If symbol {"} is involved, then the value is not getting parsed properly.

Original issue reported on code.google.com by [email protected] on 26 May 2013 at 6:16

how to support STUN CHANGE_REQUEST?

I want to support STUN CHANGE_REQUEST,how should i do?

must hava a server which has two net cards,
and set different public ip to them?

thanks

Original issue reported on code.google.com by [email protected] on 16 Jul 2013 at 11:29

This TURN server does not work with Stuntman clients

John Selbie reported:

=====================================

I am contributing a patch to the 1.8.3.4 source tree that will allow the client 
program from the Stuntman source to make STUN binding requests to your server.


Here's the gist of the change. Stuntman comes with a STUN client library and 
client program. The client program displays the mapped IP address and port if 
it gets back a successful binding response.  It also interops with JSTUN, a 
Java implementation of STUN. However, the JSTUN server refuses to respond to 
any binding request that doesn't have a CHANGE-REQUEST attribute in it.  I had 
previous contacted the developer of that code base about the issue, but he 
didn't respond back.  So the only workaround is for the client to make a 
request with an empty CHANGE-REQUEST attribute (neither the ip or port bit are 
set).

I can see in the code you don't explicitly support the CHANGE-REQUEST attribute 
unless RFC 5780 mode is turned on.  Otherwise, an error response is sent back. 
And it doesn't appear that is an option for the user to enable this yet.  So 
the patch I'm providing allows the code to reasonably accept an EMPTY 
CHANGE-REQUEST attributes, while rejecting anything else.

======================================================

Original issue reported on code.google.com by [email protected] on 1 May 2013 at 5:39

Attachments:

• rfc5766-turn-server.patch

does turnserver support the older "classic" STUN RFC3489 messages ?

What steps will reproduce the problem?

I deployed turnserver in one of my machine(192.168.11.53). When I tried with 
the buildin tool 
   turnutils_stunclient 192.168.11.53
I can get the response successfully. (see the No.3 message in the attached file)
I setup a softphone(xlite) in another machine(192.168.11.188) with stun 
configuration.
When the turnserve received the request, no response will be send back. (See 
the No.13 message in the attached file)
Is that means turnserver doesn't support the classic stun message.


What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 17 May 2013 at 3:28

Attachments:

• jjz.cap

Make TCP and TLS listeners co-existing on the same port

Currently the TURN server requires that TCP and TLS listeners are having 
different ports, with the default values as in RFC5766. But the WebRTC may 
require that both are running on the same port.

Original issue reported on code.google.com by [email protected] on 2 May 2013 at 9:47

Stale Nonce option behaves incorrectly

Stale Nonce functionality code has typo and has to be fixed

Original issue reported on code.google.com by [email protected] on 25 Apr 2013 at 8:46

Sockets leak and DOS attack prevention

What steps will reproduce the problem?
1.I use pjnath library, and pjsua client(UAS,UAC)

2.Client fast speed duplicate connect and disconnect, and then sometimes(upon 
4) later will reproduce the problem. I find 
client_ss_allocation_timeout_handler(refresh_client_ss_allocation_timeout_handle
r) the callback will run loss sometimes. why? This libevent library is a issue?


What version of the product are you using? On what operating system?
The new version also has this problem.

Please provide any additional information below.
Sorry, I know little English, I hope you can understand what express meaning .
Thank you!

Original issue reported on code.google.com by [email protected] on 18 Jul 2013 at 6:01

Authentication unnecessary required when client connects to the load balancer server

The server that just returns 300 ALTERNATE-SERVER response, requires 
authentication in pretty much the same way as the "real" server. This is 
allowed by the RFC 5389, but this is unnecessary and it may complicate the 
setup.

Original issue reported on code.google.com by [email protected] on 6 Aug 2013 at 5:55

System install procedure must be cleaned

Lots of things are missed in general installation procedure. In FreeBSD port, 
somethings are missed, too.

Original issue reported on code.google.com by [email protected] on 28 Apr 2013 at 7:21

Attribute ERROR in the "Classic" STUN has modern padding from RFC 5389

If an error is returned from the server in "classic" STUN operation, it is 
formatted as if the modern RFC 5389 was used.

Original issue reported on code.google.com by [email protected] on 3 Aug 2013 at 6:19

Segmentation fault

What steps will reproduce the problem?
1. Launch turnserver with the parameters below (on Ubuntu 12.10, running on 
Azure)
2. Try to establish a WebRTC connection between two browsers ith Chrome 25.

What is the expected output? What do you see instead?
As soon as the browsers try to connect, the turnserver process exits with a 
"segmentation fault".

What version of the product are you using? On what operating system?
Version Citrix-1.6.1.2, newly built from the svn repo.

Please provide any additional information below.

Here's the log file:

Administrator@alantaux1:/usr/local/bin$ turnserver -r alanta.com -X 
168.61.73.72 --no-tls --no-dtls -a -b turnuserdb.co
nf -f -u [email protected]:password -v
RFC 5389/5766/6062/6156 STUN/TURN Server, version Citrix-1.6.1.2 'Whirrun'
File found: ../etc/turnserver.conf
File found: ../etc/turnserver.conf
File found: ../etc/turnuserdb.conf
===========Discovering listener addresses: =========
Listener address to use: 127.0.0.1
Listener address to use: 100.68.58.111
Listener address to use: ::1
=====================================================
===========Discovering relay addresses: =============
Relay address to use: 100.68.58.111
=====================================================
IO method (listener thread): epoll
create_server_socket:209:start

IPv4. UDP listener opened on : 127.0.0.1:3478
create_server_socket:243:end
create_server_socket:209:start

IPv4. UDP listener opened on : 127.0.0.1:3479
create_server_socket:243:end
create_server_listener:130:start

IPv4. TCP listener opened on : 127.0.0.1:3478
create_server_listener:168:end
create_server_listener:130:start

IPv4. TCP listener opened on : 127.0.0.1:3479
create_server_listener:168:end
create_server_socket:209:start

IPv4. UDP listener opened on : 100.68.58.111:3478
create_server_socket:243:end
create_server_socket:209:start

IPv4. UDP listener opened on : 100.68.58.111:3479
create_server_socket:243:end
create_server_listener:130:start

IPv4. TCP listener opened on : 100.68.58.111:3478
create_server_listener:168:end
create_server_listener:130:start

IPv4. TCP listener opened on : 100.68.58.111:3479
create_server_listener:168:end
create_server_socket:209:start

IPv6. UDP listener opened on : ::1:3478
create_server_socket:243:end
create_server_socket:209:start

IPv6. UDP listener opened on : ::1:3479
create_server_socket:243:end
create_server_listener:130:start

IPv6. TCP listener opened on : ::1:3478
create_server_listener:168:end
create_server_listener:130:start

IPv6. TCP listener opened on : ::1:3479
create_server_listener:168:end
IO method (auth thread): epoll
run_listener_server: cycle=1, stats=0
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x16268f0: timer_handler
timer_event_handler: timeout 0x162b740: rtcp_map_timeout_handler
timer_event_handler: timeout 0x16268f0: timer_handler
server_input_handler:76:start
open_client_connection_socket:161:start
open_client_connection_socket: AF: 2:2
Binding socket 24 to addr

IPv4. Bind to: 100.68.58.111:3478

IPv4. UDP connected to: 98.247.37.95:59370
open_client_connection_socket:202:end
Segmentation fault (core dumped)

Please let me know if I can do anything to provide troubleshooting help.

Original issue reported on code.google.com by [email protected] on 22 Mar 2013 at 3:43

Allow multiple IPs in behind-the-NAT TURN operation (related - Issue 3)

Current implementation requires that a single IP address being used when the 
TURN server is behind a NAT (-X option). There are two problems with that:

1) RFC 5780 STUN NAT discovery requires at least two IP addresses.
2) Some setups could you multiple relay addresses.

The turnserver must allow multiple -X options of format:

 $ turnserver ... -X IPpublic1/IPprivate1 -X IPpublic2/IPprivate2 ...

to establish multiple IP-to-IP mappings.

For backward compatibility, the old form also must be supported:

 $ turnserver -X IPpublic 

- to establish a single "global" IP mapping.

Original issue reported on code.google.com by [email protected] on 14 May 2013 at 3:57

classic stun bind response id is not the same as request

We use libnice to test with rfc5766-turn-server, libnice failed to parse the 
classic-stun bin response.

After capture the packets, we found the id of bind response is different from 
bind request.

What steps will reproduce the problem?
1. setup rfc5766-turn-server
2. run simple-example from libnice package
3. failed to get the srvflx address

What is the expected output? What do you see instead?
Got srvflx 

What version of the product are you using? On what operating system?
rfc5766-turn-server -->  2.5.1.2
libnice --> 0.1.4

Please provide any additional information below.
See the attached wireshark packets.

Original issue reported on code.google.com by [email protected] on 2 Aug 2013 at 7:58

Attachments:

• nice_rfc5766-turn-server.cap

Timestamp is not checked properly in REST API implementation.

The timestamp never expires.

Original issue reported on code.google.com by [email protected] on 5 Apr 2013 at 9:16

UDP Blocked by FW

What steps will reproduce the problem?
1. Use Google Chrome to establish WebRTC session
2. Use the "?transport=tcp" flag while configuring the TURN Server in the 
client JS

What is the expected output? What do you see instead?
1. Communication from the client (google chrome [v. 25.0.1364.172 m] should be 
in TCP and not in UDP
2. I see that the communication is still in UDP.
The main issue is that if OUTBOUND UDP is blocked, there is no way to establish 
WebRTC communication between peers (no STUN RESOLUTION). We need to have a TCP 
fallback.

What version of the product are you using? On what operating system?
win 7, Google chrome 25. turn server 1.6.0.1

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 19 Mar 2013 at 4:31

Improve Log file handling

What steps will reproduce the problem?
1.Start turnserver with log to file rather than stdout option.
2.Do "ls -l /var/log/turn*" to display log file(s).
3.

What is the expected output? What do you see instead?

Log file should be closed/re-opened every 24 hours with name that includes date.

The turnserver keeps logging to the same log file forever, requiring a 
start/stop to change log files, and name includes process ID rather than date.

What version of the product are you using? On what operating system?

turnserver-1.8.1.1 
Ubuntu 12.04.1

Please provide any additional information below.

Log files older than yesterday should be compressed (like syslog).

Original issue reported on code.google.com by [email protected] on 22 Apr 2013 at 11:35

UDP channels traffic may be incompatible with pjnath library

PJNATH performs padding even for UDp channels. This is not usual, but it is 
allowed per RFC 5766. We do not support padding and the traffic may be 
incompatible.

Original issue reported on code.google.com by [email protected] on 4 Jun 2013 at 8:15

Allow ATERNATE-SERVER support in anonymous TURN operation

Currently it works only with long-term or short-term credentials. Allow 
anonymous operations.

Original issue reported on code.google.com by [email protected] on 23 Jul 2013 at 6:25

Better log control

First of all, let me thank you for excellent tool and great docs. This is just 
an enhancement request for better log control.

What steps will reproduce the problem?
1. run turnserver with any config
2. output log will go to turnserver_<pid>.log file into uncertain folder and in 
uncontrolled fashion.

What is the expected output? What do you see instead?
* would be nice to have config option 

What version of the product are you using? On what operating system?
* turnserver-1.7.2.0
* Ubuntu 12.04.2

Please provide any additional information below.
* not critical for me at the moment since I just commented out all the code 
which uses _rtpfile. 
* in my case looking only for stdout output since turnserver going to be 
executed under supervisor (http://supervisord.org/) and all stdout will be 
redirected to supervisor controlled location with graceful file rolling and 
size limitation.

Original issue reported on code.google.com by [email protected] on 30 Mar 2013 at 8:22

DTLS connection may crash under very heavy network conditions

If multiple DTLS sessions are trying to connect to the server simultaneously, 
it may crash. It is recommended to use --no-dtls option, for security, till the 
bug is fixed. The bug will be fixed in the next build.

Original issue reported on code.google.com by [email protected] on 22 Jul 2013 at 2:45

support for Microsoft ICE/STUN/TURN clients

Microsoft Lync includes a Microsoft TURN server promoted under the name "Edge" 
server.

Some clients (e.g. Polycom phones with new firmware) claim to be limited to 
work only with the Microsoft permutation of ICE/STUN/TURN rather than the IETF 
official version.

Are you aware of how Microsoft's variation of the protocol differs?  E.g. does 
it use Microsoft authentication hashes rather than md5(A1) style hashes or are 
there more obscure differences?

Does this project make any effort to support such clients and potentially relay 
calls from a WebRTC client to a Microsoft-style client?

Original issue reported on code.google.com by [email protected] on 6 Jun 2013 at 2:24

More scalable UDP networking model needed

With thousands live UDP connections, the common UDP stack implementation (like 
one in vanilla Linux kernel) may handle the UDP packets inefficiently. The 
existing model is very scalable for the TCP, but UDP requires a different 
approach.

Original issue reported on code.google.com by [email protected] on 13 Jul 2013 at 1:08

Update TURN REST API according to the latest specs

This TURN server implements the original TURN REST API proposal when the 
combination user name was constructed as "username:timestamp". In the latest 
specs it is "timestamp:username". It has to be updated to support both ways.

Original issue reported on code.google.com by [email protected] on 8 Jul 2013 at 7:20

TCP/TLS channel padding is not properly implemented

According to RFC 5766, the channel messages for TCP and TLS must be padded to 
the nearest 4 bytes boundary. This functionality is missed.

Original issue reported on code.google.com by [email protected] on 4 Jun 2013 at 8:13

Make fails due to bad CFLAGS

What steps will reproduce the problem?
1. Download turnserver-1.5.2.6
2. ./configure
3. make

What is the expected output? 

Built turnserver

What do you see instead?

/usr/bin/ld: note: 'clock_gettime@@GLIBC_2.2.5' is defined in DSO 
/lib64/librt.so.1 so try adding it to the linker command line
/lib64/librt.so.1: could not read symbols: Invalid operation


What version of the product are you using? On what operating system?
turnserver-1.5.2.6 
Amazon linux 2012.09

Please provide any additional information below.

Adding '-lrt' to CFLAGS resolves the issue.

Original issue reported on code.google.com by [email protected] on 27 Feb 2013 at 7:45

Issues with channel binding and rtcp ports in uclient.

uclient tries to bind the same channel multiple times.   This fails with some 
turn servers as restund.

uclient uses RTCP port instead of RTP port when you run it without RTCP.

Patch attached.

Original issue reported on code.google.com by [email protected] on 27 Mar 2013 at 5:20

Attachments:

• uclient_patch.diff

Red hat enterprise linux - turn/stun server is not working?

Red Hat Enterprise Linux 6.4 / 64- bit i installed the server package.

Install:

$ cd /var/tmp;
wget 
https://github.com/downloads/libevent/libevent/libevent-2.0.21-stable.tar.gz; 
tar xvfz libevent-2.0.21-stable.tar.gz; cd libevent-2.0.21-stable; ./configure; 
make; make install;
wget http://rfc5766-turn-server.googlecode.com/files/turnserver-1.8.6.3.tar.gz 
; tar xvfz turnserver-1.8.6.3.tar.gz; cd turnserver-1.8.6.3; ./configure; make; 
make install;
/var/tmp/turnserver-1.8.6.3/bin/turnserver;

Run:

[root@ip-10-59-143-73 stund]# export 
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib/; 
PATH="bin:../bin:../../bin:${PATH}" turnserver -L 176.34.x.x -a -b 
/usr/local/etc/turnuserdb.conf -f -r 176.34.x.x
1371111272: RFC 5389/5766/5780/6062/6156 STUN/TURN Server, version 
Citrix-1.8.6.3 'Black Dow'
1371111272: Config file found: /usr/local/etc/turnserver.conf
1371111272: Listener address to use: 176.34.x.x
1371111272: Config file found: /usr/local/etc/turnserver.conf
1371111272: WARNING: cannot find certificate file: turn_server_cert.pem (1)
1371111272: WARNING: cannot start TLS and DTLS listeners because certificate 
file is not set properly
1371111272: WARNING: cannot find private key file: turn_server_pkey.pem (1)
1371111272: WARNING: cannot start TLS and DTLS listeners because private key 
file is not set properly
1371111272: Relay address to use: 176.34.x.x
1371111272: IO method (listener thread): epoll
1371111272: WARNING: I cannot start alternative services of RFC 5780 because 
only one IP address is provided
1371111272: IO method: epoll
1371111272: IPv4. UDP listener opened on : 0.0.0.0:0
1371111272: IPv4. TCP listener opened on : 0.0.0.0:39227
1371111272: IO method (auth thread): epoll
1371111272: IO method (relay thread): epoll


But when TURN/STUN client is trying to connect it does not show any kind of log 
what is happening weather its working or not.

Is there any turn/stun client script with (python/perl/bash) just to test 
remotely if the stun/turn server is working correctly?

Original issue reported on code.google.com by [email protected] on 13 Jun 2013 at 8:43

Installation fails under cygwin environment in windos

What steps will reproduce the problem?
1. Open Cygwin terminal
2. cd \
3. tar xvfz turnserver-1.8.7.0.tar.gz, works fine
4. ./configure, works fine
5. make, got an error

What is the expected output? What do you see instead?
It should install successfully. Instead, I am getting error -  
src/client/ns_turn_ioaddr.c:169:13:error 'struct_sockaddr_in' has no member 
named 'sin_len'

What version of the product are you using? On what operating system?
Turn server 1.8.7.0
Windows 7, 64 bit
cygwin

Original issue reported on code.google.com by [email protected] on 4 Jul 2013 at 11:01

Attachments:

• [turn server error.png](https://storage.googleapis.com/google-code-attachments/rfc5766-turn-server/issue-36/comment-0/turn server error.png)

Support multithreaded processing in Cygwin

Currently on Cygwin platform we support only single threaded processing. It has 
to be improved.

Original issue reported on code.google.com by [email protected] on 22 Jul 2013 at 3:04

Dont-Fragment flag unnecessarily set on UDP listening sockets

In media communications, it is RECOMMENDED that all UDP network packets are 
sized below MTU. But this is NOT REQUIRED, and the RFC 5766 is not requiring 
that, and not enforcing that. But the TURN Server rfc5766-turn-server 
unnecessary enforces this requirement: all client-facing UDP sockets have 
dont-fragment flag set to 1.  This means that the TURN Server will not relay 
the packets which have size more than MTU.

Original issue reported on code.google.com by [email protected] on 9 Jun 2013 at 2:20

Some OpenSSL versions are not supported

It cannot be compiled in RedHat/CentOS with FIPS version of OpenSSL, 0.9.8.

Original issue reported on code.google.com by [email protected] on 14 Apr 2013 at 7:17

why delete my issue???

why delete my issue????

Original issue reported on code.google.com by [email protected] on 17 Jul 2013 at 12:33

This TURN server implementation cannot work behind NAT

This is not an error or bug but a capability being added to other TURN server 
implementations so that they can be hosted on cloud services such as AWS which 
only offer NAT and not public IPs. 

This can be achieved by creating a config parameter for external_IP which is 
the set to the outside address of the NAT. This address must have port 
forwarding to a valid listening address:port for the rfc5766turnserver. 
Responses to STUN and TURN requests are then formulated using the external_IP 
override rather than the native address of the listening interface.

Would you consider this enhancement to your very good TURN solution. 

Thanks,

Warren      

Original issue reported on code.google.com by [email protected] on 28 Jan 2013 at 3:33

uclinet minimum packet interval

It is not possible to configure "Per-session packet interval" less than 10 
milliseconds.

We need 5 milliseconds to simulate some audio+video clients.

Find patch attached just reducing the libevent timeout from 10 msecs to 1 msec.

PD. Feel free to close this issue without solving if this is a very specific 
use case.   Anyway I thought it could be useful for reference in case somebody 
needs to do the same in the future.

Original issue reported on code.google.com by [email protected] on 29 Mar 2013 at 3:55

Attachments:

• uclient_timer_patch.diff

Segfault on creating local listeners if default networking used

What steps will reproduce the problem?
1. Compile and install application v 1.4.2.4 
2. Run  
3.

What is the expected output? What do you see instead?
Expect initialize and run.
Segfaults after initialization messages
Ran under debugger and saw that it is crashing on enumerating listeners

Program received signal SIGSEGV, Segmentation fault.
0x000000000040a1f0 in make_local_listeners_list ()


What version of the product are you using? On what operating system?
 1.4.2.4
 Ubuntu 12.10 (GNU/Linux 3.6.4-xenU x86_64)

Please provide any additional information below.
If V4 IP addresses are specified app initializes OK.  

Original issue reported on code.google.com by [email protected] on 13 Jan 2013 at 6:58

In Debian package, make service setup optional

Currently when the debian package is installed, it always sets the turnserver 
as the system service. It may not be what some users need.

Original issue reported on code.google.com by [email protected] on 2 May 2013 at 9:49

Cygwin is not supported

Cygwin is not supported

Original issue reported on code.google.com by [email protected] on 14 Apr 2013 at 7:15

Log enhancements for Timestamp and Levels

What steps will reproduce the problem?
1.Set log to verbose
2.
3.

What is the expected output? What do you see instead?
I would like to see time stamps on each log line
I would like a log level between verbose and normal, perhaps without the 
regular "timer_event_handler: timeout" 

What version of the product are you using? On what operating system?
1.8.1 Ubuntu 12.04

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 9 Apr 2013 at 3:03

Linux and GNU C Library compatibility

> What steps will reproduce the problem?

1. compile via "make" or "build.sh"

> What is the expected output? What do you see instead?

src/apps/relay/turnmutex.c: In function ‘turn_mutex_init_recursive’:
src/apps/relay/turnmutex.c:104: warning: implicit declaration of function 
‘pthread_mutexattr_settype’
src/apps/relay/turnmutex.c:104: warning: nested extern declaration of 
‘pthread_mutexattr_settype’
src/apps/relay/turnmutex.c:104: error: ‘PTHREAD_MUTEX_RECURSIVE’ undeclared 
(first use in this function)
src/apps/relay/turnmutex.c:104: error: (Each undeclared identifier is reported 
only once
src/apps/relay/turnmutex.c:104: error: for each function it appears in.)
make: *** [bin/turnserver] Error 1

> What version of the product are you using? On what operating system?

I'm compiling from release 1.3.0.1, on and up-to-date Debian squeeze (libevent2 
from squeeze-backports).

> Please provide any additional information below.

I am not familiar with the topic, but I think that the problem resides in the 
usage of pthread.h from the GNU C Library. Both the warning on 
"pthread_mutexattr_settype" and the missing PTHREAD_MUTEX_RECURSIVE (pthread.h 
from GNU defines only PTHREAD_MUTEX_RECURSIVE_NP by default) suggests that it 
is an extension which is not enabled given the defined macros.

An option may be to modify your build system in build.sh by adding a 
conditional like the one you used for Solaris. I tried adding "-D_GNU_SOURCE" 
to "OSCFLAGS", and it resolves the issue (patch attached). It may not be, 
however, the most fit solution as it enables lots of other definitions.

Original issue reported on code.google.com by [email protected] on 27 Dec 2012 at 2:08

Attachments:

• linux_gnu_c_library_extensions.patch

There must be an option to disallow multicast and loopback peer addresses

Wor security reasons, the user must be able to disallow multicast and/or 
loopback peer addresses,

Original issue reported on code.google.com by [email protected] on 8 May 2013 at 1:38

DTLS is vulnerable under bad network conditions with "dos attack"

DTLS sockets are not handling the network errors properly

Original issue reported on code.google.com by [email protected] on 20 Jul 2013 at 8:46

Support multitgreaded TCP implementation

Current implementation handles UDP in multuthreaded way and TCP in single 
thread. It has to be improved.

Original issue reported on code.google.com by [email protected] on 8 Jul 2013 at 7:21

Make username / timestamp separator configurable?

There is a bug in the current version of chrome that does not allow a ":" to be 
used as part of a TURN url. Therefore, I think it is a good idea to allow this 
so be configured (eg use a "+") and use ":" as the default.

I am happy to supply a patch if you are interested.

Original issue reported on code.google.com by [email protected] on 25 Apr 2013 at 1:24