[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

#28942: Evaluate pion WebRTC
--------------------------------------------+------------------------------
 Reporter:  backkem                         |          Owner:  cohosh
     Type:  enhancement                     |         Status:  accepted
 Priority:  Medium                          |      Milestone:
Component:  Circumvention/Snowflake         |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:                                  |         Points:  5
 Reviewer:                                  |        Sponsor:
                                            |  Sponsor28-must
--------------------------------------------+------------------------------

Comment (by cohosh):

 Replying to [comment:57 dcf]:
 > Replying to [comment:54 cohosh]:
 > > In addition to the issues above, which can be solved with the attached
 patch
 >
 > I've started a build using the patch. The exact commit I'm building from
 is [https://gitweb.torproject.org/user/dcf/tor-browser-build.git/log/?h
 =pion-webrtc&id=f52281ae5bca107414a5292e74e2f1eca0608a3b
 f52281ae5bca107414a5292e74e2f1eca0608a3b]. Specifically, it makes the
 following changes relative to comment:51:
 >  * Applied attachment:0001-Allow-gathering-of-candidates-to-generate-
 offer.patch.
 >  * Picked up your
 [https://github.com/cohosh/snowflake/commit/e5040c70f9a4d8e47ed9e37b2f0c944859a9c56c
 "Make sure command line ice servers are used"] commit.
 >  * It does ''not'' pick up the
 [https://github.com/cohosh/snowflake/commit/ee8ddfe579092a126434bae4cf83203caf1d818b
 "Connect pion library logger with snowflake log"] commit from comment:56.
 I wasn't clear on whether that commit fixes something or whether it
 introduces its own race condition.
 That's correct. I added the logging commit for debugging purposes which
 was helpful in debugging the ICE issue but caused a race condition.
 >
 > Replying to [comment:55 cohosh]:
 > > Now I'm back to the issues found in comment:49. The client
 successfully completes the rendezvous/signaling and then is failing to
 open the data channel (which causes the proxy to eventually time out and
 keep polling).
 > Replying to [comment:56 cohosh]:
 > > Okay it seems to be working fine for me now (with this patch).
 >
 > I'm not sure what the expected outcome is now. Is attachment:0001-Allow-
 gathering-of-candidates-to-generate-offer.patch only meant to fix the
 post-2.0.23 errors in pion-webrtc that manifested in comment:43 and
 comment:51 and bring us back to the status quo ante of comment:49? Or does
 it fix everything in your tests and allow a complete bootstrap? Or only
 with proxy-go, not with browser-based proxies?
 So it's bootstrapping for me to 100% by following the above procedure. I
 don't think we've solved the issues you were seeing though. I want to add
 a lock to the safelog write functions since the race issue there was
 definitely causing trouble that resulted in logs that matched what you
 were showing. It's very possible there are more race issues present.

 I've found the PR in pion that added these bugs and am talking to them
 about it there: https://github.com/pion/webrtc/pull/763

 The PR introduced this change to get a small local example working. I
 think it will take some work to build some proof of concepts and show them
 that this is an issue. This should break things for everyone that relies
 on STUN to craft offers '''before''' they receive an answer (note that the
 example program they made her has the answering peer send the offering
 peer their candidates directly so the offering peer does not rely on ICE).

 So, my plans are to:
 - implement locks for `safelog`
 - investigate this problem they mention in the PR about "giving candidates
 too early" (might be a bug in chromium?)
 - implement their trickle example to (1) demonstrate why this change is a
 problem if the offering peer isn't allowed to perform ICE, and (2) solve
 the above problem the right way
 - create a patch for pion that reverts this breaking change and includes a
 working trickle example
 - follow up on whether dcf's build is still producing failures

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28942#comment:58>
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