Opened 8 months ago

Closed 7 months ago

#20996 closed defect (fixed)

IPv6-only client fails to bootstrap on microdescriptor fetch/fallback

Reported by: mtigas Owned by:
Priority: High Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor Version: Tor: 0.2.8.5-rc
Severity: Normal Keywords: ipv6, fallback, review-group-14
Cc: teor Actual Points:
Parent ID: Points: 0.5
Reviewer: nickm Sponsor:

Description

For a fresh client (nothing cached) when configured with "ClientUseIPv4 0" + "ClientUseIPv6 1" (and client is also on a network with no external IPv4 address).

Hangs at 45%, Asking for relay descriptors. Running on 0.2.9.7-rc.

Works fine with UseMicrodescriptors 0. ("ClientPreferIPv6DirPort 1" + "ClientPreferIPv6ORPort 1" have no affect.)

Attaching torrc and a log @ loglevel info.

CCing teor here since I vaguely remember having a conversation with him at last tor meeting where I believe he mentioned to try using "UseMicrodescriptors 0"; which (now that I've had a chance to test) seems like a good workaround at the moment.

Can't seem to find another ticket for this exactly, and just wanted something to refer to (and post some logs and info on), so please excuse if it’s actually a dupe. Possibly related: #20916.

On the mobile side, Apple’s starting to require that apps work in IPv6-only networks. And I’ve noticed that I’ve recently been assigned IPv6/NAT64 (with no external IPv4 address) on T-Mobile lately. But of course this also affects non-mobile IPv6-only networks.

(On the other hand, I'm quite happy that this all _does_ work under IPv6 with the "UseMicrodescriptors 0" workaround.)

Child Tickets

TicketStatusOwnerSummaryComponent
#19608closedIPv6-only clients can't fetch microdescriptors on 0.2.8.5-rcCore Tor/Tor
#20999closedMake IP6-using clients try harder to find an IPv6 directory serverCore Tor/Tor

Attachments (2)

torrc (724 bytes) - added by mtigas 8 months ago.
tor-info.log (110.2 KB) - added by mtigas 8 months ago.

Download all attachments as: .zip

Change History (16)

Changed 8 months ago by mtigas

Attachment: torrc added

Changed 8 months ago by mtigas

Attachment: tor-info.log added

comment:1 Changed 8 months ago by teor

Keywords: fallback added
Milestone: Tor: 0.3.0.x-final
Points: 0.5
Status: newneeds_review
Version: Tor: 0.2.9.7-rcTor: 0.2.8.5-rc

Thanks mtigas!
The previous bug is #19608, where I tried to fix it this issue in 0.2.8.

Please see my branch ipv6-only-client, which fixes this issue.
Would you like to test it?

I tested it with the chutney IPv6-only networks hs-ipv6, single-onion-ipv6, and client-ipv6-only, with Use Microdescriptors turned on (the default). These work on any machine with IPv6 localhost.

I also tested it using the command-line:

src/or/tor ClientUseIPv4 0 DataDirectory `mktemp -d`

This only works on an IPv6-capable machine.

We can add a test for this issue to chutney once #21000 is done, that work is tracked in #21001.

comment:2 Changed 8 months ago by nickm

Priority: MediumHigh

comment:3 Changed 8 months ago by mtigas

@teor

Yep! After a quick test, seems like your branch <https://github.com/teor2345/tor/tree/ipv6-only-client> seems to work perfectly under T-Mobile’s IPv6/NAT64-only network conditions. Just had to set "ClientUseIPv4 0" + "ClientUseIPv6 1"; didn’t need to touch "UseMicrodescriptors" at all.

comment:4 in reply to:  3 Changed 8 months ago by teor

Replying to mtigas:

@teor

Yep! After a quick test, seems like your branch <https://github.com/teor2345/tor/tree/ipv6-only-client> seems to work perfectly under T-Mobile’s IPv6/NAT64-only network conditions. Just had to set "ClientUseIPv4 0" + "ClientUseIPv6 1"; didn’t need to touch "UseMicrodescriptors" at all.

@mtigas,

It should work with just ClientUseIPv4 0 (tor assumes that if you turn off IPv4, you want IPv6).

I also wonder if it works with just ClientPreferIPv6ORPort 1, I think it should, but if it doesn't, we should open a separate ticket for that.

comment:5 Changed 8 months ago by teor

(I just opened #21043 as a follow-up to make various ReachableAddresses settings equivalent to ClientUseIPv4 / ClientUseIPv6.)

comment:6 Changed 8 months ago by nickm

Keywords: review-group-14 added

comment:7 Changed 8 months ago by nickm

This looks plausible to me. I have a question, though: why are we changing the semantics of ClientPreferIPv6*Port in 2e2d22d29a18 ? I don't see how that is needed for this ticket. The commit says "Required for #19608.", but #19608 is already marked as fixed. So, I'm confused.

comment:8 in reply to:  7 Changed 8 months ago by teor

Replying to nickm:

This looks plausible to me. I have a question, though: why are we changing the semantics of ClientPreferIPv6*Port in 2e2d22d29a18 ? I don't see how that is needed for this ticket. The commit says "Required for #19608.", but #19608 is already marked as fixed. So, I'm confused.

#19608 was closed as a duplicate of this issue (there was more information in this issue): I've reopened it and made it a child of this issue instead.

comment:9 Changed 7 months ago by nickm

Reviewer: nickm

comment:10 Changed 7 months ago by nickm

I still don't understand this part:

I have a question, though: why are we changing the semantics of ClientPreferIPv6*Port ...?

That is, _why_ are we making it so "PreferIPv6" implies "UseIPv6"?

And should we make corresponding changes in the manpage and in the note the change in the changes file?

comment:11 in reply to:  10 Changed 7 months ago by teor

Replying to nickm:

I still don't understand this part:

I have a question, though: why are we changing the semantics of ClientPreferIPv6*Port ...?

That is, _why_ are we making it so "PreferIPv6" implies "UseIPv6"?

Because otherwise, we won't actually look for IPv6 directory servers, even if IPv6 is preferred.

And should we make corresponding changes in the manpage and in the note the change in the changes file?

The manual page doesn't need a change: it already implies that setting ClientPreferIPv6ORPort means we might actually use IPv6.

The corresponding changes file entry is:

    - Make IP6-using clients try harder to find an IPv6 directory server.
      Fixes bug 20999; bugfix on 77a9de0 from 17840 in 0.2.8.2-alpha.

comment:12 Changed 7 months ago by nickm

Ah. Oh!

Squashed and merging.

comment:13 Changed 7 months ago by nickm

(please close and/or unparent child-tickets as appropriate?)

comment:14 Changed 7 months ago by teor

Resolution: fixed
Status: needs_reviewclosed
Note: See TracTickets for help on using tickets.