Opened 7 years ago

Last modified 9 months ago

#2983 new defect

Errant circuit creation beyond MAPADDRESS validity

Reported by: grarpamp Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.3.25
Severity: Normal Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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"

Child Tickets

Change History (20)

comment:1 Changed 7 years ago by arma

Milestone: Tor: 0.2.3.x-final

I just made #3037 to help (maybe) track this down.

Folks are welcome to track it down via some other approach in the mean time. :)

comment:2 Changed 6 years ago by grarpamp

Version: Tor: 0.2.1.32

simply noting the branch i _think_ i was on when observing this.

comment:3 Changed 6 years ago by grarpamp

Cc: grarpamp@… removed

comment:4 Changed 6 years ago by nickm

Keywords: tor-client added

comment:5 Changed 6 years ago by nickm

Component: Tor ClientTor

comment:6 Changed 5 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified
Status: newneeds_information

Can anybody confirm whether this happens with any recent version of Tor?

comment:7 Changed 5 years ago by grarpamp

I found the script again. Might be a couple weeks before I can test it.

comment:8 Changed 5 years ago by grarpamp

Status: needs_informationnew
Version: Tor: 0.2.1.32Tor: 0.2.3.25

Can anybody confirm whether this happens with any recent version of Tor?

Yes, retested, happens with this version. You can retry with 'wget -T 10 -t 5', but that's bound by the 'wait' anyways.

comment:9 Changed 3 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.7.x-final

Worth looking at during 0.2.7 triage IMO

comment:10 Changed 3 years ago by nickm

Status: newassigned

comment:11 Changed 3 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:12 Changed 3 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

comment:13 Changed 21 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:14 Changed 20 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:15 Changed 15 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:16 Changed 15 months ago by nickm

Keywords: 027-triaged-in added

comment:17 Changed 15 months ago by nickm

Keywords: 027-triaged-in removed

comment:18 Changed 15 months ago by nickm

Keywords: 027-triaged-1-out removed

comment:19 Changed 15 months ago by nickm

Status: assignednew

Change the status of all assigned/accepted Tor tickets with owner="" to "new".

comment:20 Changed 9 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.