Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-09-16T14:36:00Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7482Discard nonsense in address.c about v4-mapped addresses2021-09-16T14:36:00ZNick MathewsonDiscard nonsense in address.c about v4-mapped addressesRight now, some but not all places in address.c do strange contortions to treat ::ffff:1.2.3.4 as equivalent to 1.2.3.4. Instead, we should be rejecting these addresses as private, rather than trying to pretend that we support them.Right now, some but not all places in address.c do strange contortions to treat ::ffff:1.2.3.4 as equivalent to 1.2.3.4. Instead, we should be rejecting these addresses as private, rather than trying to pretend that we support them.https://gitlab.torproject.org/tpo/core/tor/-/issues/7488Make sure transparent proxies work with IPv62020-06-27T14:05:13ZNick MathewsonMake sure transparent proxies work with IPv6I haven't yet had a chance to make sure that TransPort and NatdPort work with IPv6. We need to test that before 0.2.4.x releases. Looking at the code, I don't see anything that would stop them, but without testing, best to assume the wo...I haven't yet had a chance to make sure that TransPort and NatdPort work with IPv6. We need to test that before 0.2.4.x releases. Looking at the code, I don't see anything that would stop them, but without testing, best to assume the worst.https://gitlab.torproject.org/tpo/core/tor/-/issues/7489Allow hidden services on IPv6 addresses2020-06-27T14:05:13ZNick MathewsonAllow hidden services on IPv6 addressesWith everything else we're doing for IPv6, we should allow HS operators to run a hidden service on a local IPv6 address. I believe Andrea was interested in this one.With everything else we're doing for IPv6, we should allow HS operators to run a hidden service on a local IPv6 address. I believe Andrea was interested in this one.Tor: 0.2.4.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7961Publish transports that bind on IPv6 addresses2021-11-19T21:12:13ZGeorge KadianakisPublish transports that bind on IPv6 addressesCurrently, `pt_get_extra_info_descriptor_string()` uses `router_pick_published_address()` to retrieve our external IP address so that it can write it in our extra-info descriptor along with the TCP port that our transport listens on.
Th...Currently, `pt_get_extra_info_descriptor_string()` uses `router_pick_published_address()` to retrieve our external IP address so that it can write it in our extra-info descriptor along with the TCP port that our transport listens on.
The bad news are that `router_pick_published_address()` only returns IPv4 addresses, and we will probably have to refactor it, or do something like this:
~~ https://gitweb.torproject.org/tor.git/blob/ebf30613ea41bbed3340851e839da9b7db4351c5:/src/or/router.c#l1775 ~~
(wrong commit reference)
for IPv6 addresses.
Not sure if this can get in 0.2.4.x. I guess it depends on how quickly we implement it, and how complex the changes are going to be.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8374Ship list of fallback directory mirrors on long-term fixed IPv6 addresses2020-06-27T14:04:40ZKarsten LoesingShip list of fallback directory mirrors on long-term fixed IPv6 addresseslegacy/trac#6027 enables clients which cannot talk to IPv4 relays to use fallback directory mirrors with IPv6 addresses and ORPorts. It's going to get merged into 0.2.5.x.
Assuming this code is in tor, how would we ship an up-to-date l...legacy/trac#6027 enables clients which cannot talk to IPv4 relays to use fallback directory mirrors with IPv6 addresses and ORPorts. It's going to get merged into 0.2.5.x.
Assuming this code is in tor, how would we ship an up-to-date list of long-term fixed directory mirror IPv6 addresses with bundles? I think I can provide a simple script or set up a service generating this list. But what's the easiest way to include the step "Grab new IPv6 addresses file and put it into all bundles" in the process of making bundles? There's no code written yet, so please say what's most convenient for bundle makers.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8377Tor claims that [::1]:9050 is non-loopback.2020-06-27T14:04:40ZNick MathewsonTor claims that [::1]:9050 is non-loopback.I just started Tor as "tor -socksport '[::1]:9050'". It said:
```
Mar 01 12:12:34.606 [notice] You configured a non-loopback address '[::1]:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy...I just started Tor as "tor -socksport '[::1]:9050'". It said:
```
Mar 01 12:12:34.606 [notice] You configured a non-loopback address '[::1]:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
```
This occurs in 0.2.3 and later.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8380DNS A records returned when asking for AAAA2020-06-27T14:04:40ZTracDNS A records returned when asking for AAAAI have Tor v0.2.5.0-alpha-dev running with DNSPort 53
Tor incorrectly returns an A record when asking for an AAAA
```
$ host -t aaaa google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
google.com h...I have Tor v0.2.5.0-alpha-dev running with DNSPort 53
Tor incorrectly returns an A record when asking for an AAAA
```
$ host -t aaaa google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
google.com has address 74.125.132.138
```
Additionally, if there is no AAAA record, it still returns an A
Using Google's public DNS:
```
$ host -t aaaa chase.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
chase.com has no AAAA record
```
Using Tor's DNSPort
```
$ host -t aaaa chase.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
chase.com has address 159.53.84.126
```
**Trac**:
**Username**: dhillTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8475internal-address check in handling RESOLVED cells doesn't cover IPv62020-06-27T14:04:36ZNick Mathewsoninternal-address check in handling RESOLVED cells doesn't cover IPv6Our check for internal addresses in connection_ap_process_not_open() doesn't look at IPv6 addresses. Better fix that. This is less horrible than it could be now that we don't cache answers, but somebody else might be caching Tor's repl...Our check for internal addresses in connection_ap_process_not_open() doesn't look at IPv6 addresses. Better fix that. This is less horrible than it could be now that we don't cache answers, but somebody else might be caching Tor's replies or something.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8846Useless log message when using IPv6 address on SocksPort without IPv62020-06-27T14:04:25ZTracUseless log message when using IPv6 address on SocksPort without IPv6I'm using TBB but with custom built tor executable, actually from git.tpo/debian/tor.git, and the log shows the following errors upon trying to visit an IPv6 address in TBB.
May 08 19:28:06.684 [Notice] Tor v0.2.4.11-alpha (git-f4f37a8f...I'm using TBB but with custom built tor executable, actually from git.tpo/debian/tor.git, and the log shows the following errors upon trying to visit an IPv6 address in TBB.
May 08 19:28:06.684 [Notice] Tor v0.2.4.11-alpha (git-f4f37a8fed617ffd) running on Linux with Libevent 2.0.21-stable and OpenSSL 1.0.1e.
May 08 19:28:06.684 [Notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 08 19:28:06.684 [Notice] This version is not a stable Tor release. Expect more bugs than usual.
May 08 19:28:06.686 [Notice] Read configuration file "XXXXXX/tor-browser_en-US/App/../Data/Tor/torrc".
May 08 19:28:06.692 [Notice] We were compiled with headers from version 2.0.19-stable of Libevent, but we're using a Libevent library that says it's version 2.0.21-stable.
May 08 19:28:06.692 [Notice] Opening Socks listener on 127.0.0.1:9150
May 08 19:28:06.692 [Notice] Opening Socks listener on 127.0.0.1:9050
May 08 19:28:06.692 [Notice] Opening Control listener on 127.0.0.1:9151
May 08 19:28:06.709 [Notice] Parsing GEOIP IPv4 file ./Data/Tor/geoip.
May 08 19:28:08.199 [Notice] Bootstrapped 5%: Connecting to directory server.
May 08 19:28:08.199 [Warning] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable; NOROUTE; count 1; recommendation warn)
May 08 19:28:08.270 [Notice] Bootstrapped 10%: Finishing handshake with directory server.
May 08 19:28:08.534 [Notice] Bootstrapped 15%: Establishing an encrypted directory connection.
May 08 19:28:08.932 [Notice] New control connection opened.
May 08 19:28:08.932 [Notice] Bootstrapped 20%: Asking for networkstatus consensus.
May 08 19:28:08.932 [Notice] Bootstrapped 25%: Loading networkstatus consensus.
May 08 19:28:10.586 [Notice] Bootstrapped 45%: Asking for relay descriptors.
May 08 19:28:10.586 [Notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 2187/3501, and can only build 27% of likely paths. (We have 65% of guards bw, 64% of midpoint bw, and 66% of exit bw.)
May 08 19:28:14.205 [Notice] We now have enough directory information to build circuits.
May 08 19:28:14.205 [Notice] Bootstrapped 80%: Connecting to the Tor network.
May 08 19:28:14.205 [Notice] Bootstrapped 90%: Establishing a Tor circuit.
May 08 19:28:14.683 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working.
May 08 19:28:14.684 [Notice] Bootstrapped 100%: Done.
May 08 19:33:48.508 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:48.792 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:50.516 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:50.517 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:51.515 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:51.516 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:52.313 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:33:52.363 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:54.314 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:33:57.545 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:34:00.998 [Warning] connection_ap_get_begincell_flags(): Bug: Hey; I'm about to ask a node for a connection that I am telling it to fulfil with neither IPv4 nor IPv6. That's probably not going to work.
May 08 19:34:01.535 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:36:28.511 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:36:50.612 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:08.202 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $A59E1E7C7EAEE083D756EE1FF6EC31CA3D8651D7~chaoscomputerclub19 at 31.172.30.2. Retrying on a new circuit.
May 08 19:37:09.088 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:34.885 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:48.819 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:37:57.915 [Notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.
May 08 19:38:35.203 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $43691853EA556C21A77E006886A5DC579855F527~sofia at 109.163.233.202. Retrying on a new circuit.
May 08 19:38:50.204 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $4F8D80A0F768A2A29856A8F26B05D35DEAA39850~wannabe at 96.47.226.19. Retrying on a new circuit.
May 08 19:39:36.202 [Notice] Tor has not observed any network activity for the past 69 seconds. Disabling circuit build timeout recording.
My torrc:
# If non-zero, try to write to disk less frequently than we would otherwise.
AvoidDiskWrites 1
# Store working data, state, keys, and caches here.
DataDirectory ./Data/Tor
GeoIPFile ./Data/Tor/geoip
# Where to send logging messages. Format is minSeverity[-maxSeverity]
# (stderr|stdout|syslog|file FILENAME).
Log notice stdout
# Bind to this address to listen to connections from SOCKS-speaking
# applications.
SocksPort 9150
ControlPort 9151
ClientPreferIPv6ORPort 1
ClientUseIPv6 1
SocksPort 127.0.0.1:9050 IPv6Traffic
I used to be able to visit IPv6 addresses from TBB up until 0.2.4.10 (if I remember correctly) using the same method (custom built tor executable).
If I start a TBB session and I don't visit any IPv6 addresses then I got no problems and no 'connection_ap_get_begincell_flags(): Bug:' messages appear in the logfile.
**Trac**:
**Username**: kargigTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9067Choice of address and match of fascist_firewall_allows_address* need to consi...2020-08-11T12:13:35ZNick MathewsonChoice of address and match of fascist_firewall_allows_address* need to consider ipv6Right now, when we decide "can we reach node X", we only pass the node's primary address to fasist_firewall_allows_*.
Also, when we decide whether to use an primary or secondary address, we don't look at fascist_firewall_* as far as I k...Right now, when we decide "can we reach node X", we only pass the node's primary address to fasist_firewall_allows_*.
Also, when we decide whether to use an primary or secondary address, we don't look at fascist_firewall_* as far as I know.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9068Unify reachableaddresses and IPv6 settings2020-06-27T14:04:17ZNick MathewsonUnify reachableaddresses and IPv6 settingsThere's really no difference between "I can't reach IPv6" and "ClientUseIPv6 0". Let's make them redundant. Let's also add an "I can't reach IPv4" option.
See legacy/trac#6027 and legacy/trac#9067There's really no difference between "I can't reach IPv6" and "ClientUseIPv6 0". Let's make them redundant. Let's also add an "I can't reach IPv4" option.
See legacy/trac#6027 and legacy/trac#9067Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10468Make DnsPort, IPv6, and AutomapHostsOnResolve work together2020-06-27T14:03:34ZNick MathewsonMake DnsPort, IPv6, and AutomapHostsOnResolve work togetherFrom legacy/trac#10465: I started Tor with "./src/or/tor -dnsport '9999 preferipv6automap' -automaphostsonresolve 1 -automaphostssuffix . "
Then I did:
```
[619]$ dig @localhost -p 9999 aaaa www.torproject.org
; <<>> DiG 9.8.3-P1 <<>> ...From legacy/trac#10465: I started Tor with "./src/or/tor -dnsport '9999 preferipv6automap' -automaphostsonresolve 1 -automaphostssuffix . "
Then I did:
```
[619]$ dig @localhost -p 9999 aaaa www.torproject.org
; <<>> DiG 9.8.3-P1 <<>> @localhost -p 9999 aaaa www.torproject.org
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45384
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.torproject.org. IN AAAA
;; ANSWER SECTION:
www.torproject.org. 60 IN A 127.237.144.204
;; Query time: 0 msec
;; SERVER: 127.0.0.1#9999(127.0.0.1)
;; WHEN: Sun Dec 22 09:19:54 2013
;; MSG SIZE rcvd: 52
```
and
```
[621]$ dig @localhost -p 9999 example.com
; <<>> DiG 9.8.3-P1 <<>> @localhost -p 9999 example.com
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18398
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 60 IN A 127.201.101.133
;; Query time: 0 msec
;; SERVER: 127.0.0.1#9999(127.0.0.1)
;; WHEN: Sun Dec 22 09:20:31 2013
;; MSG SIZE rcvd: 45
```
It seems to be sending A even if it was asked for an AAAA.
(There are deeper DNSPort+IPv6 issues going on, of course, but this part is probably easier, and it's an independently useful bit of functionality.)
See legacy/trac#10465 notes for moreTor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10987IPv6 is not working when using SocksPort2020-06-27T14:03:25ZDavid Gouletdgoulet@torproject.orgIPv6 is not working when using SocksPortTor daemon replies to a SOCKS5 connect command with an IPv4 payload when using IPv6 thus making the client trying to receive too much bytes and failing to use IPv6 with a SOCKS5 connection.
I'll be submitting a patch for this soon. Jus...Tor daemon replies to a SOCKS5 connect command with an IPv4 payload when using IPv6 thus making the client trying to receive too much bytes and failing to use IPv6 with a SOCKS5 connection.
I'll be submitting a patch for this soon. Just need to get this bug number and make the changes file.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11211Multiple ServerTransportListenAddr entries should be allowed per transport.2023-11-16T20:18:11ZYawning AngelMultiple ServerTransportListenAddr entries should be allowed per transport.Looking through or/config.c, it is apparent that the ServerTransportListenAddr line only allows one address/port to be specified per transport. This is problematic because there are cases where it is beneficial/required to list more tha...Looking through or/config.c, it is apparent that the ServerTransportListenAddr line only allows one address/port to be specified per transport. This is problematic because there are cases where it is beneficial/required to list more than one.
A simple example of where this would be useful is:
```
ServerTransportListenAddr obfs3 0.0.0.0:443
ServerTransportListenAddr obfs3 [::]:443
```
The Pluggable Transport spec doesn't explicitly disallow having multiple bind addresses for TOR_PT_SERVER_BIND_ADDR, but I'm not sure what would happen if more than one is passed with each of the pt config protocol libraries in use.
The keys holding transport names must appear on the same order
as they appear on TOR_PT_SERVER_TRANSPORTS.
Currently the particular example I used is probably a moot point because of #7961, but in general I don't see a good reason why each transport should be limited to one bind address.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/11360Listen on IPv6 by default for SocksPort *:Port2021-06-18T18:20:31ZDavid Gouletdgoulet@torproject.orgListen on IPv6 by default for SocksPort *:PortThat would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon....That would be very useful if tor could listen on both IPv4 and IPv6 for the SocksPort. One use case is for Torsocks to work seamlessly with v4 and v6 without having to configure a v6 port in the configuration file and restart the daemon.
One way to fix that would be to change the function parse_port_config() in _src/or/config.c_ to allow multiple default values adding v6 defaults (which would benefit other ports as well).
Else, having a check somewhere that adds other defaults for specific ports but not sure that it's a good idea nor makes sense in the long run in terms of maintainability.
I thought also about bringing back legacy/trac#4760 by default and setting the ipv6 only option only and only if the user has defined an option in the torrc explicitly. For instance, this in the torrc would ONLY allow v6 (remove dual stack).
```
SocksPort [::1]:9050
```
Thoughts?https://gitlab.torproject.org/tpo/core/tor/-/issues/11625Tor DNSPORT returns NXDOMAIN for AAAA records?2022-06-17T16:14:40ZNick MathewsonTor DNSPORT returns NXDOMAIN for AAAA records?On legacy/trac#11603, mickeyc reports:
```
Behaviour has changed with 0.2.5.4, but it is still broken. Now I'm getting an NXDOMAIN
instead whenever I do any AAAA lookups. A record lookups are still fine:
mike@glue:~$ dig aaaa gmail.com...On legacy/trac#11603, mickeyc reports:
```
Behaviour has changed with 0.2.5.4, but it is still broken. Now I'm getting an NXDOMAIN
instead whenever I do any AAAA lookups. A record lookups are still fine:
mike@glue:~$ dig aaaa gmail.com @localhost -p 5304
; <<>> DiG 9.9.5-3-Debian <<>> aaaa gmail.com @localhost -p 5304
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19056
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;gmail.com. IN AAAA
;; Query time: 249 msec
;; SERVER: ::1#5304(::1)
;; WHEN: Sun Apr 27 11:37:35 BST 2014
;; MSG SIZE rcvd: 27
mike@glue:~$ dig +short a gmail.com @localhost -p 5304
173.194.70.18
mike@glue:~$
```https://gitlab.torproject.org/tpo/core/tor/-/issues/12138No IPv6 support when suggesting a bindaddr to a PT2022-02-28T19:40:20ZGeorge KadianakisNo IPv6 support when suggesting a bindaddr to a PTThis recent post in tor-talk:
http://www.marshut.com/iwuqqh/setting-up-an-ipv6-%20supporting-obfs3-bridge.html
revealed that Tor does not support IPv6 when supporting a bind address to a pluggable transport. It seems that we missed that ...This recent post in tor-talk:
http://www.marshut.com/iwuqqh/setting-up-an-ipv6-%20supporting-obfs3-bridge.html
revealed that Tor does not support IPv6 when supporting a bind address to a pluggable transport. It seems that we missed that during legacy/trac#7011.
The problem is that the first time someone fires up a `ServerTransportPlugin`, Tor will suggest to it to bind in `0.0.0.0:0`. This can be seen in `get_stored_bindaddr_for_server_transport`:
https://gitweb.torproject.org/tor.git/blob/2ee56e4c2c841a45418cfb826e1ce6689278382d:/src/or/statefile.c#l517
```
no_bindaddr_found:
/** If we didn't find references for this pluggable transport in the
state file, we should instruct the pluggable transport proxy to
listen on INADDR_ANY on a random ephemeral port. */
tor_asprintf(&default_addrport, "%s:%s", fmt_addr32(INADDR_ANY), "0");
return default_addrport;
```
Instead of using `fmt_addr32(INADDR_ANY)`, we should use `fmt_addrport` and suggest `[::]` if we need to use IPv6. We should probably suggest an IPv6 address, if our ORPort is IPv6 (what if we have both kinds of ORPorts?).
Implementation of this should not be hard. I can do it one of these days.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/12163Tor 0.2.4.22 doesn't bind to low IPv6 ports2020-06-27T14:02:57ZTracTor 0.2.4.22 doesn't bind to low IPv6 portsIPv4 works fine with a low port number (445 in my case), but IPv6 doesn't.
Config:
ORPort 445
ORPort [2001:db8:a:b::c]:445
[warn] Could not bind to 2001:db8:a:b::c:445:
| > | Permission denied
Now when I change the IPv6 port to a hi...IPv4 works fine with a low port number (445 in my case), but IPv6 doesn't.
Config:
ORPort 445
ORPort [2001:db8:a:b::c]:445
[warn] Could not bind to 2001:db8:a:b::c:445:
| > | Permission denied
Now when I change the IPv6 port to a higher number everything works fine:
ORPort [2001:db8:a:b::c]:4445
OS is Ubuntu; Linux version 3.13.0-24-generic (buildd@batsu) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) legacy/trac#47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014
**Trac**:
**Username**: rommelbakTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12558Tor doesn't show warning for non-reachable IPv6 OR port2020-06-27T14:02:49ZTracTor doesn't show warning for non-reachable IPv6 OR portI recently upgraded my routers firmware. After that, I restarted Tor as usual. After one day, I noticed that atlas is showing my relay as offline since restart.
After more than hour of investigating, I found out that my router gave my R...I recently upgraded my routers firmware. After that, I restarted Tor as usual. After one day, I noticed that atlas is showing my relay as offline since restart.
After more than hour of investigating, I found out that my router gave my Raspberry Pi a new IPv6 interface ID. Due to this, my port forwarding didn't work anymore.
The strange thing is: In my tor logs, I saw this:
"Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor."
Looks like Tor was just referring to my IPv4 OR Port, which was still reachable, and didn't notice my non-reachable IPv6 OR Port. This issue should be fixed.
**Trac**:
**Username**: anonghttps://gitlab.torproject.org/tpo/core/tor/-/issues/13043torspec lies about accepting both IPv4 and IPv6 for ORAddress lines2020-06-27T14:02:36ZIsis Lovecrufttorspec lies about accepting both IPv4 and IPv6 for ORAddress lines(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, desp...(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, despite what `dir-spec.txt` says.
The spec [says](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l1166):
```
"a" SP address ":" port NL
[Any number]
The "or-address" element as specified in section 2.1.1.
```
[and](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l587):
```
"or-address" SP ADDRESS ":" PORT NL
[Any number]
ADDRESS = IP6ADDR | IP4ADDR
IPV6ADDR = an ipv6 address, surrounded by square brackets.
IPV4ADDR = an ipv4 address, represented as a dotted quad.
PORT = a number between 1 and 65535 inclusive.
An alternative for the address and ORPort of the "router" line, but with
two added capabilities:
* or-address can be either an IPv4 or IPv6 address
* or-address allows for multiple ORPorts and addresses
A descriptor SHOULD NOT include an or-address line that does nothing but
duplicate the address:port pair from its "router" line.
The ordering of or-address lines and their PORT entries matter because
Tor MAY accept a limited number of addresses or ports. As of Tor 0.2.3.x
only the first address and the first port are used.
```
- In terms of how many `"a"`/`"or-address"` lines there may be, the spec is only correct if you pay _super close attention to the last sentence_ (this is actually the first time I've noticed it :) ).
- In terms of whether IPv4 and/or IPv6 addresses are acceptable, _the spec is currently wrong_, according to the functions `router_rebuild_descriptor()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l1811 [source]] and `router_dump_router_to_string()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l2330 [source]] in `src/or/router.c` in tor's source code.Tor: 0.3.3.x-finalteorteor