Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 318
    • Issues 318
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 36
    • Merge requests 36
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #823
Closed
Open
Created Sep 22, 2008 by Trac@tracbot

r16621 introduced random stream detaching

When I use a relay of mine running a version later than r16621 as an exit to, for example, http://upload.wikimedia.org/wikipedia/commons/7/79/Yellowjacket_nest_1_sjh.JPG then the first few (between 3 and 100) times I try, the stream gets DETACHED with reason=END and remote_reason=unknown. Re-attaching the stream to another circuit works fine, and then the stream succeeds. If I keep trying the same address through my relay a bunch of times, it eventually succeeds. However, restarting my CLIENT Tor program (which I'm using to test this, ie, not the relay), and trying again at the same address causes the same problem.

I narrowed down the problem to this block in eventdns.c:

/* we only bother with the first four addresses. */
if (j + 4*addrtocopy > length) goto err;
//if (name_matches) {
	memcpy(&reply.data.a.addresses[reply.data.a.addrcount],
		   packet + j, 4*addrtocopy);
	reply.data.a.addrcount += addrtocopy;
	reply.have_answer = 1;
	if (reply.data.a.addrcount == MAX_ADDRS) break;
//}
j += 4*addrtocopy;

Note that the // comments were added by me, and they actually fix this problem (ie, the stream never detaches if those //'s are present, but the problem DOES happen when they are NOT present). However, I dont understand this code at all, so I figured I'd submit a bug report with what I've figured out so far, and see what you guys think.

I printed out the names right after the assignment of name_matches in that function, and the print statement was run twice for a single stream attach try. This is what my tor log (level=debug) looked like: launch_resolve(): Launching eventdns request for [scrubbed] eventdns: Resolve requested. eventdns: Setting timeout for request 3afe38 eventdns: req->name = upload.wikimedia.org and tmp_name = upload.wikimedia.org eventdns: req->name = upload.wikimedia.org and tmp_name = upload.pmtpa.wikimedia.org eventdns: Removing timeout for request 3afe38

Note that I'm running windows XP, compiling from source, and in case it matters, my DNS server is 192.168.1.1, which is my router running DD-WRT

Hope this helps!

[Automatically added by flyspray2trac: Operating System: All]

Trac:
Username: TheJash

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking