[tor-bugs] #8786 [Tor]: Add extra-info line that tracks the number of consensus downloads of each pluggable transports

[Tor Bug Tracker & Wiki]

#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