[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #8786 [Tor]: Add extra-info line that tracks the number of consensus downloads of each pluggable transports
#8786: Add extra-info line that tracks the number of consensus downloads of each
pluggable transports
-------------------------------------------------+-------------------------
Reporter: asn | Owner:
Type: enhancement | Status:
Priority: Low | needs_revision
Component: Tor | Milestone: Tor:
Severity: Normal | 0.2.8.x-final
Keywords: pt, tor-bridge, flashproxy, | Version:
026-triaged-1, 026-deferrable, | Resolution:
027-triaged-1-out | Actual Points:
Parent ID: | Points:
Sponsor: |
-------------------------------------------------+-------------------------
Changes (by karsten):
* status: needs_review => needs_revision
Comment:
Quick update: asn was so kind to run this branch on LeifEricson, one of
the bridges shipped with Tor Browser. After 24 hours that bridge reported
the following lines:
{{{
dirreq-v3-transport <OR>=28872
dirreq-v3-version v4=28872
[...]
bridge-ip-versions v4=31040,v6=0
bridge-ip-transports <OR>=8,obfs3=22072,obfs4=8280,scramblesuit=688
}}}
Obviously, all directory requests are being attributed to <OR> connections
and coming in via IPv4. While the latter is at least plausible, the
former is clearly wrong. This is caused by passing `NULL` as third
parameter to `geoip_note_client_seen` in the following part of
`directory.c`:
{{{
if (1) {
struct in_addr in;
tor_addr_t addr;
if (tor_inet_aton((TO_CONN(conn))->address, &in)) {
tor_addr_from_ipv4h(&addr, ntohl(in.s_addr));
geoip_note_client_seen(GEOIP_CLIENT_NETWORKSTATUS,
&addr, NULL,
time(NULL));
}}}
I'm not sure yet how we can learn the transport name at this point. IIRC,
`conn` is a `dir_connection_t`, but in case of tunneled directory requests
there are also an `edge_connection_t` and an `or_connection_t` involved.
And in order to learn the transport, we'll have to check the `channel_t`
to invoke its `get_transport_name` function.
Here's a wild idea: we use `conn->dirreq_id` to find the `circuit_t` in
`circuit_get_globel_list()` with matching `dirreq_id`, and then we can
learn the transport via `TO_OR_CIRCUIT(circ)->p_chan`. Totally untested,
of course.
Speaking of tunneled vs. direct directory requests, there's also the
possibility that a directory request is made to the DirPort, and in that
case we couldn't say it's using transport `<OR>`. Maybe we'll have to
introduce a new transport `<DIR>` to count those directory requests in
`dirreq-v3-transport`. I don't expect there to be many such requests, but
if it's easy to be correct here, let's try that.
Regarding `dirreq-v3-version`, when looking at the code above it's unclear
whether the distinction between IPv4 and IPv6 actually works. Without
testing, I'd say that we should try passing `(TO_CONN(conn))->address` to
`geoip_note_client_seen` rather than messing with it first.
All the above is a mix of note-to-self and request-for-help. If something
of the above seems obviously wrong or right to somebody here, please do
let me know. Otherwise, I'll hack on this in a few days.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8786#comment:13>
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