Hi Patrick. Not sure I follow - a control port filter acts as a proxy...
Application => Filter => Tor Control Port
If the filter is shut down the socket the application is connected to
is... well, gone. Is the trouble that Onionshare gives a poor
indication when this happens? If so then indeed, that sounds like an
Onionshare bug.
On Mon, Nov 14, 2016 at 11:00 AM, Patrick Schleizer
<patrick-mailinglists@???> wrote:
> anonym:
>> Patrick Schleizer:
>>> When the filter is terminated, onionshare apparently does not notice
>>> that. Would be better if onionshare would notice that. Is that a bug?
>>
>> It seems like a "bug" in onionshare, or even the control port language
>> protocol itself since it (AFAICT) doesn't have a concept of the server
>> quitting mid-session. No signal is sent, and I haven't even found an
>> event one can explicitly subscribe to to learn when it shuts down. In
>> fact, any stem-application will, for instance, notice that Tor closed
>> its control port on the next send() or recv() on the socket, and then
>> throw a stem.SocketClosed.
>
> Both nc and telnet will notice and automatically terminate as expected
> once the filter was stopped. Therefore I guess the control protocol may
> be sufficient.
>
> Do you think this could be a bug in onionshare or onionshare? //cc
> Damian, Micah
>
> Cheers,
> Patrick
>
