Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:41:53Zhttps://gitlab.torproject.org/legacy/trac/-/issues/30649Every few hours, relays [warn] Received circuit padding stop command for unkn...2020-06-13T15:41:53ZteorEvery few hours, relays [warn] Received circuit padding stop command for unknown machine.toralf says on #tor-relays:
```
I got 5x within last 36 ours with 0.4.1.1-alpha: [warn] Received circuit padding stop command for unknown machine. -shall I ignore that?
```
I'm marking this as 041-must, because we will get lots ...toralf says on #tor-relays:
```
I got 5x within last 36 ours with 0.4.1.1-alpha: [warn] Received circuit padding stop command for unknown machine. -shall I ignore that?
```
I'm marking this as 041-must, because we will get lots of bug reports from relay operators if we release a stable with this warning. At the very least, we must downgrade it to a protocol error.Tor: 0.4.0.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/28624Should we remember dormant state on restart?2020-06-16T01:00:03ZRoger DingledineShould we remember dormant state on restart?One of the core ideas of #2149 was for Tor to remember its dormancy across restarts. As of the finishing of #2149, Tor will go dormant 24 hours after startup if it's seen no activity -- but if you start it again, it'll be active for 24 h...One of the core ideas of #2149 was for Tor to remember its dormancy across restarts. As of the finishing of #2149, Tor will go dormant 24 hours after startup if it's seen no activity -- but if you start it again, it'll be active for 24 hours again. So people who restart their computers, or their Tor-including apps, will continue putting load on the Tor network.
So I am opening this ticket to not forget that second piece of it.
The first question is around the engineering side: when we go dormant, do we write that fact into our state file? And when we change our mind, I guess we clear it? Do we also write it when the controller commands us to go dormant? I guess yes.
The second question is about how thorough we want to be. Specifically, if we're expecting that people will restart their Tor, what about people who never leave their Tor going for a full 24 hours? Those people will never switch to a dormant state. Is that ok? The fix would be to record "partial progress towards going dormant" in the state file, which is kind of ugly but also doable.
The third question is around how to handle it when we start up and the state file says we were dormant. Continuing to stay dormant seems like the clear right behavior -- because after all, we can wake up and start bootstrapping if we actually get an application level request. But I guess that means we don't even try to bootstrap? Are there controller apps like Tor Launcher and Nyx that wait for the 100% bootstrap message and tell you that your Tor is broken if it doesn't happen? Is there something we can give those apps instead that will satisfy them that Tor is "acting as intended"? Is there some simple "connect to a relay and do a handshake with it once" thing that we can do instead on startup, to satisfy ourselves that Tor *could* work if we wanted it to? Or should we stay totally isolated from the network when we start up in dormant state?
I think some of these are ux questions, and answering them might be easier if we pick a couple of specific use cases for dormant mode. Here are two:
(1) What if some linux distro includes a Tor client package by default, and users can configure their apps to use it but many users don't. In that case we'd have thousands or millions of Tor clients installed but not usefully using the Tor network. And our primary goal there would be to make those Tors go totally quiet after a while. This was the original motivation for #2149.
(2) ...I was going to use an example here of Tor bundled with an app, like Brave or Briar, but I think in this case the app should be responsible for making Tor behave politely to the Tor network.
So I think use case (1) is the one to focus on, and that also simplifies the ux questions.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/27244Use mmap to hold our cached consensus, when we even need it stored in RAM at ...2020-06-13T15:29:52ZNick MathewsonUse mmap to hold our cached consensus, when we even need it stored in RAM at all.Tor: 0.4.0.x-final