[tor-bugs] #13885 [- Select a component]: AllowDotExit strange behavior

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Dec 3 05:20:11 UTC 2014


#13885: AllowDotExit strange behavior
----------------------------------+---------------------
 Reporter:  nixscripter           |          Owner:
     Type:  defect                |         Status:  new
 Priority:  normal                |      Milestone:
Component:  - Select a component  |        Version:
 Keywords:                        |  Actual Points:
Parent ID:                        |         Points:
----------------------------------+---------------------
 When I upgraded from tor 0.2.2 (I know, it's old) to the current 0.2.5,
 the behavior of AllowDotExit changed. I use this feature in order to
 create stable passive FTP connections to servers, and it doesn't work
 anymore.

 I turned on stream debugging in the console, and this is what I see when I
 try to connect to a an ArchLinux FTP mirror by specifying an exit node
 (whose policy I did check):

 650 STREAM 35 NEWRESOLVE 0 ftp.sjtu.edu.cn.kramse.exit:34303
 PURPOSE=DNS_REQUEST
 650 STREAM 35 NEW 18 ftp.sjtu.edu.cn.kramse.exit:34303
 SOURCE_ADDR=(Tor_internal):49683 PURPOSE=DNS_REQUEST
 650 STREAM 35 SENTRESOLVE 18 ftp.sjtu.edu.cn.kramse.exit:34303
 650 STREAM 35 SUCCEEDED 18 ftp.sjtu.edu.cn.kramse.exit:34303
 650 STREAM 35 REMAP 18 202.38.97.230.kramse.exit:34303 SOURCE=EXIT
 650 STREAM 35 CLOSED 18 202.38.97.230.kramse.exit:34303 REASON=DONE
 650 STREAM 36 NEW 0 202.38.97.230:21 SOURCE_ADDR=127.0.0.1:49684
 PURPOSE=USER
 650 STREAM 36 SENTCONNECT 6 202.38.97.230:21
 650 STREAM 36 REMAP 6 202.38.97.230:21 SOURCE=EXIT
 650 STREAM 36 SUCCEEDED 6 202.38.97.230:21
 650 STREAM 37 NEWRESOLVE 0 my-linux-box:34303 PURPOSE=DNS_REQUEST
 650 STREAM 37 NEW 6 my-linux-box:34303 SOURCE_ADDR=(Tor_internal):49685
 PURPOSE=DNS_REQUEST
 650 STREAM 37 SENTRESOLVE 6 my-linux-box:34303
 650 STREAM 37 FAILED 6 my-linux-box:34303 REASON=RESOLVEFAILED
 650 STREAM 37 CLOSED 6 my-linux-box:34303 REASON=DONE
 getinfo circuit-status
 250+circuit-status=
 18 BUILT
 $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$52F9083EE37A143BD03F77CF35ED1B7DC9108BE8~somethingsomething,$0078FFEABB3B87512DD6701C2930D8FCA128F97D~TelosTorExit5,$EC116BCB80565A408CE67F8EC3FE3B0B02C3A065~kramse
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2014-12-03T04:54:10.556288
 17 BUILT
 $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$516BC3FDE382EBE5C6D1BA63056C071F28E65747~trockner,$D1271A1E15C568DA709D3A1E68188EEAE8DDB834~worfedpm
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2014-12-03T04:51:34.986853
 7 BUILT
 $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$F596E1B1EF98E1DDBBDC934DB722AF54069868F6~bauruine202,$B7580D392853F23597E11575F061B8097ADD92B6~spfTOR1e3
 BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL
 TIME_CREATED=2014-12-03T04:49:01.986921
 6 BUILT
 $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$5A16F7E31B26F286889F20027F57A5E253AF3F23~servbr4a,$E801BFE9048106FB3E39A1B076CB03648CE93D8F~Gertrude
 BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL
 TIME_CREATED=2014-12-03T04:49:01.371019
 5 BUILT
 $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$1C90D3AEADFF3BCD079810632C8B85637924A58E~splitDNA,$D6DF9D18146CBEFE005CAB010E5E11C297DB87D2~TapLink
 BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL
 TIME_CREATED=2014-12-03T04:48:22.986518
 4 BUILT
 $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$D3EC9A20C83E1E3050CA3759B8957D91D2DE128C~Oezie,$1B89A79F50A9B3F46A8AB07B14C5662DA3364ED3~4Privacy
 BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL
 TIME_CREATED=2014-12-03T04:48:21.990858
 .
 250 OK
 getinfo stream-status
 250-stream-status=36 SUCCEEDED 6 202.38.97.230:21
 250 OK

 I don't know why it's trying to resolve my own box, but whatever.

 Anyway, when I see what circuit the stream is attached to, I get this:

 getinfo stream-status
 250-stream-status=36 SUCCEEDED 6 202.38.97.230:21
 250 OK

 Why isn't it attached to circuit 18? That's the one with the exit node I
 specified...

 As a result, when I try to initiate the data connection, it comes from a
 different IP, so the server pretends to be down as a self-protection
 mechanism (other servers also send back ICMP responses, so it seems server
 dependent):

 650 STREAM 41 NEW 0 202.38.97.230:41474 SOURCE_ADDR=127.0.0.1:49687
 PURPOSE=USER
 650 STREAM 41 SENTCONNECT 18 202.38.97.230:41474
 650 STREAM 41 DETACHED 18 202.38.97.230:41474 REASON=TIMEOUT
 650 STREAM 41 SENTCONNECT 17 202.38.97.230:41474
 650 STREAM 41 DETACHED 17 202.38.97.230:41474 REASON=TIMEOUT
 650 STREAM 41 SENTCONNECT 20 202.38.97.230:41474
 650 STREAM 41 DETACHED 20 202.38.97.230:41474 REASON=TIMEOUT
 650 STREAM 41 SENTCONNECT 21 202.38.97.230:41474
 650 STREAM 41 FAILED 21 202.38.97.230:41474 REASON=END
 REMOTE_REASON=INTERNAL
 650 STREAM 41 CLOSED 21 202.38.97.230:41474 REASON=END
 REMOTE_REASON=INTERNAL

 This used to work in 0.2.2. Here are the only non commented lines in my
 config that I'm using to debug this:

 AllowDotExit 1
 AllowUnverifiedNodes middle,rendezvous
 Log notice syslog
 RunAsDaemon 1
 User tor
 Group tor
 DataDirectory /var/lib/tor
 ControlPort 9051

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


More information about the tor-bugs mailing list