Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:05:51Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21358Tor fails to reconnect after computer resumes from sleep2020-06-13T15:05:51Zweasel (Peter Palfrader)Tor fails to reconnect after computer resumes from sleepA user reports that tor 0.2.9.x does not work after resumes, similar (or the same as) bug #19969, marked already fixed.
https://bugs.debian.org/853146:
> Tor (or tor with little t) doesn't reconnect automatically to Tor
> network after...A user reports that tor 0.2.9.x does not work after resumes, similar (or the same as) bug #19969, marked already fixed.
https://bugs.debian.org/853146:
> Tor (or tor with little t) doesn't reconnect automatically to Tor
> network after I resume my computer from sleep. So instead I have to
> run "sudo systemctl restart tor" to get it working again. Though, I
> think it reconnects automatically after several minutes of computer
> being on but I would like it to reconnect immediately after the
> computer has resumed from sleep.
>
> I'm not sure if tor uses systemd but so if it uses maybe there is some
> 'resume sleep' hook in systemd that could be used for tor to
> reconnect. Please let me know if you think such change would cause
> some other problems.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21311Exits should resolve IPv6 addresses, regardless of IPv6Exit2020-06-13T15:27:40ZteorExits should resolve IPv6 addresses, regardless of IPv6ExitThat way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.
Was: launch_resolve() should always resolve AAAA records, regardless of IPv6ExitThat way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.
Was: launch_resolve() should always resolve AAAA records, regardless of IPv6ExitTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18580exit relay fails with 'unbound' DNS resolver when lots of requests time-out2020-06-13T17:34:27ZDhalgrenexit relay fails with 'unbound' DNS resolver when lots of requests time-outper
[tor-relays] What does this message mean in my tor logs?
https://lists.torproject.org/pipermail/tor-relays/2016-January/008621.html
[tor-relays] unbound bogs down strangely, degrading exit relay
https://lists.torproject.org/piperma...per
[tor-relays] What does this message mean in my tor logs?
https://lists.torproject.org/pipermail/tor-relays/2016-January/008621.html
[tor-relays] unbound bogs down strangely, degrading exit relay
https://lists.torproject.org/pipermail/tor-relays/2016-March/008918.html
Relay daemon ceases to service Tor Browser requests, timing out, when a local instance of 'unbound' is the DNS resolver and large numbers of DNS requests time-out.
Works fine when 'named' is swapped in place of 'unbound'.
GoDaddy DNS stops responding when large numbers of queries are submitted and this was observed as the particular trigger.
To reproduce, configure the SOA+NS records for several thousand dummy domains to point to a non-responding IP, then generate large numbers of requests against them.
The commands
unbound-control dump_requestlist
unbound-control dump_infra
are helpful for identifying the state.
Have debug-level daemon trace taken when relay was in the unresponsive condition described.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18480Some tor time functions have undefined behavior with dates after 2037 and 32-...2020-06-13T14:55:00ZteorSome tor time functions have undefined behavior with dates after 2037 and 32-bit time_tThe following tor time functions will overflow in 2037. We could improve their semantics by checking for overflow and checking if the functions we call succeed or return an error:
* tor_gmtime_r
* format_rfc1123_time
* format_*iso_time*
...The following tor time functions will overflow in 2037. We could improve their semantics by checking for overflow and checking if the functions we call succeed or return an error:
* tor_gmtime_r
* format_rfc1123_time
* format_*iso_time*
* parse_iso_time
* parse_http_timeTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17145<tor.exe --service install -options -f ...\torrc> returns Error 1064 on Windows2020-06-13T14:49:22ZTrac<tor.exe --service install -options -f ...\torrc> returns Error 1064 on Windows```
tor --service install -options -f C:\tor\torrc
```
from https://www.torproject.org/docs/faq#NTService failed to start the service (Error 1064: An exception occured in the service when handling the control request).
But other options...```
tor --service install -options -f C:\tor\torrc
```
from https://www.torproject.org/docs/faq#NTService failed to start the service (Error 1064: An exception occured in the service when handling the control request).
But other options works:
```
tor.exe --service install -options ControlPort 9051
```
start the Tor Win32 Service and creates the folder C:\Documents and Settings\LocalService\Application Data\tor - tor.exe works like a client only (no disk torrc file, no relay keys). This is useless because i can't use my torrc and run the relay.
The only way to create a running tor service for a relay is to use the "sc create..." in cmd command line as irc#tor<coderman_> suggested. So this is how it works:
```
sc create "Tor Win32 Service" binPath= "\"C:\tornou\Tor\tor.exe\" --nt-service -f \"C:/tornou/Data/Tor/torrc\""
```
returns ImagePath="C:\tornou\Tor\tor.exe" --nt-service -f "C:/tornou/Data/Tor/torrc" and the service is running.
From this point of view, if nobody will fix the related bug, the https://www.torproject.org/docs/faq#NTService may be updated with this "sc create... working option".
Regards,
torQUES
**Trac**:
**Username**: TORquesTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14006Hidden service error: "We'd like to launch a circuit to handle a connection, ...2020-06-13T14:41:16ZGeorge KadianakisHidden service error: "We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits..."The HS operator in https://lists.torproject.org/pipermail/tor-dev/2014-December/007956.html saw this Tor log:
```
Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a
connection, but we already have 32 general-purpose c...The HS operator in https://lists.torproject.org/pipermail/tor-dev/2014-December/007956.html saw this Tor log:
```
Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a
connection, but we already have 32 general-purpose client circuits
pending. Waiting until some finish. [268 similar message(s) suppressed
in last 600 seconds]
```
His network seems to be flaky so this might be the result of crappy network. However, we might want to investigate a bit further, since that message was supressed 250 times.
I can imagine situations in very busy hidden services, where 32 clients try to access them at the same time, which means that it tries to establish 32 circuits at the same time which might cause this problem.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11966"Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge users2020-06-13T14:36:12ZRoger Dingledine"Bootstrapped 20%: Asking for networkstatus consensus" is a lie for bridge usersWhen a Tor client that's configured to use a bridge sees
```
[notice] Bootstrapped 20%: Asking for networkstatus consensus
```
its next plan is actually to send a DIR_PURPOSE_FETCH_SERVERDESC request for the bridge's descriptor. This is ...When a Tor client that's configured to use a bridge sees
```
[notice] Bootstrapped 20%: Asking for networkstatus consensus
```
its next plan is actually to send a DIR_PURPOSE_FETCH_SERVERDESC request for the bridge's descriptor. This is surprising.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11301Tor does not reconnect after network loss with guards used as bridges2020-06-13T14:35:00ZMike PerryTor does not reconnect after network loss with guards used as bridgesYawning and I have both noticed that tor can become unresponsive if either normal tor bridges or PT bridges are configured, and the client suffers a network connectivity loss. After sustained network connectivity loss, all of the orconns...Yawning and I have both noticed that tor can become unresponsive if either normal tor bridges or PT bridges are configured, and the client suffers a network connectivity loss. After sustained network connectivity loss, all of the orconns end up closed, and Tor will not try to reconnect to its bridges, even when new stream attempts arrive.
It is possible that Tor is simply marking all of its bridges down in this case, and is not trying to reconnect to them when the network connectivity returns, thinking they are still down?
The only way to solve this issue is to either send "SIGNAL HUP" to the control port, or to kill -HUP `pidof tor`. After recieving the HUP signal, tor immediately launches new orconns and circuits for its bridges, and attaches the currently pending streams to these new circuits.
Sometimes, after this problem has happened once, tor will cease building circuits even if the network remains available.
This is extremely bad for usability, because TBB becomes completely unusable in this case, and the only thing a normal user can do is exit the whole browser and re-launch it.
This may also indicate a deeper bug with how Tor handles the liveness/'down' status of normal Guard nodes, and may cause Tor to rotate Guards more frequently than necessary.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9390Warn if you're being a public relay but have too-low file descriptor limit2020-06-13T14:30:58ZRoger DingledineWarn if you're being a public relay but have too-low file descriptor limitInspired by discussion on #3030: if we're a public relay, we should check if ulimit -n is too low (under 8192 I'm thinking, based on debian's init script), and warn (and recommend using a package) if so.
This is to help people who run T...Inspired by discussion on #3030: if we're a public relay, we should check if ulimit -n is too low (under 8192 I'm thinking, based on debian's init script), and warn (and recommend using a package) if so.
This is to help people who run Tor from tarball and don't realize all the fixes you have to do manually to do it right.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7164microdesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 ...2022-03-17T20:05:40ZTracmicrodesc.c:378: Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1Oct 20 21:14:18.594 [Warning] microdesc_free(): Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1
**Trac**:
**Username**: jaj123Oct 20 21:14:18.594 [Warning] microdesc_free(): Bug: microdesc_free() called, but md was still referenced 1 node(s); held_by_nodes == 1
**Trac**:
**Username**: jaj123Tor: unspecified