Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:39:22Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29777Rate-limit "Problem bootstrapping" warnings to one every 5 seconds2020-06-13T15:39:22ZteorRate-limit "Problem bootstrapping" warnings to one every 5 secondsLet's put a rate-limit on warnings like this:
```
Jan 29 11:36:27.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 11; recommendation warn; host 322C6E3A973BC10FC36DE3037AD27BC89...Let's put a rate-limit on warnings like this:
```
Jan 29 11:36:27.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 11; recommendation warn; host 322C6E3A973BC10FC36DE3037AD27BC89F14723B at 212.83.154.33:8443)
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29245Tor 0.4 eventually hits "Delaying directory fetches: No running bridges" afte...2020-06-13T15:37:40ZTracTor 0.4 eventually hits "Delaying directory fetches: No running bridges" after some period of inactivity with bridges```
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Tor NOTICE: Delaying directory fetches: No runni...```
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
Tor NOTICE: Delaying directory fetches: No running bridges
Tor NOTICE: Application request when we haven't received a consensus with exits. Optimistically trying known bridges again.
```
Tested on latest Tor Browser alpha with snowflake bridge.
**Trac**:
**Username**: ArmalsLoveArmalsLifeTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29201Tor bootstrap hangs when offline2020-06-13T15:37:16ZDamian JohnsonTor bootstrap hangs when offlineHi Nick. When launching a tor process stem uses bootstrap messages to determine when the instance we launch is available. Recently-ish tor changed such that when offline tor bootstrapping does not progress past 0%, printing hundreds of.....Hi Nick. When launching a tor process stem uses bootstrap messages to determine when the instance we launch is available. Recently-ish tor changed such that when offline tor bootstrapping does not progress past 0%, printing hundreds of...
```
Jan 29 11:36:27.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 11; recommendation warn; host 322C6E3A973BC10FC36DE3037AD27BC89F14723B at 212.83.154.33:8443)
Jan 29 11:36:28.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 12; recommendation warn; host F741E5124CB12700DA946B78C9B2DD175D6CD2A1 at 163.172.154.162:9001)
Jan 29 11:36:28.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 14; recommendation warn; host D71B1CA1C9DC7E8CA64158E106AD770A21160FEE at 185.34.33.2:31415)
Jan 29 11:36:29.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 13; recommendation warn; host F2DFE5FA1E4CF54F8E761A6D304B9B4EC69BDAE8 at 129.13.131.140:443)
Jan 29 11:36:30.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 14; recommendation warn; host 47C42E2094EE482E7C9B586B10BABFB67557030B at 185.220.101.34:20034)
Jan 29 11:36:30.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 14; recommendation warn; host B06F093A3D4DFAD3E923F4F28A74901BD4F74EB1 at 178.17.174.14:9001)
Jan 29 11:36:31.000 [warn] Problem bootstrapping. Stuck at 0% (starting): Starting. (Network is unreachable; NOROUTE; count 15; recommendation warn; host CF6D0AAFB385BE71B8E111FC5CFF4B47923733BC at 154.35.175.225:443)
```
There's a few issues with this...
1. Poor experience from a user perspective. Deluging the user with hundreds of warnings is pretty unhelpful.
2. Stem's ability to launch tor processes no longer works when offline.
3. Stem's integ tests no longer pass when offline. I can sidestep this but first I'd like to confirm if this is the desired behavior from tor or not.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29128Place complete obfs4 bridge line in accessible location2020-06-13T15:36:59ZColin ChildsPlace complete obfs4 bridge line in accessible locationCurrently operators wanting to distribute or use personal obfs4 bridges must follow 5 steps:
1. Determine their bridge's IP address
2. Check logs for their bridge's fingerprint
3. Check logs for which port obfs4 is running on
4. Retrie...Currently operators wanting to distribute or use personal obfs4 bridges must follow 5 steps:
1. Determine their bridge's IP address
2. Check logs for their bridge's fingerprint
3. Check logs for which port obfs4 is running on
4. Retrieve their obfs4 cert from /var/lib/tor/pt_state/obfs4_bridgeline.txt
5. String the above together in the following format:
```
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=$FROMSTEP4 iat-mode=0
```
This can be a confusing process, and is only fully explained upon opening `/var/lib/tor/pt_state/obfs4_bridgeline.txt`; however it leaves filling in the fields (with the exception of the cert) to the user.
Having the complete bridge line placed somewhere accessible would make this process much less painful for operators.Tor: 0.4.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29110Allow passing seed value to slow/prop_distr/* tests2020-06-13T15:36:53ZAlexander Færøyahf@torproject.orgAllow passing seed value to slow/prop_distr/* testsIt would be useful to be able to pass the seed as an environment variables or argument to the `slow/prop_distr/...` tests to quickly check if one can reproduce a known test error with a given seed.
This is related to #29109.It would be useful to be able to pass the seed as an environment variables or argument to the `slow/prop_distr/...` tests to quickly check if one can reproduce a known test error with a given seed.
This is related to #29109.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29018Make all statistics depend on ExtraInfoStatistics2020-06-13T15:42:53ZteorMake all statistics depend on ExtraInfoStatisticsLike #29017, when a user sets ExtraInfoStatistics 0, they probably don't want any statistics in their extra-info document.Like #29017, when a user sets ExtraInfoStatistics 0, they probably don't want any statistics in their extra-info document.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28962circuits are not both ready. Stalling conn.2020-06-13T15:36:04Ztraumschulecircuits are not both ready. Stalling conn.Using an unstable (wifi) connection my Tor 0.4.0.0-alpha-dev client shows `circuits are not both ready. Stalling conn.` and most connections hang for some minutes until it let‘s through a bunch and hangs again.
It‘s confusing to see net...Using an unstable (wifi) connection my Tor 0.4.0.0-alpha-dev client shows `circuits are not both ready. Stalling conn.` and most connections hang for some minutes until it let‘s through a bunch and hangs again.
It‘s confusing to see netflow padding while waiting for connections, looks like an instance of #23681.
Relevant code is around src/core/or/circuituse.c:3025.
Log shows a lot of timeouts like:
```
Dec 30 10:48:14.000 [info] circuit_build_times_get_xm(): Xm mode #0: 325 75
Dec 30 10:48:14.000 [info] circuit_build_times_get_xm(): Xm mode #1: 375 47
Dec 30 10:48:14.000 [info] circuit_build_times_get_xm(): Xm mode #2: 325 75
Dec 30 10:48:14.000 [info] circuit_build_times_set_timeout_worker(): Circuit build measurement period of 1337373ms is more than twice the maximum build time we have ever observed. Capping it to 1143450ms.
Dec 30 10:48:14.000 [info] circuit_build_times_set_timeout(): Set circuit build timeout to 29s (28864.874645ms, 1143450.000000ms, Xm: 336, a: 0.361406, r: 0.282000) based on 1000 circuit times
Dec 30 10:48:14.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard <scrubbed>
Dec 30 10:48:14.000 [info] circuit_build_no_more_hops(): circuit built!
Dec 30 10:48:14.000 [info] pathbias_count_build_success(): Got success count 209.532891/219.352138 for guard <scrubbed>
Dec 30 10:48:14.000 [info] connection_ap_handshake_attach_circuit(): Intro circ 4177057486 (id: 2028) present and awaiting ACK. Rend circuit 3511196698 (id: 2011). Stalling. (stream 41 sec old)
Dec 30 10:48:14.000 [info] or_state_save(): Saved state to "/var/lib/tor/state"
Dec 30 10:48:14.000 [info] rend_client_introduction_acked(): Got nack for [scrubbed] from [scrubbed]...
Dec 30 10:48:14.000 [info] rend_client_report_intro_point_failure(): 5 options left for [scrubbed].
Dec 30 10:48:14.000 [info] hs_client_reextend_intro_circuit(): Re-extending circ 4177057486, this time to [scrubbed].
Dec 30 10:48:14.000 [info] circuit_send_intermediate_onion_skin(): Sending extend relay cell.
Dec 30 10:48:14.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 3511196698 (id: 2011) already here. Nointro-ack yet on intro 4177057486 (id: 2028). (stream 41 sec old)
Dec 30 10:48:14.000 [info] connection_ap_handshake_attach_circuit(): Intro 4177057486 (id: 2028) and rend circuit 3511196698 (id: 2011) circuits are not both ready. Stalling conn. (41 sec old)
...
Dec 30 10:49:01.000 [info] connection_ap_handshake_attach_circuit(): Intro 4177057486 (id: 2028) and rend circuit 3511196698 (id: 2011) circuits are not both ready. Stalling conn. (88 sec old)
Dec 30 10:49:02.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 3511196698 (id: 2011) already here. Nointro-ack yet on intro 4177057486 (id: 2028). (stream 89 sec old)
Dec 30 10:49:02.000 [info] connection_ap_handshake_attach_circuit(): Intro 4177057486 (id: 2028) and rend circuit 3511196698 (id: 2011) circuits are not both ready. Stalling conn. (89 sec old)
Dec 30 10:49:03.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 3511196698 (id: 2011) already here. Nointro-ack yet on intro 4177057486 (id: 2028). (stream 90 sec old)
Dec 30 10:49:03.000 [info] connection_ap_handshake_attach_circuit(): Intro 4177057486 (id: 2028) and rend circuit 3511196698 (id: 2011) circuits are not both ready. Stalling conn. (90 sec old)
Dec 30 10:49:04.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 608 to [scrubbed] ([scrubbed]) after 8689 ms. Delta 1ms
Dec 30 10:49:04.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 3511196698 (id: 2011) already here. Nointro-ack yet on intro 4177057486 (id: 2028). (stream 91 sec old)
Dec 30 10:49:04.000 [info] connection_ap_handshake_attach_circuit(): Intro 4177057486 (id: 2028) and rend circuit 3511196698 (id: 2011) circuits are not both ready. Stalling conn. (91 sec old)
Dec 30 10:49:05.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 3511196698 (id: 2011) already here. Nointro-ack yet on intro 4177057486 (id: 2028). (stream 92 sec old)
Dec 30 10:49:05.000 [info] connection_ap_handshake_attach_circuit(): Intro 4177057486 (id: 2028) and rend circuit 3511196698 (id: 2011) circuits are not both ready. Stalling conn. (92 sec old)
Dec 30 10:49:07.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 3511196698 (id: 2011) already here. Nointro-ack yet on intro 4177057486 (id: 2028). (stream 93 sec old)
Dec 30 10:49:07.000 [info] connection_ap_handshake_attach_circuit(): Intro 4177057486 (id: 2028) and rend circuit 3511196698 (id: 2011) circuits are not both ready. Stalling conn. (93 sec old)
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28930consider reordering PT/proxy phases2020-06-13T15:35:59ZTaylor Yuconsider reordering PT/proxy phasesA pluggable transport can itself use a firewall-bypass proxy, so maybe the progression should go more like
1. `conn_pt`
2. `conn_proxy`
3. `conn_proxy_done`
4. `conn_pt_done`A pluggable transport can itself use a firewall-bypass proxy, so maybe the progression should go more like
1. `conn_pt`
2. `conn_proxy`
3. `conn_proxy_done`
4. `conn_pt_done`Tor: unspecifiedAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28860Increased DNS failure rate when using ServerDNSResolvConfFile with tor 0.3.4....2020-06-13T15:35:44ZnusenuIncreased DNS failure rate when using ServerDNSResolvConfFile with tor 0.3.4.9 (as opposed to 0.3.3.x)A major tor exit relay operator reports that
after upgrading from 0.3.3.x to 0.3.4.9 his DNS failure rate significantly increased.
He also reported that he is observing DNS issues only when using ServerDNSResolvConfFile and no problems...A major tor exit relay operator reports that
after upgrading from 0.3.3.x to 0.3.4.9 his DNS failure rate significantly increased.
He also reported that he is observing DNS issues only when using ServerDNSResolvConfFile and no problems when not using that config option.
Using that option worked fine on tor 0.3.3.x
With ServerDNSResolvConfFile option on 0.3.4.9:
```
Dec 13 02:39:52.000 [notice] eventdns: Nameserver 8.8.8.8:53 is back up
Dec 13 02:39:53.000 [warn] eventdns: All nameservers have failed
```Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28714"No circuits are opened" on controllers that DisablePredictedCircuits and bui...2020-06-13T15:35:06Zteor"No circuits are opened" on controllers that DisablePredictedCircuits and build 2-hop circuitssbws sets `DisablePredictedCircuits 0` after bootstrap, then builds 2-hop circuits using a controller. After a few days, once all the 3-hop circuits time out, sbws stalls (#28639).
We can fix this issue by considering all controller cir...sbws sets `DisablePredictedCircuits 0` after bootstrap, then builds 2-hop circuits using a controller. After a few days, once all the 3-hop circuits time out, sbws stalls (#28639).
We can fix this issue by considering all controller circuits to be opened circuits, regardless of length. The relevant code is in circuit_any_opened_circuits().
On most clients, Tor's predicted circuits code keeps opening enough circuits to avoid a stall.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28664Describe consensus digest calculation2020-06-13T15:34:55ZDamian JohnsonDescribe consensus digest calculationHi lovely network team folks. No doubt I'm being blind but I'm having difficulty figuring out how to calculate network status document digests.
During the voting period (minutes 55-60 of the hour) I fetched the detached signatures and u...Hi lovely network team folks. No doubt I'm being blind but I'm having difficulty figuring out how to calculate network status document digests.
During the voting period (minutes 55-60 of the hour) I fetched the detached signatures and upcoming consensus. The detached signatures cite the digest...
```
% curl http://128.31.0.39:9131/tor/status-vote/next/consensus-signatures > sigs
% curl http://128.31.0.39:9131/tor/status-vote/next/consensus > next_consensus
% grep consensus-digest sigs
consensus-digest 296BA01987256A1C8EFB20E17667152DCFA50755
```
But in trying hex encoded sha1s of various ranges of the consensus I'm having difficulty getting a value that matches that. No doubt I'm missing something but the spec is unhelpfully vague saying simply 'this is the digest' without citing a section describing how it's calculated...
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3309
It's probably buried in there somewhere but I've skimmed through the spec a few times and it's not jumping out at me. Mind clarifying in the spec how to calculate this?
Thanks!Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28611Add `-mstack-protector-guard=global` to CFLAGS instead of `--disable-gcc-hard...2020-06-13T15:34:34ZTracAdd `-mstack-protector-guard=global` to CFLAGS instead of `--disable-gcc-hardening` configure option on Windows?workaround https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832#c8
Tor compiles fine on Windows mingw gcc 8.2 without `--disable-gcc-hardening` if add `-mstack-protector-guard=global` to CFLAGS
**Trac**:
**Username**: grjworkaround https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832#c8
Tor compiles fine on Windows mingw gcc 8.2 without `--disable-gcc-hardening` if add `-mstack-protector-guard=global` to CFLAGS
**Trac**:
**Username**: grjTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28597Document SOCKSPolicy better2020-06-13T15:34:33ZteorDocument SOCKSPolicy betterWe can improve the documentation for SOCKSPolicy:
* the default policy is accept all
* mention SOCKSPolicy in SOCKSPort and DNSPortWe can improve the documentation for SOCKSPolicy:
* the default policy is accept all
* mention SOCKSPolicy in SOCKSPort and DNSPortTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28525Make tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale...2020-06-13T15:34:24ZNeel Chauhanneel@neelc.orgMake tor_addr_is_internal_() aware of RFC 6598 (Carrier Grade NAT/Large Scale NAT) IPv4 RangesWith the IPv4 depletion, many ISPs, cell carriers and cloud providers are deploying Carrier Grade NAT with the subnet defined in RFC 6598 (100.64.0.0/10). We should make Tor aware of this range as it is internal as well.
I will write a ...With the IPv4 depletion, many ISPs, cell carriers and cloud providers are deploying Carrier Grade NAT with the subnet defined in RFC 6598 (100.64.0.0/10). We should make Tor aware of this range as it is internal as well.
I will write a patch and give a link to a GitHub PR.Tor: 0.2.9.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28356DataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts forcing ...2020-06-13T15:33:52ZTracDataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts forcing sandboxed Tor to crash== Problem 1
By default `DataDirectory` and `CacheDirectory` is the same. On Debian it is `/var/lib/tor`. If you set `DataDirectoryGroupReadable 1` in `torrc` (and forget about `CacheDirectoryGroupReadable`) and then restart Tor, you ex...== Problem 1
By default `DataDirectory` and `CacheDirectory` is the same. On Debian it is `/var/lib/tor`. If you set `DataDirectoryGroupReadable 1` in `torrc` (and forget about `CacheDirectoryGroupReadable`) and then restart Tor, you expect granting permissions to this directory. However, Tor will not do that, but change `drwx--S---` permission to `drwx------` for this directory (which is itself not logical---removing permissions instead of granting them). Tor will also issue a warning:
```
[warn] Fixing permissions on directory /var/lib/tor
```
Later this warning will be repeated at each startup of Tor. I think that this warning should be improved, e.g.:
```
[warn or err] DataDirectoryGroupReadable and CacheDirectoryGroupReadable links to the same directory. You have to set both of them to 1 of both of them to 0.
```
Maybe you have another suggestion (e.g., if any of these options is 1, another is 1 too). `man torrc` doesn't tell anything about this conflict. It should be addressed in man page too.
== Problem 2
The situation is worse when your `torrc` has `Sandbox` enabled:
```
DataDirectoryGroupReadable 1
CacheDirectoryGroupReadable 1
Sandbox 1
```
In this case Tor successfully starts, but if you issue `SIGNAL RELOAD` command (e.g., using `tor-prompt`), Tor immediately crashes with the log:
```
============================================================ T= XXXXXXXXXX
(Sandbox) Caught a bad syscall attempt (syscall chmod)
/usr/bin/tor(+0x1a4d66)[0x556326474d66]
/lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807]
/lib/x86_64-linux-gnu/libc.so.6(chmod+0x7)[0x7f63c91b4807]
/usr/bin/tor(+0xfafed)[0x5563263cafed]
/usr/bin/tor(set_options+0x2ed)[0x5563263d42dd]
/usr/bin/tor(options_init_from_string+0x4c7)[0x5563263d6d97]
/usr/bin/tor(options_init_from_torrc+0x471)[0x5563263d72f1]
/usr/bin/tor(+0x55531)[0x556326325531]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0xe35)[0x7f63ca776a15]
/usr/bin/tor(do_main_loop+0x25f)[0x556326325e3f]
/usr/bin/tor(tor_run_main+0x1165)[0x556326328315]
/usr/bin/tor(tor_main+0x3a)[0x55632632032a]
/usr/bin/tor(main+0x19)[0x556326320099]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f63c90fab45]
/usr/bin/tor(+0x500e9)[0x5563263200e9]
```
Should `Sandbox` be in conflict with these option? If yes, this should be documented in man page, and Tor has to complain an error during startup.
== Problem 3
Suppose, you disable `Sandbox`, but keep the options `DataDirectoryGroupReadable` and `CacheDirectoryGroupReadable` in place. During start Tor sets directory permissions to `drwxr-x---` allowing `debian-tor` group to list files.
If you later grant read access to any file in this directory, Tor will remove this access soon. E.g., `state` file loses its group read permission at each Tor's startup. Other files may lose it less frequently. We are trapped in the situation where `DataDirectoryGroupReadable` and `CacheDirectoryGroupReadable` are useless: what's the goal to be able to read directory's content, bit be unable to read any file inside it?
Earlier it was in less conflict with different tools which control Tor, because it was recommended to run each tool on behalf of `debian-tor` user. Now it is recommended to run it from another user who is a member of `debian-tor` group (see discussion in [[https://trac.torproject.org/projects/tor/ticket/25890|#25890]]), but "group approach" also fails...
**Trac**:
**Username**: wagonTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28344Should we log \r\n on Windows?2020-06-13T15:33:50ZteorShould we log \r\n on Windows?Tor's logging code terminates strings with \n.
When I run tor.exe via the command prompt on Windows, I don't see any of the log output, because there's no \r at the end of the line.
Should we make tor log \r\n on Windows?Tor's logging code terminates strings with \n.
When I run tor.exe via the command prompt on Windows, I don't see any of the log output, because there's no \r at the end of the line.
Should we make tor log \r\n on Windows?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28281outline of high-level bootstrap tracker abstractions2020-06-13T15:33:39ZTaylor Yuoutline of high-level bootstrap tracker abstractionsThis is a placeholder to summarize the high-level bootstrap tracking abstractions I talked about with Nick.This is a placeholder to summarize the high-level bootstrap tracking abstractions I talked about with Nick.Tor: unspecifiedTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/28223Unparseable microdescriptor on public relay2020-06-13T15:33:25ZteorUnparseable microdescriptor on public relayA relay operator reported this error:
```
Get this at my exit relay since yesterday:
# head /tmp/warn.log
Oct 23 23:30:17.000 [notice] Tor 0.3.5.3-alpha opening new log file.
Oct 23 23:30:33.000 [warn] parse error: internal NUL characte...A relay operator reported this error:
```
Get this at my exit relay since yesterday:
# head /tmp/warn.log
Oct 23 23:30:17.000 [notice] Tor 0.3.5.3-alpha opening new log file.
Oct 23 23:30:33.000 [warn] parse error: internal NUL character.
Oct 23 23:30:33.000 [warn] Unparseable microdescriptor
Oct 23 23:30:33.000 [warn] parse error: internal NUL character.
Oct 23 23:30:33.000 [warn] Unparseable microdescriptor
even with log level "debug" there seems to be no more information.
Anything I should worry about?
```
https://lists.torproject.org/pipermail/tor-relays/2018-October/date.htmlTor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28220Create a chutney network with a single authority, and make sure it bootstraps2020-06-13T15:33:24ZteorCreate a chutney network with a single authority, and make sure it bootstrapsDepends on #28203, which logs bootstrap progress.
It looks like there are a lot of race conditions in chutney and tor. We can eliminate most of these race conditions by launching a single authority, and seeing if it bootstraps reliably....Depends on #28203, which logs bootstrap progress.
It looks like there are a lot of race conditions in chutney and tor. We can eliminate most of these race conditions by launching a single authority, and seeing if it bootstraps reliably. Then we can narrow down the source of chutney's instability.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28190Hidden service v2 exceeded launch limit with 11 intro points in the last 37 s...2020-06-13T15:33:20ZteorHidden service v2 exceeded launch limit with 11 intro points in the last 37 secondsThis looks like a new bug in 0.3.6.0-alpha-dev:
```
Warning: Hidden service pc66kjzgfsqdlyj5 exceeded launch limit with 11 intro points in the last 37 seconds. Intro circuit launches are limited to 10 per 300 seconds. Number: 1
Warning: ...This looks like a new bug in 0.3.6.0-alpha-dev:
```
Warning: Hidden service pc66kjzgfsqdlyj5 exceeded launch limit with 11 intro points in the last 37 seconds. Intro circuit launches are limited to 10 per 300 seconds. Number: 1
Warning: Intro point 0 at test006r: circuit is open Number: 1
Warning: Intro point 1 at test005r: no circuit Number: 1
Warning: Intro point 2 at test001a: circuit is open Number: 1
Warning: Intro point 3 at test004r: circuit is open Number: 1
```
I haven't seen this warning in chutney before.
For details, see:
https://travis-ci.org/teor2345/chutney/jobs/445959016Tor: unspecified