Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-10-15T16:30:29Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32622Fix misleading STATUS_CLIENT warning message2020-10-15T16:30:29ZPhilipp Winterphw@torproject.orgFix misleading STATUS_CLIENT warning messageAfter Tor 0.4.3.0-alpha-dev successfully established a TCP connection with a bridge but failed to finish its handshake, it sends the following `STATUS_CLIENT` message to the controller:
```
650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=10 TA...After Tor 0.4.3.0-alpha-dev successfully established a TCP connection with a bridge but failed to finish its handshake, it sends the following `STATUS_CLIENT` message to the controller:
```
650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=10 TAG=handshake_dir SUMMARY="Finishing handshake with directory server" WARNING="DONE" REASON=DONE COUNT=1 RECOMMENDATION=warn HOSTID="0000000000000000000000000000000000000000" HOSTADDR="[scrubbed]"
```
One can reproduce this by using torproject.org's web server as a bridge: 95.216.163.36:80. The substring `WARNING="DONE"` is misleading and should – if I'm interpreting [control-spec.txt](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2682) correctly – contain a human-readable description of what went wrong. Other `STATUS_CLIENT` messages do a better job; for example:
```
650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=5 TAG=conn_dir SUMMARY="Connecting to directory server" WARNING="Connection refused" REASON=CONNECTREFUSED COUNT=1 RECOMMENDATION=warn HOSTID="0000000000000000000000000000000000000000" HOSTADDR="[scrubbed]"
```
Here, the substring `WARNING="Connection refused"` gives me a good idea of what's going on.
I suggest to fix the warning in this particular error case.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32542hs-v3: Add the 2 missing SOCKS extended errors from prop3042021-06-23T17:23:06ZDavid Gouletdgoulet@torproject.orghs-v3: Add the 2 missing SOCKS extended errors from prop304The two missing codes are the intro failure and RP failure.
```
* X'F2' Onion Service Introduction Failed
Client failed to introduce to the service meaning the descriptor was
found but the service is not anymore at the ...The two missing codes are the intro failure and RP failure.
```
* X'F2' Onion Service Introduction Failed
Client failed to introduce to the service meaning the descriptor was
found but the service is not anymore at the introduction points. The
service has likely changed its descriptor or is not running.
* X'F3' Onion Service Rendezvous Failed
Client failed to rendezvous with the service which means that the client
is unable to finalize the connection.
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32474Remove CodeStructure.md once I'm sure that it is subsumed by intro.html2021-07-22T16:19:07ZNick MathewsonRemove CodeStructure.md once I'm sure that it is subsumed by intro.htmlTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32230configure summary is confusing or incorrect2020-06-27T13:49:02Zteorconfigure summary is confusing or incorrectSome of the options in the new configure summary are confusing or incorrect. The configure summary was introduced in legacy/trac#31373.
Wrong place:
* maybe --enable-systemd should be an optional library?
Inverted, should be --enable-*...Some of the options in the new configure summary are confusing or incorrect. The configure summary was introduced in legacy/trac#31373.
Wrong place:
* maybe --enable-systemd should be an optional library?
Inverted, should be --enable-* :
* --disable-seccomp
* --disable-libscrypt
* --disable-gcc-hardening ?
* --disable-linker-hardening ?
* --disable-module-dirauth
* --disable-unittests
Remove Double-Negative ? :
* assert()s disabled (--disable-asserts-in-tests, dev only): no
* assert()s enabled (--enable-asserts-in-tests, dev only): yes
Broken:
* --enable-gcc-warnings:
* is not Verbose Warnings
* is an alias for --enable-fatal-warnings, which is already listed
* did you mean --disable-gcc-warnings-advisory ?
* --disable-asciidoc
* also disables manpages and HTML, but they are shown as enabled
* --enable-fragile-hardening
* should be true if --enable-expensive-hardening is set, but is shown as false
Missing:
* --disable-module-relay
* please build the module feature summary from the list of modules in configure
* --disable-asciidoc
* --enable-lzma
* --enable-zstd
* --enable-cargo-online-mode
* --with-tor-user=[user]
* --with-tor-group=[group]
* and a few others
* and a whole bunch of env varsTor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32140single onion: Padding negotiated cell from wrong hop2020-06-27T13:49:06Zteorsingle onion: Padding negotiated cell from wrong hopAs of master commit d616214e47, I occasionally see these errors in chutney:
```
PASS: single-onion-v23
Detail: chutney/tools/warnings.sh /home/dev/chutney/net/nodes.1571380287
Warning: Padding negotiated cell from wrong hop on circuit 11...As of master commit d616214e47, I occasionally see these errors in chutney:
```
PASS: single-onion-v23
Detail: chutney/tools/warnings.sh /home/dev/chutney/net/nodes.1571380287
Warning: Padding negotiated cell from wrong hop on circuit 11 Number: 1
Warning: Received circuit padding stop command for unknown machine. Number: 1
```Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/32040HS intro padding machine reactivates after receiving INTRODUCE_ACK2021-07-15T13:41:34ZGeorge KadianakisHS intro padding machine reactivates after receiving INTRODUCE_ACKWhile reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down...While reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down. Then when INTRODUCE_ACK arrives, it reactivates (probably because INTRODUCE_ACK is part of the accepted purposes and the machine is shutdown/freed at that time) and sends again padding, then again shuts down...
This does not work as intended and causes extra cells to fly in with a pattern that probably does not help them blend in.
Here are some Tor logs (with padanalysis incoming/outgoing cells logs):
```
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:57.000 [warn] outgoing-cell: EXTEND 0
Oct 11 13:25:58.000 [warn] incoming-cell: EXTENDED 0 148
Oct 11 13:25:58.000 [warn] outgoing-cell: INTRODUCE1 4
Oct 11 13:25:58.000 [warn] outgoing-cell: PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (7)
Oct 11 13:25:58.000 [warn] incoming-cell: INTRODUCE_ACK 4 0
Oct 11 13:25:58.000 [info] rend_client_introduction_acked(): Received ack. Telling rend circ...
Oct 11 13:25:58.000 [info] circpad_setup_machine_on_circ(): Registering machine client_ip_circ to origin circ 5 (8)
Oct 11 13:25:58.000 [info] circpad_node_supports_padding(): Checking padding: supported
Oct 11 13:25:58.000 [info] circpad_negotiate_padding(): Negotiating padding on circuit 5 (8), command 2
Oct 11 13:25:58.000 [warn] outgoing-cell: 8 PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [info] circpad_machine_spec_transition(): Circuit 5 circpad machine 0 transitioning from 0 to 1
Oct 11 13:25:58.000 [info] circpad_marked_circuit_for_padding(): Circuit 5 is not marked for close because of a pending padding machine in index 0.
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (15)
...
Oct 11 13:36:11.000 [info] circuit_mark_for_close_(): Circuit 4130340667 (id: 5) marked for close at src/core/or/circuituse.c:1509 (orig reason: 9, new reason: 0)
```
I'm not sure what the fix should be here. It might be that we need to remove INTRODUCE_ACK from the list of accepted purposes, but if we do that then if INTRODUCE_ACK arrives earlier we will stop padding after. Hmm.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/31812http URL's in docs/comments should be https2021-07-22T16:19:25ZJeremyRandhttp URL's in docs/comments should be httpsThe documentation and comments in Tor's repo have quite a few http URL's that should be changed to https. Patch incoming shortly for this.The documentation and comments in Tor's repo have quite a few http URL's that should be changed to https. Patch incoming shortly for this.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31576Remove/stop shipping contrib/dist/rc.subr2020-06-27T13:49:31ZteorRemove/stop shipping contrib/dist/rc.subrIt appears FreeBSD no longer needs it.It appears FreeBSD no longer needs it.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31482Avoid possible overflow when converting between coarse stamp to approx ms2021-08-23T15:16:07ZteorAvoid possible overflow when converting between coarse stamp to approx msOur coarse monotonic time conversion code can overflow on some platforms.
In particular, passing a large rate to a token bucket will overflow on iOS, and any other platform where monotime.numerator^2^ / monotime.denominator > 512.
I h...Our coarse monotonic time conversion code can overflow on some platforms.
In particular, passing a large rate to a token bucket will overflow on iOS, and any other platform where monotime.numerator^2^ / monotime.denominator > 512.
I have a fix that makes sure that token bucket's rate_per_sec_to_rate_per_sec() can't cause an overflow. I can do tests and a changes file after nickm answers some of my remaining questions.
Gaba, this is a fix on a refactor for legacy/trac#25766, which was originally for sponsor 8. Are refactor bug fixes covered by sponsor 31 now?Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31036Logfile grow upto 2GB tor fails and refuse to start2020-07-30T13:42:33ZcypherpunksLogfile grow upto 2GB tor fails and refuse to starti have enabled logging to file by log-level warning. there showed up repeatedly messages. once logfilesize >2GByte tor crash and cannot start again with logging enabled to this file.i have enabled logging to file by log-level warning. there showed up repeatedly messages. once logfilesize >2GByte tor crash and cannot start again with logging enabled to this file.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30992circpadding machines have shutdown sync issues (with intro circ NACKs and oth...2021-07-15T13:41:34ZGeorge Kadianakiscircpadding machines have shutdown sync issues (with intro circ NACKs and other cases)When client-side intro circuits get NACKed they re-extend to a different intro point using the same circuit.
This seems to mess up the circsetup machines and we get "padding came from wrong hop" log warns.When client-side intro circuits get NACKed they re-extend to a different intro point using the same circuit.
This seems to mess up the circsetup machines and we get "padding came from wrong hop" log warns.Tor: 0.4.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30726Missing relay keys in bandwidth file spec2020-06-27T13:50:06ZteorMissing relay keys in bandwidth file specNot in spec or examples:
* relay_in_recent_consensus_count
* consensus_bandwidth
* consensus_bandwidth_is_unmeasured
* desc_bw_avg
* desc_bw_bur
* desc_bw_obs_last
* desc_bw_obs_mean
Not in spec:
* relay_recent_measurement_attempt_count...Not in spec or examples:
* relay_in_recent_consensus_count
* consensus_bandwidth
* consensus_bandwidth_is_unmeasured
* desc_bw_avg
* desc_bw_bur
* desc_bw_obs_last
* desc_bw_obs_mean
Not in spec:
* relay_recent_measurement_attempt_count
* relay_recent_priority_list_count
We need a specification for these keys so we know what they mean.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30187100% cpu usage in winthreads tor_cond_wait2021-01-19T21:23:07ZTrac100% cpu usage in winthreads tor_cond_waitFor years I run relay using self-compiled win64 version of tor.
Compiler mingw64.
Relay runs well for some time but suddenly starts using 100% cpu all cores.
I traced where it happens. The following loop never ends :
```
do {
DWO...For years I run relay using self-compiled win64 version of tor.
Compiler mingw64.
Relay runs well for some time but suddenly starts using 100% cpu all cores.
I traced where it happens. The following loop never ends :
```
do {
DWORD res;
res = WaitForSingleObject(cond->event, ms);
EnterCriticalSection(&cond->lock);
if (cond->n_to_wake &&
cond->generation != generation_at_start) {
--cond->n_to_wake;
--cond->n_waiting;
result = 0;
waiting = 0;
goto out;
} else if (res != WAIT_OBJECT_0) {
result = (res==WAIT_TIMEOUT) ? 1 : -1;
--cond->n_waiting;
waiting = 0;
goto out;
} else if (ms != INFINITE) {
endTime = GetTickCount();
if (startTime + ms_orig <= endTime) {
result = 1; /* Timeout */
--cond->n_waiting;
waiting = 0;
goto out;
} else {
ms = startTime + ms_orig - endTime;
}
}
/* If we make it here, we are still waiting. */
if (cond->n_to_wake == 0) {
/* There is nobody else who should wake up; reset
* the event. */
ResetEvent(cond->event);
}
out:
LeaveCriticalSection(&cond->lock);
} while (waiting);
```
res = WAIT_OBJECT_0;
ms = INFINITE;
cond->n_to_wake=0x11
cond->generation=0x28
generation_at_start=0x28
it means no path with "goto out" ever execute
more than one thread run this loop and each one eat separate core
Some people I shared binaries with report same problem.
Pls check
**Trac**:
**Username**: bolvanTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29645test.exe hangs on Appveyor CI2020-06-27T13:50:45Zteortest.exe hangs on Appveyor CITor's test.exe sometimes hangs on our Appveyor Windows CI.
I've seen this happen twice over the past few weeks.
Here is one example:
https://ci.appveyor.com/project/torproject/tor/builds/22791909/job/u0jd5tpr07mt2nv3
We've reduced the ...Tor's test.exe sometimes hangs on our Appveyor Windows CI.
I've seen this happen twice over the past few weeks.
Here is one example:
https://ci.appveyor.com/project/torproject/tor/builds/22791909/job/u0jd5tpr07mt2nv3
We've reduced the job time limit to 30 minutes to mitigate this issue.
But I am not sure how to debug it further.Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/29136PT_LOG and PT_STATUS event fields unspecifed2021-09-16T14:24:09ZDamian JohnsonPT_LOG and PT_STATUS event fields unspecifedRecently Tor added PT_LOG and PT_STATUS events to the spec...
https://gitweb.torproject.org/torspec.git/commit/?id=3028cf1
https://gitweb.torproject.org/torspec.git/commit/?id=b38257e
Unfortunately the 'pt-spec.txt section 3.3.5' secti...Recently Tor added PT_LOG and PT_STATUS events to the spec...
https://gitweb.torproject.org/torspec.git/commit/?id=3028cf1
https://gitweb.torproject.org/torspec.git/commit/?id=b38257e
Unfortunately the 'pt-spec.txt section 3.3.5' section they mention does not exist, and in looking around I can't find anything that describes what these event fields are defined as ('PT=' 'TYPE=', 'CONNECT=', etc).
I started to write a stem parser for these but can't continue until this is done (I can't parse events without knowing what fields they include).
David is aware of this and plans to has kindly offered to add the missing info...
```
22:24 <+atagar> dgoulet: Your control-spec addition to descript PT_LOG and PT_STATUS
cite a pt-spec section 3.3.4 which does not exist.
22:24 <+atagar> s/descript/describe
22:29 <+atagar> dgoulet: Huh. I'm not spotting anything that lists the keyword
arguments ('PT=' and 'SEVERITY=') so guess the sections simply
missing from the spec. I need that for stem support so please
give me a nudge when the event spec's done. :)
22:59 <+dgoulet> atagar: oh hmmm I'll fix that sorry
23:17 <+atagar> Thanks! Much appreciated. :)
```Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28081rust protover discards all votes if one is not UTF-82020-07-31T12:22:39ZTracrust protover discards all votes if one is not UTF-8
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27194Reject protover extra commas in protover2021-09-16T14:29:03ZTracReject protover extra commas in protoverLike how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra com...Like how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra commas, including leading commas.
**Trac**:
**Username**: cyberpunksTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24841Your relay has a very large number of connections to other relays. Is your ou...2020-06-27T13:54:29ZTracYour relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?debian-tor-0.3.2.8-rc-1
SOCKSPort 9050
ORPort 80.67.176.53:9001
ORPort [2001:910:1035::1]:9001
ExitRelay 0
https://atlas.torproject.org/#details/A2547D13A3659ECF23AF8B9456B2E277110BF136
```
janv. 08 20:41:35 alex Tor[21674]: Tor 0.3.2...debian-tor-0.3.2.8-rc-1
SOCKSPort 9050
ORPort 80.67.176.53:9001
ORPort [2001:910:1035::1]:9001
ExitRelay 0
https://atlas.torproject.org/#details/A2547D13A3659ECF23AF8B9456B2E277110BF136
```
janv. 08 20:41:35 alex Tor[21674]: Tor 0.3.2.8-rc (git-3696eb720795a666) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.0g, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.3.3.
janv. 08 20:41:35 alex Tor[21674]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
janv. 08 20:41:35 alex Tor[21674]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
janv. 08 20:41:35 alex Tor[21674]: Read configuration file "/etc/tor/torrc".
janv. 08 20:41:35 alex Tor[21674]: Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
janv. 08 20:41:35 alex Tor[21674]: Scheduler type KIST has been enabled.
janv. 08 20:41:35 alex Tor[21674]: Opening Socks listener on 127.0.0.1:9050
janv. 08 20:41:35 alex Tor[21674]: Opening OR listener on 80.67.176.53:9001
janv. 08 20:41:35 alex Tor[21674]: Opening OR listener on [2001:910:1035::1]:9001
janv. 08 20:41:35 alex Tor[21674]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
janv. 08 20:41:35 alex Tor[21674]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
janv. 08 20:41:35 alex Tor[21674]: Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
janv. 08 20:41:35 alex Tor[21674]: Your Tor server's identity key fingerprint is 'tyng A2547D13A3659ECF23AF8B9456B2E277110BF136'
janv. 08 20:41:35 alex Tor[21674]: Bootstrapped 0%: Starting
janv. 08 20:41:38 alex Tor[21674]: Starting with guard context "default"
janv. 08 20:41:38 alex Tor[21674]: Bootstrapped 80%: Connecting to the Tor network
janv. 08 20:41:38 alex Tor[21674]: Signaled readiness to systemd
janv. 08 20:41:38 alex Tor[21674]: Opening Control listener on /var/run/tor/control
janv. 08 20:41:39 alex Tor[21674]: Bootstrapped 85%: Finishing handshake with first hop
janv. 08 20:41:39 alex Tor[21674]: Bootstrapped 90%: Establishing a Tor circuit
janv. 08 20:41:42 alex Tor[21674]: Tor has successfully opened a circuit. Looks like client functionality is working.
janv. 08 20:41:42 alex Tor[21674]: Bootstrapped 100%: Done
janv. 08 20:41:42 alex Tor[21674]: Now checking whether ORPort 80.67.176.53:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
janv. 08 20:41:43 alex Tor[21674]: Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
janv. 08 20:42:41 alex Tor[21674]: Performing bandwidth self-test...done.
janv. 08 23:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 11 connections to 7 relays. Found 11 current canonical connections, in 0 of which we were a non-canonical peer. 4 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 02:41:38 alex Tor[21674]: Heartbeat: Tor's uptime is 5:59 hours, with 2 circuits open. I've sent 4.61 MB and received 16.47 MB.
janv. 09 02:41:38 alex Tor[21674]: Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor.
janv. 09 02:41:38 alex Tor[21674]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 2 v4 connections; and received 0 v1 connections, 0 v2 connections, 1 v3 connections, and 37 v4 connections.
janv. 09 02:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 14 connections to 9 relays. Found 14 current canonical connections, in 0 of which we were a non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 04:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 15 connections to 10 relays. Found 15 current canonical connections, in 0 of which we were a non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 05:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 11 connections to 7 relays. Found 11 current canonical connections, in 0 of which we were a non-canonical peer. 4 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 06:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 9 connections to 6 relays. Found 9 current canonical connections, in 0 of which we were a non-canonical peer. 3 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 08:41:38 alex Tor[21674]: Heartbeat: Tor's uptime is 11:59 hours, with 0 circuits open. I've sent 8.13 MB and received 24.95 MB.
janv. 09 08:41:38 alex Tor[21674]: Average packaged cell fullness: 93.781%. TLS write overhead: 16%
janv. 09 08:41:38 alex Tor[21674]: Circuit handshake stats since last time: 0/0 TAP, 1/1 NTor.
janv. 09 08:41:38 alex Tor[21674]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 4 v4 connections; and received 0 v1 connections, 0 v2 connections, 4 v3 connections, and 74 v4 connections.
```
**Trac**:
**Username**: tyngTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16016extrainfo_insert(): Bug: No entry found in extrainfo map.2020-07-02T11:22:42ZRoger Dingledineextrainfo_insert(): Bug: No entry found in extrainfo map.I get these on moria1 pretty often. It's been ongoing for a long time I think -- since whenever we attempted to fix that last bug with ri / ei synchronization.
Here's a potentially useful info-level log:
```
May 13 18:50:37.600 [info] c...I get these on moria1 pretty often. It's been ongoing for a long time I think -- since whenever we attempted to fix that last bug with ri / ei synchronization.
Here's a potentially useful info-level log:
```
May 13 18:50:37.600 [info] connection_dir_client_reached_eof(): Received extra server info (size 5307) from server '131.188.40.189:80'
May 13 18:50:37.600 [info] router_load_extrainfo_from_string(): 3 elements to add
May 13 18:50:37.600 [warn] extrainfo_insert(): Bug: No entry found in extrainfo map. [1 similar message(s) suppressed in last 1800 seconds] (on Tor 0.2.7.1-alpha-dev 95a9920461dd3322)
May 13 18:50:37.623 [info] connection_dir_client_reached_eof(): Received 0/9 extra-info documents requested from 131.188.40.189:80
```
I don't know if this last line is related or not.
Actually, I get one of the Bug: messages every hour on moria1, a little bit after the 50 minute mark. Sounds like I'm hearing votes from other authorities, and they make me think of an extrainfo I don't have, so I try to get it, and then bug.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14389little-t-tor: Provide support for better TBB UI of hidden service client auth...2020-06-27T14:01:53ZGeorge Kadianakislittle-t-tor: Provide support for better TBB UI of hidden service client authorization**This is the network-team-side of ticket legacy/trac#30237.
**
The current hidden service spec allows clients to authenticate themselves using auth-cookies. The future proposal 224 will allow clients to authenticate using username/passw...**This is the network-team-side of ticket legacy/trac#30237.
**
The current hidden service spec allows clients to authenticate themselves using auth-cookies. The future proposal 224 will allow clients to authenticate using username/password or pubkey.
Currently users have to edit their torrc and add HidServAuth lines for the hidden services that require authorization. In the future, it would be nicer if TBB had an interface for users to type in their authorization credentials.
Tor knows whether an HS needs authorization, because the intro list is encrypted. Tor would have to somehow transfer this knowledge to TBB, so that the browser can present a nice UI that the user can fill on the go.
Furthermore, with the future username/password authorization and this UI improvement, it won't be necessary for people to write on their torrc which hidden services they visit and what's their auth-cookie.
This is a ticket about finding out what mods need to happen in little-t-tor, and coordinating the development of this feature.Tor: 0.4.4.x-final