Snowflake Docker container doesn't build on Raspberry Pi (32 bit)

Support Relay Operator
1

Since there are unfortunately no Docker images either for obfs4 or snowflake proxies for armv7 (Raspi 32 bit) machines, I tried to create a Docker image from the repository.

I am not a Docker expert but I managed to build and run an obfs4 proxy docker image.

But when I try to build a snowflake proxy image from The Tor Project / Anti-censorship / docker-snowflake-proxy · GitLab by running “make build”, I get this output:

docker build --build-arg VERSION= -t thetorproject/snowflake-proxy .
Sending build context to Docker daemon  87.55kB
Step 1/13 : FROM docker.io/library/golang:1.18 AS builder
 ---> 725ec8ce8093
Step 2/13 : ARG VERSION=main
 ---> Using cache
 ---> b5c6c8bdf201
Step 3/13 : WORKDIR /builder
 ---> Using cache
 ---> 3c07a3a57fd1
Step 4/13 : RUN git clone --depth=1 -b ${VERSION} https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake.git
 ---> Running in b1e5a25506e3
fatal: You must specify a repository to clone.

usage: git clone [<options>] [--] <repo> [<dir>]

    -v, --verbose         be more verbose
    -q, --quiet           be more quiet
    --progress            force progress reporting
    -n, --no-checkout     don't create a checkout
    --bare                create a bare repository
    --mirror              create a mirror repository (implies bare)
    -l, --local           to clone from a local repository
    --no-hardlinks        don't use local hardlinks, always copy
    -s, --shared          setup as shared repository
    --recurse-submodules[=<pathspec>]
                          initialize submodules in the clone
    --recursive ...       alias of --recurse-submodules
    -j, --jobs <n>        number of submodules cloned in parallel
    --template <template-directory>
                          directory from which templates will be used
    --reference <repo>    reference repository
    --reference-if-able <repo>
                          reference repository
    --dissociate          use --reference only while cloning
    -o, --origin <name>   use <name> instead of 'origin' to track upstream
    -b, --branch <branch>
                          checkout <branch> instead of the remote's HEAD
    -u, --upload-pack <path>
                          path to git-upload-pack on the remote
    --depth <depth>       create a shallow clone of that depth
    --shallow-since <time>
                          create a shallow clone since a specific time
    --shallow-exclude <revision>
                          deepen history of shallow clone, excluding rev
    --single-branch       clone only one branch, HEAD or --branch
    --no-tags             don't clone any tags, and make later fetches not to follow them
    --shallow-submodules  any cloned submodules will be shallow
    --separate-git-dir <gitdir>
                          separate git dir from working tree
    -c, --config <key=value>
                          set config inside the new repository
    --server-option <server-specific>
                          option to transmit
    -4, --ipv4            use IPv4 addresses only
    -6, --ipv6            use IPv6 addresses only
    --filter <args>       object filtering
    --remote-submodules   any cloned submodules will use their remote-tracking branch
    --sparse              initialize sparse-checkout file to include only files at root

The command '/bin/sh -c git clone --depth=1 -b ${VERSION} https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake.git' returned a non-zero code: 129
make: *** [Makefile:17: build] Error 129

When I do a git clone of the main branch of the snowflake.git repository in my shell, it works without problem.

Any help will be appreciated. I would like to provide a permanent bridge on my Raspberry Pi, but am a bit disappointed that there is no official Docker image provided by the Tor project.

2

You are right, there was no docker images for armv7 neither for obfs4-bridge or snwoflake-proxy. I just fixed that, now there is for both. I hope they work fine for you.

8 Likes
3

I could deploy the image from dockerhub now without any problem. Thanks a lot.

How can I see that it works correctly? All I see in the docker log is this:

2022/05/16 16:05:24 In the last 1h0m0s, there are 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.

Can I somehow connect to my own snowflake proxy?

4

No, you can’t connect to your own proxy easily, as the client doesn’t choose the proxy it connect to but is assigned by the broker.

This log line you are copying should be an indicator that clients are connecting, as ‘connections’ should increase and you should see traffic being relayed. We have currently more snowflake proxies than clients, so not seeing clients in some of those log entries is normal, but you should see some at some point.

The thing we are not having enough is proxies with ‘unrestricted NAT’. You will see it if you run it with the -verbose flag, few seconds after launching the proxy there should be line like:

NAT Type measurement: unknown -> restricted = restricted

If you see it being restricted check if you are running the docker image with network_mode: host and if you don’t have any firewall blocking incoming UDP connections to the proxy.

2 Likes
5

Yes, I do have that line in my logfile:

2022/05/16 16:36:19 NAT Type measurement: unknown -> restricted = restricted
2022/05/16 16:36:19 NAT type: restricted

Later I have these lines:

2022/05/16 17:39:20 sdp offer successfully received.
2022/05/16 17:39:20 Generating answer...
2022/05/16 17:39:40 Timed out waiting for client to open data channel.

My router of course blocks everything that is not explicitly allowed.

if you don’t have any firewall blocking incoming UDP connections to the proxy.

I have no ports forwarded from docker to the host Rasperry Pi as I could not find any info about that. The snowflake documentation says just start up the container and you are done. (The obfs4 proxy doc explicitly lists that I need to set up two port forwardings.)

6

Which, in the case of somewhat inexperieced users like me who are running the proxy on the base system, may come down to issues with the hardware provided by their isp not allowing any adjustment to NAT settings. On top of that is the difficulty they might be experincing when adding hardware to their existing set up. For instance, I’m trying to add a Linksys WRT32x router to my existing set up which is an Actiontec T3200M ‘gateway’ (on the Telus network in Canada) and its certainly a steep learing curve. Once I get the Linksys working and flash the firmware to DDWRT I think/hope I’ll be able to sort the NAT to open. I have no way of knowing for sure but I expect there may be quite a few users in the same boat, which means a lot of people with restricted NATs and not as much throughput on the proxies as there could be. At least there will be throughput even with a restricted NAT, just not as much as one would like.

I know this is a bit off topic for this thread but I thought I’d chime in about the NAT part. :wink:

7

This topic was automatically closed 2 hours after the last reply. New replies are no longer allowed.

8

You need to forward the whole network as the proxy will use any random UDP port in the range 32768-60999. If you are using docker-compose add network_mode: host as an option:

If you are running it manually you can add --network host as a param.

2 Likes