Custom Query (24248 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (22 - 24 of 24248)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Resolution Summary Owner Reporter
#933 fixed MapAddress for domains? mwenge Aleph0
Description

Would it be non-trivial to have the MapAddress option behave like TrackHostExits? That is, if an entry is like MapAddress .rapidshare.com .rapidshare.com.exitpoint.exit have it applied to rs1xx.rapidshare.com, rs223dt.rapidshare.com, rs28tl2.rapidshare.com...

I already have such a line in my TORRC file; on start Tor doesn't complain, but apparently that line doesn't have any effect.

My goal is to have all connections to rapidshare.com exit through the same exit point (that I've already defined with a separate MapAddress line for rapidshare.com), regardless if I'm redirected.

The alternative would be to add 5000-odd MapAddress lines specifying every possible hostname given Rapidshare's current naming convention (rs[0-9]+[a-z]+[1-9]?.rapidshare.com) , but I don't know how Tor would handle such a big config file; my connections drop (flaky company proxy) often enough already...

I already have TrackHostExits enabled for both rapidshare.com and .rapidshare.com, so when rapidshare.com redirects me to whatever.rapidshare.com Tor will reuse the existing circuit.

If the connection drops halfway, my download manager will remember having been redirected and will retry on whatever.rapidshare.com. However, if it takes more than TrackHostExitsExpire seconds, Tor will assign this stream to a new circuit with a different exit point (and Rapidshare will claim I've shared my account and lock it... T_T ).

Thanks for your consideration.

[Automatically added by flyspray2trac: Operating System: All]

#943 fixed Tor's once-per-second events are not quite once-per-second? nickm arma
Description

Mar 16 11:07:43.655 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0 Mar 16 11:07:44.659 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0 Mar 16 11:07:45.663 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0 Mar 16 11:07:46.667 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0 Mar 16 11:07:47.671 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0 Mar 16 11:07:48.675 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0 Mar 16 11:07:49.676 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0 Mar 16 11:07:50.679 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0 Mar 16 11:07:51.683 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0

My 'bw' events are getting sent out slightly more than one second apart. Didn't we try to send them out every second? More broadly, is libevent calling our once-a-second events every 1.004 seconds or the like?

Maybe that evtimer_add() call in second_elapsed_callback() should be at the beginning? That seems a bit more fragile in the case where it takes a whole second to process stuff. But if it takes any non-trivial amount of time to process stuff, then that function isn't reliably getting called once a second. How big a problem is that?

[Automatically added by flyspray2trac: Operating System: All]

#945 fixed Vidalia config from previous install causes new Vidalia to hang coderman coderman
Description

If a previous Vidalia install has created a vidalia.conf in the local application data folder it will contain a control port setting that will not connect to the VM instance of Tor. Tor VM should detect if the existing vidalia.conf needs to be replaced with a Tor VM default.

The manual work around is to move the %LOCALAPPDATA%\Vidalia\vidalia.conf elsewhere and restart.

EDIT: fixed; to be included in 0.0.2

[Automatically added by flyspray2trac: Operating System: All]

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: See TracQuery for help on using queries.