[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25600 [Obfuscation/Snowflake]: Tor eventually hits "No running bridges" with Snowflake
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs