Tor merge requestshttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests2022-10-27T15:46:23Zhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/643Add several new metrics to MetricsPort2022-10-27T15:46:23ZDavid Gouletdgoulet@torproject.orgAdd several new metrics to MetricsPortRelated to #40194
Signed-off-by: David Goulet <dgoulet@torproject.org>Related to #40194
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/642rephist: Track number of streams seen per type2022-10-27T14:47:23ZDavid Gouletdgoulet@torproject.orgrephist: Track number of streams seen per typeRelated to #40194
Signed-off-by: David Goulet <dgoulet@torproject.org>Related to #40194
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/641circ: Set proper timeout cutoff for HS circuits2022-10-26T19:13:17ZDavid Gouletdgoulet@torproject.orgcirc: Set proper timeout cutoff for HS circuitsExplicitly set the S_CONNECT_REND purpose to a 4-hop cutoff.
As for the established rendezvous circuit waiting on the RENDEZVOUS2,
set one that is very long considering the possible waiting time for the
service to get the request and jo...Explicitly set the S_CONNECT_REND purpose to a 4-hop cutoff.
As for the established rendezvous circuit waiting on the RENDEZVOUS2,
set one that is very long considering the possible waiting time for the
service to get the request and join our rendezvous.
Part of #40694
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/640hs: Retry rdv circuit if repurposed2022-10-26T19:09:32ZDavid Gouletdgoulet@torproject.orghs: Retry rdv circuit if repurposedThis can happen if our measurement subsystem decides to snatch it.
Fixes #40696
Signed-off-by: David Goulet <dgoulet@torproject.org>This can happen if our measurement subsystem decides to snatch it.
Fixes #40696
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/639hs: Change the error for a collapsing client circuit2022-10-26T18:59:38ZDavid Gouletdgoulet@torproject.orghs: Change the error for a collapsing client circuitChange it to an "unreachable" error so the intro point can be retried
and not flagged as a failure and never retried again.
Closes #40692
Signed-off-by: David Goulet <dgoulet@torproject.org>Change it to an "unreachable" error so the intro point can be retried
and not flagged as a failure and never retried again.
Closes #40692
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/638circ: Set proper timeout cutoff for HS circuits2022-10-26T19:13:14ZDavid Gouletdgoulet@torproject.orgcirc: Set proper timeout cutoff for HS circuitsExplicitly set the S_CONNECT_REND purpose to a 4-hop cutoff.
As for the established rendezvous circuit waiting on the RENDEZVOUS2,
set one that is very long considering the possible waiting time for the
service to get the request and jo...Explicitly set the S_CONNECT_REND purpose to a 4-hop cutoff.
As for the established rendezvous circuit waiting on the RENDEZVOUS2,
set one that is very long considering the possible waiting time for the
service to get the request and join our rendezvous.
Part of #40694
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/637hs: Retry rdv circuit if repurposed2022-10-26T19:09:28ZDavid Gouletdgoulet@torproject.orghs: Retry rdv circuit if repurposedThis can happen if our measurement subsystem decides to snatch it.
Fixes #40696
Signed-off-by: David Goulet <dgoulet@torproject.org>This can happen if our measurement subsystem decides to snatch it.
Fixes #40696
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/635dir auths now omit Measured= if rs->is_authority2022-10-26T20:32:32ZRoger Dingledinedir auths now omit Measured= if rs->is_authority dir auths now omit Measured= if rs->is_authority
Directory authorities stop voting a consensus "Measured" weight
for relays with the Authority flag. Now these relays will be
considered unmeasured, which should reserv... dir auths now omit Measured= if rs->is_authority
Directory authorities stop voting a consensus "Measured" weight
for relays with the Authority flag. Now these relays will be
considered unmeasured, which should reserve their bandwidth
for their dir auth role and minimize distractions from other roles.
In place of the "Measured" weight, they now include a
"MeasuredButAuthority" weight (not used by anything) so the bandwidth
authority's opinion on this relay can be recorded for posterity.
Resolves ticket 40698.Tor: 0.4.7.x-post-stableRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/633hs: Change the error for a collapsing client circuit2022-10-26T18:59:34ZDavid Gouletdgoulet@torproject.orghs: Change the error for a collapsing client circuitChange it to an "unreachable" error so the intro point can be retried
and not flagged as a failure and never retried again.
Closes #40692
Signed-off-by: David Goulet <dgoulet@torproject.org>Change it to an "unreachable" error so the intro point can be retried
and not flagged as a failure and never retried again.
Closes #40692
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/631dirauth: Remove Faravahar2022-11-01T09:18:10ZDavid Gouletdgoulet@torproject.orgdirauth: Remove FaravaharCloses #40688
Signed-off-by: David Goulet <dgoulet@torproject.org>Closes #40688
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/630dirauth: Change dizum IP address2022-10-26T18:33:49ZDavid Gouletdgoulet@torproject.orgdirauth: Change dizum IP addressCloses #40687
Signed-off-by: David Goulet <dgoulet@torproject.org>Closes #40687
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/608relay: Don't send DESTROY remote reason backward or forward2022-08-02T20:25:20ZDavid Gouletdgoulet@torproject.orgrelay: Don't send DESTROY remote reason backward or forwardFixes #40649
Signed-off-by: David Goulet <dgoulet@torproject.org>Fixes #40649
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/606conn: Notify btrack subsys on normal OR conn close2022-08-02T20:11:22ZDavid Gouletdgoulet@torproject.orgconn: Notify btrack subsys on normal OR conn closeFixes #40604
Signed-off-by: David Goulet <dgoulet@torproject.org>Fixes #40604
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.7.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/605Fix a check, make a netflow padding function more safe.2022-07-27T15:35:14ZNick MathewsonFix a check, make a netflow padding function more safe.Previously, `channelpadding_get_netflow_inactive_timeout_ms` would
crash with an assertion failure if `low_timeout` was greater than
`high_timeout`. That wasn't possible in practice because of checks
in `channelpadding_update_padding_for...Previously, `channelpadding_get_netflow_inactive_timeout_ms` would
crash with an assertion failure if `low_timeout` was greater than
`high_timeout`. That wasn't possible in practice because of checks
in `channelpadding_update_padding_for_channel`, but it's better not
to have a function whose correctness is this tricky to prove.
Fixes #40645. Bugfix on 0.3.1.1-alpha.
I've made this patch against 0.4.5 in case we decide to ~Backport.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/603relay: Send DESTROY cell instead of TRUNCATED cell2022-07-26T20:17:37ZDavid Gouletdgoulet@torproject.orgrelay: Send DESTROY cell instead of TRUNCATED cellNote that with this commit, TRUNCATED cells won't be used anymore that
is client and relays won't emit them.
Fixes #40623
Signed-off-by: David Goulet <dgoulet@torproject.org>Note that with this commit, TRUNCATED cells won't be used anymore that
is client and relays won't emit them.
Fixes #40623
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/601relay: Remove unused conn->ext_or_conn_id2022-11-08T17:35:24ZDavid Gouletdgoulet@torproject.orgrelay: Remove unused conn->ext_or_conn_idThis also incidently removes a use of uninitialized stack data from the
connection_or_set_ext_or_identifier() function.
Fixes #40648
Signed-off-by: David Goulet <dgoulet@torproject.org>This also incidently removes a use of uninitialized stack data from the
connection_or_set_ext_or_identifier() function.
Fixes #40648
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.8.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/579Enable IP_BIND_ADDRESS_NO_PORT if supported2023-01-12T17:34:15ZAlex XuEnable IP_BIND_ADDRESS_NO_PORT if supportedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40597#note_2805680:
> The man page says:
>
> > ### SO_REUSEADDR
> > Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local address...https://gitlab.torproject.org/tpo/core/tor/-/issues/40597#note_2805680:
> The man page says:
>
> > ### SO_REUSEADDR
> > Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses. For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address. When the listening socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address. Argument is an integer boolean flag.
>
> I relied on "For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address.", and I reckon so did #2850. This is, however, misleading: it's only true when a port is specified. When no port is specified, a port is selected from those with no connections at all, not those without a listening socket. https://blog.cloudflare.com/how-to-stop-running-out-of-ephemeral-ports-and-start-to-love-long-lived-connections/ has a good explanation of this. According to the article, the Linux-specific solution is to set IP_BIND_ADDRESS_NO_PORT. I think it's probably not so terrible if it's Linux-specific, since this only affects relay operators using OutboundBindAddress. AIUI, there are a few reasons why this flag isn't set by default: the main reason is that getsockname won't work between bind and connect for sockets using this flag; another reason is that this adds the possibility that bind could succeed but connect fails. Neither apply to tor, the former because tor doesn't use getsockname in this manner, and the second because tor already handles the case where connect fails due to EADDRINUSE because OutboundBindAddress is optional.
@adietrich if you could test this, I would greatly appreciate it. `IP_BIND_ADDRESS_NO_PORT` is supported back to Linux 4.2, so unless you're running centos 7 or debian 8 it should solve your issue. thanks!Tor: 0.4.8.x-freezeAlex XuAlex Xuhttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/558rephist: Introduce a fraction and period for overload onionskin2022-04-14T13:33:42ZDavid Gouletdgoulet@torproject.orgrephist: Introduce a fraction and period for overload onionskinThis code was heavily reused from the previous DNS timeout work done in
ticket #40491 that was removed afterall from our code.
Closes #40560
Signed-off-by: David Goulet <dgoulet@torproject.org>This code was heavily reused from the previous DNS timeout work done in
ticket #40491 that was removed afterall from our code.
Closes #40560
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.6.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/545hs: Schedule mainloop event on dirinfo change2022-03-10T14:25:12ZDavid Gouletdgoulet@torproject.orghs: Schedule mainloop event on dirinfo changeDue to a possible Guard subsystem recursion, when the HS client gets
notified that the directory information has changed, it must run it in a
seperate mainloop event to avoid such issue.
See the ticket for more information on the recurs...Due to a possible Guard subsystem recursion, when the HS client gets
notified that the directory information has changed, it must run it in a
seperate mainloop event to avoid such issue.
See the ticket for more information on the recursion. This also fixes a
fatal assert.
Fixes #40579
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/merge_requests/540hs: Fix multiple port label on single metric2022-03-09T13:51:36ZDavid Gouletdgoulet@torproject.orghs: Fix multiple port label on single metricPrometheus needs unique labels and so this bug was causing an onion
service with multiple ports to have multiple "port=" label for the
metrics requiring a port label.
Fixes #40581
Signed-off-by: David Goulet <dgoulet@torproject.org>Prometheus needs unique labels and so this bug was causing an onion
service with multiple ports to have multiple "port=" label for the
metrics requiring a port label.
Fixes #40581
Signed-off-by: David Goulet <dgoulet@torproject.org>Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org