User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

ooniraspberrypi-bugsbadthings [2013/03/05 23:56]
EI 8 FDB created
ooniraspberrypi-bugsbadthings [2013/11/01 13:33]
Line 1: Line 1:
-**Work around for the bug where Tor client doesn'​t know its own IP address and causes tests to fail.** 
-23:26 < blueboxthief>​ data_dir: data_dir: ~/.tor/ 
-23:26 < blueboxthief>​ and ~/.tor exists.. 
-23:27 < aagbsn> try commenting that out and run again 
-23:27 < blueboxthief>​ Ok, strange thing is that it worked before... 
-23:27 < aagbsn> there is a bug where the tor client doesn'​t get its own IP if it has all the descriptors cached 
-23:27 < blueboxthief>​ as in worked for the first time and then failed.. 
-23:27 < aagbsn> hellais: ​ might know the ticket # 
-23:29 < blueboxthief>​ seems better 
-23:29 < aagbsn> :) 
-23:29 < blueboxthief>​ There we go.. 
-23:29 < aagbsn> we should probably document that option with a #XXX broken or something 
-23:29 < aagbsn> though fetching the descriptors every ooni launch isn't ideal either 
-23:29 < blueboxthief>​ "[D] Obtained our IP address from a Tor Relay None" 
-23:35 < aagbsn> btw, if you see a Traceback in your ooniprobe.log,​ that's not supposed to happen, and indicates a bug, not a test failure (well could be both) 
-23:35 < aagbsn> you'll see a line like "​Traceback (most recent call last)" 
-23:37 < aagbsn> if you do encounter those, the most helpful thing to do is paste that output into a ticket https://​​projects/​tor/​newticket with component ooni  
-</​code> ​ 
ooniraspberrypi-bugsbadthings.txt · Last modified: 2013/11/01 13:33 (external edit)