Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#1827 closed defect (fixed)

binding a socket for to learn our interface address is freaking out users

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


People who use little snitch on OS X are being told that their Tor mysteriously sends udp packets to on startup.

This is false -- no packets are sent. grep for in src/common/address.c to learn what's going on.

But the number of reports from users is increasing. I imagine they think it looks like spyware behavior -- sekrit undocumented spyware behavior, too.

We should explore other ways to learn the user's interface address that don't trigger software like little snitch.

Child Tickets

Change History (13)

comment:1 Changed 9 years ago by nickm

Well, we could use the usual means to discover their DNS server, and if that's in a non-private network, open a testing UDP connection to that address. But that would be more error prone.

We could try changing the address to (say) and hope that looks less disturbing.

If we've opened any TCP sockets to public addresses at all, we could do a getsockname() on them rather than on a UDP socket. This might be our best bet. It would mean that we'd have to delay a little before coming up as a router if we needed to guess our address.

We could file a bug report against "little snitch" and see if they can't teach their software that connecting() a UDP socket doesn't actually send any traffic.

comment:2 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:3 Changed 8 years ago by nickm

Or we could just call getifaddrs() if it's present (GetAdaptersAddresses/GetAdaptersInfo on win32), and look for an interface with a non-private address.

comment:4 Changed 7 years ago by nickm

I started to throw together an implementation in branch "bug1827". It needs more review and attention, but first I should test whether the windows version even sorta compiles and works.

comment:5 Changed 7 years ago by nickm

Status: newneeds_review

Now it builds on windows. Needs more testing, and review.

One thing I'm concerned about is that interfaces can have link-local addresses and whatnot; I hope we catch all of those.

comment:6 Changed 7 years ago by nickm

Apparently for older/weirder unixes, I should support SIOCGIFCONF.

comment:7 in reply to:  6 Changed 7 years ago by nickm

Replying to nickm:

Apparently for older/weirder unixes, I should support SIOCGIFCONF.

And now that's implemented. Wow, what a bunch of crappy interfaces!

comment:8 Changed 7 years ago by nickm

I think this is suitable for merge, though I'd like a review first if anybody has time.

comment:9 Changed 7 years ago by Sebastian

Some small review points:

Maybe we should have unit tests for tor_addr_is_multicast()?

I think you forgot a close(fd) in the if (ioctl(fd, SIOCGIFCONF, &ifc) < 0) { case

For the "if (sa->sa_family != AF_INET && sa->sa_family != AF_INET6)": above you comment that AF_INET6 isn't supported here, maybe if we do see it we should warn?

please see branch bug1827 in my repo for a whitespace cleanup in and a fixup for documentation. Make sure that you didn't want to write more where I added a ".".

Didn't have more questions/spot more issues on a quick go.

comment:10 Changed 7 years ago by rransom

"ihplapi.dll" does not look right. Should that be "iphlpapi.dll" (which matches the name of the header file, for what little that's worth in Windows development)?

comment:11 Changed 7 years ago by rransom

I've pushed some fixups to my bug1827 branch. The Unixoid code looks good to me; I don't have Windows documentation handy.

comment:12 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Added a fixup from sebastian's comments (missing close(fd)). Squashing and merging the rest.

comment:13 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.