Running 2 relays with 0.4.0.2_alpha [err] descriptor at 0x8a0acdb0830 begins with unexpected string "".
I run one relay and another tor instance for hidden services and socksport. Haven't had a problem until 0.4.0.2_alpha. Ive had it crash twice so far. Maybe my configs aren't sane? [err] descriptor at 0x8a0acdb0830 begins with unexpected string "". Is another process running in our data directory? Exiting. First config User tor PIDFile /var/run/tor2/tor2.pid SOCKSPort 9052 ControlPort 9053 Log notice file /var/lib/tor2/notices.log RunAsDaemon 1 DataDirectory /var/lib/tor2/data CookieAuthentication 1 ClientUseIPv6 1 ClientPreferIPv6ORPort 1 ClientPreferIPv6DirPort 1 HiddenServiceDir /var/lib/tor2/ssh/ HiddenServicePort 22 127.0.0.1:22 HiddenServiceDir /var/lib/tor2/ssh-new/ HiddenServiceVersion 3 HiddenServicePort 22 127.0.0.1:22 HiddenServiceDir /var/lib/tor2/bitcoind/ HiddenServicePort 8333 127.0.0.1:8333 Second config User tor PIDFile /var/run/tor/tor.pid Log notice syslog Log notice file /var/log/tor/debug.log #Log notice debug file /var/lib/tor/data/tor.log DataDirectory /var/lib/tor/data ControlPort 9051 HashedControlPassword CookieAuthentication 1 ORPort 9001 ORPort []:9050 DirPort 9030 BandwidthRate 4 MBytes BandwidthBurst 5 MBytes Nickname PancakeWhore ContactInfo ExitPolicy reject *:* ExitPolicy reject6 *:*
Hi,
On 28 Feb 2019, at 09:57, technonerd@fea.st wrote:
I run one relay and another tor instance for hidden services and socksport. Haven't had a problem until 0.4.0.2_alpha. Ive had it crash twice so far. Maybe my configs aren't sane?
[err] descriptor at 0x8a0acdb0830 begins with unexpected string "". Is another process running in our data directory? Exiting.
Which instance do the errors occur on?
ORPort []:9050
This config line will probably cause a parse error. If this is meant to be an IPv6 ORPort, try: ORPort [::]:9050 T
Hello, teor wrote:
Hi,
On 28 Feb 2019, at 09:57, technonerd@fea.st wrote:
I run one relay and another tor instance for hidden services and socksport. Haven't had a problem until 0.4.0.2_alpha. Ive had it crash twice so far. Maybe my configs aren't sane?
[err] descriptor at 0x8a0acdb0830 begins with unexpected string "". Is another process running in our data directory? Exiting.
Which instance do the errors occur on?
ORPort []:9050
This config line will probably cause a parse error.
If this is meant to be an IPv6 ORPort, try:
ORPort [::]:9050
T
Indeed, ORPort []:9050 is incorrect, even it's not the reason of the error described in this message. teor: However, shouldn't the line: ORPort 9050 bind to all v4 and v6 available interfaces / IP addresses? If it does not, we should fix it to do so. As in: ORPort 9050 - bind to all available v4 and v6 ORPort 0.0.0.0:9050 - bind to all available from the v4 class ORport [::]:9050 - bind to all available from the v6 class ORPort <explicit-address>:port - bind to specified address exactly Back to the err message: I see you use two Tor instances and properly set up two different datadirectories for each, one in /var/lib/tor/data and one in /var/lib/tor2/data -- so the possibility of two (Tor) processes running in the same datadirectory shouldn't be of concern. Please follow-up this bug, maybe downgrade your logs to at least info level and monitor the processes running and using the Tor DataDirectory paths. Already crashed twice so far? Which instance crashed the one running a relay or the one hosting onion services?
ORPort []:9050
This config line will probably cause a parse error.
If this is meant to be an IPv6 ORPort, try:
ORPort [::]:9050
T
Indeed, ORPort []:9050 is incorrect, even it's not the reason of the error described in this message.
Sorry for the confusion I had removed the ipv6 address before sending the email. But it would be ORPort [ipv6_address]:9050
Back to the err message: I see you use two Tor instances and properly set up two different datadirectories for each, one in /var/lib/tor/data and one in /var/lib/tor2/data -- so the possibility of two (Tor) processes running in the same datadirectory shouldn't be of concern.
Please follow-up this bug, maybe downgrade your logs to at least info level and monitor the processes running and using the Tor DataDirectory paths.
I have been using nyx to monitor the relay process via "sudo -u tor nyx" I will stop using it for the time being and just monitor the files.
Already crashed twice so far? Which instance crashed the one running a relay or the one hosting onion services?
The relay has crashed twice, the one hosting the onion service has been unaffected.
Hi, Cc'ing Linus, because he is also interested in IPv6.
On 28 Feb 2019, at 19:01, s7r <s7r@sky-ip.org> wrote:
However, shouldn't the line: ORPort 9050
bind to all v4 and v6 available interfaces / IP addresses? If it does not, we should fix it to do so. As in:
ORPort 9050 - bind to all available v4 and v6 ORPort 0.0.0.0:9050 - bind to all available from the v4 class ORport [::]:9050 - bind to all available from the v6 class ORPort <explicit-address>:port - bind to specified address exactly
Tor already binds to IPv4 and IPv6 by default. But it only autodetects IPv4 addresses. (Binding to IPv6 doesn't really do much, if you don't have an IPv6 address to advertise.) I'd love to make Tor autodetect IPv6 addresses. Here's what we need to do to make that happen: 1. make relays extend over IPv6 * these relays should declare a new protocol version "IPv6Relay=1" 2. make relays check their IPv6 ORPorts for reachability using an IPv6Relay * make relays connect to their own IPv6 ORPort (needs 1) * detect and track IPv4 and IPv6 ORPort reachability separately 3. make relays autodetect an IPv6 address (needs 2) Here's the parent ticket for this change: https://trac.torproject.org/projects/tor/ticket/24403 Our next step is to write a proposal for this change. (There is already some code in some of the tickets.) T
teor wrote:
Hi,
Cc'ing Linus, because he is also interested in IPv6.
On 28 Feb 2019, at 19:01, s7r <s7r@sky-ip.org <mailto:s7r@sky-ip.org>> wrote:
However, shouldn't the line: ORPort 9050
bind to all v4 and v6 available interfaces / IP addresses? If it does not, we should fix it to do so. As in:
ORPort 9050 - bind to all available v4 and v6 ORPort 0.0.0.0:9050 - bind to all available from the v4 class ORport [::]:9050 - bind to all available from the v6 class ORPort <explicit-address>:port - bind to specified address exactly
Tor already binds to IPv4 and IPv6 by default. But it only autodetects IPv4 addresses. (Binding to IPv6 doesn't really do much, if you don't have an IPv6 address to advertise.)
Oh I thought IPv6 needs to be stated explicitly or at least generally by omitting IPv4 at all even as the general 0.0.0.0. So ORPort 0.0.0.0:9001 would bind to all IPv4 and IPv6 available addresses on a server? The same would ORPort 9001 ?
I'd love to make Tor autodetect IPv6 addresses.
Here's what we need to do to make that happen: 1. make relays extend over IPv6 * these relays should declare a new protocol version "IPv6Relay=1" 2. make relays check their IPv6 ORPorts for reachability using an IPv6Relay * make relays connect to their own IPv6 ORPort (needs 1) * detect and track IPv4 and IPv6 ORPort reachability separately 3. make relays autodetect an IPv6 address (needs 2)
Here's the parent ticket for this change: https://trac.torproject.org/projects/tor/ticket/24403
Our next step is to write a proposal for this change. (There is already some code in some of the tickets.)
T
Sounds like a good plan. I'd love that too -- but the thing I am thinking now is how to address the temporary addresses that are used in operating systems (in some my default, in some not by default)? Those addresses change over time randomly, and maybe more often than a relay would find useful. Is there a flag or something that can make an application tell the difference between a temporary IPv6 address and a static one, for example?
On 1 Mar 2019, at 10:26, s7r <s7r@sky-ip.org> wrote:
teor wrote:
Cc'ing Linus, because he is also interested in IPv6.
On 28 Feb 2019, at 19:01, s7r <s7r@sky-ip.org <mailto:s7r@sky-ip.org>> wrote:
However, shouldn't the line: ORPort 9050
bind to all v4 and v6 available interfaces / IP addresses? If it does not, we should fix it to do so. As in:
ORPort 9050 - bind to all available v4 and v6 ORPort 0.0.0.0:9050 - bind to all available from the v4 class ORport [::]:9050 - bind to all available from the v6 class ORPort <explicit-address>:port - bind to specified address exactly
Tor already binds to IPv4 and IPv6 by default. But it only autodetects IPv4 addresses. (Binding to IPv6 doesn't really do much, if you don't have an IPv6 address to advertise.)
Oh I thought IPv6 needs to be stated explicitly or at least generally by omitting IPv4 at all even as the general 0.0.0.0.
So ORPort 0.0.0.0:9001 would bind to all IPv4 and IPv6 available addresses on a server?
No, 0.0.0.0 is an IPv4 address, so Tor only binds to IPv4. [::] is the equivalent IPv6 address, but that doesn't work for ORPorts, because Tor doesn't autodetect IPv6 addresses. (I think you can specify Address [IPv6], but I'm not sure if that works the way it should. We should fix it along with autodetection.)
The same would ORPort 9001 ?
Yes, a missing address means IPv4 and IPv6, if the OS supports it. (There are flags that turn off IPv4 or IPv6 binding, too.)
I'd love to make Tor autodetect IPv6 addresses.
Here's what we need to do to make that happen: 1. make relays extend over IPv6 * these relays should declare a new protocol version "IPv6Relay=1" 2. make relays check their IPv6 ORPorts for reachability using an IPv6Relay * make relays connect to their own IPv6 ORPort (needs 1) * detect and track IPv4 and IPv6 ORPort reachability separately 3. make relays autodetect an IPv6 address (needs 2)
Here's the parent ticket for this change: https://trac.torproject.org/projects/tor/ticket/24403
Our next step is to write a proposal for this change. (There is already some code in some of the tickets.)
Sounds like a good plan.
I'd love that too -- but the thing I am thinking now is how to address the temporary addresses that are used in operating systems (in some my default, in some not by default)? Those addresses change over time randomly, and maybe more often than a relay would find useful.
Is there a flag or something that can make an application tell the difference between a temporary IPv6 address and a static one, for example
If temporary addresses are allocated from temporary address ranges, Tor should ignore them. (Or we can teach it to ignore them.) If they are allocated from permanent address ranges, then the operator needs to tell Tor which address to use. It's just like IPv4. T
On Fri, 1 Mar 2019 11:54:31 +1000 teor <teor@riseup.net> wrote:
I'd love that too -- but the thing I am thinking now is how to address the temporary addresses that are used in operating systems (in some my default, in some not by default)? Those addresses change over time randomly, and maybe more often than a relay would find useful.
Is there a flag or something that can make an application tell the difference between a temporary IPv6 address and a static one, for example
If temporary addresses are allocated from temporary address ranges, Tor should ignore them. (Or we can teach it to ignore them.)
If they are allocated from permanent address ranges, then the operator needs to tell Tor which address to use.
There are no globally designated "temporary" or "permanent" address ranges. Temporary addresses are created by the OS in the same /64 subnet received from the upstream router as other IPs. See https://tools.ietf.org/html/rfc4941 (There are the ULA and Link-local ranges, but those are unrelated to the temporary/permanent question). -- With respect, Roman
Op 01/03/2019 om 10:20 schreef Roman Mamedov:
There are no globally designated "temporary" or "permanent" address ranges. Temporary addresses are created by the OS in the same /64 subnet received from the upstream router as other IPs. See https://tools.ietf.org/html/rfc4941 (There are the ULA and Link-local ranges, but those are unrelated to the temporary/permanent question).
Both Windows and Linux mark those addresses as temporary, and it seems to be possible to detect the difference when listing available interfaces. I guess the same is true for other operating systems. This would probably have to be done in platform specific code, I don't think there is a generic way to deal with this. So it probably won't be trivial to get it right 100% of the time.
participants (5)
-
AVee -
Roman Mamedov -
s7r -
technonerd＠fea.st -
teor