processone/stun

STUN and TURN library for Erlang / Elixir

stun's Issues

ejabberd_stun crashing with badfun,undefined when receiving unexpected TURN packet

What version of ejabberd are you using?

17.07

What operating system (version) are you using?

Ubuntu 17.04

How did you install ejabberd (source, package, distribution)?

Package

What did not work as expected? Are there error messages in the log? What
was the unexpected behavior? What was the expected result?

When a TURN message with credentials is received but use_turn has not been explicitly set to true in ejabberd, the STUN process crashes:

2017-08-07 15:00:50.678 [error] <0.6671.1>@ejabberd_listener:udp_recv:319 failed to process UDP packet:
** Source: {{192,0,2,1}, 49745}
** Reason: {{badfun,undefined},[{stun,process,2,[{file,"src/stun.erl"},{line,232}]},{ejabberd_listener,udp_recv,3,[{file,"src/ejabberd_listener.erl"},{line,317}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}
** Packet: <<0,3,0,76,33,18,164,66,147,192,145,48,234,247,85,140,228,23,150,152,0,25,0,4,17,0,0,0,0,13,0,4,0,0,14,16,0,6,0,4,115,116,117,110,0,20,0,0,0,21,0,10,50,49,54,48,54,50,54,48,51,53,0,0,0,8,0,20,68,53,203,248,222,198,133,165,142,12,108,151,149,81,179,52,15,9,126,19,128,40,0,4,209,187,56,199>>

It seems that AuthFunc is not set, and its absence is not properly handled.

hex.pm documentation page for stun shows error message

The hex.pm page for stun points at https://hexdocs.pm/stun/ and is returning errors with the text

  PAGE NOT FOUND
  Is something wrong with the package documentation? Open an issue on the project 
  the documentation belongs to. Most packages link to their repository from their 
  hex.pm page.

This impacts all releases of the stun documentation there from verson 1.0.31 as far as I can tell.

allocate_udp_test failing

Hi,
until recently, allocate_udp_test only failed on hurd-i386 (which I didn't much care about, see https://bugs.debian.org/820393), but now it is also happening on amd64, which is rather important.
It might be because Debian Sid has Erlang 20 now.

Full build log attached.

erlang-p1-stun_1.0.12-1_amd64.build.txt

Phoenix deps compile fast_tls issue on windows

I was following along to a blog to install an erlang stun component using mix on
Windows 10.

ref:
https://littlelines.com/blog/2020/07/06/building-a-video-chat-app-in-phoenix-liveview

In brief:

after adding # {:stun, "~> 1.0"} to mix.xs and running mix deps.get then mix compile
I received an error message while trying to run what appears to be a batch compile
executable called cl.exe that the dependency fast_tls.c, could not be compiled due to
missing c (++?) header files (eg stdio.h ...), On further investigation this appeared to
be due to the Microsoft Visual Studio MVSC compiler tools not being in place, and
after installing some of the Microsoft Visual Studio core, I managed to create a dummy project and access the command line within the Microsoft Visual Studio env and re-ran the mix command. This appeared to advance things a little and the next error was due
to the missing openssl src files. I then applied the fix I saw to the Mac homebrew settings:

 export LDFLAGS="-L/usr/local/opt/openssl/lib -L/usr/local/lib -L/usr/local/opt/expat/lib"
 export CFLAGS="-I/usr/local/opt/openssl/include/ -I/usr/local/include -I/usr/local/opt/expat/include"
 export CPPFLAGS="-I/usr/local/opt/openssl/include/ -I/usr/local/include -I/usr/local/opt/expat/include"

for the windows environment. And then re-ran the mix compile.
But now it is clear that the MSVC compiler presumable called by the cl.exe batch file
will not allow the fast_stl.c source file to compile. Apart from spitting out a host of warnings it stops compilation with essentially these error messages:

c:/Users/Paul/Desktop/phoenix/els_umbrella/deps/fast_tls/c_src/fast_tls.c(484): error C2057: expected constant expression
c:/Users/Paul/Desktop/phoenix/els_umbrella/deps/fast_tls/c_src/fast_tls.c(484): error C2466: cannot allocate an array of constant size 0
c:/Users/Paul/Desktop/phoenix/els_umbrella/deps/fast_tls/c_src/fast_tls.c(484): error C2133: 'name': unknown size

This appears to tell me that this particular compiler is too picky when looking a memory allocation for data structures such as arrays?

Well, I was just wondering if there is another way to go to compile this source code on a Windows 10 machine without using Visual Studio? I've tried changing the so-called Platform toolset (to LLVM clang-cl an alternative lib offered by Visual Study) but this has not effect. I don't want to have to doctor the fast_tls.c code since quite clearly it compiles fine on other platforms. Or, has anyone had a similar experience in trying to compile this mix dep on a Windows platform?

Best regards.

Paul.

Originally posted by @philipmoniaga in processone/ejabberd#1107 (comment)

IPv6 for STUN

Can you add IPv6 support in more IPv4?

And an update of all supported RFCs: https://www.process-one.net/en/ejabberd/protocols/.

There are for STUN:

• RFC 3489 - "classic" STUN: https://tools.ietf.org/html/rfc3489
• RFC 5389 - base "new" STUN specs: https://tools.ietf.org/html/rfc5389
• RFC 5769 - test vectors for STUN protocol testing: https://tools.ietf.org/html/rfc5769
• RFC 5780 - NAT behavior discovery support: https://tools.ietf.org/html/rfc5780
• RFC 7350 - DTLS as Transport for STUN: https://tools.ietf.org/html/rfc7350
• RFC 7376 - Problems with STUN Long-Term Authentication for TURN: https://tools.ietf.org/html/rfc7376
• RFC 7443 - ALPN support for STUN & TURN: https://tools.ietf.org/html/rfc7443
• RFC 7635 - oAuth third-party TURN/STUN authorization: https://tools.ietf.org/html/rfc7635
• RFC 8489 - base "new" STUN specs: https://tools.ietf.org/html/rfc8489
• RFC 8656 - TURN: Relay Extensions to STUN: https://tools.ietf.org/html/rfc8656

Maybe I have forgotten some.

Failing test on Fedora Rawhide

Greetings!

I am working on updating stun in Fedora Rawhide, and I'm having a failing unit test:

/usr/bin/rebar eunit skip_deps=true -v
==> stun-1.0.23 (eunit)                   
INFO:  sh info:      
        cwd: "/home/bowlofeggs/rpmbuild/BUILD/stun-1.0.23"
        cmd: cp -R src/turn_tmp_sup.erl src/turn_sm.erl src/turn.erl src/stun_tmp_sup.erl src/stun_test.erl src/stun_sup.erl src/stun_shaper.erl src/stun_listener.erl src/stun_codec.erl src/stun_app.erl src/stun.erl ".eunit"
INFO:  Cover compiling /home/bowlofeggs/rpmbuild/BUILD/stun-1.0.23
======================== EUnit ========================
module 'stun'
module 'stun_test'
  stun_test: init_test...[0.030 s] ok
  stun_test: mk_cert_test...ok
  stun_test: add_udp_listener_test...ok
  stun_test: add_tcp_listener_test...[0.001 s] ok
  stun_test: add_tls_listener_test...ok
  stun_test: bind_udp_test...[0.001 s] ok
  stun_test: bind_tcp_test...
=INFO REPORT==== 29-Jul-2018::20:17:51 ===
accepted connection: 127.0.0.1:57465 -> 127.0.0.1:34780ok
  stun_test: bind_tls_test...
=INFO REPORT==== 29-Jul-2018::20:17:51 ===
accepted connection: 127.0.0.1:55111 -> 127.0.0.1:53490*failed*
in function stun_test:'-bind_tls_test/0-fun-1-'/2 (src/stun_test.erl, line 109)
in call from stun_test:bind_tls_test/0 (src/stun_test.erl, line 109)
**error:{assertEqual,[{module,stun_test},
              {line,109},
              {expression,"fast_tls : send ( TLSSocket , Pkt )"},
              {expected,ok},
              {value,{error,closed}}]}
  output:<<"">>

  stun_test: del_tcp_listener_test...ok
  stun_test: del_tls_listener_test...ok
  stun_test: allocate_udp_test...[0.005 s] ok
  [done in 0.200 s]
module 'stun_codec'
module 'stun_app'
module 'turn'
module 'stun_listener'
module 'stun_shaper'
module 'stun_sup'
module 'turn_sm'
module 'stun_tmp_sup'
module 'turn_tmp_sup'
=======================================================
  Failed: 1.  Skipped: 0.  Passed: 10.
Cover analysis: /home/bowlofeggs/rpmbuild/BUILD/stun-1.0.23/.eunit/index.html
Coverdata export: /home/bowlofeggs/rpmbuild/BUILD/stun-1.0.23/.eunit/cover.coverdata

=INFO REPORT==== 29-Jul-2018::20:17:51 ===
    application: fast_tls
    exited: killed
    type: temporary

=INFO REPORT==== 29-Jul-2018::20:17:51 ===
    application: p1_utils
    exited: killed
    type: temporary

=INFO REPORT==== 29-Jul-2018::20:17:51 ===
    application: stun
    exited: killed
    type: temporary
ERROR: One or more eunit tests failed.
ERROR: eunit failed while processing /home/bowlofeggs/rpmbuild/BUILD/stun-1.0.23: rebar_abort

I also saw a failing test with fast_tls, which seems like it might be relevant:

processone/fast_tls#35

Here are some of the dependencies installed:

erlang-20.3.8.2
erlang-fast_tls-1.0.23-1.fc29.x86_64
erlang-p1_utils-1.0.12-1.fc29.noarch
erlang-rebar-2.6.4-6.fc28.x86_64

IPv6 for ICE

Can you add IPv6 support in more IPv4?

And an update of all supported RFCs: https://www.process-one.net/en/ejabberd/protocols/.

There are for ICE:

• RFC 5245 - ICE: https://tools.ietf.org/html/rfc5245
• RFC 5768 – ICE–SIP: https://tools.ietf.org/html/rfc5768
• RFC 6336 – ICE–IANA Registry: https://tools.ietf.org/html/rfc6336
• RFC 6544 – ICE–TCP: https://tools.ietf.org/html/rfc6544
• RFC 8445 - ICE-NAT: https://tools.ietf.org/html/rfc8445

Maybe I have forgotten some.

no longer compiles with elixir 1.0.5

I haven't recompiled ejabberd with elixir in a couple of weeks. Now, when I try to compile it, I get the following error:

==> p1_stun (compile)
src/stun_listener.erl:39: type dict() undefined
ERROR: compile failed while processing /home/jadams/projects/concur.io/concurio_jabber/deps/p1_stun: rebar_abort
** (Mix) Could not compile dependency p1_stun, /home/jadams/bin/rebar command failed. If you want to recompile this dependency, please run: mix deps.compile p1_stun

Logging issues

Hello.
My setup: ejabberd 20.07 with stun 1.0.38. compiled using rebar 2.6.4, Erlang/OTP version 23.1.

In ejabberd.yml I have: loglevel: info

The issue is that I don't see info level messages from the stun/turn library module in logs. I see only notice level ones.

For example, I see

[notice] <0.566.0>@turn:wait_for_allocate/2:194 Creating TURN allocation (lifetime: 600 seconds)
[notice] <0.565.0>@turn:terminate/3:446 Relayed 244 KiB (in 3296 B / 42 packets, out 247058 B / 2370 packets), duration: 47 seconds

but I don't see such messages as "Accepting long-term STUN/TURN authentication" as in previous versions (before switching to new logging API on Erlang/OTP 22+).

I see these messages in logs only if I manually change ?LOG_INFO to ?LOG_NOTICE in the code and recompile the stun library.

rebar debug output shows that erlang version is correctly identified as 23:

DEBUG: Matched required ERTS version: 11.1 -> .*
DEBUG: Matched required OTP release: 23 -> .*
DEBUG: Min OTP version unconfigured
DEBUG: erl_opts [debug_info,debug_info,{i,"include"},{d,'RAND_UNIFORM'}]
DEBUG: Files to compile first: []
DEBUG: Starting 3 compile worker(s)

Also the changelog states that: Add session ID, transport, username, and IP addresses to log output.
But I don't see such info. In my example you can see plain "Creating TURN allocation (lifetime: 600 seconds)" without additional info.

Remove erlang:now deprecation warning with Erlang R18

Here is an example of the deprecation we have:

Warning: erlang:now/0: Deprecated BIF. See the "Time and Time Correction in Erlang" chapter of the ERTS User's Guide for more information.

STUN/TURN Server to make video call

processone/ejabberd#1925

IPv6 for TURN

Can you add IPv6 support in more IPv4?

And an update of all supported RFCs: https://www.process-one.net/en/ejabberd/protocols/.

There are for TURN:

• RFC 5766 - base TURN specs: https://tools.ietf.org/html/rfc5766
• RFC 5928 - TURN Resolution Mechanism: https://tools.ietf.org/html/rfc5928
• RFC 6062 - TCP relaying TURN extension: https://tools.ietf.org/html/rfc6062
• RFC 6156 - IPv6 extension for TURN: https://tools.ietf.org/html/rfc6156
• RFC 7376 - Problems with STUN Long-Term Authentication for TURN: https://tools.ietf.org/html/rfc7376
• RFC 7443 - ALPN support for STUN & TURN: https://tools.ietf.org/html/rfc7443
• RFC 7635 - oAuth third-party TURN/STUN authorization: https://tools.ietf.org/html/rfc7635
• RFC 8016 - Mobility with TURN: https://tools.ietf.org/html/rfc8016
• RFC 8155 - TURN Server Auto Discovery: https://tools.ietf.org/html/rfc8155
• RFC 8656 - TURN: Relay Extensions to STUN: https://tools.ietf.org/html/rfc8656

Maybe I have forgotten some.

Error compiling with rebar3

Hi,

Running rebar3 compile causes this error:

===> Verifying dependencies...
===> Compiling stun
===> Compiling /Users/rogerioyokomizo/projects/stun/c_src/*.c
===> clang: error: no such file or directory: 'c_src/*.c'
clang: error: no input files

Turning provider_hooks off solves the problem:
https://github.com/processone/stun/blob/master/rebar.config.script#L106

- {[provider_hooks], IsRebar3,
-	  AppendList([{pre, [
-			     {compile, {pc, compile}},
-			     {clean, {pc, clean}}
-			    ]}]), []},

lots of error_logger:info_msg logs

Hi, I'm using this app to provide a STUN/TURN server for a WebRTC client. When a client connects I get a lot of logs like:

accepted long-term STUN authentication for user
created TURN allocation for user
deleting TURN allocation for  user
created/updated TURN permission for user 

Those look as debug logs to me, is there a special reason for them to use error_logger:info_msg directly instead of ?dbg()?

I can send a PR turning them to ?dbg if you are OK with it.

STUN listener process leak

Hi,
when you call add_listener there is a new process spawned

https://github.com/processone/stun/blob/master/src/stun_listener.erl#L66-L67

But I can't see it to be linked to anything or spawned under some supervisor. When your stun_listener process dies, all processes spawned as a result of a call to add_listener will remain and ports they are using will remain open. Am I right?