In VSCode, the staticcheck tool emits this warning:
> should call wg.Add(1) before starting the goroutine to
> avoid a race (SA2000)go-staticcheck
To avoid this warning, just move wg.Add outside.
This update required two main changes to how we use the library. First,
we had to make sure we created the datachannel on the offering peer side
before creating the offer. Second, we had to make sure we wait for the
gathering of all candidates to complete since trickle-ice is enabled by
default. See the release notes for more details:
https://github.com/pion/webrtc/wiki/Release-WebRTC@v3.0.0.
Normally all dangling goroutines are terminated when the main function
exits. However, for projects that use a patched version of snowflake as
a library, these goroutines continued running as long as the main function
had not yet terminated. This commit has all open SOCKS connections close
after receiving a shutdown signal.
Bug #21314: maintains a separate snowflake connect loop per SOCKS
connection. This way, if Tor decides to stop using Snowflake, Snowflake
will stop using the client's network.
Snowflake clients will now attempt NAT discovery using the provided STUN
servers and report their NAT type to the Snowflake broker for matching.
The three possibilities for NAT types are:
- unknown (the client was unable to determine their NAT type),
- restricted (the client has a restrictive NAT and can only be paired
with unrestricted NATs)
- unrestricted (the client can be paired with any other NAT).
Instead of returning nil from NewBrokerChannel and having
WebRTCDialer.Catch check for nil, let NewBrokerChannel return an error
and bail out before calling WebRTCDialer.Catch.
Suggested by cohosh.
https://bugs.torproject.org/33040#comment:3
These functions are called for their side effect of sending a PT error
message on stdout; they also return a representation of the error
message as an error object for the caller to use if it wishes. These
functions *always* return a non-nil error object; it is not something to
be logged, any more than the return value of errors.New is.
The mistaken logging was added in
https://bugs.torproject.org/31794b26c7a7a733ec9dd19faed3d42e1ec
There were a few tests that needed refreshing since the introduction of
the pion library. Also added a few tests for the ICE server parsing
function in the client.
- Error strings are no longer capitalized nor end with punctuation
- Alias import
- Remove extraneous initilisation code (No need to provide zero value
for variables, because the compiler does that anyway)
Modified the snowflake client to use pion/webrtc as the webrtc library.
This involved a few small changes to match function signatures as well
as several larger ones:
- OnNegotiationNeeded is no longer supported, so CreateOffer and
SetLocalDescription have been moved to a go routine called after the
other peer connection callbacks are set
- We need our own deserialize/serialize functions
- We need to use a SettingEngine in order to access the
OnICEGatheringStateChange callback
https://bugs.torproject.org/25600#comment:14
Snowflake in Tor Browser has been hanging after surfing for a while.
(Tor reports "no running bridges".) It only began happening after commit
12922a232b, which caused snowflake-client not to log to a file by
default (leaving it to log to its default stderr). What seems to be
happening is that tor doesn't read from its PT clients' stderr, leaving
a buffer to fill up that eventually causes a hang.
It also expects to be called with a non-empty string, which isn't
the case with this Split which always envokes the loop at least
once. If -ice was omitted, an error was logged.
Rather than having it happen as a side effect of flag parsing.
Having it happen as a side effect of flag parsing caused log messages
related to handling the option (e.g. "IceServerList:") to always go to
stderr, despite the presence of a -log option. This is because the
requested log file had not been opened yet.
