Where do we get daily builds?

-----Original Message----- From: tor-relays tor-relays-bounces@lists.torproject.org On Behalf Of David Goulet Sent: 22 July 2020 20:55 To: tor-relays@lists.torproject.org Subject: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery

Greetings everyone!

We've very recently merged upstream (tor.git) full IPv6 supports which implies many many things. We are still finalizing the work but most of it is in at the moment.

This is a call for help if anyone would like to test either git master[1] or nightly builds[2] (only Debian) to test for us a specific feature.

The feature we would love for some of you to test is the IPv6 address discovery. In short, with this new feature, specifying an ORPort without an address will automatically bind tor to [::]:<port> and attempt to find the IPv6 address by looking at (in this order):

1. "Address" from torrc 2. "ORPort address:port" from torrc 3. Interface address. First public IPv6 is used. 4. Local hostname, DNS AAAA query.

If all fails, the relay will simply never publish an IPv6 in the descriptor but it will work properly with the IPv4 (still mandatory).

The other new thing is that now tor supports *two* "Address" statement which can be a hostname or IPv4 or IPv6 now.

Thus this is now valid:

Address 1.2.3.4 Address [4242::4242] ORPort 9001

Your Tor will bind to 0.0.0.0:9001 and [::]:9001 but will publish the 1.2.3.4 for the IPv4 address and [4242::4242] for IPv6 in the descriptor that is the address to use to reach your relay's ORPort.

Now, if you happen to have this configuration which I believe might be common at the moment:

ORPort 9001 ORPort [4242::4242]:9001

The second ORPort which specifies an IPv6 address will supersede the "ORPort 9001" which uses [::] and thus you will bind on 0.0.0.0:9001 and [4242::4242]:9001. You should get a notice log about this.

Thus the recommended configuration to avoid that log notice would be to bind to specific addresses per family:

ORPort <IPv4>:9001 ORPort <IPv6>:9001

And of course, if you want your relay to _not_ listen on IPv6:

ORPort 9001 IPv4Only

In your notice log, you will see which address is used to bind on the ORPort and then you will see the reachability test succeed or not on the address that tor either used from the configuration or auto discovered that is the address you are supposedly reachable from.

Man page has NOT been updated yet, it will arrive once we stabilize the IPv6 feature and everything around it.

Please, do report (on this thread) _anything_ even slightly annoying about this like logging or lack of logging and so on. This is a complex feature and errors can be made thus any testing you can offer is extremely appreciated.

Thanks!! David

[1] https://gitweb.torproject.org/tor.git/ [2] https://2019.www.torproject.org/docs/debian.html.en

-- EeJVrrC/dHQXEXYB1ShOOZ4QuQ8PMnRY2XGq4BYsFq4=

Hello,

I have a hard time trying to correctly update my configuration following this change, with Tor 0.4.5.2 on Ubuntu focal. The machine has both an IPv4 and IPv6 connectivity, but my relay must only use IPv4 to listen for connections.

The relevant parts of my configuration before moving to the 0.4.5 branch was: ``` ORPort 192.168.2.1:9001 NoAdvertise ORPort <public-ipv4>:9001 NoListen

Address <public-ipv4>

OutboundBindAddress 192.168.2.1 ```

Since 0.4.5, the order of the ORPort lines seem to matter.

* First case:

torrc ORPort lines: ``` ORPort 192.168.2.1:9001 NoAdvertise ORPort <public-ipv4>:9001 NoListen ```

Log from `tor --verify-config -f torrc`: ``` Nov 27 11:26:30.043 [warn] We are advertising an ORPort, but not actually listening on one. Nov 27 11:26:30.043 [warn] Failed to parse/validate config: Misconfigured server ports Nov 27 11:26:30.043 [err] Reading config failed--see warnings above. ```

* Second case:

torrc ORPort lines: ``` ORPort <public-ipv4>:9001 NoListen ORPort 192.168.2.1:9001 NoAdvertise ```

Log from `tor --verify-config -f torrc`:

``` Nov 27 11:29:17.236 [warn] We are listening on an ORPort, but not advertising any ORPorts. This will keep us from building a router descriptor, and make us impossible to use. Nov 27 11:29:17.237 [warn] Failed to parse/validate config: Misconfigured server ports Nov 27 11:29:17.237 [err] Reading config failed--see warnings above. ```

It looks like the second ORPort line always supersedes the first one?

Finally, by changing the configuration to:

``` ORPort 192.168.2.1:9001 NoAdvertise OrPort 9001 NoListen IPv4Only ```

Log from `tor --verify-config -f torrc`:

``` Nov 27 11:34:12.699 [warn] Could not interpret ORPort address as IPv4 Nov 27 11:34:12.699 [warn] Failed to parse/validate config: Invalid ORPort configuration Nov 27 11:34:12.699 [err] Reading config failed--see warnings above. ```

So I am unsure what is the correct approach with what I am trying to achieve. I am not sure if I am missing something or if it's a bug in the new feature?

Thanks,

On 22/07/2020 21:54, David Goulet wrote:

Greetings everyone!

We've very recently merged upstream (tor.git) full IPv6 supports which implies many many things. We are still finalizing the work but most of it is in at the moment.

This is a call for help if anyone would like to test either git master[1] or nightly builds[2] (only Debian) to test for us a specific feature.

The feature we would love for some of you to test is the IPv6 address discovery. In short, with this new feature, specifying an ORPort without an address will automatically bind tor to [::]:<port> and attempt to find the IPv6 address by looking at (in this order):

1. "Address" from torrc
2. "ORPort address:port" from torrc
3. Interface address. First public IPv6 is used.
4. Local hostname, DNS AAAA query.

If all fails, the relay will simply never publish an IPv6 in the descriptor but it will work properly with the IPv4 (still mandatory).

The other new thing is that now tor supports *two* "Address" statement which can be a hostname or IPv4 or IPv6 now.

Thus this is now valid:

Address 1.2.3.4 Address [4242::4242] ORPort 9001

Your Tor will bind to 0.0.0.0:9001 and [::]:9001 but will publish the 1.2.3.4 for the IPv4 address and [4242::4242] for IPv6 in the descriptor that is the address to use to reach your relay's ORPort.

Now, if you happen to have this configuration which I believe might be common at the moment:

ORPort 9001 ORPort [4242::4242]:9001

The second ORPort which specifies an IPv6 address will supersede the "ORPort 9001" which uses [::] and thus you will bind on 0.0.0.0:9001 and [4242::4242]:9001. You should get a notice log about this.

Thus the recommended configuration to avoid that log notice would be to bind to specific addresses per family:

ORPort <IPv4>:9001 ORPort <IPv6>:9001

And of course, if you want your relay to _not_ listen on IPv6:

ORPort 9001 IPv4Only

In your notice log, you will see which address is used to bind on the ORPort and then you will see the reachability test succeed or not on the address that tor either used from the configuration or auto discovered that is the address you are supposedly reachable from.

Man page has NOT been updated yet, it will arrive once we stabilize the IPv6 feature and everything around it.

Please, do report (on this thread) _anything_ even slightly annoying about this like logging or lack of logging and so on. This is a complex feature and errors can be made thus any testing you can offer is extremely appreciated.

Thanks!! David

[1] https://gitweb.torproject.org/tor.git/ [2] https://2019.www.torproject.org/docs/debian.html.en

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays