Opened 6 years ago

Closed 6 years ago

#9904 closed defect (fixed)

When starting a Tor Relay, Tor may use a disabled network adapter for IP information

Reported by: hantwister Owned by:
Priority: Low Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version: Tor: 0.2.3.25
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm running OS X 10.8.5 on a Late 2008 13-inch Aluminum MacBook. The computer has a private IP address on an ethernet adapter. When attempting to start a relay using the latest version of the Tor Browser Bundle (Vidalia 0.2.21, Tor 0.2.3.25 git-17c24b3118224d65), the following was continuously observed:

Oct 05 14:46:01.485 [Info] resolve_my_address(): Learned IP address '25.2.x.x' for local interface. Using that.

Oct 05 14:46:01.486 [Debug] resolve_my_address(): Resolved Address to '25.2.x.x'.

Oct 05 14:46:01.488 [Info] router_pick_published_address(): Success: chose address '25.2.x.x'.

When running ifconfig, the following was observed:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=27<RXCSUM,TXCSUM,VLAN_MTU,TSO4>
	ether 00:23:32:x:x:x 
	media: autoselect
	status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 00:23:12:x:x:x 
	inet6 fe80::x:x:x:x%en1 prefixlen 64 scopeid 0x5 
	inet 192.168.x.x netmask 0xffffff00 broadcast 192.168.x.255
	media: autoselect
	status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
	ether 02:23:12:x:x:x 
	media: autoselect
	status: inactive
ham0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1404
	ether 7a:79:19:x:x:x 
	inet 25.2.x.x netmask 0xff000000 broadcast 25.255.255.255
	inet6 fe80::x:x:x:x%ham0 prefixlen 64 scopeid 0x7 
	inet6 2620:9b::x:x prefixlen 96 
	open (pid 88)

Based on the source code of get_interface_address6, it appears that Tor first looks for an interface with an IP address that is not a loopback, is not a multicast and is not an internal address. Because the connected ethernet adapter has an internal address, Tor skips over it, and the checks appear to succeed for the ham0 device. The ham0 device is actually a virtual device provided by LogMeIn Hamachi.

In an attempt to remedy this, I stopped and quit Hamachi, and then used ifconfig to take the virtual network adapter down. In spite of this, Tor continued to produce log messages similar to those listed above, and continued to try to use the IP of the disabled virtual network adapter.

Reviewing the source code for get_interface_addresses_raw, it appears that Tor only checks if a device's network family is IPv4 or IPv6. Adding a check to verify that the interface is up and running appears to fix the problem for me (patch attached), but I imagine such a change should be tested on a variety of *nix boxes.

Child Tickets

Attachments (1)

tor-check-if-up.patch (447 bytes) - added by hantwister 6 years ago.
Simple patch to check if a network adapter is up

Download all attachments as: .zip

Change History (3)

Changed 6 years ago by hantwister

Attachment: tor-check-if-up.patch added

Simple patch to check if a network adapter is up

comment:1 Changed 6 years ago by nickm

Keywords: tor-relay added
Milestone: Tor: 0.2.4.x-final
Status: newneeds_review

At first glance, this looks okay to me. I'm tentatively marking it for inclusion in 0.2.4.x since it seems Clearly Right. Anybody see a reason to defer it to 0.2.5.x instead?

comment:2 Changed 6 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

I've merged it into 0.2.4, crediting it to "hantwister" in the changelog. Please let me know if there's some other name you'd prefer me to list.

Either way, thanks for the patch!

Note: See TracTickets for help on using tickets.