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