Roflcoptor should close connections if clients go away

subgraph / roflcoptor

Tor Control Port Filter and State Tracker Daemon

BSD 3-Clause "New" or "Revised" License

25 stars 8 forks source link

Roflcoptor should close connections if clients go away #64

Open dma opened 7 years ago

dma commented 7 years ago

Reproduce:

Run ricochet in oz in SGOS
Kill oz-daemon while sandbox up/app running
Start oz-daemon
Try to run ricochet again in oz in SGOS
TorHS collision, ricochet can't setup listener
Probably roflcoptor's fault: ephemeral hidden services go away when the client connection to the tor control port is closed.

david415 commented 7 years ago

so... if there were multiple applications that were relying on their own onion services via roflcoptor... and roflcoptor sees a connection close it should close it's control port destroying all the onion services? i think the solution here is for roflcoptor to DEL_ONION the specific onion service corresponding to the application that closed it's connection to roflcoptor.

special commented 7 years ago

Tracking ADD_ONION and issuing DEL_ONION when the app->roflcopter connection is closed would work for this case, but it's going to be fragile and it will leave similar problems like GETINFO onions/current unsolved.

I think a much better solution would be to make one roflcopter->tor connection for each application->roflcopter connection, and close them at the same time. All of tor's per-connection behavior would then be automatically correct.