GitLab

Make a test connection to the symmetrically NAT'd probe site to
determine NAT type. This replaces the previous method of getting
ICE candidates from two different STUN servers and more
definitively determines compatability with a symmetrically NAT'd
client.

This brings in the bug-reporting instructions from #14 (bbf3629e).

Decrease the wait time between proxy polls and the poll adjustment so
that we have more proxies available for the increased client load.

We need to extract the remote address of the client to pass along to the
bridge. This adds an extra check to see whether the retrieved address is
a remote address (as opposed to local, loopback, or unspecified). It
also expands the SDP regexes to check for addresses in the ice
candidates.

This fixes issue #16

Option 1 is to request an account at gitlab.torproject.org. Option 2 is
to edit the public pad I just created.

Closes #14.

This compliments the poll the rate adjustment on proxy failures to
address proxy matching issues. Since we cannot determine our NAT type
directly for browser-based proxies, we assume a restricted NAT type if
the datachannel fails to open.

If we stop getting keep-alive pings for some timeout period, close the
stale connection. This solves bug #31278 where chrome proxies hang open
on an idle connection.

Trac: 34127

Trac: 34140

This might just be an issue with node-webrtc but seems a harmless
workaround.

Trac: 34126

Trac: 34128

Trac: 34132

Trac: 34127

Trac: 33365
Trac: 33112

If the proxy succeeds in opening a datachannel to the client, decrease
the poll interval. If they fail, increase the poll interval. This will
cause less reliable/more restrictive proxies to poll less frequently.

Remove the parts that apply only to the Go code and get CI working on
the new directory structure.

This repository is for the web proxy only

https://bugs.torproject.org/33800

This will prevent a bug where tor skips bandwidth events for local
addresses (see https://bugs.torproject.org/33693)