Nathan Freitas <[email protected]> writes: > On May 3, 2014 4:18:28 PM EDT, George Kadianakis <[email protected]> wrote: >>George Kadianakis <[email protected]> writes: >> >>> Nathan Freitas <[email protected]> writes: >>> >>>> On May 3, 2014 6:10:58 AM EDT, George Kadianakis >><[email protected]> wrote: >>>>>Nathan Freitas <[email protected]> writes: >>>>> >>>>>> Orbot now supports Obfs3 and Scramblesuit, thanks to Yawning's >>help. >>>>>> >>>>> >>>>>Great news! Thanks! >>>>> >>>>>BTW, how are obfs3 bridges supposed to be used? >>>> >>>> This is the string I use for scramblesuit, copied directly from the >>bridges.tp.o page: >>>> >>>> scramblesuit xxx.xxx.xxx.xxx:xxxxx fingerprintxxx >>password=sharedsecretxxx >>>> >>>>>I installed Orbot-v14.0.0-ALPHA-2a.apk and checked the Preferences >>>>>menu. There used to be an option called 'Obfuscated Bridges' that >>it's >>>>>not there anymore. I assumed that I just have to specify a bridge, >>and >>>>>then prefix it with the transport name, like you do in the torrc. >>>> >>>> Yes. >>>> >>>>> >>>>>So I clicked on 'Bridges' and then inserted 'obfs3 <ip>:<port>' >>(with >>>>>my own <ip> and <port>) and started up Orbot. Unfortunately, I think >>>>>that it didn't work very well. In the logs I got: >>>>>"""" >>>>>Adding bridge: obfs3 <ip>:<port> >>>> >>>> Hmm.... Add a fingerprint perhaps? >>>> >>> >>> Hm, I just tried that bridge again (without adding a fingerprint), >>and >>> now I'm getting the usual PT error: >>> "We were supposed to connect to bridge '<ip>:<port>' using pluggable >>> transport 'obfs3', but we can't find a pluggable transport proxy >>> supporting 'obfs2'. ..." >>> >>> I'm not sure why I'm getting this today instead of the error I was >>> getting yesterday [0]. I don't remember rebooting or changing >>> anything. >>> >>> In any case, this new message usually means that obfsproxy crashed >>> early: before being configured to be a Pluggable Transport. The same >>> should be true for obfsclient too. Could it be a permission issue? >>> >> >>We played a bit with Yawning on this. >> >>Are we sure that the ClientTransportPlugin is even set at all? >> >>Because looking at >>https://gitweb.torproject.org/orbot.git/blob/HEAD:/src/org/torproject/android/service/TorService.java#l1713 >>it seems that it depends on the boolean PREF_BRIDGES_OBFUSCATED which >>apparently is never set since commit 147b57af4. >> >>This seems to agree with my experience since I'm getting the log >>message "Using standard bridges" which is on the 'else' codepath. >> >>Or maybe we are missing something. > > Wow, I just realized that I removed that preference UI, but on my test device > it was already set to TRUE, since I did not do a clean install. > > Thanks for the testing, and will push a new release our in next 24 hours with > that fixed.
Thanks! BTW, I'd suggest to parse the Bridge lines to figure out if PTs are used and only then insert a ClientTransportPlugin line (in contrast, to always adding a ClientTransportPlugin line). That's to avoid issues like #11658. You can check if a Bridge line uses PTs, by checking if its second element is a C-identifier as the pt-spec.txt suggests. An IP:PORT is not a C-identifier because of the colon. -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
