Opened 5 years ago

Last modified 3 weeks ago

#4847 assigned defect

Bridges binding only to an IPv6 address doesn't work

Reported by: ln5 Owned by: ln5
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.3.10-alpha
Severity: Normal Keywords: ipv6, tor-bridge
Cc: Actual Points:
Parent ID: #5788 Points:
Reviewer: Sponsor:

Description

A bridge not listening to an IPv4 address looks OK (bootstraps 100%) but leaves the client hanging at 50%.

Workaround: Specify an ORPort on an IPv4 address in addition to the IPv6 address.

An idea is that it's related to the self testing that the bridge is
supposed to perform. (Setting AssumeReachable 1 hasn't changed
anything in my tests though.)

Child Tickets

Change History (17)

comment:1 Changed 5 years ago by nickm

Interesting. 50% is what... downloading descriptors? Is there anything in the client logs to try to figure out what it's trying to do that's failing?

comment:2 Changed 5 years ago by ln5

  • Parent ID set to #3563

The 404 on fetching /tor/server/authority.z?

Jan 11 19:46:13.000 [notice] Bootstrapped 50%: Loading relay descriptors.
Jan 11 19:46:13.000 [info] connection_edge_process_relay_cell(): -1: end cell (closed normally) for stream 17555. Removing stream.
Jan 11 19:46:13.000 [info] _connection_free(): Freeing linked Socks connection [open] with 0 bytes on inbuf, 0 on outbuf.
Jan 11 19:46:13.000 [info] connection_dir_client_reached_eof(): Received server info (size 0) from server ':::4701'
Jan 11 19:46:13.000 [info] connection_dir_client_reached_eof(): Received http status code 404 ("Not found") from server ':::4701' while fetching "/tor/server/authority.z". I'll try again soon.
Jan 11 19:46:13.000 [info] _connection_free(): Freeing linked Directory connection [client finished] with 0 bytes on inbuf, 0 on outbuf.
Jan 11 19:46:24.000 [info] smartlist_choose_node_by_bandwidth_weights(): Empty routerlist passed in to consensus weight node selection for rule weight as guard
Jan 11 19:46:24.000 [info] smartlist_choose_node_by_bandwidth(): Empty routerlist passed in to old node selection for rule weight as guard

comment:3 Changed 5 years ago by ln5

  • Parent ID changed from #3563 to #5788

comment:4 Changed 5 years ago by nickm

  • Milestone set to Tor: 0.2.3.x-final

comment:5 Changed 5 years ago by ln5

  • Status changed from new to assigned

A bridge without an IPv4 OR port returns 404 when asked for
"/tor/server/authority.z" because it doesn't have a descriptor for
itself (router.c:desc_routerinfo is NULL).

This is because router_get_advertised_or_port() uses
get_primary_or_port() which looks for IPv4 ports only which has other
implications as well:

  1. a relay without an IPv4 OR port doesn't have a descriptor for itself (the root cause of this bug, see router_rebuild_descriptor()) and doesn't consider itself publishable and won't upload its descriptor (see decide_if_publishable_server())
  1. a relay doesn't realize when its IPv6 OR port changes (see retry_all_listeners())
  1. directory authorities on IPv6 don't work well (see init_keys() and dirserv_generate_networkstatus_vote_obj())

I think that we should start by fixing the places where we ask "what's
_the_ OR port?" when what we really want to know is "do we have an OR
port?". This should be a good start at fixing point 1 above. The
question about what to put in the "router" line for a relay without an
IPv4 OR port arises. Proposal 186 suggests listing a magic IPv4
address (127.1.1.1) and flag such relays with a new flag indicating
that they're running but not on the address listed in the "r" line.
We might want to do this sooner than anticipated for supporting relays
without an IPv4 OR port.

Points 2 and 3 are addressed in #6026 and #6027 respectively.

comment:6 Changed 5 years ago by nickm

  • Milestone changed from Tor: 0.2.3.x-final to Tor: 0.2.4.x-final

Worthwhile, but there's a workaround, so I'm going to say "postpone for 0.2.4.x." I want to get 0.2.3.x out the door.

If anyone feels strongly, I'd take a patch to warn the user if they try to do this in 0.2.3.x

comment:7 Changed 5 years ago by nickm

  • Keywords tor-bridge added

comment:8 Changed 5 years ago by nickm

  • Component changed from Tor Bridge to Tor

comment:9 Changed 4 years ago by nickm

  • Milestone changed from Tor: 0.2.4.x-final to Tor: 0.2.5.x-final

comment:10 Changed 3 years ago by nickm

  • Milestone changed from Tor: 0.2.5.x-final to Tor: 0.2.???

comment:11 Changed 19 months ago by teor

  • Parent ID changed from #5788 to #17811
  • Severity set to Normal

comment:12 Changed 19 months ago by teor

  • Parent ID changed from #17811 to #5788

comment:13 Changed 19 months ago by teor

#17840 might make this easier by making sure that client bootstrap works on IPv6-only hosts. But the descriptor issues still remain. (And the code in #17840 uses !server_mode() to find clients. We should update that to !public_server_mode() when we want bridge relays to work on IPv6.)

comment:14 Changed 8 months ago by teor

  • Milestone changed from Tor: 0.2.??? to Tor: 0.3.???

Milestone renamed

comment:15 Changed 6 months ago by nickm

  • Keywords tor-03-unspecified-201612 added
  • Milestone changed from Tor: 0.3.??? to Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:16 Changed 5 weeks ago by nickm

  • Keywords tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:17 Changed 3 weeks ago by arma

I think if you set AssumeReachable 1 then your bridge will proceed as intended?

Note: See TracTickets for help on using tickets.