Opened 5 months ago

Closed 4 months ago

#25087 closed defect (duplicate)

Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201802
Cc: dcf, arlolra, boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Logs/

Jan 30 10:45:02.000 [notice] Opening Socks listener on 127.0.0.1:9150
Jan 30 10:45:03.000 [warn] The communication stream of managed proxy './TorBrowser/Tor/PluggableTransports/snowflake-client' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors.
Jan 30 10:45:04.000 [notice] Bootstrapped 5%: Connecting to directory server
Jan 30 10:45:04.000 [warn] We were supposed to connect to bridge '0.0.3.0:1' using pluggable transport 'snowflake', but we can't find a pluggable transport proxy supporting 'snowflake'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
Jan 30 10:45:04.000 [warn] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Can't connect to bridge; PT_MISSING; count 1; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
Jan 30 10:45:04.000 [notice] Closing no-longer-configured Socks listener on 127.0.0.1:9150
Jan 30 10:45:04.000 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Jan 30 10:45:04.000 [notice] Closing old Socks listener on 127.0.0.1:9150
Jan 30 10:45:36.000 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.

Child Tickets

Change History (20)

comment:1 Changed 5 months ago by cypherpunks

Summary: Snowflake stops working on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1Snowflake doesn't on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1

oops; it never worked in the first place: better wording

comment:2 Changed 5 months ago by gk

Status: newneeds_information
Summary: Snowflake doesn't on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1Snowflake doesn't work on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1

I wonder what is different to my Debian where it is working as expected... Do you have a snowflake.log in /path/to/your/tor-browser/Browser/TorBrowser/Data/Tor/pt_state directory that could explain what is going on?

comment:3 in reply to:  2 Changed 5 months ago by cypherpunks

Replying to gk:

I wonder what is different to my Debian where it is working as expected... Do you have a snowflake.log in /path/to/your/tor-browser/Browser/TorBrowser/Data/Tor/pt_state directory that could explain what is going on?

None, even when I use ./start-tor-browser --debug; there's a state file tho

Guard in=bridges rsa_id=2B280B23E1107BB62ABFC40DDCC8824814F80A72 bridge_addr=0.0.3.0:1 sampled_on=2018-01-20T08:15:11 sampled_by=0.3.2.9 listed=1
Guard in=bridges rsa_id=B9E7141C594AF25699E0079C1F0146F409495296 bridge_addr=0.0.2.0:2 sampled_on=2018-01-28T02:54:45 sampled_by=0.3.2.9 unlisted_since=2018-01-27T06:16:34 listed=0 confirmed_on=2018-01-20T20:16:48 confirmed_idx=0 pb_use_attempts=32.000000 pb_use_successes=26.000000 pb_circ_attempts=153.000000 pb_circ_successes=148.000000 pb_successful_circuits_closed=139.000000 pb_collapsed_circuits=3.000000 pb_unusable_circuits=6.000000 pb_timeouts=5.000000
TorVersion Tor 0.3.2.9
LastWritten 2018-01-30 12:06:26
TotalBuildTimes 149
CircuitBuildAbandonedCount 2
CircuitBuildTimeBin 775 1
CircuitBuildTimeBin 825 5
CircuitBuildTimeBin 875 5
CircuitBuildTimeBin 925 4
CircuitBuildTimeBin 975 6
CircuitBuildTimeBin 1025 5
CircuitBuildTimeBin 1075 8
.
.
.

Also I can't reproduce it on another laptop with the same clean freshly installed Lubuntu 17 64 bits... so seems very strange o_O

Last edited 5 months ago by cypherpunks (previous) (diff)

comment:4 Changed 5 months ago by gk

Cc: dcf arlolra added
Component: Applications/Tor BrowserObfuscation/Snowflake

Hm. Be careful with posting your states file here as it usually contains your guard nodes which you might not want to reveal. Adding some Snowflake folks that might be able to help debugging this.

Any idea what is different between those two systems?

comment:5 Changed 5 months ago by yawning

Jan 30 10:45:04.000 [warn] We were supposed to connect to bridge '0.0.3.0:1' using pluggable transport 'snowflake', but we can't find a pluggable transport proxy supporting 'snowflake'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.

