itchyonion (130b63cc) at 08 Jun 08:03
use debian buster and bullseye as base images
Debian 9/stretch has been moved to archive.debian.org
Using old_stable
and stable
as labelled by https://wiki.debian.org/DebianReleases
Not sure I understand the point of this change. Can you elaborate?
This error message still expecting 3.
All the programs in the snowflake server chain
(snowflake-server, haproxy, extor-static-cookie)
bind to an explicit source IP address
before connecting to the next link in the chain,
in order free up more 4-tuples: because if everything were on 127.0.0.1
there would not be enough ephemeral port numbers for as many connections as we have.
tor itself also binds to a source address before connecting to middle relays
when the OutboundBindAddress
option is set,
as it is on the snowflake-01 bridge.
There is a socket option IP_BIND_ADDRESS_NO_PORT
you can set
when doing this bind-before-connect pattern that enables better port number reuse
and helps conserve ephemeral ports further.
But there is a problem when some programs use IP_BIND_ADDRESS_NO_PORT
and some do not:
the ones that do will be starved of ephemeral ports.
See extensive past analysis:
Because formerly tor did not use IP_BIND_ADDRESS_NO_PORT
,
we had fallen into an equilibrium of all the snowflake programs
similarly not using the socket option.
But now that tor 0.4.7.13
always uses IP_BIND_ADDRESS_NO_PORT
when OutboundBindAddress
is set,
we need to flip the other way, and make all the snowflake programs set IP_BIND_ADDRESS_NO_PORT
.
See #40270.
The necessary change has already been made in extor-static-cookie.
In haproxy, it only requires a configuration change to start using
IP_BIND_ADDRESS_NO_PORT
.
This merge request is to make the necessary change in snowflake-server.
IP_BIND_ADDRESS_NO_PORT
is a Linux-only option.
The patch defines a dialerControl
function that sets
IP_BIND_ADDRESS_NO_PORT
on Linux and is a no-op on other platforms.
Looks Good. Sorry I missed this MR ealier.
Extend the sleep time, so it has enough time to get test results for the resource.
Implemented some checks in !141 (merged)
Not sure if it's normal.
This is what has been returned by the broker to a /proxy
request:
{
"Status": "client match",
"Offer": "{\"type\":\"offer\",\"sdp\":\"v=0\\r\\no=- <SCRUBBED> <SCRUBBED> IN IP4 0.0.0.0\\r\\ns=-\\r\\nt=0 0\\r\\na=fingerprint:sha-256 <SCRUBBED>\\r\\na=extmap-allow-mixed\\r\\na=group:BUNDLE 0\\r\\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\\r\\nc=IN IP4 0.0.0.0\\r\\na=setup:actpass\\r\\na=mid:0\\r\\na=sendrecv\\r\\na=sctp-port:5000\\r\\na=ice-ufrag:<SCRUBBED>\\r\\na=ice-pwd:<SCRUBBED>\\r\\na=end-of-candidates\\r\\n\"}",
"NAT": "unrestricted",
"RelayURL": "wss://snowflake.torproject.net/"
}
Offer:
v=0
o=- <SCRUBBED> <SCRUBBED> IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 <SCRUBBED>
a=extmap-allow-mixed
a=group:BUNDLE 0
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=setup:actpass
a=mid:0
a=sendrecv
a=sctp-port:5000
a=ice-ufrag:<SCRUBBED>
a=ice-pwd:<SCRUBBED>
a=end-of-candidates
As you can see, it contains no ICE candidates. Also note the a=end-of-candidates
. My Snowflake sent an answer but connection failed.
I have noticed this twice already.
Can this be due to the fact we're trying to filter out local network ICE candidates? And maybe STUN being blocked for the clients?
A summary of things I'm working on and future plans. @meskio would like to hear your opinion (and others too).
Right now Stencil is used as a componentent of SplitHashring
type SplitHashring struct {
*Hashring
*Stencil
}
and responsible for computing the distribution method if the operator didn't specify one. It is paired with a Hashring
because(I believe) the result needs to be deterministic -- since we don't have any persistence yet and the results are only kept in memory. With the introduction of database, we would remember the bridges we have seen before. As such, I don't think a standalone package is needed anymore. The job of computing bridge assignments can be done by either introducing a new method in Resource or Collection and it could be much simpler.
The logic will be something like this:
We talked about keeping the current bridge distribution during migaration to database. But if we want to stop using Stencil, there needs to be an intermediate step because the new algorithm cannot produce the same results as Stencil. My plan is to write the results of current Stencil computations to a database file, then load the database file with new version of rdsys.
My understanding of Hashring/SplitHashring is that it's needed because we keep almost everything about Resource
in memory so consistent hashring is important to reproduce the things we have computed. With the introduction of database, we can make the in-memory data struct a lot simpler by saving computation results to the database. We can add a Database
field in BackendResources
and simplify collection
to map[string]*Resource
and get rid of structs like Hashring
, SplitHashring
, Stencil
. But this is likely beyond the scope of this issue.
Debian 9/stretch has been moved to archive.debian.org
Using old_stable
and stable
as labelled by https://wiki.debian.org/DebianReleases