[tor-bugs] #31091 [Core Tor/Tor]: Bug stracktrace when pluggable transport cannot bind to port

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Jul 6 10:08:39 UTC 2019


#31091: Bug stracktrace when pluggable transport cannot bind to port
------------------------------+------------------------------
     Reporter:  s7r           |      Owner:  (none)
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:
    Component:  Core Tor/Tor  |    Version:  Tor: unspecified
     Severity:  Normal        |   Keywords:
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:                |
------------------------------+------------------------------
 I have just setup some new obfs4 fast bridges running latest obfs4proxy
 from yawning / master (locally compiled on my server) and Tor 0.4.2.0
 -alpha-dev and encountered a bug stack trace when started to try with the
 pluggable transport listening on a port < 1024. This is well known, which
 is why even in the wiki page it is recommended and properly documented to
 use setcap in order to grant permission to the PT executable to bind to
 lower ports, but shouldn't it just warn and exit, instead of offering all
 this:

 {{{
 Jul 06 05:51:18.000 [warn] Server managed proxy encountered a method
 error. (obfs4 listen tcp <ipv4>:<port>: bind: permission denied)
 Jul 06 05:51:18.000 [warn] Managed proxy at '/usr/local/bin/obfs4proxy'
 failed the configuration protocol and will be destroyed.
 Jul 06 05:51:18.000 [err] tor_assertion_failed_(): Bug:
 ../src/feature/client/transports.c:1836: managed_proxy_stdout_callback:
 Assertion mp->conf_state == PT_PROTO_COMPLETED failed; aborting. (on Tor
 0.4.2.0-alpha-dev )
 Jul 06 05:51:18.000 [err] Bug: Assertion mp->conf_state ==
 PT_PROTO_COMPLETED failed in managed_proxy_stdout_callback at
 ../src/feature/client/transports.c:1836: . Stack trace: (on Tor 0.4.2.0
 -alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /usr/bin/tor(log_backtrace_impl+0x47)
 [0x559a576f5d87] (on Tor 0.4.2.0-alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:
 /usr/bin/tor(tor_assertion_failed_+0x147) [0x559a576f0ed7] (on Tor 0.4.2.0
 -alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /usr/bin/tor(+0xd4a89) [0x559a575b8a89]
 (on Tor 0.4.2.0-alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /usr/bin/tor(+0x1e4e4b)
 [0x559a576c8e4b] (on Tor 0.4.2.0-alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f6f343265a0] (on Tor
 0.4.2.0-alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /usr/bin/tor(do_main_loop+0x105)
 [0x559a57555ed5] (on Tor 0.4.2.0-alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /usr/bin/tor(tor_run_main+0x1245)
 [0x559a57543905] (on Tor 0.4.2.0-alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /usr/bin/tor(tor_main+0x3a)
 [0x559a57540cfa] (on Tor 0.4.2.0-alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /usr/bin/tor(main+0x19)
 [0x559a57540879] (on Tor 0.4.2.0-alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf1) [0x7f6f32b7b2e1] (on Tor 0.4.2.0
 -alpha-dev )
 Jul 06 05:51:18.000 [err] Bug:     /usr/bin/tor(_start+0x2a)
 [0x559a575408ca] (on Tor 0.4.2.0-alpha-dev )
 }}}

 What if it just stopped here:
 {{{
 Jul 06 05:51:18.000 [warn] Server managed proxy encountered a method
 error. (obfs4 listen tcp <ip>:<port>: bind: permission denied)
 Jul 06 05:51:18.000 [warn] Managed proxy at '/usr/local/bin/obfs4proxy'
 failed the configuration protocol and will be destroyed.
 }}}

 Or maybe even exit entirely so the operator can know something is really
 wrong.

 Also, I don't know if this is related or not, I will try to make more
 tests to confirm or infirm this, but under Debian stable the bridges that
 are not run with setcap don't get a reasonable measured speed. Those with
 setcap that listen to lower ports have a bw of 2.5 - 3.5 MiB/s and those
 without setcap have a bw of 12 KiB/s - 70 KiB/s and they are all on the
 same infrastructure / hardware resources / internet speed. I will do some
 more digging to confirm this, right now 2 out of 2 obfs4 bridges that were
 configured without setcap did not get good bandwidth measurement even
 after 15 days of continuous uptime.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31091>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list