Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
Hi Am 27.11.2020 um 11:43 schrieb t...@fr33tux.org: The relevant parts of my configuration before moving to the 0.4.5 branch was: ``` ORPort 192.168.2.1:9001 NoAdvertise ORPort :9001 NoListen Address OutboundBindAddress 192.168.2.1 ``` A silly question to double check: That really worked? I don't use OutboundBindAddress but given the name "outbound-bind-address" the outbound traffic has to bind to a public IP. And 192.168/16 is not public. For what it's worth. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
t...@fr33tux.org wrote: 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 :9001 NoListen Address 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 :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 :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, Hello, It won't work, maybe because it was broken in the latest alpha. I already filed a ticket about it: https://gitlab.torproject.org/tpo/core/tor/-/issues/40205 and https://gitlab.torproject.org/tpo/core/tor/-/issues/40208 Feel free to comment there with your setup scenarios, or if you don't have a gitlab account I'll link this mail post there. Try this: - first disable IPv6 from the box entirely, because of https://gitlab.torproject.org/tpo/core/tor/-/issues/40205 - Set just this in your torrc (and it will guess Address): ORPort 192.168.2.1:9001 However, your examples look correct setups and are not directly related to those gitlab issues which represent different environments and setups -- can you please paste your entire torrc and make sure 192.168.2.1 or whatever LAN IP you have is the correct LAN IP assigned to this box and that port is free? Also do you set Address? I would ask you to stay on alpha and not roll back to a previous version as we need to fix this, and the more people test it the better. OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
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 :9001 NoListen Address 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 :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 :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 [::]: 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 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 :9001 ORPort :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 OpenPGP_0x18E899E680C4FF62.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
On 7/22/20 9:54 PM, David Goulet wrote: > In your notice log, you will see which address is used to bind on the ORPort Not here (hardened stable Gentoo), this is from the notice log: Aug 26 20:59:18.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Aug 26 20:59:19.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Aug 26 20:59:48.000 [notice] Clean shutdown finished. Exiting. Aug 26 20:59:49.000 [notice] Tor 0.4.5.0-alpha-dev opening log file. Aug 26 20:59:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Aug 26 20:59:50.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Aug 26 20:59:54.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. Aug 26 20:59:54.000 [notice] Your Tor server's identity key fingerprint is 'zwiebeltoralf 63BF46A63F9C21FD315CD061B3EAA3EB05283A0A' Aug 26 20:59:54.000 [notice] Bootstrapped 0% (starting): Starting Aug 26 20:59:54.000 [notice] This version of Tor (0.4.5.0-alpha-dev) is newer than any recommended version, according to the directory authorities. Recommended versions are: 0.3.5.10,0.3.5.11,0.4.2.7,0.4.2.8,0.4.3.3-alpha,0.4.3.4-rc,0.4.3.5,0.4.3.6,0.4.4.1-alpha,0.4.4.2-alpha,0.4.4.3-alpha,0.4.4.4-rc Aug 26 21:00:13.000 [notice] Starting with guard context "default" Aug 26 21:00:13.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Aug 26 21:00:14.000 [notice] Bootstrapped 5% (conn): Connecting to a relay Aug 26 21:00:14.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay Aug 26 21:00:14.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay Aug 26 21:00:14.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done Aug 26 21:00:14.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Aug 26 21:00:14.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Aug 26 21:00:14.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit Aug 26 21:00:15.000 [notice] Bootstrapped 100% (done): Done Aug 26 21:00:16.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor. Aug 26 21:01:15.000 [notice] Performing bandwidth self-test...done. Aug 26 21:02:21.000 [notice] New control connection opened from 127.0.0.1. and this the config: # torrc # PIDFile /var/run/tor/tor.pid DataDirectory /var/lib/tor/data Nickname zwiebeltoralf Address 5.9.158.75 OutboundBindAddress 5.9.158.75 OutboundBindAddress [2a01:4f8:190:514a::2] DirPort 5.9.158.75:80 ORPort 5.9.158.75:443 DirPort [2a01:4f8:190:514a::2]:80 NoAdvertise ORPort [2a01:4f8:190:514a::2]:443 ControlPort 9051 Log notice file /var/log/tor/notice.log Log warn file /var/log/tor/warn.log %include /etc/tor/torrc.d/ ConnDirectionStatistics 1 -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
On 8/26/20 7:00 PM, Toralf Förster wrote: > Or better asked, why it has a "tor-tor" prefix - this breaks any easy install > method/quirk here under Gentoo :-( :# > > $ tar -tvf /var/cache/distfiles/tor-0.4.5.0-alpha-dev.tar.gz | head > drwxrwxr-x root/root 0 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev And last, but not least the 4.5.0-alpha-dev tar ball lacks a configure script ... -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
On 8/26/20 5:46 PM, Toralf Förster wrote: > On 8/26/20 4:56 PM, David Goulet wrote: >> If you are still running a 0.4.5.0-alpha version > Not tagged yet, or ? > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > Or better asked, why it has a "tor-tor" prefix - this breaks any easy install method/quirk here under Gentoo :-( :# $ tar -tvf /var/cache/distfiles/tor-0.4.5.0-alpha-dev.tar.gz | head drwxrwxr-x root/root 0 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/ -rw-rw-r-- root/root 6536 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/.appveyor.yml -rw-rw-r-- root/root 3926 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/.clang-format -rw-rw-r-- root/root 787 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/.editorconfig -rw-rw-r-- root/root 3569 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/.gitignore -rw-rw-r-- root/root 422 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/.gitlab-ci.yml -rw-rw-r-- root/root 104 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/.gitmodules -rw-rw-r-- root/root 13591 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/.travis.yml -rw-rw-r-- root/root 282 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/CODE_OF_CONDUCT -rw-rw-r-- root/root 1187 2020-06-09 20:14 tor-tor-0.4.5.0-alpha-dev/CONTRIBUTING ... -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
On 8/26/20 4:56 PM, David Goulet wrote: > If you are still running a 0.4.5.0-alpha version Not tagged yet, or ? -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
On 22 Jul (15:54: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. Greetings everyone! Thanks everyone that is helping testing this! If you are still running a 0.4.5.0-alpha version (or git master), we would like to ask you one more thing. If you could flip this torrc option to 1 so we can help our metrics team build proper graphs to learn how much IPv6 connections we have in the network. ConnDirectionStatistics 1 Big thanks everyone! David -- C/P9tCyvJP95vPJI5IUPHZQ9JQz0ffWlbT270iRUOW0= signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
hi Gerard, you can find the instructions via the link provided in the original email: [2] https://2019.www.torproject.org/docs/debian.html.en gr. Paul On Thu, Jul 23, 2020 at 11:48 PM Dr Gerard Bulger wrote: > Where do we get daily builds? > > -Original Message- > From: tor-relays 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 [::]: 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 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 :9001 > ORPort :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= > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
Dr Gerard Bulger: > Where do we get daily builds? See the nightly repos here (debian based only): https://deb.torproject.org/torproject.org/dists/ -- https://mastodon.social/@nusenu signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
Where do we get daily builds? -Original Message- From: tor-relays 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 [::]: 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 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 :9001 ORPort :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= ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[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 [::]: 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 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 :9001 ORPort :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= signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
