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-mailingli...@whonix.org> 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 > _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.