Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #25599

Closed (moved)
Open
Opened Mar 22, 2018 by Arlo Breault@arlo

SOCKS4 failure message

Sometimes, Tor emits this:

[warn] The connection to the SOCKS4 proxy server at 127.0.0.1:$someport just failed. Make sure that the proxy >> server is up and running.

At which point no more handlers fire. Looking at the Tor source, this happens when SOCKS is "marked for close". This is inconvenient because then the client must be restarted for connectivity to work again.

\

Are you still experiencing this? Is it reproducible?

\

I experienced this sporadically while working on multiplexing. Right now it seems fine though.

It seems to be 100% reproducible if I explicitly readPipe.Close() on the webrtc peer. My guess is that when the copyLoop sends an error or EOF at SOCKS, Tor interprets that as an unexpected situation, "marks for close / deletion" and so the SOCKS4 server disappears.

Maybe there's a way to account for this in main() to also be able to recover the initial SOCKS listening? (this is not in the goptlib example, which we were originally based on) When the SOCKS connection is closed normally in handler, there's doesn't seem to be an issue.

But, should test more possibilities / longer times.

\ Migrated from https://github.com/keroserene/snowflake/issues/32

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#25599