[tor-bugs] #33401 [Circumvention/Snowflake]: turbotunnel-quic snowflake-client occasionally uses lots of CPU
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Feb 21 10:50:42 UTC 2020
#33401: turbotunnel-quic snowflake-client occasionally uses lots of CPU
-------------------------------------+--------------------------
Reporter: dcf | Owner: dcf
Type: defect | Status: assigned
Priority: Medium | Milestone:
Component: Circumvention/Snowflake | Version:
Severity: Normal | Resolution:
Keywords: turbotunnel | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------+--------------------------
Comment (by dcf):
I tracked this down to a bug in quic-go that has been fixed in a newer
version.
* [https://github.com/lucas-clemente/quic-
go/commit/079279b9cf4cb5dafc8b7f673a2e7e47a4b6a06e fix mismatching
expectation of the keep alive timer]
> session.maybeResetTimer() and session.run() were using slightly
different definitions of when a keep-alive PING should be sent. Under
certain conditions, this would make us repeatedly set a timer for the
keep-alive, but on timer expiration no keep-alive would be sent.
What was going wrong is [https://github.com/lucas-clemente/quic-
go/blob/907071221cf97f75398d9cf8b1174e94f56e8f96/session.go#L449 here].
{{{
deadline = s.idleTimeoutStartTime().Add(s.peerParams.IdleTimeout / 2)
}}}
If the current time is more than 50% of `IdleTimeout` past
`idleTimeoutStartTime`, then this line computes a deadline in the past.
The deadline in the past makes the `s.timer` always immediately
selectable, which makes `session.run` always call back right into
`maybeResetTimer` and set another deadline in the past. It continues until
some external event such as an arriving packet resets
`idleTimeoutStartTime`.
We can resolve the problem by using a more recent commit of quic-go. But
the commit [https://github.com/lucas-clemente/quic-
go/commit/079279b9cf4cb5dafc8b7f673a2e7e47a4b6a06e 079279b] we need is not
in any published release yet (v0.14.4 is the newest as of this writing,
released just 4 days ago). So we would have to set it to a specific commit
rather than a tag.
The instability of quic-go is making me like it less for Turbo Tunnel
purposes. This isn't the first time I've found a bug in the most recent
tagged release that had already been fixed in master (i.e., not in any
version that `go get` would get for you with Go modules activated). The
other time was [https://github.com/lucas-clemente/quic-go/issues/2172
GH#2172].
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33401#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list