[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #2983 [Tor Client]: Errant circuit creation beyond MAPADDRESS validity



#2983: Errant circuit creation beyond MAPADDRESS validity
------------------------+---------------------------------------------------
 Reporter:  grarpamp    |          Owner:     
     Type:  defect      |         Status:  new
 Priority:  normal      |      Milestone:     
Component:  Tor Client  |        Version:     
 Keywords:              |         Parent:     
   Points:              |   Actualpoints:     
------------------------+---------------------------------------------------
 I think I found something strange. Consider the following shell
 script.


 for exit in list_of_exits ; do
  mapaddress example.com=example.com.$exit.exit [1]

  Fire off ten to twenty background processes in parallel that try
  to connect to example.com. Depending on timing and other issues,
  some may succeed, some may fail, some may be waiting their timeout
  retry period due to failure to connect to example.com the first
  time, etc. Think wget here.

  wait - 'wait' them in the shell till they all exit.

  mapaddress example.com=example.com [3]
  mapaddress example.com.$exit.exit=example.com.$exit.exit [2]
  getinfo address-mappings/all
 done


 [2] Now this map effectively clears the dynamically made map (from
 [1]) to the default (no) mapping. And the getinfo confirms it is
 gone. The shell 'wait' ensures that the spawned processes are all
 gone and thus do not remain to make further use of the map in [1].

 The bug is... sometimes (while for'ing through the long list of
 exits), at the end of the next iteration of the loop (and beyond,
 until the old entry expires), getinfo will show a dynamic entry for
 the previous exit. Of the form:
 example.com.<exit>.exit <it's IP address>.<exit>.exit "2011-04-xx
 xx:xx:xx"


 My guess is that the processes put in a request for a circuit (by
 simply trying to connect). But that [2] doesn't kill that request
 within Tor, it only removes any dynamic map that currently exists.

 I subsequently tested by adding [3], it had no effect on this issue.

 I believe both [2] and [3] should kill any pending requests for
 their respective, formerly mapped, entities.

 Also, I see this every once in a while, no real hypothesis other
 than something similar is going on:
 example.com <it's IP address> "2011-04-xx xx:xx:xx"

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2983>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs