[tor-bugs] #20451 [Obfuscation/meek]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'

[Tor Bug Tracker & Wiki]

#20451: The communication stream of managed proxy '/usr/bin/meek-client' is
'closed'
------------------------------+------------------------------
 Reporter:  tagener-noisu     |          Owner:  dcf
     Type:  defect            |         Status:  needs_review
 Priority:  Medium            |      Milestone:
Component:  Obfuscation/meek  |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:                    |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:
------------------------------+------------------------------

Comment (by dcf):

 Replying to [comment:10 asn]:
 > Eek. I guess the proper long-term fix here involves introducing another
 error type that can be emited mid-run? For example, `PT-ERROR` or
 `GENERAL-ERROR` or something?
 >
 > Abusing `CMETHOD-ERROR` seems like a reasonable choice for the short-
 term.

 In the past, we discussed (and even had a patch for) treating anything
 written to stderr as an error message: #9957. It even mentions this exact
 use case:
 > obfsproxy may complain about some things (e.g. it not being able to
 write to its own log file) over stderr. If one runs obfsproxy as intended
 (using the ServerTransportPlugin directive in torrc), obfsproxy may exit
 (Tor will report this, of course) without any verbal explanation.

 comment:9:ticket:12088 discusses using ENV-ERROR (although in my recent
 tests, ENV-ERROR isn't reflected in the tor logs?) and the desire for
 something like GENERIC-ERROR:

 > > About error reporting: suppose your transport needs to create its own
 subdirectories in the state dir. You call pt.MakeStateDir, then you
 manually create the directories inside it. Suppose the creation of one of
 these directories fails. Is that an ENV-ERROR? If not, then a failure to
 create the state dir itself probably should also not be an ENV-ERROR.
 (Except to the extent that we abuse ENV-ERROR as a general-purpose error
 logging function.)
 > This is true. As far as what the API does, I would prefer it to always
 ENV-ERROR, or never so the error handling in the applications can do the
 right thing (and if the latter, I will more than likely continue to abuse
 ENV-ERROR as a general purpose error reporting mechanism till something
 better comes around, because providing 0 feedback to the actual user is
 terrible).
 > > CMETHOD-ERROR/SMETHOD-ERROR could be a good way to report these kinds
 of generic errors that happen at startup. "CMETHOD-ERROR foo failed to
 create state directory." The only thing is I bet application authors want
 to handle all the state dir stuff once at the top of their program, before
 they enter the CMETHOD processing loop. It kind of makes me wish for a
 GENERIC-ERROR that could appear at any time during negotiation.
 > I kind of like the #9957 approach here ("Spam errors to stderr, tor will
 propagate the complaints to interested parties"). It's simple, and the
 code is technically done, so it's more likely to exist sooner than adding
 new statements to the PT protocol.

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