Opened 5 months ago

Last modified 18 hours ago

#32888 needs_revision enhancement

Log address config info when tor starts up

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: 0.4.4.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, 043-deferred
Cc: Actual Points:
Parent ID: #5940 Points: 1
Reviewer: nickm Sponsor:

Description (last modified by teor)

We're going to be modifying tor's address detection and reachability code for an upcoming sponsor. To help us debug, we should log the following info when tor starts up:

IPv4:

  • the Address torrc option
    • and whether it is an IP address, or a DNS name
  • the local hostname
    • and whether it is an IP address, or a DNS name
  • the local network interface addresses

See resolve_my_address() for details.

IPv6:

  • the IPv6 address of the first IPv6 ORPort torrc option

See router_build_fresh_descriptor() and router_get_advertised_ipv6_or_ap() (in #32588) for details.

When (or if) we use them as part of address detection, we should also log the following info:

IPv4 and IPv6:

  • the Address torrc option
    • and whether it is an IP address, or a DNS name
  • the IPv4 and IPv6 addresses of the first ORPort torrc option of each address family
  • the local hostname
    • and whether it is an IP address, or a DNS name
  • the local network interface addresses

Notes:

  • We'll need a proposal to decide if ORPort or hostname should come first
  • We'll probably want a summary at notice level, and then detailed logs at info level
  • If all these methods fail, relays use X-Your-Address-Is: headers from directory authorities. They are out of scope, because they are not available at startup.
  • Similarly, we won't print address reachability self-testing info, because it's not available at startup.
  • We may want to print similar log messages (including X-Your-Address-Is: and reachability info) as part of tor's regular heartbeat messages. But that deserves a separate ticket.

I don't think we'll use (or log):

  • the addresses of any DirPort torrc options
  • the addresses of multiple ORPort torrc options

Child Tickets

Change History (14)

comment:1 Changed 5 months ago by teor

Description: modified (diff)

Edit description to add the relevant functions.

comment:2 Changed 5 months ago by teor

Owner: teor deleted
Parent ID: #24403

Let's prioritise this task when we roadmap the grant.

comment:3 Changed 4 months ago by gaba

Keywords: network-team-roadmap-? removed

comment:4 Changed 4 months ago by teor

Parent ID: #24403#5940

May be needed for #5940.

comment:5 Changed 4 months ago by nickm

Keywords: 043-deferred added

All 0.4.3.x tickets without 043-must, 043-should, or 043-can are about to be deferred.

comment:6 Changed 4 months ago by nickm

Milestone: Tor: 0.4.3.x-finalTor: unspecified

comment:7 Changed 3 months ago by teor

Status: assignednew

Change tickets that are assigned to nobody to "new".

comment:8 Changed 44 hours ago by c

I created a work-in-progress PR here: https://github.com/torproject/tor/pull/1910

So far I've addressed most of IPv4 logging requirements except logging "the local network interface addresses". I assume this logic is handled at get_interface_address6 which fetches a list of addresses returned by getifaddrs(3) and returns one address that can then be used by the caller. The issue here is, adding a log_debug() line inside of this function only seems to run through the loop when the code is built with -O0 optimisation, meaning this loop may get skipped entirely during runtime at higher optimisation levels.

My question is, for debugging purposes are we only worried about -O0 level, or is there a better place to put this debug logging, or something else entirely?

comment:9 Changed 44 hours ago by nickm

Milestone: Tor: unspecifiedTor: 0.4.4.x-final
Reviewer: nickm

comment:10 Changed 44 hours ago by nickm

So far this PR looks fine. I don't understand what you're saying about the -O0 issue, though. Could you show me the code where logging only gets called when building at -O0? It might be that you're seeing an inlining issue here, where the code still exists, but the function is no longer created.

comment:11 Changed 22 hours ago by c

Odd, so far I cannot reproduce either with make distclean && ./configure (no args to ./configure), or with ./configure CFLAGS='-g -Os'. I'll try with -O2 and -O3 but maybe I just made a mistake when building or stepping through the code, rather than it being optimisation's fault.

If it continues working at all optimisation levels then I will just commit the change. I just stuck a log_debug() statement inside get_interface_address6()'s loop, to print out each address it finds.

comment:12 Changed 21 hours ago by c

Seems to work. I cleaned up and pushed the interface address debug logging to the PR.

comment:13 Changed 18 hours ago by nickm

Status: newneeds_review

comment:14 Changed 18 hours ago by nickm

Status: needs_reviewneeds_revision

Looks good! I've added a small style note, and a place where there is a more convenient function you could use. You can fix them both in a fixup commit

Note: See TracTickets for help on using tickets.