Opened 6 years ago

Last modified 4 months ago

#5298 new defect

Relay does not pick the right IP addr of local node when multiple interfaces are available

Reported by: ciaccio Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.3.25
Severity: Normal Keywords: tor-relay, ipv6, reachability, 034-triage-20180328, 034-removed-20180328
Cc: vitrom@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

My laptop has two network interfaces: eth0, statically configured, in use when I'm wired in my office; and ppp0, dynamically configured, when I'm abroad and use a 3G wireless interface.

When I'm on eth0 (LAN), the tor relay works regularly.
When I'm on the ppp0 (3G wireless), the tor relay works too but the ORPort and DirPort are not reachable from the outside, because the relay still picks the IP address associated to eth0 instead of ppp0.

This problem affects both on the stable release (0.2.2.35) and the latest git snapshot (and probably many other releases).

With the stable release, I've tracked the bug down to
src/or/config.c:resolve_my_address(), a rather messy piece of code which mistakenly resolves via hostname rather than picking the IP address based on the actual route default. I had to rewrite that function almost from scratch, and now it works.

With the latest snapshot, same problem in
src/or/config.c:resolve_my_address(), plus another issue in
src/common/address.c:get_interface_address6(): here a list of all net devices available is built, but then the first valid one is picked, regardless of it being the one in use or not (on my laptop it always chooses eth0). Solved by disabling the list of net devices, thus falling back to the default "discovery" mechanism (the only one implemented in the stable release).

I have patches, if needed.

Child Tickets

TicketStatusOwnerSummaryComponent
#7773closedandreaRelay does not pick the right IP addr of local nodeCore Tor/Tor

Attachments (2)

diff1 (5.6 KB) - added by ciaccio 6 years ago.
patch for tor stable
diff2 (6.0 KB) - added by ciaccio 6 years ago.
patches for tor git snapshot

Download all attachments as: .zip

Change History (34)

comment:1 Changed 6 years ago by nickm

Yes, please submit your patch.

Changed 6 years ago by ciaccio

Attachment: diff1 added

patch for tor stable

Changed 6 years ago by ciaccio

Attachment: diff2 added

patches for tor git snapshot

comment:2 in reply to:  1 ; Changed 6 years ago by ciaccio

Replying to nickm:

Yes, please submit your patch.

patches now attached.

comment:3 in reply to:  2 Changed 6 years ago by ciaccio

Replying to ciaccio:

Replying to nickm:

Yes, please submit your patch.

patches now attached.

still no answer after 9 days or so...

comment:4 Changed 6 years ago by nickm

Sorry; stuff is insanely busy around here.

I'm trying to understand the actual functional change in config.c right now -- looking at it, I think I can see how it might help with your situation, but I haven't yet been able to convince myself that it doesn't somehow break some other category of usage. If you can maybe explain what the functional change is supposed to be, that could help me figure it out.

comment:5 in reply to:  4 ; Changed 6 years ago by ciaccio

Replying to nickm:

I'm trying to understand the actual functional change in config.c right now -- looking at it, I think I can see how it might help with your situation, but I haven't yet been able to convince myself that it doesn't somehow break some other category of usage. If you can maybe explain what the functional change is supposed to be, that could help me figure it out.

The proposed new version of resolve_my_address() should only differ in the way it "guesses" the local IP address when nothing is given as options->Address.

But, during debug, I preferred to rearrange the entire routine because the original one was a mess IMHO -- it probably suffered from too many consecutive ad-hoc bug fixes.

When guessing local IP address, the old resolve_my_address() routine tries by first inferring the local hostname (e.g. from /etc/hostname I think) and resolving that; on failure, it guesses from network interfaces directly. This is OK when the host is a server with a fixed public IP address, but not for, say, a laptop with a dynamic IP address, where the local hostname might not correspond to anything at all; or, a laptop with both a eth0 and a ppp0, where the hostname is always bound to the eth0 IP address even when ppp0 is actually in use (this happens when I unplug my laptop from the office LAN and move to home, for instance). The new resolve_my_address() always guesses the local IP address from network interfaces directly; so it always picks the one which is currently in use.

comment:6 in reply to:  5 Changed 6 years ago by ciaccio

Replying to ciaccio:

Replying to nickm:

I'm trying to understand the actual functional change in config.c right now -- looking at it, I think I can see how it might help with your situation, but I haven't yet been able to convince myself that it doesn't somehow break some other category of usage. If you can maybe explain what the functional change is supposed to be, that could help me figure it out.

The proposed new version of resolve_my_address() should only differ in the way it "guesses" the local IP address when nothing is given as options->Address.

But, during debug, I preferred to rearrange the entire routine because the original one was a mess IMHO -- it probably suffered from too many consecutive ad-hoc bug fixes.

When guessing local IP address, the old resolve_my_address() routine tries by first inferring the local hostname (e.g. from /etc/hostname I think) and resolving that; on failure, it guesses from network interfaces directly. This is OK when the host is a server with a fixed public IP address, but not for, say, a laptop with a dynamic IP address, where the local hostname might not correspond to anything at all; or, a laptop with both a eth0 and a ppp0, where the hostname is always bound to the eth0 IP address even when ppp0 is actually in use (this happens when I unplug my laptop from the office LAN and move to home, for instance). The new resolve_my_address() always guesses the local IP address from network interfaces directly; so it always picks the one which is currently in use.

