Opened 8 years ago

Closed 4 years ago

Last modified 3 years ago

#4636 closed enhancement (worksforme)

Add GETINFO interface_address

Reported by: krkhan Owned by: krkhan
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: maybe-proposal easy tor-client small-feature controller
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

get_interface_address6() in src/common/address.c finds out the IP address of the internet-facing interface. This can be useful to controllers like arm which can use the IP address for setting up port-forwarding.

Child Tickets

Change History (19)

comment:1 Changed 8 years ago by rransom

From src/common/address.c:

/** Set *<b>addr</b> to the IP address (if any) of whatever interface
 * connects to the Internet.  This address should only be used in checking
 * whether our address has changed.  Return 0 on success, -1 on failure.
 */
int
get_interface_address6(int severity, sa_family_t family, tor_addr_t *addr)

I'm not exposing this function to the control port if its result ‘should only be used in checking whether our address has changed’.

comment:2 Changed 8 years ago by krkhan

Resolution: wontfix
Status: newclosed

I re-did the get_interface_address6() part in arm so it sounds okay if it's not exposed. Vidalia doesn't need it right now anyway (it relies on miniupnp for port-forwarding).

comment:3 Changed 8 years ago by rransom

Milestone: Tor: 0.2.3.x-final
Resolution: wontfix
Status: closedreopened

Tor appears to use the result of get_interface_address6 for purposes other than ‘checking whether our address has changed’, so the documentation comment may be wrong. Also:

  • If the point of this GETINFO item is to let controllers know what Tor currently thinks its address is, we should expose that piece of information to the control port. (That would be even harder for controllers to figure out on their own than what the current implementation of get_interface_address6 would return.)
  • Once nickm's bug1827 branch is merged, we will have OS-specific methods of finding lists of network interface addresses. Exposing all of those might be useful to a controller.
  • If the goal is to help controllers set up port forwarding for Tor, perhaps we should expose whatever information Tor passes to tor-fw-helper to the control port.
  • Do GETINFO net/listeners/or and GETINFO net/listeners/dir help here?

comment:4 in reply to:  3 Changed 8 years ago by Sebastian

Replying to rransom:

Tor appears to use the result of get_interface_address6 for purposes other than ‘checking whether our address has changed’, so the documentation comment may be wrong. Also:

  • If the point of this GETINFO item is to let controllers know what Tor currently thinks its address is, we should expose that piece of information to the control port. (That would be even harder for controllers to figure out on their own than what the current implementation of get_interface_address6 would return.)

I think rather that this is a bug in how we use the function currently, it was never intended for something that it later got used for.

comment:5 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

Looks like this did not get an implementation in time for feature-freeze. It's worth doing this in 0.2.4.x

comment:6 Changed 7 years ago by nickm

Keywords: maybe-proposal easy added

comment:7 Changed 7 years ago by nickm

Keywords: tor-client added

comment:8 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:9 Changed 7 years ago by nickm

Keywords: small-feature added

comment:10 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

comment:11 Changed 6 years ago by rl1987

Tor already responds to GETINFO address, which outputs address retrieved from router_pick_published_address(), but this may not be an IP address of network interface used by Tor instance if it is running behind NAT.

Should GETINFO address/ipv4 and GETINFO address/ipv6 return address from get_interface_address6() with family parameter being AF_INET and AF_INET6 respectively? Should we leave implementation of GETINFO address as-is, in order to leave opportunity to retrieve published (guessed?) address available to controller?

comment:12 Changed 6 years ago by nickm

I think that depends on what the actual use case is. Vidalia/arm/other controller people, what do you need here?

comment:13 Changed 6 years ago by atagar

Vidalia/arm/other controller people, what do you need here?

If you're asking how this ticket originated, krkhan was working on a UPnP feature for arm years back. It was never very reliable and as such wasn't merged. Besides that I don't have any context regarding this ticket.

comment:14 Changed 6 years ago by rl1987

Does this need to be implemented for Tor 0.2.5.x?

comment:15 Changed 6 years ago by rl1987

Keywords: controller added

comment:16 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:17 Changed 4 years ago by nickm

Resolution: worksforme
Status: reopenedclosed

Without more info on what this is actually supposed to be used for, I don't think it makes sense to plan work on it.

comment:18 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:19 Changed 3 years ago by nickm

Milestone: Tor: 0.3.???

Milestone deleted

Note: See TracTickets for help on using tickets.