Fix IPv6 bridges with a private/dynamic IPv4 address
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.)
Activity
changed milestone to %Tor: unspecified
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
Trac:
Parent: N/A to #3563 (moved)Trac:
Parent: #3563 (moved) to #5788 (moved)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:
-
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())
-
a relay doesn't realize when its IPv6 OR port changes (see retry_all_listeners())
-
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 (moved) and #6027 (moved) respectively.
Trac:
Status: new to assigned-
Trac:
Parent: #5788 (moved) to #17811 (moved)
Sponsor: N/A to N/A
Severity: N/A to NormalTrac:
Parent: #17811 (moved) to #5788 (moved)#17840 (moved) 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 (moved) uses !server_mode() to find clients. We should update that to !public_server_mode() when we want bridge relays to work on IPv6.)