...still no answer after 5 weeks or so... :-(

comment:7 Changed 6 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:8 Changed 6 years ago by nickm

Status: newneeds_review

comment:9 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:10 Changed 6 years ago by nickm

Component: Tor RelayTor

comment:11 Changed 5 years ago by nickm

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

comment:12 Changed 5 years ago by nickm

Keywords: 024-deferrable added
Owner: set to andrea
Status: needs_reviewassigned

comment:13 Changed 5 years ago by nickm

Closed #7773 as a duplicate of this; it may have implementation this one doesn't, though.

comment:14 Changed 5 years ago by VitRom

Cc: vitrom@… added
Keywords: multihomed ppp0 3G tor-relay 024-deferrablemultihomed, ppp0 3G tor-relay 024-deferrable
Milestone: Tor: 0.2.4.x-final
Version: Tor: 0.2.3.12-alphaTor: 0.2.3.25

I have the similar problems too.

Not sure is it Tor-only or Vidalia Bundle.

My config is VERY generic:

  • Relay bundle release, Vidalia 0.2.21 + Tor 0.2.3.25(git-17c24b3118224d65).
  • Win-XP + WiFi or LAN as a main iface + a few more ifaces for VPN.
  • Network with DHCP goes from home-class ADSL router with NAT and UPnP.

Mine VPN is Hamachi and their iface still in "connected" state all the time.
But all transports/ifaces bindings are in the right order: physical first then virtual.

Almost any network app works fine and able to open ports via UPnP and receive incoming connections. Except Top/Vidalia.

A Tor log shows that everytime due a strange logic (dumb number comparison? OMG!) Tor chooses Hamachi iface (25.x.x.x) instead of mine WiFi (192.x.x.x). Regardless of WiFi goes first in the binding stack. As a result Tor claims about directory port not accessible outside etc. But because of DHCP addressing I can't bind Tor to a some static IP (and moreover this IP is in private range anyway).

PS.
IMO an acceptable and quick enough fix looks like an ability to assign *network* for autodetect current address (192.x.x.0) instead of *address* itself.

comment:15 Changed 5 years ago by nickm

Milestone: Tor: 0.2.4.x-final

comment:16 Changed 5 years ago by nickm

Keywords: multihomed, ppp0 3G tor-relay 024-deferrablemultihomed ppp0 3G tor-relay 024-deferrable

comment:17 Changed 5 years ago by nickm

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

comment:18 Changed 4 years ago by nickm

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

This is going to need a serious redesign.

comment:19 Changed 4 years ago by ciaccio

Fortunately I'm able to patch it on my own. It's a pity, that you don't want to consider a possible contribution on solving this.

comment:20 Changed 4 years ago by nickm

Sorry, but I already answered above: it changes the behavior in a way that will make some previously broken installations work, and some previously working installations break. I don't think it's a good idea to change the default behavior unless it's a strict improvement with well-specified behavior.

comment:21 Changed 4 years ago by ciaccio

If you can tell what working installations would break, I might attempt to provide a patch that works in that case too. The current default behaviour is wrong for sure, although it happens to work fine when the node has only one network interface.

comment:22 Changed 21 months ago by teor

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

Milestone renamed

comment:23 Changed 20 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:24 Changed 15 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:25 Changed 15 months ago by nickm

Keywords: 024-deferrable removed

comment:26 Changed 15 months ago by nickm

Keywords: ip-detection added
Severity: Normal
Status: assignedneeds_review

comment:27 Changed 6 months ago by dgoulet

Status: needs_reviewnew

comment:28 Changed 6 months ago by dgoulet

Owner: andrea deleted
Status: newassigned

comment:29 Changed 6 months ago by teor

Keywords: ipv6 reachability added; multihomed ppp0 3G ip-detection removed
Milestone: Tor: unspecifiedTor: 0.3.4.x-final
Status: assignednew
Summary: Relay does not pick the right IP addr of local nodeRelay does not pick the right IP addr of local node when multiple interfaces are available

I don't think this bug can happen in modern versions of Tor:

  • when Tor is configured with only a port, it binds to all local interfaces. It does not guess a local interface.
  • when Tor guesses an external IPv4 address to advertise, it guesses based on the external IP address discovered from a remote relay's response.

That said, bugs like it still exist: it is possible for tor to guess an unreachable address.

We might fix this as part of #24403, by trying to reach multiple addresses until one works. (We would also need to re-check reachability every hour, rather than just checking once.) Multiple reachability checks are important for IPv6 reachability, because there are likely to be more IPv6 addresses available on local interfaces than IPv4 addresses.

comment:30 Changed 5 months ago by nickm

Keywords: 034-triage-20180328 added

comment:31 Changed 5 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:32 Changed 4 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Note: See TracTickets for help on using tickets.