Opened 12 years ago

Closed 3 years ago

#659 closed defect (duplicate)

When configuring OR/Dir Ports, Tor always processes OR Port change first

Reported by: HANtwister Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay
Cc: HANtwister, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

I wasn't exactly sure how to phrase the subject, so feel free to rename it.

Basically, when you change the OR or Directory Port Settings in Vidalia, Tor
will always try to configure the OR Port first.

This creates a problem if the user tries to switch the OR Port and the Dir Port
(or just change the OR Port to the current Dir Port, and change the Dir Port to
anything else). In short, in such a scenario, Tor blocks itself.

For example:
Say a Tor Server was configured to use Dir Port 443 and OR Port 8080.
If the user tried to change it to use Dir Port 80 and OR Port 443, the following
error message would be presented:

[Warning] Could not bind to Address already in use [WSAEADDRINUSE ].
Is Tor already running?

This error message would be presented because Tor first closes the OR Port, 8080.
It then tries to open Port 443, but it is already using Port 443 as the Dir Port.

[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]

Child Tickets

Change History (7)

comment:1 Changed 12 years ago by HANtwister

Question: I'm not familiar with how Tor and Vidalia work together
(does Vidalia hand the settings over to Tor in bulk or one at a time?),
but should I be pointing this out here or on the Vidalia Bug Tracker?

comment:2 Changed 12 years ago by nickm

This is a Tor thing, and unfortunately it hasn't got a great and easy solution right now.

The problem isn't the order that Tor binds ports--the problem is that Tor always tries to bind the new ports
before it releases the old ones. (This is important to do, since if Tor frees ports before binding new ones, and
binding the new ones fails, Tor may not be able to return to a good state.) But sometimes, if tor already
_has_ the new port it needs, this makes tor fail to change its settings.

Probably the right solution is to have Tor not attempt to bind ports for listeners that it is already using for
other listeners, and instead just to use those listeners' sockets as-is.

Since the fix will be tricky and potentially destabilizing, and since there's an easy workaround in practice, I'm
going to mark this bug to get fixed in 0.2.1.x.

comment:3 Changed 10 years ago by nickm

Description: modified (diff)
Milestone: post 0.2.1.xTor: unspecified

Moving to the "unspecified" milestone. The real fix is a bit tricky. Here's our current behavior:

  1. For every listener that changed its port, open the new port.
  2. If they all succeeded, close the old sockets and assign the new sockets to the listeners.

Here is the complicated fix:

  1. Inventory all the ports we have.
  2. Figure out all the ports that we want and do not yet have
  3. Bind the ports that we want
  4. (assuming success) Assign every socket to the listener that it belongs to
  5. (assuming success) Close the sockets we aren't using any longer

Here is a more conservative "fix":

  1. When we get an EADDRINUSE, see whether we are already using the port for another listener. If so, tell the user that Tor doesn't support swapping ports around.

The fixes are made a bit more complicated because you can't do a simple equality check for "is this the same addr:port", since is special.

It would be cute to have a fix for this, but it's not hurting anybody now, and the workaround is pretty easy.

comment:4 Changed 10 years ago by nickm

See also #531: some transitions are just plain not doable in a reversible way.

comment:5 Changed 8 years ago by nickm

Keywords: tor-relay added

comment:6 Changed 8 years ago by nickm

Component: Tor RelayTor

comment:7 Changed 3 years ago by nickm

Cc: HANtwister,nickmHANtwister, nickm
Resolution: Noneduplicate
Severity: Normal
Status: newclosed

Closing this as duplicate of #531 .

Note: See TracTickets for help on using tickets.