#28329: Design TBA+Orbot configuration UI/UX -------------------------------------------------+------------------------- Reporter: sysrqb | Owner: tbb- | team Type: enhancement | Status: | needs_revision Priority: Very High | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: tbb-mobile, ux-team, TBA-a3, | Actual Points: TorBrowserTeam201903, tbb-8.5 | Parent ID: | Points: Reviewer: | Sponsor: | Sponsor8 -------------------------------------------------+-------------------------
Comment (by gk): Replying to [comment:53 sysrqb]: > Replying to [comment:50 gk]: > > Replying to [comment:47 sysrqb]: > > > anto, gk, thanks for the reviews! I believe I corrected all of the comments. Anto, do you have an opinion on how we should handle GeKo's comments in comment:46? I haven't tried this new branch with Gk's patch for #28802 > > > > One thing I noticed both with your older and newest branch for this bug is that it seems Tor is happily bootstrapping for a while before switching to bridges. I have not looked deeper if that's actually an issue but it makes me suspicious to see, with your older branch, Bootstrapped 5% and 10% messages before getting the warnings that e.g. some obfs3 bridges are not reachable and then bootstrapping continues with Bootstrapped 15% and 20% messages before I see notices that new bridge descriptors got fetched (for those two bridges that _are_ actually working). > > I noticed soemthing similar on rare occasions, too. I have trouble reproducing it, though. It seems related to the background TorService stopping Tor. Maybe there is a race condition where the user presses the connect button in tor browser, tor browser begins the bootstrapping process and sends the "start tor" signal to TorService, TorService starts the Tor process and waits for the control port. If the user presses the settings icon before TorService successful opens a controller connection, then the "stop tor" signal is ignored. > > This seems a little different than the bug you described because Tor shouldn't begin bootstrapping without bridges and then suddenly switch to using a bridge. However, I haven't tested this branch with working bridges yet, so maybe these bugs are related. I'll try reproducing this bug today. I actually think that's a general Tor issue as I see it on desktop as well (I guess I could have tested that earlier :( ): {{{ Mar 13 14:11:38.000 [notice] Bootstrapped 5%: Connecting to directory server Mar 13 14:11:38.000 [notice] Bootstrapped 10%: Finishing handshake with directory server Mar 13 14:11:38.000 [warn] Proxy Client: unable to connect to 2001:470:b381:bfff:216:3eff:fe23:d6c3:443 ("general SOCKS server failure") Mar 13 14:11:38.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection Mar 13 14:11:38.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus Mar 13 14:11:38.000 [notice] new bridge descriptor 'ndnop3' (fresh): $8DFCD8FB3285E855F5A55EDDA35696C743ABFC4E~ndnop3 at 109.105.109.165 }}} That's weird, though... -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28329#comment:56> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs