[tor-bugs] #25600 [Obfuscation/Snowflake]: Tor eventually hits "No running bridges" with Snowflake

[Tor Bug Tracker & Wiki]

#25600: Tor eventually hits "No running bridges" with Snowflake
-----------------------------------+------------------------------
 Reporter:  cypherpunks            |          Owner:  (none)
     Type:  defect                 |         Status:  needs_review
 Priority:  Medium                 |      Milestone:
Component:  Obfuscation/Snowflake  |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:                         |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+------------------------------
Changes (by dcf):

 * status:  reopened => needs_review


Comment:

 Replying to [comment:13 cypherpunks]:
 > Replying to [comment:12 dcf]:
 > > I have encountered this "No running bridges" problem too. I wonder if
 it happens when a snowflake proxy comes online but it behind a kind of
 NAT, or something, such that it can't actually do WebRTC.
 > I don't think that's the case since I almost always hit the fallback
 proxy (the 37... one) and this problem always happens when I use
 snowflake.
 >
 > But I think I finally nailed it: When I followed your suggestion to use
 `-log snowflake.log` I no longer had that problem (it's been a couple of
 hours now of testing, hopefully there will be no other surprise). So I
 think there's definitely some issue in the patch for #25471. This also
 confirms my results in comment:6 where I didn't have this problem with the
 earlier build of snowflake.

 My guess: tor is not reading from the client transport plugin's stderr
 pipe. In the absence of the `-log` option, snowflake-client writes log
 messages to stderr. Eventually the pipe buffer fills up, and snowflake-
 client hangs while writing a log message.

 The reason it didn't happen in earlier versions of snowflake-client is
 that earlier versions always logged to a file by default.
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=12922a232ba63bd8d94c92ced32e23aa2fb055ed
 12922a232b] made it log to stderr by default and added a `-log` option.
 The change would have happened in Tor Browser 8.0a5, because that's when
 #21312 caused an upgrade to the version of snowflake-client that doesn't
 log by default.

 Why this affects snowflake and not other PTs: probably just because
 snowflake-client writes more to the log (because of #25429 and other
 causes). Other PTs are probably affected; they just don't fill up the pipe
 buffer as fast.

 Could you try this patch for snowflake-client?
 {{{
 --- a/client/snowflake.go
 +++ b/client/snowflake.go
 @@ -150,6 +150,8 @@ func main() {
                 }
                 defer logFile.Close()
                 log.SetOutput(logFile)
 +       } else {
 +               log.SetOutput(ioutil.Discard)
         }

         log.Println("\n\n\n --- Starting Snowflake Client ---")
 }}}

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