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.
