When starting a Tor Relay, Tor may use a disabled network adapter for IP information
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.
Trac:
Username: hantwister