Whilst watching, listening at sites such as Rabbit https://www.rabb.it/:
Reproducible with Waterfox 56.2.6 on (unsupported) FreeBSD-CURRENT.
From #21312 (Memory and file descriptor leaks in programs that use go-webrtc) – Tor Bug Tracker & Wiki (2017-01-25, closed defect (fixed), closed 2018-03-21) I _assume_ that the periodic disconnects with Waterfox involve _go-webrtc_. Assumption based on the second of these phrases (with added emphases):
Well,
CGO_DestroyPeerdoesn't appear to be thread-safe; so let's fix that. The client is currently defaulting to 1 concurrent peer, which would explain why it doesn't hit this issue, if that's the cause. The proxies, which are handling multiple peers, each of which are voluntarily exiting every 30s of inactivity, seem like they could be hitting some contention there, but possibly not at the rate things are failing?
… Potentially of note: the abort happens immediately after the first
OnClosechannel. The client had been connected for 78Â seconds.
…
Firefox 56.2.2 Causing disconnect issues with Rabb.it : waterfox (sic – probably _Waterfox_ 56.2.2 (there was no such version of Firefox) (2018-07-22, archived)
Waterfox 56.2.5 not working with Rabb.it Version 56.2.0 does : waterfox (2018-12-14)
… constant disconnects …
Technically, I doubt that the disconnects are _constant_; I assume that they are periodic. Probably disconnected after 78Â seconds although re: the first of the quotes above I guess that other timings may be observed/perceived.
From https://www.reddit.com/comments/a65psj/-/ef8mqcq/:
… can you reproduce the issue with Rabbit with Firefox ESR 60?
https://trac.torproject.org/projects/tor/ticket/21312#comment:66 from me seeks advice.
@grahamperrin Sorry, but it doesn't appear as if Waterfox is using go-webrtc.
@arlolra thanks for investigating.
@MrAlex94 and all: other possible explanations for Rabb.it ceasing to work with Waterfox at/around the time of release of 56.2.2?
For me the exactness (78 seconds) was remarkable but if you think it'll help to be less specific, I can remove this from the title of the issue.
For me the exactness (78 seconds) was remarkable but if you think it'll help to be less specific, I can remove this from the title of the issue.
I grepped the webrtc source for a constant timer of 78 but didn't come up with anything.
The log from that report shows a user's session with 48s of activity, followed by 30s of inactivity after which a timer killed the connection. Alas, it may have just been a coincidence.
https://www.rabb.it/ (archived) â–¶
– an application, no longer web-based. This issue is redundant.
Most helpful comment
https://trac.torproject.org/projects/tor/ticket/21312#comment:66 from me seeks advice.