The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:54:38Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24681Make the default fallback weight in Tor 10.02020-06-27T13:54:38ZteorMake the default fallback weight in Tor 10.0This is a follow-up to legacy/trac#24679.
* update the default weight in parse_dir_fallback_line() to 10.0
* update the man page to reflect the new default
10.0 gives us:
* 0.5% clients bootstrapping off an authority when all fallbacks...This is a follow-up to legacy/trac#24679.
* update the default weight in parse_dir_fallback_line() to 10.0
* update the man page to reflect the new default
10.0 gives us:
* 0.5% clients bootstrapping off an authority when all fallbacks are up, * 2% when 25% are down (our replacement threshold)
* 7% when 40% are down (our worst case scenario)Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24677Use ping ::1 on Linux when ping6 ::1 fails2020-06-27T13:54:38ZteorUse ping ::1 on Linux when ping6 ::1 failsTurns out that some Linuxes don't have ping6, but ping ::1 works just fine.
This is a one-line change in Makefile.amTurns out that some Linuxes don't have ping6, but ping ::1 works just fine.
This is a one-line change in Makefile.amTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24671sched: KISTLite should set an upper limit to write on the outbuf2022-10-11T23:40:02ZDavid Gouletdgoulet@torproject.orgsched: KISTLite should set an upper limit to write on the outbufRight now, for the `KISTLite` scheduler, the write limit on the outbuf for a channel is set to `INT_MAX`. This is crazy high and will bloat the outbuf if the channel is struggling to send out data on the wire or the socket is stuck.
Van...Right now, for the `KISTLite` scheduler, the write limit on the outbuf for a channel is set to `INT_MAX`. This is crazy high and will bloat the outbuf if the channel is struggling to send out data on the wire or the socket is stuck.
Vanilla scheduler uses the `num_cells_writeable()` method to limit the amount it puts on the outbuf which is 32KB maximum.
KIST uses the kernel information for this limit.
This is very important that we actually put a limit in the outbuf because it keeps the cells in the circuit queue and that is handled by our OOM in case of memory pressure.
I suggest we simply use the `channel_num_cells_writeable()` for the upper limit when KISTLite is used.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24668sched: scheduler_compare_channels() function will never pick a channel with n...2022-09-01T21:31:34ZDavid Gouletdgoulet@torproject.orgsched: scheduler_compare_channels() function will never pick a channel with no active circuits.In the schedulers, scheduler_compare_channels() is used to decide which channel is 'best' to write data from. It delegates to circuitmux_compare_muxes(), which delegates to ewma_cmp_cmux().
But ewma_cmp_cmux() will never prefer a cmux ...In the schedulers, scheduler_compare_channels() is used to decide which channel is 'best' to write data from. It delegates to circuitmux_compare_muxes(), which delegates to ewma_cmp_cmux().
But ewma_cmp_cmux() will never prefer a cmux with no active circuits on it! So a channel without active circuits will never be picked by the scheduler to flush from a circuit, which is what triggers flushing from its destroy queue. So the channel will stay around forever, never flushing.
To fix this one, we probably have to fix ewma_cmp_cmux() to look at destroy cells too (somehow). And we still need to make sure that the scheduler's position in the heap changes when the data considered by scheduler_compare_channels() changes [*].
[*] I'm not convinced that we're even doing this right with the current scheduler_compare_channels() code. :(https://gitlab.torproject.org/tpo/core/tor/-/issues/24667OOM needs to consider the DESTROY queued cells2022-11-23T15:46:53ZDavid Gouletdgoulet@torproject.orgOOM needs to consider the DESTROY queued cellsOur OOM is only looking a the circuit queue cells and HS descriptors to free up memory.
We need to teach it to cleanup DESTROY cells in case cleaning up the circuits is not enough.
This isn't that trivial because while cleaning up circ...Our OOM is only looking a the circuit queue cells and HS descriptors to free up memory.
We need to teach it to cleanup DESTROY cells in case cleaning up the circuits is not enough.
This isn't that trivial because while cleaning up circuits in the OOM handler, we will also send DESTROY cells for those thus allocating memory. But also not sending those will affects other relays hanging on dead circuits.
All in all, this is an interesting challenge but there might be something smart to do even if not perfect.
The idea here is to avoid an attack that takes advantage of a bug in tor that can fill up the DESTROY cell queue and our OOM just can't do anything about it.https://gitlab.torproject.org/tpo/core/tor/-/issues/24666sched: Store the circuit ID instead of the full DESTROY cell in the destroy q...2020-06-27T13:54:39ZDavid Gouletdgoulet@torproject.orgsched: Store the circuit ID instead of the full DESTROY cell in the destroy queueTor currently keeps the DESTROY cells it needs to relay on the `cmux->destroy_queue` but it keeps the entire `packed_cell_t` which is a full 514 bytes usually.
Instead, we should keep the `circid_t` because this is really only what we n...Tor currently keeps the DESTROY cells it needs to relay on the `cmux->destroy_queue` but it keeps the entire `packed_cell_t` which is a full 514 bytes usually.
Instead, we should keep the `circid_t` because this is really only what we need which would shrink down the used memory by a factor of 128x.
We've observed this on very loaded relays getting DoS with CREATE/DESTROY cells at high rate by many clients which is filling the DESTROY queue while tor is struggling to flush them on the network towards a relay that is also struggling.
This needs to be backported as far as we can in order to avoid relays being memory DoS too hard. The next step is to make our OOM consider those DESTROY cells but that is a bit more involving.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24665sched: In KIST, the extra_space kernel value needs to be allowed to be negative2020-06-27T13:54:39ZDavid Gouletdgoulet@torproject.orgsched: In KIST, the extra_space kernel value needs to be allowed to be negativeKIST, when updating the TCP socket information, computes a limit of bytes we are allowed to write on the socket of the given active channel.
First, the `tcp_space` tells us how much TCP buffer space we have in the kernel for this socket...KIST, when updating the TCP socket information, computes a limit of bytes we are allowed to write on the socket of the given active channel.
First, the `tcp_space` tells us how much TCP buffer space we have in the kernel for this socket. The computation is below. I encourage anyone to go read the comment in `update_socket_info_impl()` to know more about the why:
```
tcp_space = (ent->cwnd - ent->unacked) * (int64_t)(ent->mss);
```
After that, we compute some `extra_space` to be used to give the kernel a bit more data so when the ACK comes back from the packets sitting in the `tcp_space`, it can then take some in that extra space and doesn't have to wait on the scheduler to feed more data. Here is how it is computed:
```
extra_space =
clamp_double_to_int64(
(ent->cwnd * (int64_t)ent->mss) * sock_buf_size_factor) - ent->notsent;
```
It uses the `notsent` value which is the size of the queue in the kernel with data *not* sent so the data in there is not reflected in the `unacked` value because they haven't been sent yet on the wire.
That queue can be large, someimtes bigger than the `tcp_space` we computed above because the congestion window moves over time and the kernel can move as much as its want from the congestion windows into the output queue, that is the TCP stack black magic. On minute the cwnd = 10 and the other it is 67.
If `extra_space` becomes negative because `notsent` is bigger than the current congestion window, this means that the regular `tcp_space` needs to shrink down. Right now, we just add the extra_space if it is positive but the reality is that the current tcp space needs to consider the `notsent` size also.
Bottom line, if `tcp_space + extra_space` end up < 0, the allowed limit needs to be `0` and not what `tcp_space` is.
We've been able to find this issue while looking at very loaded relays that kept putting data in the outbuf while the connection socket was not ready to write. We realized that the `notsent` queue was huge but still KIST was allowing more bytes to be written over and over again filling the outbuf at a rapid rate and thus the memory.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24660Wrap our PRNG interface(s) in Rust with appropriate traits2020-06-27T13:54:39ZIsis LovecruftWrap our PRNG interface(s) in Rust with appropriate traitsSimilar to legacy/trac#24659, we should provide a way to wrap our C code for getting randomness in Rust, while implementing the appropriate traits (from `rand`) so that we're able to switch in Rust implementations if we want later.
This...Similar to legacy/trac#24659, we should provide a way to wrap our C code for getting randomness in Rust, while implementing the appropriate traits (from `rand`) so that we're able to switch in Rust implementations if we want later.
This is also blocking legacy/trac#23886.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/24659Wrap our sha2 interface in Rust which implements the appropriate traits2020-06-27T13:54:39ZIsis LovecruftWrap our sha2 interface in Rust which implements the appropriate traitsWe should wrap our usage of hash digest functions (and XOFs) in Rust types which implement the appropriate traits, yet still exposes the same API functionality we currently have in C. To keep this task small, I think we should start off ...We should wrap our usage of hash digest functions (and XOFs) in Rust types which implement the appropriate traits, yet still exposes the same API functionality we currently have in C. To keep this task small, I think we should start off with just the sha2 code for now. (Later, it's probably some copy-paste and a bit of refactoring to provide the same interface for other digests, and similar for XOFs.)
This ticket is probably slightly blocked on legacy/trac#24658, and in turn is blocking legacy/trac#23886.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/24652Rust builds fail on macOS with linker error2020-06-27T13:54:40ZteorRust builds fail on macOS with linker errorBoth my gcc and clang builds get this error:
https://travis-ci.org/teor2345/tor/jobs/316748503
https://travis-ci.org/teor2345/tor/jobs/316748509
```
Undefined symbols for architecture x86_64:
"_res_9_init", referenced from:
st...Both my gcc and clang builds get this error:
https://travis-ci.org/teor2345/tor/jobs/316748503
https://travis-ci.org/teor2345/tor/jobs/316748509
```
Undefined symbols for architecture x86_64:
"_res_9_init", referenced from:
std::sys::unix::net::res_init_if_glibc_before_2_26::h5cce5181e3d1daee in libtor_rust.a(std-af00cffd9617c4f1.std13-3c37598e0257c2e4b7713b0956fa5bab.rs.rcgu.o)
ld: symbol(s) not found for architecture x86_64
```
The Linux builds are fine, as are the non-Rust macOS builds.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24650Simplify bridge code: do we need separate addr and addport_configured?2021-09-16T14:31:18ZNick MathewsonSimplify bridge code: do we need separate addr and addport_configured?Looking at the bridge code, it seems that we have separate addrport_configured and addr elements in the bridge_info_t... but that there isn't actually a way for them to diverge. If that's true, we should remove one of them as redundant....Looking at the bridge code, it seems that we have separate addrport_configured and addr elements in the bridge_info_t... but that there isn't actually a way for them to diverge. If that's true, we should remove one of them as redundant.
(If they *can* diverge, we should document how that happens, exactly)https://gitlab.torproject.org/tpo/core/tor/-/issues/24649Simplify bridge code: do we still need mark-unmark-and-sweep logic?2021-09-16T14:31:18ZNick MathewsonSimplify bridge code: do we still need mark-unmark-and-sweep logic?In an older version of the bridge code, we would encode some state information in the bridge_info_t object. Therefore, when we reloaded the configuration, it was important that we use the old object for any bridges that we still had. F...In an older version of the bridge code, we would encode some state information in the bridge_info_t object. Therefore, when we reloaded the configuration, it was important that we use the old object for any bridges that we still had. For that reason, we would (on reloading the configuration) first mark all bridges, then unmark any bridges that were still in the configuration (while adding any new bridges), and finally we'd free all the marked bridges.
But, looking at the code now, it appears we no longer take this approach: once marked_for_removal is set on a bridge, nothing clears it. If that's the case, we could simplify our bridge configuration logic a bit by just clearing the bridge list and rebuilding it, and dropping this whole "marked_for_removal" business.https://gitlab.torproject.org/tpo/core/tor/-/issues/24641Simplify "did this option change" functions in config.c2020-06-27T13:54:40ZNick MathewsonSimplify "did this option change" functions in config.cThere's a great deal of boilerplate here, in all the options_transition_* functions. I hate to say it, but this seems like a job for macros.There's a great deal of boilerplate here, in all the options_transition_* functions. I hate to say it, but this seems like a job for macros.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24639After I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn errors2020-06-27T13:54:40ZTracAfter I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn errorsAfter I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn errors.
```
│ 13:29:26 [NOTICE] Performing bandwidth self-test...done.
│ 13:28:45 [NOTICE] Bootstrapped 100%: Done
│ 13:28:45 [NOTICE] Tor has successfull...After I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn errors.
```
│ 13:29:26 [NOTICE] Performing bandwidth self-test...done.
│ 13:28:45 [NOTICE] Bootstrapped 100%: Done
│ 13:28:45 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
│ 13:28:45 [WARN] 6 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE ** [4 duplicates hidden]**
│ 13:28:45 [WARN] 106 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:45 [WARN] 112 connections have failed:
│ 13:28:45 [WARN] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Connection timed out; TIMEOUT; count 14; recommendation warn; host
│ 5CF8AFA5E4B0BB88942A44A3F3AAE08C3BDFD60B at 178.16.208.62:443) ** [94 duplicates hidden]**
│ 13:28:45 [WARN] 105 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:45 [WARN] 111 connections have failed:
│ 13:28:45 [WARN] 104 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:45 [WARN] 110 connections have failed:
│ 13:28:44 [WARN] 103 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:44 [WARN] 109 connections have failed:
│ 13:28:44 [WARN] 102 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:44 [WARN] 108 connections have failed:
│ 13:28:43 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit
│ 13:28:42 [NOTICE] Bootstrapped 85%: Finishing handshake with first hop
│ 13:28:42 [NOTICE] Bootstrapped 80%: Connecting to the Tor networ
```
```
rk
│ 13:28:40 [WARN] 5 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE ** [59 duplicates hidden]**
│ 13:28:40 [WARN] 93 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 98 connections have failed:
│ 13:28:40 [WARN] 92 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 97 connections have failed:
│ 13:28:40 [WARN] 91 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 96 connections have failed:
│ 13:28:40 [WARN] 90 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 95 connections have failed:
│ 13:28:40 [WARN] 89 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 94 connections have failed:
│ 13:28:40 [WARN] 88 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 93 connections have failed:
│ 13:28:40 [WARN] 87 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 92 connections have failed:
│ 13:28:40 [WARN] 86 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 91 connections have failed:
│ 13:28:40 [WARN] 85 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 90 connections have failed:
│ 13:28:40 [WARN] 84 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 89 connections have failed:
│ 13:28:40 [WARN] 83 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 88 connections have failed:
│ 13:28:40 [WARN] 82 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 87 connections have failed:
│ 13:28:40 [WARN] 81 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 86 connections have failed:
│ 13:28:40 [WARN] 80 connections died in state connect()ing with SSL state (No SSL object)
│ 13:28:40 [WARN] 85 connections have failed:
─┘ 13:28:40 [WARN] 79 connections died in state connect()ing with SSL state (No SSL obj
```
**Trac**:
**Username**: DbryrtfbcbhgfTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24634test_hs_common.c:974:33: warning: declaration of 'time' shadows a global decl...2020-06-27T13:54:40ZGeorge Kadianakistest_hs_common.c:974:33: warning: declaration of 'time' shadows a global declaration```
09:54:31 [0m[0m../src/test/test_hs_common.c: In function 'set_consensus_times':
09:54:43 [0m[0m../src/test/test_hs_common.c:974:33: warning: declaration of 'time' shadows a global declaration [-Wshadow]
[ https://jenkins.torproject.o...```
09:54:31 [0m[0m../src/test/test_hs_common.c: In function 'set_consensus_times':
09:54:43 [0m[0m../src/test/test_hs_common.c:974:33: warning: declaration of 'time' shadows a global declaration [-Wshadow]
[ https://jenkins.torproject.org/job/tor-debian-release-binaries-arm/18/ARCHITECTURE=armhf,SUITE=wheezy/consoleFull ]
```Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24633to->pending->tqh_last is 0xFFFFFFFFFFFFFFFF。2020-06-27T13:54:40ZTracto->pending->tqh_last is 0xFFFFFFFFFFFFFFFF。I'm debuging tor. And it throw an error at function timeouts_sched,
The version is: release-0.3.2
this is the stack:
> tor.exe!timeouts_sched(timeouts * T=0x0000000000517e90, timeout * to=0x0000000003307450, unsigned __int64 expires=21...I'm debuging tor. And it throw an error at function timeouts_sched,
The version is: release-0.3.2
this is the stack:
> tor.exe!timeouts_sched(timeouts * T=0x0000000000517e90, timeout * to=0x0000000003307450, unsigned __int64 expires=2123027) 行 355 C
tor.exe!timeouts_add(timeouts * T=0x0000000000517e90, timeout * to=0x0000000003307450, unsigned __int64 timeout=6290) 行 394 C
tor.exe!timer_schedule(timeout * t=0x0000000003307450, const timeval * tv=0x000000000027dee8) 行 300 C
tor.exe!channelpadding_schedule_padding(channel_s * chan=0x00000000032f7c80, int in_ms=629) 行 478 C
tor.exe!channelpadding_decide_to_pad_channel(channel_s * chan=0x00000000032f7c80) 行 783 C
tor.exe!run_connection_housekeeping(int i=3, __int64 now=1513329560) 行 1132 C
tor.exe!run_scheduled_events(__int64 now=1513329560) 行 1464 C
tor.exe!second_elapsed_callback(periodic_timer_t * timer=0x00000000042a5550, void * arg=0x0000000000000000) 行 2216 C
tor.exe!periodic_timer_cb(__int64 fd=-1, short what=1, void * arg=0x00000000042a5550) 行 187 C
tor.exe!event_persist_closure(event_base * base=0x00000000004e8fa0, event * ev=0x000000000427d200) 行 1532 C
tor.exe!event_process_active_single_queue(event_base * base=0x00000000004e8fa0, evcallback_list * activeq=0x00000000004e8eb0, int max_to_process=2147483647, const timeval * endtime=0x0000000000000000) 行 1591 C
tor.exe!event_process_active(event_base * base=0x00000000004e8fa0) 行 1689 C
tor.exe!event_base_loop(event_base * base=0x00000000004e8fa0, int flags=0) 行 1912 C
tor.exe!run_main_loop_once() 行 2631 C
tor.exe!run_main_loop_until_done() 行 2685 C
tor.exe!do_main_loop() 行 2599 C
tor.exe!tor_main(int argc=1, char * * argv=0x000000000046c850) 行 3780 C
tor.exe!main(int argc=1, char * * argv=0x000000000046c850) 行 34 C
1.Run tor
2.when it say Bootstrapped 100%: Done, disable network
3.enable network
It will crush.
timeout.c
#if !defined WHEEL_NUM
#define WHEEL_NUM 4
#endif
...
struct timeouts {
struct timeout_list wheel[WHEEL_NUM][WHEEL_LEN], expired;
...
}
In function timeouts_sched,
int wheel, slot;
...
wheel = timeout_wheel(rem);
...
to->pending = &T->wheel[wheel][slot];
if wheel >= WHEEL_NUM, it will crush.
**Trac**:
**Username**: sx5486510Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24630Stop initialising rust git submodules, travis does this automatically2020-06-27T13:54:41ZteorStop initialising rust git submodules, travis does this automaticallyisis told me to do this.isis told me to do this.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24627DisableNetwork is set - Rend stream is 120 seconds late2020-06-27T13:54:41ZTracDisableNetwork is set - Rend stream is 120 seconds lateI'm using Windows 10 with a VPN.
I was able to access a specific site fine for weeks, I don't remember doing anything special to let me get there, but yesterday the connection timed out. I've found similar issues on this site but no fixe...I'm using Windows 10 with a VPN.
I was able to access a specific site fine for weeks, I don't remember doing anything special to let me get there, but yesterday the connection timed out. I've found similar issues on this site but no fixes worked.
I've tried:
-clean installing my entire computer
-factory resetting my router
-using BridgeDB to add bridges
-using new Identity, new circuit, several times
Here's my logs:
12/14/2017 20:00:12 PM.100 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit
12/14/2017 20:00:14 PM.900 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
12/14/2017 20:00:14 PM.900 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/14/2017 20:00:14 PM.900 [NOTICE] Closing old Socks listener on 127.0.0.1:9150
12/14/2017 20:00:15 PM.300 [NOTICE] Delaying directory fetches: DisableNetwork is set.
12/14/2017 20:00:24 PM.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/14/2017 20:00:24 PM.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/14/2017 20:00:24 PM.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12/14/2017 20:00:24 PM.700 [NOTICE] Opening Socks listener on 127.0.0.1:9150
12/14/2017 20:00:26 PM.700 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
12/14/2017 20:00:26 PM.700 [NOTICE] Bootstrapped 100%: Done
12/14/2017 20:00:29 PM.800 [NOTICE] New control connection opened from 127.0.0.1.
12/14/2017 20:00:30 PM.100 [NOTICE] New control connection opened from 127.0.0.1.
12/14/2017 20:03:11 PM.200 [NOTICE] Rend stream is 120 seconds late. Giving up on address '[scrubbed].onion'.
help and thank you!
**Trac**:
**Username**: stevensondhiemTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24619Tor 0.3.1.9 exited unexpectedly on Windows2021-07-09T17:30:27ZcypherpunksTor 0.3.1.9 exited unexpectedly on WindowsOS: Windows 7 SP1 x64
Tor browser 7.0.11 (32-bit)
Installed it fine, but everytime I log back in from sleep or hibernation, or if it sits idle for a while, I get the error message:
"Tor unexpectedly exited, etc etc"
Restarting doesn'...OS: Windows 7 SP1 x64
Tor browser 7.0.11 (32-bit)
Installed it fine, but everytime I log back in from sleep or hibernation, or if it sits idle for a while, I get the error message:
"Tor unexpectedly exited, etc etc"
Restarting doesn't solve it. Reinstalling didn't solve it. I noticed it started happening for me after installing 7.0.10 about a week or so ago. Went back to 7.0.8, but that didn't solve it either. It's still happening with 7.0.11, but not as much as 7.0.10.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24617Feature flags for new controller-accessible Tor features2022-06-17T17:42:24ZmeejahFeature flags for new controller-accessible Tor featuresAs Tor grows new features available via the control protocol, it would be useful to indicate support for these features via some GETINFO.
Currently, controllers have two ways to discover if the Tor they connected to supports a feature: ...As Tor grows new features available via the control protocol, it would be useful to indicate support for these features via some GETINFO.
Currently, controllers have two ways to discover if the Tor they connected to supports a feature: "just try" and see if there's an error; or look at the Tor version.
Both of these can be problematic:
You can't always "just try". For example, when HS_DESC was first added as an event it didn't include the onion address, so you'd wait forever to see if a descriptor was uploaded. For completely new commands, "just try" is probably sufficient but when commands gain new capabilities and/or options it can get less obvious what the right thing to do is.
Doing version comparisons can get tricky: as a new feature is implemented, it will generally appear on master first, then maybe in an alpha release and finally in a "real/full" release. A controller wanting to take fullest advantage of a new feature (e.g. to let users test it against a Tor from "master") would have to program in each of these versions separately, which is tedious.
Instead, a definitive "GETINFO" which returns details of the feature would be ideal. Then, a controller can change its behavior and take advantage of a new feature as soon as it's on master and users can continue to take advantage of this as the feature moves through alphas, betas, etcetera. This would also work well for features that can be turned off (or on) through other mechanisms (e.g. configuration, command-line or build options).
Such flags could also "roll up" logical features that actually need multiple controller commands/events to work. For example, adding v3 services changed some config options, modified the ADD_ONION command and (later) provided upload information via the HS_DESC event. So until the ADD_ONION *and* HS_DESC changes landed, a controller couldn't properly add a v3 ephemeral service.