Suggests the pluggable transport binary is failing to launch or crashing immediately. I personally suspect the former (and have a hunch about the root cause). Since PT logging sucks (and will continue to suck for the foreseeable future, see #9957), the next step will be manually running the binary to see if it's at least marginally functional.

$ cd tor-browser_en-US/Browser/TorBrowser/Tor/PluggableTransports
$ LD_LIBRARY_PATH=/home/blahblahblah/tor-browser_en-US/Browser/TorBrowser/Tor/ ./snowflake-client

Note: Adjust the paths as appropriate to match your system.

comment:6 in reply to:  4 Changed 5 months ago by cypherpunks

Replying to gk:

Hm. Be careful with posting your states file here as it usually contains your guard nodes which you might not want to reveal.

lol it's just the fingerprint for the guards for meek-amazon and snowflake (snowflake fails, I switch to meek-amazon), nothing too serious I suppose.
Replying to yawning:
I don't have the system at hand for now, I'll try it out tomorrow if I can get hold of it as it's not my pc.

comment:7 Changed 5 months ago by cypherpunks

OK; did what yawning suggested and this is the output,

./snowflake-client: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

This is the last time I can have access to this system so please forgive me if I can't provide further debugging.

comment:8 in reply to:  7 Changed 5 months ago by yawning

Replying to cypherpunks:

OK; did what yawning suggested and this is the output,

./snowflake-client: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

This is the last time I can have access to this system so please forgive me if I can't provide further debugging.

Hmm, that's part of gcc's runtime. I wonder how reasonable it is to expect people to have a copy of that.

https://packages.ubuntu.com/artful/libatomic1 for Ubuntu and derivatives.

comment:9 Changed 5 months ago by arma

Summary: Snowflake doesn't work on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

Retitled the ticket based on new info

comment:10 Changed 5 months ago by arma

It sounds like we should either bundle libatomic, which bumps up the bundle size for everyone, or do some sort of "is there libatomic? if not tell the user" test on startup.

I'd be tempted to suggest the latter at least to start, since it should be easier, and as we wait maybe everybody will get libatomic, and while snowflake is still in alpha it should let us get a sense of how many people have this issue.

comment:11 Changed 5 months ago by arma

Speaking of atomic, there's an intriguingly related ChangeLog entry to Tor itself in 0.3.3.1-alpha:

    - Use stdatomic.h where available, rather than mutexes, to implement
      atomic_counter_t. Closes ticket 23953.

But on first glance it looks like that's headers, not the library. But, does that mean that if Tor Browser builds Tor on a system with libatomic headers, then Tor Browser's Tor will expect a libatomic it can use?

comment:12 in reply to:  11 Changed 5 months ago by yawning

Replying to arma:

Speaking of atomic, there's an intriguingly related ChangeLog entry to Tor itself in 0.3.3.1-alpha:

    - Use stdatomic.h where available, rather than mutexes, to implement
      atomic_counter_t. Closes ticket 23953.

But on first glance it looks like that's headers, not the library. But, does that mean that if Tor Browser builds Tor on a system with libatomic headers, then Tor Browser's Tor will expect a libatomic it can use?

"Depends". libatomic is what GCC will fall back to if does not have native code generation capability for an atomic operation on a given target. If Tor Browser is targeting something where GCC ends up doing that, then yes, Tor Browser's Tor will also expect a working libatomic.

as we wait maybe everybody will get libatomic.

In an ideal world, GCC will support the relevant code generation for all the targets that the bundle is shipped for, and no one will need libatomic.

After thinking about this for a bit, I'm of the opinion that as long as the GCC used to build Tor Browser generates code that links to it, Tor Browser should bundle it, much like how libstdc++ is bundled.

comment:13 Changed 5 months ago by cypherpunks

Status: needs_informationnew

I think I provided all of the necessary information. Setting as new again.

comment:14 Changed 5 months ago by cypherpunks

Resolution: worksforme
Status: newclosed

comment:15 Changed 5 months ago by yawning

Resolution: worksforme
Status: closedreopened

comment:16 Changed 4 months ago by gk

Component: Obfuscation/SnowflakeApplications/Tor Browser
Keywords: TorBrowserTeam201802 added
Status: reopenedneeds_information

Blech. Taking this back. I wonder if a simple GCC update would help here. arma: thanks for that catch.

boklm: Do we have some easy way of spinning up such an Lubuntu (or a similar disfunctioning system) to work on this bug?

comment:17 Changed 4 months ago by gk

Cc: boklm added

comment:18 in reply to:  16 Changed 4 months ago by boklm

Replying to gk:

boklm: Do we have some easy way of spinning up such an Lubuntu (or a similar disfunctioning system) to work on this bug?

I have been able to reproduce this issue with docker and the ubuntu:17.10 image, with the following steps:

  • starting an ubuntu:17.10 container: docker run -t -i ubuntu:17.10 bash
  • installing the xz-utils package with apt-get update && apt-get install xz-utils
  • downloading and extracting Tor Browser 8.0a1

Then I have the following error when trying to run snowflake-client:

tb@dc7363eb5e77:~/tor-browser_en-US/Browser/TorBrowser/Tor/PluggableTransports$ LD_LIBRARY_PATH=/home/tb/tor-browser_en-US/Browser/TorBrowser/Tor/ ./snowflake-client 
./snowflake-client: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory

comment:19 Changed 4 months ago by cypherpunks

Status: needs_informationnew

comment:20 Changed 4 months ago by cypherpunks

Resolution: duplicate
Status: newclosed

Duplicate of #24465

Note: See TracTickets for help on using tickets.