[tor-bugs] #2812 [- Select a component]: TorCtl Zombie Connections

[Tor Bug Tracker & Wiki]

#2812: TorCtl Zombie Connections
----------------------------------+-----------------------------------------
 Reporter:  atagar                |          Owner:     
     Type:  defect                |         Status:  new
 Priority:  normal                |      Milestone:     
Component:  - Select a component  |        Version:     
 Keywords:                        |         Parent:     
   Points:                        |   Actualpoints:     
----------------------------------+-----------------------------------------
 Hi, when TorCtl fails to authenticate it leaves a connection to the
 ControlPort. To repro...

 a. Start TBB with it configured to use cookie authentication. TBB uses
 relative paths for cookies so TorCtl is gonna fail to connect (separate
 issue, related to https://trac.torproject.org/projects/tor/ticket/1101).
 On a side note, arm has a somewhat platform specific workaround for this
 (no windows) if you're interested.

 b. Check initial connections. You'll see one for Vidalia.

 atagar at fenrir:~/Desktop/arm/src$ netstat -np | grep
 "127.0.0.1:9051.*ESTABLISHED 5267/tor"
 tcp        0      0 127.0.0.1:9051          127.0.0.1:36863
 ESTABLISHED 5267/tor

 c. Have TorCtl try (and fail) to connect a few times:

 >>> from TorCtl import TorCtl
 >>> TorCtl.connect()
 Failed to read authentication cookie (file doesn't exist):
 ./Data/Tor/control_auth_cookie
 >>> TorCtl.connect()
 Failed to read authentication cookie (file doesn't exist):
 ./Data/Tor/control_auth_cookie

 d. Check again with netstat. You'll see a new connection for each attempt
 you made:

 atagar at fenrir:~/Desktop/arm/src$ netstat -np | grep
 "127.0.0.1:9051.*ESTABLISHED 5267/tor"
 tcp        0      0 127.0.0.1:9051          127.0.0.1:45175
 ESTABLISHED 5267/tor
 tcp        0      0 127.0.0.1:9051          127.0.0.1:36863
 ESTABLISHED 5267/tor
 tcp        0      0 127.0.0.1:9051          127.0.0.1:45177
 ESTABLISHED 5267/tor

 Note that calling close on the connections or sockets is *not* sufficient
 (nor is most other things I've tried this last hour). The only thing I've
 found that does the trick is calling "s.shutdown(socket.SHUT_RDWR)" on the
 failed socket (see attached patch).

 Cheers! -Damian

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2812>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online