[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #18460 [Tor]: Relays and bridges are not counting directory requests coming in via IPv6
#18460: Relays and bridges are not counting directory requests coming in via IPv6
-------------------------------------------------+-------------------------
Reporter: karsten | Owner:
Type: defect | Status:
Priority: Medium | needs_review
Component: Tor | Milestone: Tor:
Severity: Normal | 0.2.8.x-final
Keywords: tor-relay tor-bridge 026-backport | Version: Tor:
027-backport | 0.2.8.1-alpha
Parent ID: | Resolution:
Reviewer: | Actual Points:
| Points:
| Sponsor:
-------------------------------------------------+-------------------------
Comment (by karsten):
Okay, I took the painful route of renaming `address` and `addr` in
`connection_t` (to `ADDRESS` and `ADDR`) and looking for the compile
errors appearing from that. I also annotated all places where either of
the two fields are set or modified with a `/* XXX18460 */` comment. I'm
pushing my branch as
[https://gitweb.torproject.org/karsten/tor.git/log/?h=task-18460
-annotations-dont-merge task-18460-annotations-dont-merge to my public
repository], but please don't merge that anywhere.
I'm counting 16 functions where either or both of the two fields are set
or modified, however, I cannot rule out that I forgot some cases. But
let's use this as a start.
Let's go through these cases by filtering out all where `addr` is copied
from another `addr` using `tor_addr_copy()` and `address` is set to a
string representation of that same `addr` using `tor_dup_addr()`. That's
the ideal case in the context of this ticket where we could use either
`addr` or `address` and get the exact same result:
- connection_listener_new()
- connection_exit_connect_dir()
- directory_initiate_command_rend()
- evdns_server_callback()
- connection_ext_or_handle_cmd_useraddr()
Let's move on to the more complicated cases. One of them is where
`address` ''may'' be set to a const string like `"(Tor_internal)"` or
`"(rendezvous)"` rather than a string representation of `addr`. This
would make it impossible to use `address`, but we most likely don't care
about these addresses anyway:
- connection_ap_make_link()
- connection_exit_begin_conn()
- dnsserv_launch_request()
Let's look at the case that teor refers to above, which is where we're
parsing a `"Forwarded-For:"` HTTP header and writing the parsed address to
`address` but not to `addr`. This case makes it difficult to use `addr`
instead of `address`, because the former is not updated but only the
latter:
- http_set_address_origin()
That leaves us with 7 more places in the code where either `addr` or
`address` is set, which I didn't classify further and which I'm mostly
listing here in case somebody else wants to take a look:
- connection_handle_listener_read()
- connection_ap_handshake_send_resolve()
- connection_exit_begin_resolve()
- connection_or_init_conn_from_address()
- dns_resolve_impl()
- set_unix_port()
- rend_service_set_connection_addr_port()
My preliminary conclusion for this ticket is that we should stick to
`address` and extend the code towards also supporting string
representations of IPv6 addresses. I could imagine that we can simply use
`tor_addr_parse()` rather than `tor_inet_aton()` and
`tor_addr_from_ipv4h()` to convert the `address` to an `addr` which would
support both v4 and v6. I can write a patch and changes file for this and
test it in a local Chutney network. But I'd first like to hear whether
this makes sense at all. Thanks!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18460#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs