Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-10-11T23:39:35Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40109Does every new consensus disable IntroDosDefense?2022-10-11T23:39:35ZRoger DingledineDoes every new consensus disable IntroDosDefense?In handle_establish_intro_cell_dos_extension(), when the intro point receives an extension asking it to enable the rate limiting feature, it does:
```
/* We passed validation, enable defenses and apply rate/burst. */
circ->introduce2...In handle_establish_intro_cell_dos_extension(), when the intro point receives an extension asking it to enable the rate limiting feature, it does:
```
/* We passed validation, enable defenses and apply rate/burst. */
circ->introduce2_dos_defense_enabled = 1;
/* Initialize the INTRODUCE2 token bucket for the rate limiting. */
token_bucket_ctr_init(&circ->introduce2_bucket,
(uint32_t) intro2_rate_per_sec,
(uint32_t) intro2_burst_per_sec,
(uint32_t) approx_time());
```
But then later, in hs_dos_consensus_has_changed() we call set_consensus_parameters(ns) which resets some global variables about what we think the consensus says (so far so good), and then it calls update_intro_circuits() which goes through the list of established intro points and
```
SMARTLIST_FOREACH_BEGIN(intro_circs, circuit_t *, circ) {
/* Defenses might have been enabled or disabled. */
TO_OR_CIRCUIT(circ)->introduce2_dos_defense_enabled =
consensus_param_introduce_defense_enabled;
/* Adjust the rate/burst value that might have changed. */
token_bucket_ctr_adjust(&TO_OR_CIRCUIT(circ)->introduce2_bucket,
consensus_param_introduce_rate_per_sec,
consensus_param_introduce_burst_per_sec);
} SMARTLIST_FOREACH_END(circ);
```
It sure looks to me like this is *overwriting* the values requested in the intro cell DoS extension.
And since the consensus right now doesn't have these consensus params set, then they will be reset to their defaults ("disabled", "25", "200") for every intro point every time a new consensus is processed by the intro point.
If this is so, then it sure seems like we want to set some flag on the intro point, called "I am using explicit values rather than the default", and if that flag is set then we don't mess with it when processing a new consensus.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40108ADD_ONION command returns "Missing 'Port' argument" when null terminator is p...2022-09-01T21:42:49ZrichardADD_ONION command returns "Missing 'Port' argument" when null terminator is present at endSo I naively sent:
"ADD_ONION ED25519-V3:$(base64PrivateKey)\0"
over the control port including the NULL terminator from my C string. Rather than yelling at me for sending non-printable characters (or something similar), the command...So I naively sent:
"ADD_ONION ED25519-V3:$(base64PrivateKey)\0"
over the control port including the NULL terminator from my C string. Rather than yelling at me for sending non-printable characters (or something similar), the command returned "Missing 'Port' argument"
Seems weird.
EDIT:
tor --version -> "Tor version 0.4.3.6"https://gitlab.torproject.org/tpo/core/tor/-/issues/40100Mixing long lived streams with shorter connections causes hidden tor service ...2021-07-09T17:30:28Ztubby-torMixing long lived streams with shorter connections causes hidden tor service name (.onion) resolution/routing failuresFrom one single tor instance with default settings and a single client address, long-lived streams to some .onion addresses seems to eventually break name resolution/routing to other .onion addresses that are short-lived connections.
Fo...From one single tor instance with default settings and a single client address, long-lived streams to some .onion addresses seems to eventually break name resolution/routing to other .onion addresses that are short-lived connections.
For example:
- Copy a large file over ssh from Client to server a.onion, b.onion, c.onion. (simultaneously for several hours)
- Connect to server d.onion, e.onion, f.onion for a few commands, then disconnect several times during the long running streams.
Eventually and intermittently, connections to d.onion, e.onion, f.onion fail on the client-side only.
Tests to isolate the problem:
- Testing the connections from another clients works, confirming that the servers d.onion, e.onion, f.onion are still up and it is a problem with the client-side tor
- Forcing a `SIGNAL NEWNYM` on the client corrects the problem and the client can subsequently connect to d.onion, e.onion, f.onion. The bad side-effect is that all the long-running streams are disconnected (of course).
- Forcing very aggressive circuit rebuilding on the client-side tor mostly solves the problem but also causes more disconnection of streams. I haven't been able to isolate further which one of these options is actually fixing the problem, but providing these are further information for others.
```
KeepalivePeriod 1
LongLivedPorts
MaxCircuitDirtiness 30
NewCircuitPeriod 30
```
- Stream Isolation `SocksPort ... IsolateDestAddr` did NOT seem to help.
I suspect that stale circuits are remaining opened for the long-running streams and that even though they keep streaming, they can no longer resolve/route new .onion requests and thus fail.
I think that tor with default configuration should be robust in these situations and there should not be an obscure .onion name resolution/routing failre to connect to hosts. Most users will not be able to diagnose such a situation and will also have trouble resolving it, ultimately giving the impression that .onion services are unreliable, regardless of whether it is .onion server side failure or client side .onion name resolution or routing failure.
I am not specifically looking for a solution, since I have many workarounds, simply trying to report the issue in a way that may help the tor project.
I have NOT tested the same problem using clearnet IP or domain name based servers, so I cannot report if it is specific to .onion or more general to all client-side tor circuits.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40090ONION_CLIENT_AUTH_ADD persistence error unhelpfully vague2022-02-28T19:41:25ZDamian JohnsonONION_CLIENT_AUTH_ADD persistence error unhelpfully vagueI tried to add an integ test for persisting hidden service credentials to disk (calling ONION_CLIENT_AUTH_ADD with a "Permanent" flag) but the error response I received from tor is unhelpfully vague...
> Unable to store creds for "yvhz3...I tried to add an integ test for persisting hidden service credentials to disk (calling ONION_CLIENT_AUTH_ADD with a "Permanent" flag) but the error response I received from tor is unhelpfully vague...
> Unable to store creds for "yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid"
It's possible that there's an issue on my end, or also possible that the feature doesn't work. Unfortunately this response is too nebulous for me to troubleshoot.https://gitlab.torproject.org/tpo/core/tor/-/issues/40089ONION_CLIENT_AUTH_ADD client names aren't persisted2021-06-23T17:22:08ZDamian JohnsonONION_CLIENT_AUTH_ADD client names aren't persistedONION_CLIENT_AUTH_ADD is documented as accepting a ClientName, but ONION_CLIENT_AUTH_VIEW is failing to echo these names back as proscribed by the spec...
```
Sent to tor: ONION_CLIENT_AUTH_ADD yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7...ONION_CLIENT_AUTH_ADD is documented as accepting a ClientName, but ONION_CLIENT_AUTH_VIEW is failing to echo these names back as proscribed by the spec...
```
Sent to tor: ONION_CLIENT_AUTH_ADD yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid x25519:FCV0c0ELDKKDpSFgVIB8Yow8Evj5iD+GoiTtK878NkQ= ClientName=StemInteg
Received from tor: 250 OK
Sent to tor: ONION_CLIENT_AUTH_VIEW yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid
Received from tor:
250-ONION_CLIENT_AUTH_VIEW yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid
250-CLIENT yvhz3ofkv7gwf5hpzqvhonpr3gbax2cc7dee3xcnt7dmtlx2gu7vyvid x25519:FCV0c0ELDKKDpSFgVIB8Yow8Evj5iD+GoiTtK878NkQ=
250 OK
```Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40084Controller support for creating authenticated onion services2021-06-23T17:22:08ZDamian JohnsonController support for creating authenticated onion services[As discussed on tor-dev@](https://lists.torproject.org/pipermail/tor-dev/2020-June/014377.html) the only way to create a v3 onion service with authentication is by writing files to disk within a 'authorized_clients' directory.
Our ADD_...[As discussed on tor-dev@](https://lists.torproject.org/pipermail/tor-dev/2020-June/014377.html) the only way to create a v3 onion service with authentication is by writing files to disk within a 'authorized_clients' directory.
Our ADD_ONION command can create authenticated v2 services via its 'BasicAuth' flag, and we can authenticate **to** a v3 service with ONION_CLIENT_AUTH_ADD. However, there isn't yet a controller mechanism to **create** a v3 service with authentication. This is intended to track that.Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40070UX Problems with migration to V3 names2021-06-30T15:30:22Zpf.teamUX Problems with migration to V3 namesAs we all know, from about November 2021 deprecated v2 onion names will cease to work altogether ( https://blog.torproject.org/v2-deprecation-timeline ).
We understand the reasons behind this decision, but at the same time we consider s...As we all know, from about November 2021 deprecated v2 onion names will cease to work altogether ( https://blog.torproject.org/v2-deprecation-timeline ).
We understand the reasons behind this decision, but at the same time we consider solving the problem caused by it to be vital.
The crux of the v3 vs v2 issue is as follows:
A v2 name looks like a random combination of 16 letters and digits. Half of them, or even more, may be picked by the v2 service owner via the mining process to ensure that the name of their service can be remembered more easily. This way the user only has to remember a word or a combination thereof, associated with this service, and 8 or less random letters and digits. It is much easier than having to remember 16 random symbols, although remembering 16 random symbols is still realistically possible.
V3 names have no such option. Even if the owner of the service manages to pick 8-12 symbols, there will still be at least 40 random symbols left. Remembering such a name exactly seems to us to be impossible for most users.
This means that v3 names have some obvious drawbacks:
1. Since v3 names cannot be easily remembered, they would have to be recorded somehow, whether on a digital device or on paper, which compromises the safety of the user in case of a search by security services or affiliated groups in repressive regimes. Keeping such names in encrypted containers of any sort does not help much, since the very presence of such containers automatically provokes additional questioning. Refusing to show their contents may be interpreted as admission of guild or involvement, or simply provoke security services to employ coercion or even torture.
2. These names are hard to input manually. Even a skilled PC user would have to spend about half a minute inputting a v3 name without checking for misprints and other errors. A less skilled user would need more than 2 minutes and would very likely require several attempts to do so. It's even worse on a smartphone or any other mobile device, which is sometimes the only way some people can connect to the Internet. By our calculations, it takes 2 minutes 40 seconds to input 54 symbols on a mobile device, and that's without checking for any errors.
3. When inputting such a long name manually, it would be harder to determine, if failure to connect to a hidden service is caused by some Tor network issues, problems with the service itself, or simply an input error, since you'd have to check 54 symbols and rule out typos or misprints, such as mistaking "g" for "q" or I for "l" etc. The problem becomes even bigger when working with a name recorded on paper in handwriting.
We consider the worst and most critical consequences of v2 deprecation to be:
1. Multiple new potential avenues for user data leaks: lost paper scraps with v3 names, attempts to record hidden service names in insecure places, such as blogs, messengers, social networks etc, browser bookmarks, plaintext files on stationary and mobile devices, and so on.
2. Much more inconveniences when working with hidden services, potentially making them unusable in a lot of cases. If the user tries to input handwritten symbols 5 or 6 times and still fails, they might decide that the service itself is not responding, when in reality the user simply mistyped one of the 54 symbols in the name. Moreover, inputting the name becomes more labour-intensive and time-consuming, which is especially important for people pursued by repressive regimes or working under duress or high levels of stress, such as activists, whistleblowers etc.
V2 deprecation is probably sound from a technical standpoint, but, as far as we know, one of Tor Project's main goals is to provide a user-friendly platform for private and anonymous communication between people who aren't themselves tech specialists. V2 deprecation without making v3 names more user-friendly and convenient jeopardizes this goal. The attempt to solve this issue by creating the pseudo-domain securedrop.tor.onion does not seem to be a good solution, since it makes name resolution dependent on a centralized authority, and therefore susceptible to censorship, and cannot be considered reliable or secure.
What we think can be done about this:
* Abstain from turning v2 support off, leaving v3 as the default version. Put a risk warning for the service owner in case they want to use v2. Tor users should also receive a warning when trying to connect to v2 services, like they used to get in old versions of Tor Browser when trying to extend the browser window to full screen size.
* Replace v2 with an additional service that would redirect users to a v3 name, supported by the Tor router. This service should also use short names. Redirection verification can be accomplished via additional security measures, like symmetric encryption via passphrase: the client connects to the v2-style name and receives an encrypted v3 name in return, inputs a password and gets either the necessary v3 name or an encryption error that means the v2 name has been compromised.
* Use several v2 names to access a v3 service as a variation of the previous method. To access a v3 service, the user has to access several v2 services. It is much less likely that all of these v2 names would be compromised, and remembering several v2 names is still easier than one v3 name.
We consider solving this issue to be of extreme importance, but without resorting to centralized naming authorities. Otherwise, Tor Project might be reduced to just a tool for circumventing superficial government censorship on the Internet, making it unsuitable for people who require actual privacy and anonymity.https://gitlab.torproject.org/tpo/core/tor/-/issues/40064hs: Implement self reachability test2021-09-27T16:40:27ZDavid Gouletdgoulet@torproject.orghs: Implement self reachability testI have not thought of the anonymity problem that could bring if any, just more of a pragmatic approach of how that could be useful.
Onion services sometimes can find themselves unable to publish a descriptor for many different reasons o...I have not thought of the anonymity problem that could bring if any, just more of a pragmatic approach of how that could be useful.
Onion services sometimes can find themselves unable to publish a descriptor for many different reasons or even bugs that we keep finding. Even under severe DDoS, they become unavailable but they don't know.
What if they would regularly do self reachability tests and in case of failure, they could do some "recovery actions" but also dumping their state so it is more easily debuggable.
But also, they could export that status onto something like tor#40063 which could inform very quickly the operator which in turn could correlate with the their stats if this is a tor problem or a DDoS or network issue or anything to that end.https://gitlab.torproject.org/tpo/core/tor/-/issues/40063stats: Create a stat exporter port for monitoring purposes2021-06-23T17:22:08ZDavid Gouletdgoulet@torproject.orgstats: Create a stat exporter port for monitoring purposesThe `Control Port` does basically export a lot of data that tor holds but this new `Stat Port` (we'll call that for now) differs in a couple of ways.
The idea is that it would be a pull mechanism so tools connect to the port, request a ...The `Control Port` does basically export a lot of data that tor holds but this new `Stat Port` (we'll call that for now) differs in a couple of ways.
The idea is that it would be a pull mechanism so tools connect to the port, request a series of stats, tor sends it and then disconnects. This follows the Prometheus model which is to expose your stats through an HTTP interface and the monitoring server just comes in regularly and get the data.
Tor has already everything to support that that is listener port and HTTP interface we can hook on (with a bit of work :).
We can export all sorts of stats useful for monitoring relays and onion services. For example, for onion service monitoring, exporting these would be game changer for service operators:
1. Amount of traffic the .onion is getting
2. Amount of introduction requests
3. Amount of rendezvous requests and how many succeeds vs fails.
4. Descriptor status with HSDir
...
The reason it differs from the Control Port is that most public relays or onion services would prefer not having that port open **especially** on a public address. But also, this follows the concept of providing a `REST` interface which would be very little amount of work for the tor daemon where with the control port, is often a mixed of poking at our internal state instead of a pre-populated memory with stats.
There is of course the question of data safety here. If we build nice interface that in couple clicks allows operators to have beautiful Grafana graphs, then some says it is an incentive to export it and sometimes publicly.
However, this is really not different from the Control Port or Nyx monitoring interface. The problem shows up when the third part tool gathering the data actually archives. That today, is doable. This would yes be lowering the bar for this to happen but I think the ability to properly monitor a relay or an onion service outweigh the cons.
We could see that at first it is only for onion services and on a non public port. We could think of security checks like this but in the end, this is would just be another tool in the service operator belt to properly monitor tor if they choose to with of course risks associated with it like anything tor opens.
This is one example that @ahf worked on but with a push model: https://github.com/ahf/tor/tree/ahf/feature/stats_reporterTor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40062Tor always overwrites onion service hostname file, but should leave it alone ...2021-06-23T17:22:07ZRoger DingledineTor always overwrites onion service hostname file, but should leave it alone if it shouldn't changeIf you start your Tor with an onion service, it will make the appropriate files in your onion service directory, e.g.
```
$ ls -la hidden_service
total 32
drwx------ 3 arma arma 4096 Jul 24 05:14 .
drwxrwxrwt 21 root root 12288 Jul 24 ...If you start your Tor with an onion service, it will make the appropriate files in your onion service directory, e.g.
```
$ ls -la hidden_service
total 32
drwx------ 3 arma arma 4096 Jul 24 05:14 .
drwxrwxrwt 21 root root 12288 Jul 24 05:11 ..
drwx------ 2 arma arma 4096 Jul 24 05:11 authorized_clients
-rw------- 1 arma arma 63 Jul 24 05:14 hostname
-rw------- 1 arma arma 64 Jul 16 00:11 hs_ed25519_public_key
-rw------- 1 arma arma 96 Jul 16 00:11 hs_ed25519_secret_key
```
but if you then set the directory to read-only, Tor will fail to start, complaining
```
Jul 24 05:16:38.104 [warn] Couldn't open "/tmp/hidden_service//hostname.tmp" (/tmp/hidden_service//hostname) for writing: Permission denied
Jul 24 05:16:38.104 [warn] Could not write onion address to hostname file "/tmp/hidden_service//hostname"
Jul 24 05:16:38.104 [warn] Error loading rendezvous service keys
Jul 24 05:16:38.104 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.4.5.0-alpha-dev 5336ac26693cdba4)
```
Back in the day, I added some logic where it would first *read* the hostname file, and decide if it already has the correct content in it, and if it does, it would leave it alone (i.e. not try to write). It looks like either I misremembered doing that, or we lost that feature somewhere along the way.
If we resume doing that behavior, then people can set their onion service keys directory to be read-only, which will let them improve their opsec.
Bug reported by Jeff Moss on his Defcon onion.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40003hs-v2: Add a deprecation warning2021-06-23T17:22:07ZDavid Gouletdgoulet@torproject.orghs-v2: Add a deprecation warningWe've entered deprecation path for v2: https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.html
0.4.4.x series should be the first version to warn of deprecation.We've entered deprecation path for v2: https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.html
0.4.4.x series should be the first version to warn of deprecation.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34400control: HSFETCH command fails to validate v2 addresses2022-07-07T00:49:02ZDavid Gouletdgoulet@torproject.orgcontrol: HSFETCH command fails to validate v2 addressesIn `handle_control_hsfetch()`:
```
} else if (strcmpstart(arg1, v2_str) == 0 &&
rend_valid_descriptor_id(arg1 + v2_str_len) &&
base32_decode(digest, sizeof(digest), arg1 + v2_str_len,
...In `handle_control_hsfetch()`:
```
} else if (strcmpstart(arg1, v2_str) == 0 &&
rend_valid_descriptor_id(arg1 + v2_str_len) &&
base32_decode(digest, sizeof(digest), arg1 + v2_str_len,
REND_DESC_ID_V2_LEN_BASE32) ==
REND_DESC_ID_V2_LEN_BASE32) {
```
The above snippet is how we validate the v2 address for the `HSFETCH` command. The `base32_decode()` function returns the number of bytes _decoded_ and thus it should returns on success `sizeof(digest)`, not the total length of the base32 address (20 vs 32).
Issue was introduced in commit `a517daa56f5848d25ba79617a1a7b82ed2b0a7c0` meaning since 0.4.1.1-alpha (ticket legacy/trac#28913).
I noticed this because I recently updated the bad HSDirscanner Tor to use our latest and it broke the scanner.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34299man page has wrong default for MinUptimeHidServDirectoryV22022-07-07T00:49:01ZRoger Dingledineman page has wrong default for MinUptimeHidServDirectoryV2In legacy/trac#14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the ...In legacy/trac#14149 (Tor 0.2.6.3-alpha) we changed the default for MinUptimeHidServDirectoryV2 to 96 hours, to reflect that the directory authorities had already changed it manually. We changed the spec too. But we forgot to change the man page.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/34254Jenkins fails with hs_service.c:3118:3: error: comparison of unsigned express...2022-07-07T00:49:01ZGeorge KadianakisJenkins fails with hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenk...```
11:23:10 ../tor/src/feature/hs/hs_service.c: In function 'log_cant_upload_desc':
11:23:10 ../tor/src/feature/hs/hs_service.c:3118:3: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
```
https://jenkins.torproject.org/job/tor-ci-windows-master/659/consoleFull
Seems to be a by-product of legacy/trac#33400.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/34087HSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circ2021-06-23T17:22:07Zs7rHSv3: Bug: Non-fatal assertion in hs_client.c:981: close_or_reextend_intro_circClient side HSv3 non fatal bug. It occurs like between ~20 - 30 times in a total of 100.000 built rendezvous circuits:
```
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_c...Client side HSv3 non fatal bug. It occurs like between ~20 - 30 times in a total of 100.000 built rendezvous circuits:
```
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(desc == NULL) failed in close_or_reextend_intro_circ at ../src/feature/hs/hs_client.c:981. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(hs_client_receive_introduce_ack+0x2f5) [0x55d8749cfe95] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(rend_process_relay_cell+0x226) [0x55d874a1e796] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xbe368) [0x55d874966368] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
Apr 11 08:58:25.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:981: close_or_reextend_intro_circ: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.4.4.0-alpha-dev )
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34086HSv3: Bug Non-fatal assertion in hs_client.c:776: client_rendezvous_circ_has_...2021-06-23T17:22:07Zs7rHSv3: Bug Non-fatal assertion in hs_client.c:776: client_rendezvous_circ_has_openedClient side HSv3 non fatal bug. It occurs like between ~50 - 70 times in a total of 100.000 built rendezvous circuits:
```
Apr 03 14:53:04.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:776: client_rendezvous_circ_ha...Client side HSv3 non fatal bug. It occurs like between ~50 - 70 times in a total of 100.000 built rendezvous circuits:
```
Apr 03 14:53:04.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:776: client_rendezvous_circ_has_opened: Non-fatal assertion !(!node_supports_v3_rendezvous_point(rp_node)) failed. (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(!node_supports_v3_rendezvous_point(rp_node)) failed in client_rendezvous_circ_has_opened at ../src/feature/hs/hs_client.c:776. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(circuit_has_opened+0x80) [0x55d874947810] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Apr 03 14:53:04.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
```Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/34085HSv3: Bug Non-fatal assertion in hs_client.c:518: intro_circ_is_ok2021-07-09T17:22:00Zs7rHSv3: Bug Non-fatal assertion in hs_client.c:518: intro_circ_is_okClient side HSv3 non fatal bug. It occurs like between ~80-120 times in a total of 100.000 built rendezvous circuits:
```
Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:518: intro_circ_is_ok: Non-fata...Client side HSv3 non fatal bug. It occurs like between ~80-120 times in a total of 100.000 built rendezvous circuits:
```
Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:518: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at ../src/feature/hs/hs_client.c:518. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(hs_client_send_introduce1+0x271) [0x55d8749ce5e1] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_ap_handshake_attach_circuit+0x3bd) [0x55d874949d5d] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_ap_attach_pending+0x178) [0x55d87494e108] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
```https://gitlab.torproject.org/tpo/core/tor/-/issues/34084HSv3: Bug at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:7392021-06-23T17:22:42Zs7rHSv3: Bug at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:739Client side HSv3 non fatal bug. It occurs like between ~80-120 times in a total of 100.000 built rendezvous circuits.
Seems like Tor is unable to find the right pubkey to assign to the introduction circuit and this causes a wave of asse...Client side HSv3 non fatal bug. It occurs like between ~80-120 times in a total of 100.000 built rendezvous circuits.
Seems like Tor is unable to find the right pubkey to assign to the introduction circuit and this causes a wave of asserts (also see dup legacy/trac#34085).
```
Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:739: setup_intro_circ_auth_key: This line should not have been reached. (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Line unexpectedly reached at setup_intro_circ_auth_key at ../src/feature/hs/hs_client.c:739. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(hs_client_circuit_has_opened+0x342) [0x55d8749ceb22] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
```
This gets shortly followed by:
```
Mar 31 18:44:17.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:518: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: Tor 0.4.4.0-alpha-dev: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at ../src/feature/hs/hs_client.c:518. Stack trace: (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(log_backtrace_impl+0x56) [0x55d874ac7ee6] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_bug_occurred_+0x16c) [0x55d874ac30ec] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(hs_client_send_introduce1+0x271) [0x55d8749ce5e1] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_ap_handshake_attach_circuit+0x3bd) [0x55d874949d5d] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_ap_attach_pending+0x178) [0x55d87494e108] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_send_next_onion_skin+0x2b8) [0x55d874930d38] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbe4ba) [0x55d8749664ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xbf1c5) [0x55d8749671c5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(circuit_receive_relay_cell+0x2b4) [0x55d874968a44] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(command_process_cell+0x2c8) [0x55d87494b788] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(channel_tls_handle_cell+0x4eb) [0x55d87492af0b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0xac5ca) [0x55d8749545ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(connection_handle_read+0xa92) [0x55d8749183a2] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(+0x75609) [0x55d87491d609] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f1984b569ba] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f1984b57537] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(do_main_loop+0xff) [0x55d87491e88f] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_run_main+0x10b5) [0x55d87490bbc5] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(tor_main+0x3a) [0x55d8749092ca] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(main+0x19) [0x55d874908e89] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f198443809b] (on Tor 0.4.4.0-alpha-dev )
Mar 31 18:44:17.000 [warn] Bug: tor(_start+0x2a) [0x55d874908eda] (on Tor 0.4.4.0-alpha-dev )
```Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/34083Client rendezvous circuit is no longer in circuit_wait but in pending_entry_c...2021-10-08T14:44:40Zs7rClient rendezvous circuit is no longer in circuit_wait but in pending_entry_connectionsWhen you are creating many rendezvous client circuits with a reasonable concurrency, you get tons of messages in the log file marked as bug like this:
```
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877d94940 is...When you are creating many rendezvous client circuits with a reasonable concurrency, you get tons of messages in the log file marked as bug like this:
```
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877d94940 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d8789c16c0 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d875eef5a0 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d876063640 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877b92960 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d8764ae550 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d878a83f00 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877854530 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d878cac3a0 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d875b8d290 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d8788a4d70 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d878144a30 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
May 01 08:55:43.000 [warn] connection_ap_attach_pending(): Bug: 0x55d877a2dc30 is no longer in circuit_wait. Its current state is waiting for rendezvous desc. Why is it on pending_entry_connections? (on Tor 0.4.4.0-alpha-dev )
```
No sense to send more lines since they are all the same, but just with different circuit ID. The number of such messages exceeds 1000 in a total say at least 100.000 built rendezvous circuits.Tor: 0.4.7.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34082Master ticket for client side rendezvous circuit related bugs that cause reac...2021-06-23T17:22:42Zs7rMaster ticket for client side rendezvous circuit related bugs that cause reachability problems in HSv3 landThis is the master ticket for some reachability issues I discovered while stress testing my onionbalance v3 setup. They all occurred while handling HSv3 services.
At least two of them always occur together, but handling them as separate...This is the master ticket for some reachability issues I discovered while stress testing my onionbalance v3 setup. They all occurred while handling HSv3 services.
At least two of them always occur together, but handling them as separate tickets for now and keeping this master ticket to glue them together, since they all mention different stack traces.Tor: unspecified