Opened 7 months ago

Closed 6 months ago

#20250 closed defect (fixed)

meek fails on macOS 10.12 when built with Go 1.4.3 or Go 1.6.3

Reported by: tordevSZ0 Owned by: dcf
Priority: High Milestone:
Component: Obfuscation/meek Version:
Severity: Major Keywords: meek, macOS, TorBrowser, 10.12, sierra
Cc: brade, mcs, boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Having issues using the meek pluggable transports on macOS 10.12 installation with a fresh install of TorBrowser.

On the same machine running 10.11.6 before upgrade, TorBrowser with both of the meek transports worked fine.

With 10.12, (tested with admin and standard accounts), the initial tor connection UI completes, the browser opens and the initial meek connection is established. However, briefly after the browser window has opened with the successful about:tor page it is clear something is wrong. Monitoring internet traffic with a network monitor it is clear that the traffic to the meek server stops almost immediately after the browser has opened.

Having read some of the control port issues for other 10.12 users, I tested this issue with the extensions.torlauncher.control_port_use_socket pref set to false in prefs.js and without it, but it had no effect either way.

Attached are the tor, meek-client and meek-client-torbrowser logs. Really hope someone can help with this since meek is the only way to use tor in my country without having the police banging down the door.

Tor Log:

AUTHENTICATE <HASH>
250 OK
SETEVENTS STATUS_CLIENT NOTICE WARN ERR
250 OK
650 NOTICE Opening Socks listener on 127.0.0.1:9150
650 NOTICE Bootstrapped 5%: Connecting to directory server
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=5 TAG=conn_dir SUMMARY="Connecting to directory server"
650 NOTICE Bootstrapped 10%: Finishing handshake with directory server
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=10 TAG=handshake_dir SUMMARY="Finishing handshake with directory server"
650 NOTICE Bootstrapped 15%: Establishing an encrypted directory connection
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=15 TAG=onehop_create SUMMARY="Establishing an encrypted directory connection"
650 NOTICE Bootstrapped 20%: Asking for networkstatus consensus
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=20 TAG=requesting_status SUMMARY="Asking for networkstatus consensus"
650 NOTICE Bootstrapped 25%: Loading networkstatus consensus
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=25 TAG=loading_status SUMMARY="Loading networkstatus consensus"
650 STATUS_CLIENT NOTICE CONSENSUS_ARRIVED
650 STATUS_CLIENT NOTICE ENOUGH_DIR_INFO
650 NOTICE Bootstrapped 80%: Connecting to the Tor network
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=80 TAG=conn_or SUMMARY="Connecting to the Tor network"
650 NOTICE Bootstrapped 90%: Establishing a Tor circuit
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=90 TAG=circuit_create SUMMARY="Establishing a Tor circuit"
650 NOTICE Tor has successfully opened a circuit. Looks like client functionality is working.
650 NOTICE Bootstrapped 100%: Done
650 STATUS_CLIENT NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"
650 STATUS_CLIENT NOTICE CIRCUIT_ESTABLISHED
650 NOTICE New control connection opened from 127.0.0.1.
650 NOTICE New control connection opened from 127.0.0.1.

#NOTICE THE LINE BELOW:

650 WARN The connection to the SOCKS4 proxy server at 127.0.0.1:57343 just failed. Make sure that the proxy server is up and running.

650 NOTICE Delaying directory fetches: No running bridges
650 NOTICE Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit)

meek-client log:

0:05 using helper on 127.0.0.1:49193
0:05 listening on 127.0.0.1:49196
0:33 using helper on 127.0.0.1:49199
0:33 listening on 127.0.0.1:49202

meek-client-torbrowser log:

0:00 running firefox command --invisible" "-no-remote" "-profile" "/Applications/TorBrowser-Data/Tor/PluggableTransports/profile.meek-http-helper?
0:00 firefox started with pid 3644
0:01 running meek-client command --log" "meek-client.txt" "--helper" "127.0.0.1:49193?
0:01 meek-client started with pid 3646
0:27 sig terminated
0:27 sending signal terminated to PID 3646
0:27 killing PID 3646
0:27 killing PID 3644
0:32 running firefox command --invisible" "-no-remote" "-profile" "/Applications/TorBrowser-Data/Tor/PluggableTransports/profile.meek-http-helper?
0:32 firefox started with pid 3660
0:33 running meek-client command --log" "meek-client.txt" "--helper" "127.0.0.1:49199?
0:33 meek-client started with pid 3661
1:00 sig terminated
1:00 sending signal terminated to PID 3661
1:00 killing PID 3661
1:00 killing PID 3660

Child Tickets

Attachments (4)

tbb6.5a3.png (274.1 KB) - added by tordevSZ0 7 months ago.
tbb6.5a3conn.png (19.5 KB) - added by tordevSZ0 7 months ago.
meek-0.22-18371-3-go1.7.1.zip (2.7 MB) - added by dcf 7 months ago.
Build of meek-client and meek-client-torbrowser (tag 0.22-18371-3) for Darwin using Go 1.7.1.
meek-0.22-18371-3-go1.7.1.zip.asc (801 bytes) - added by dcf 7 months ago.
Signature for meek-0.22-18371-3-go1.7.1.

Change History (35)

comment:1 Changed 7 months ago by dcf

Does it fail if you disable the Firefox TLS camouflage? I suggest that because it is slightly tricky and involved subprocesses. Find your torrc-defaults file: it may be under "$HOME/Library/Application Support" or it might be in a directory next to TorBrowser.app called TorBrowser-data.

Change this line:

ClientTransportPlugin meek exec PluggableTransports/meek-client-torbrowser -- PluggableTransports/meek-client

to this:

ClientTransportPlugin meek exec PluggableTransports/meek-client

comment:2 Changed 7 months ago by cypherpunks

Can you test Tor Browser with removed data dir as described:
delete the "TorBrowser-Data" folder from "~/Library/Application Support" then fresh install of Tor Browser again.

And, if you can, preserve TorBrowser-Data folder to somewhere else before deleting it, so to investigate it later in case of success.

comment:3 Changed 7 months ago by tordevSZ0

cypherpunks, this error was observed on a fresh install after all persistent directories (~/Library/Application Support/TorBrowser-Data, /Applications/TorBrowser-Data and /Applications/TorBrowser.app) had been removed. Just retested on another machine with a fresh install of 10.12. Had exactly the same results. Sometimes you can be lucky and the meek process remains functioning for a while before crashing and then you have to restart. Never continues working for more than a minute.

comment:4 Changed 7 months ago by tordevSZ0

dcf. By modifying the meek PT in torrc-defaults the connection fails immediately.

1 connections have failed:
1 connections died in state handshaking (TLS) with SSL state SSLv2/SSLv3 read server hello A in HANDSHAKE

comment:5 Changed 7 months ago by tordevSZ0

Here is a list of connections made during an attempted connection (ignore the 1st failed connections as commented, but notice the PIDs to understand the process connection relationships and which ones fail in the real failed connection attempt in part 2).Hope is possible to follow.

PART 1 - FAILED ATTEMPT (THIS CONNECTION FAILED DUE TO HUMAN ERROR, BUT SETS UP PROCESSES/PIDs, SO WILL SHOW HERE, PERSISTENT FAILURE OCCURRED DURING PART 2)

process format: procname.PID
ff=firefox

START:

ff.4636 loads

tor.real.4637 loads

tor.real.4637 opens 127.0.0.1:9151 <-> *:* (listen)

ff.4636 opens *:* <-> *:*

tor.real.4637 opens

127.0.0.1:9151 <-> 127.0.0.1:49332
127.0.0.1:9151 <-> 127.0.0.1:49333

ff.4636 opens *:* <-> *:*

tor.real.4637 opens *:* <-> *:*

ff4636 converts the two open *:*<->*:* connections to

127.0.0.1:49332 <-> 127.0.0.1:9151
127.0.0.1:49333 <-> 127.0.0.1:9151

tor.real 4637 converts *:* <-> *:* to

127.0.0.1:9150 <-> *:*

ff.4640 is launched and opens *:* <-> *:*

meek-client.4652 launches

ff.4640 converts *:* <-> *:* to

127.0.0.1:49344: <-> *:*

meek-client.4652 opens tcp6 *:* <->

meek-client.4652 converts *:*<->*:* to

tcp4 127.0.0.1:49337 <-> *:*

to.real.4637 opens *:* <-> *:*

meek-client.4652 opens

127.0.0.1:49337 <-> 127.0.0.1:49338

tor.real.4637 converts *:*<->*:* to

127.0.0.1:49338 <-> 127.0.0.1:49337

meek-client.4652 opens *:*<->*:*

ff.4640 opens

127.0.0.1:49334 <-> 127.0.0.1:49339

meek-client.4652 converts *:*<->*:* to

127.0.0.1:49339 <-> 127.0.0.1:49334

ff.4640 opens

LOCALIP:49340 <-> <AMZN>:443

MEEK

ff.4640 closes connection

127.0.0.1:49334 <-> 127.0.0.1:49339

meek-client.4652 converts

127.0.0.1:49339 <-> 127.0.0.1:49334

ff.4640 opens

127.0.0.1:49334 <-> 127.0.0.1:49343

meek-client.4652 opens

127.0.0.1:49343 <-> 127.0.0.1:49334

tor.real.4637 closes

127.0.0.1:9150 <-> *:*
127.0.0.1:49338 <-> 127.0.0.1:49337

ff.4640 closes

127.0.0.1:49334 <-> *:*
LOCALIP:49340 <-> <AMZN>:443
127.0.0.1:49334 <-> 127.0.0.1:49343

meek-client.4652 closes

127.0.0.1:49337 <-> *:*
127.0.0.1:49337 <-> 127.0.0.1:49338
127.0.0.1:49343 <-> 127.0.0.1:49334

ff.4640 and meek-client.4652 close

END OF PART 1 (INITIAL FAIL - NOT WHERE KEY DETAILS LIE, JUST NOTE PIDs)

following connections remain from part 1

ff.4636

127.0.0.1:49332 <-> 127.0.0.1:9151
127.0.0.1:49333 <-> 127.0.0.1:9151

tor.real.4637

127.0.0.1:9151 <-> *:*
127.0.0.1:9151 <-> 127.0.0.1:49332
127.0.0.1:9151 <-> 127.0.0.1:49333

——————

START OF PART 2 (WHERE REAL FAILURE OCCURS)

tor.real.4637 opens

*:* <-> *:*

tor.real.4637 converts *:*<->*:* to

127.0.0.1:9150 <-> *:*

ff.4673 launched and opens

*:* <->*:*

meek-client.4674 launched

ff.4673 converts *:* <-> *:* to

127.0.0.1:49344 <-> *:*

meek-client.4674 opens

127.0.0.1:49347 <-> *:*

tor.real.4637 opens *:*<->*:*

meek0client.4674 opens

127.0.0.1:49347 <-> 127.0.0.1:49348

tor.real.4637 converts *:*<->*:* to

127.0.0.1:49348 <-> 127.0.0.1:49347

meek-client.4674 opens *:*<->*:*

ff.4673 opens

127.0.0.1:49344 <-> 127.0.0.1:49349

ff.4673 converts

127.0.0.1:49344 <-> 127.0.0.1:49349

ff.4673 converts

127.0.0.1:49344 <-> 127.0.0.1:49347

to

LOCALIP:49100 <-> <AMZN>:443

meek-client.4674 converts *:*<->*:* to

127.0.0.1:49351 <-> 127.0.0.1:49344

ff.4673 opens

127.0.0.1:49344 <-> 127.0.0.1:49352

meek-client.4674 converts

127.0.0.1:49351 <-> 127.0.0.1:49344

to

127.0.0.1:49352 <-> 127.0.0.1:49344

ff.4673 closes

127.0.0.1:49344 <-> 127.0.0.1:49352

meek-client.4674 converts

127.0.0.1:49352 <-> 127.0.0.1:49344

to

127.0.0.1:49353 <-> 127.0.0.1:49344

to

127.0.0.1:49354 <-> 127.0.0.1:49344

to

127.0.0.1:49355 <-> 127.0.0.1:49344

to

*:*<->*:*

127.0.0.1:49357 <-> 127.0.0.1:49344

to

127.0.0.1:49358 <-> 127.0.0.1:49344

to

127.0.0.1:49359 <-> 127.0.0.1:49344

to

*:*<->*:*

127.0.0.1:49361 <-> 127.0.0.1:49344

to

127.0.0.1:49362 <-> 127.0.0.1:49344

to

127.0.0.1:49363 <-> 127.0.0.1:49344

to

127.0.0.1:49363 <-> 127.0.0.1:49344

to

127.0.0.1:49364 <-> 127.0.0.1:49344

to

127.0.0.1:49365 <-> 127.0.0.1:49344

to

127.0.0.1:49366 <-> 127.0.0.1:49344

to

*:*<->*:*

to

127.0.0.1:49368 <-> 127.0.0.1:49344

to

*:*<->*:*

to


127.0.0.1:49369 <-> 127.0.0.1:49344

ff.4673 opens

127.0.0.1:49344 <-> 127.0.0.1:49369


meek-client.4673 converts

127.0.0.1:49369 <-> 127.0.0.1:49344

to

*:*<->*:*

ff.4673 closes

127.0.0.1:49344 <-> 127.0.0.1:49369

meek-client.4674 converts

*:* <->*:*

to

127.0.0.1:49371 <-> 127.0.0.1:49344

| goes through :49371 -> :49380 in steps of 1 port
\/


127.0.0.1:49380 <-> 127.0.0.1:49344

to

*:*<->*:*

to

127.0.0.1:49382 <-> 127.0.0.1:49344

| goes through :49382 -> :49385 in steps of 1 port
\/


127.0.0.1:49385 <-> 127.0.0.1:49344

to

*:* <-> *:*

to

127.0.0.1:49387 <-> 127.0.0.1:49344

| goes through :49387 -> :49392 in steps of 1 port
\/

127.0.0.1:49392 <-> 127.0.0.1:49344

then closes

ff.4673 opens

127.0.0.1:49344 <-> 127.0.0.1:49392

then promptly closes again

meek-client.4674 opens

*:*<-> *:*

ff.4673 opens

127.0.0.1:49344 <-> 127.0.0.:49393

meek-client.4674 opens and closes

*:*<->*:*

ff.4673 opens

127.0.0.1:49344 <-> 127.0.0.1:49393

meek-client.4674 opens and closes *:* <-> *:*

ff.4673 opens

127.0.0.1:49344 <-> 127.0.0.1:49394

and closed

meek-client.4674 opens *:*<->*:*

and converts to

127.0.0.1:49396 <-> 127.0.0.1:49344

| goes through :49396 -> :49398 in steps of 1 port
\/

127.0.0.1:49398 <-> 127.0.0.1:49344

ff.4673 opens

127.0.0.1:49344 <-> 127.0.0.1:49398

and closed

meek-client.4674 opens

127.0.0.1:49400 <-> 127.0.0.1:49344

closed

ff.4673 opens

127.0.0.1:49344 <-> 127.0.0.1:49401

tor.real.4637 closes

127.0.0.1:49348 <-> 127.0.0.1:49347

ff.4673 closes

127.0.0.1:49344 <-> 127.0.0.1:49401

meek-client.4674 closes

127.0.0.1:49347 <-> 127.0.0.1:49348

tor.real.4637 closes 127.0.0.1:9150 <-> *:*

ff.4673 closes

127.0.0.1:49344 <-> *:*
LOCALIP:49100 <-> <AMZN>:443

meek-client.4674 quits

ff.4673 quits

ff.4636 closes

127.0.0.1:49332 <-> 127.0.0.1:9151
127.0.0.1:49333 <-> 127.0.0.1:9151

tor.real.4637 closes

127.0.0.1:9151 <-> *:*
127.0.0.1:9151 <-> 127.0.0.1:49332
127.0.0.1:9151 <-> 127.0.0.1:49333

ff.4636 quits
tor.real.4637 quits

Last edited 7 months ago by tordevSZ0 (previous) (diff)

comment:6 follow-up: Changed 7 months ago by cypherpunks

On the same machine running 10.11.6 before upgrade, TorBrowser with both of the meek transports worked fine.

It's probably coincidence. Might be censors update their filters too?

By modifying the meek PT in torrc-defaults the connection fails immediately.

Can you test your configuration outside of censored network? Or test it with modified front for meek

comment:7 in reply to: ↑ 6 Changed 7 months ago by tordevSZ0

Replying to cypherpunks:

On the same machine running 10.11.6 before upgrade, TorBrowser with both of the meek transports worked fine.

It's probably coincidence. Might be censors update their filters too?

By modifying the meek PT in torrc-defaults the connection fails immediately.

Can you test your configuration outside of censored network? Or test it with modified front for meek

I really don't think it is a coincidence. As I said here https://trac.torproject.org/projects/tor/ticket/20251#comment:5, I am acecssing TRAC using meek with TorBrowser on 10.11.6 right now without any problems while two machines running fresh installs of 10.12 in the same country as the 10.11.6 installation, with clean installs of TorBrowser are unable to maintain the meek connections.

If you read through https://trac.torproject.org/projects/tor/ticket/20250?replyto=6#comment:5, especially at the end of the log, and the line:

"650 WARN The connection to the SOCKS4 proxy server at 127.0.0.1:57343 just failed. Make sure that the proxy server is up and running."

in the main ticket, it seems meek-client is crashing.

comment:8 Changed 7 months ago by cypherpunks

it seems meek-client is crashing.

There are no facts about crashing or terminating meek abnormally in your logs

tor.real.4637 closes 127.0.0.1:9150 <-> *:*

ff.4673 closes

127.0.0.1:49344 <-> *:*
LOCALIP:49100 <-> <AMZN>:443

meek-client.4674 quits

ff.4673 quits

it seems meek quits when tor were finished (socks port closed on exit)

comment:9 follow-up: Changed 7 months ago by cypherpunks

tor were finished (socks port closed on exit)

Or DisableNetwork option activated

comment:10 in reply to: ↑ 9 Changed 7 months ago by tordevSZ0

Replying to cypherpunks:

tor were finished (socks port closed on exit)

Or DisableNetwork option activated

Has anyone else actually tried using meek with TorBrowser for more than 2 minutes on 10.12?

comment:11 in reply to: ↑ description ; follow-ups: Changed 7 months ago by dcf

Replying to tordevSZ0:

Having issues using the meek pluggable transports on macOS 10.12 installation with a fresh install of TorBrowser.

Are you using the stable release 6.0.5, or the alpha release 6.5a3?

In the stable 6.0.5, meek is compiled with Go 1.4.3. In the alpha 6.5a3, meek is compiled with Go 1.6.3. Go 1.6.3 has a fix for Sierra; Go 1.4.3 does not have the fix. If this Go bug is the cause, then the alpha release may work for you where the stable release does not.

Note that there is an unrelated bug in the alpha release, #20030, which means that you will have to manually kill the firefox and meek-client processes after you close the browser.

Please try the alpha release 6.5a3. If it works for you, that means we have to use a newer version of Go to compile the next stable release.

comment:12 in reply to: ↑ 11 ; follow-ups: Changed 7 months ago by tordevSZ0

Replying to dcf:

Replying to tordevSZ0:

Having issues using the meek pluggable transports on macOS 10.12 installation with a fresh install of TorBrowser.

Are you using the stable release 6.0.5, or the alpha release 6.5a3?

In the stable 6.0.5, meek is compiled with Go 1.4.3. In the alpha 6.5a3, meek is compiled with Go 1.6.3. Go 1.6.3 has a fix for Sierra; Go 1.4.3 does not have the fix. If this Go bug is the cause, then the alpha release may work for you where the stable release does not.

Note that there is an unrelated bug in the alpha release, #20030, which means that you will have to manually kill the firefox and meek-client processes after you close the browser.

Please try the alpha release 6.5a3. If it works for you, that means we have to use a newer version of Go to compile the next stable release.

This may be an error on my part, but when using a fresh install of 6.5a3 on 10.12, the initial Tor Network Settings window opens, but fails to connect to the tor control port, even with extensions.torlauncher.control_port_use_socket pref set to false in prefs.js. I monitor file accesses by applications and noticed that the TorBrowser.app, after creating and writing to the '~/Library/Application Support/TorBrowser-Data' directory as it should, then tries to write to the non-existent '~/Library/Application', and then times out trying to connect to tor.real with the message 'failed to connect to control port'. It might be something else, but this makes me wonder whether a hard-coded path with spaces in it isn't written properly - e.g. ~/Library/Application Support which would yield ~/Library/Application with an error instead of '~/Library/Application Support'.

Changed 7 months ago by tordevSZ0

comment:13 in reply to: ↑ 11 Changed 7 months ago by tordevSZ0

Replying to dcf:

Replying to tordevSZ0:

Having issues using the meek pluggable transports on macOS 10.12 installation with a fresh install of TorBrowser.

Are you using the stable release 6.0.5, or the alpha release 6.5a3?

In the stable 6.0.5, meek is compiled with Go 1.4.3. In the alpha 6.5a3, meek is compiled with Go 1.6.3. Go 1.6.3 has a fix for Sierra; Go 1.4.3 does not have the fix. If this Go bug is the cause, then the alpha release may work for you where the stable release does not.

Note that there is an unrelated bug in the alpha release, #20030, which means that you will have to manually kill the firefox and meek-client processes after you close the browser.

Please try the alpha release 6.5a3. If it works for you, that means we have to use a newer version of Go to compile the next stable release.

I added an attachment to the main ticket showing TorBrowser.app trying to write to the non-existent directory '~/Library/Application' https://trac.torproject.org/projects/tor/attachment/ticket/20250/tbb6.5a3.png

comment:14 Changed 7 months ago by gk

Yes, dragging 6.5a3 just to your desktop for testing purposes should help here.

comment:15 in reply to: ↑ 12 Changed 7 months ago by dcf

Replying to tordevSZ0:

Replying to dcf:

Replying to tordevSZ0:

Having issues using the meek pluggable transports on macOS 10.12 installation with a fresh install of TorBrowser.

Please try the alpha release 6.5a3. If it works for you, that means we have to use a newer version of Go to compile the next stable release.

This may be an error on my part, but when using a fresh install of 6.5a3 on 10.12, the initial Tor Network Settings window opens, but fails to connect to the tor control port, even with extensions.torlauncher.control_port_use_socket pref set to false in prefs.js. I monitor file accesses by applications and noticed that the TorBrowser.app, after creating and writing to the '~/Library/Application Support/TorBrowser-Data' directory as it should, then tries to write to the non-existent '~/Library/Application', and then times out trying to connect to tor.real with the message 'failed to connect to control port'. It might be something else, but this makes me wonder whether a hard-coded path with spaces in it isn't written properly - e.g. ~/Library/Application Support which would yield ~/Library/Application with an error instead of '~/Library/Application Support'.

What you describe really sounds like #20210 (also #20215, #18753), but that should have been fixed by setting extensions.torlauncher.control_port_use_socket=false.

Please try installing the alpha bundle into a directory other than /Applications, for example in your home directory or on your desktop. That should work around the space issue either way.

comment:16 in reply to: ↑ 12 ; follow-up: Changed 7 months ago by dcf

Replying to tordevSZ0:

This may be an error on my part, but when using a fresh install of 6.5a3 on 10.12, the initial Tor Network Settings window opens, but fails to connect to the tor control port, even with extensions.torlauncher.control_port_use_socket pref set to false in prefs.js.

I think I know why setting this pref appeared to have no effect. You have to edit the prefs.js file found under ~/Library/Application Support/TorBrowser-Data, not the one in the installation directory under /Applications. The one under /Applications doesn't have an effect once it is copied to ~/Library/Application Support/TorBrowser-Data.

comment:17 Changed 7 months ago by tordevSZ0

I edited ~/Library/Application Support/TorBrowser-Data/Browser/<PROFILE>/prefs.js. Will try to test it again with the .app outside /Applications and extensions.torlauncher.control_port_use_socket pref set to false in prefs.js (Application Support).

comment:18 in reply to: ↑ 16 Changed 7 months ago by tordevSZ0

Replying to dcf:

Replying to tordevSZ0:

This may be an error on my part, but when using a fresh install of 6.5a3 on 10.12, the initial Tor Network Settings window opens, but fails to connect to the tor control port, even with extensions.torlauncher.control_port_use_socket pref set to false in prefs.js.

I think I know why setting this pref appeared to have no effect. You have to edit the prefs.js file found under ~/Library/Application Support/TorBrowser-Data, not the one in the installation directory under /Applications. The one under /Applications doesn't have an effect once it is copied to ~/Library/Application Support/TorBrowser-Data.

Placing TorBrowser.app (v6.5a3) on the Desktop solved the control port issue, but connecting with meek had the same issue as 6.0.5. The first time, the connection UI completed, traffic went through to the meek server for around a minute and a half (longer than normal, yes, but I think this may have been a coincidence (seen this long on 6.0.5 also). I tested a few more times and it behaved as with 6.0.5, lasting very short period and stopping abruptly. Logs were also essentially the same as I have already posted.

Changed 7 months ago by tordevSZ0

comment:19 Changed 7 months ago by tordevSZ0

See the attachment above for a snapshot of a network monitor showing the connection to the meek server failing abruptly. https://trac.torproject.org/projects/tor/attachment/ticket/20250/tbb6.5a3conn.png

comment:20 Changed 7 months ago by mcs

  • Cc brade mcs added

comment:21 follow-up: Changed 7 months ago by tordevSZ0

Is there any news on this? Can someone else test this? Mac tor users in countries where tor is blocked rely on meek.

comment:22 Changed 7 months ago by boklm

  • Cc boklm added

comment:23 in reply to: ↑ 21 Changed 7 months ago by dcf

Replying to tordevSZ0:

Is there any news on this? Can someone else test this? Mac tor users in countries where tor is blocked rely on meek.

We talked about it in the Tor Browser meeting today. The next step is to try to reliably reproduce the behavior you reported.

comment:24 follow-up: Changed 7 months ago by mcs

Kathy and I tried to reproduce this problem using TB 6.5a3 on an macOS Sierra system. Using the built-in meek-amazon option, we experienced general flakiness: sometimes Tor bootstrapping would stop, sometimes bootstrapping would complete but we could not load any pages, and sometimes we could browse for a short time.

At least some of the time, the meek-client process disappears. Just now, I caught it in a crash after attaching lldb to it. Here is the stacktrace:

* thread #8: tid = 0x873b, 0x0001214f meek-client`runtime.unlock + 271, stop reason = EXC_BAD_ACCESS (code=1, address=0xe5db311a)
  * frame #0: 0x0001214f meek-client`runtime.unlock + 271
    frame #1: 0x000328b1 meek-client`runtime.findrunnable + 849
    frame #2: 0x000330f6 meek-client`runtime.schedule + 502
    frame #3: 0x00033331 meek-client`runtime.park_m + 337
    frame #4: 0x00052e23 meek-client`runtime.mcall + 67

I somewhat randomly found this article which implies but does not confirm that go 1.7 may include fixes for Sierra that are not in 1.6.3: https://github.com/github/git-lfs/issues/1440
Maybe we should try to compile meek with go 1.7?

Changed 7 months ago by dcf

Build of meek-client and meek-client-torbrowser (tag 0.22-18371-3) for Darwin using Go 1.7.1.

Changed 7 months ago by dcf

comment:25 in reply to: ↑ 24 Changed 7 months ago by dcf

  • Keywords changed from meek, macOS, TorBrowser, 10.12, sierra, macOS to meek, macOS, TorBrowser, 10.12, sierra
  • Status changed from new to needs_information
  • Version Tor: unspecified deleted

Replying to mcs:

I somewhat randomly found this article which implies but does not confirm that go 1.7 may include fixes for Sierra that are not in 1.6.3: https://github.com/github/git-lfs/issues/1440
Maybe we should try to compile meek with go 1.7?

I think you're right. While I didn't find any mention of a problem in the Go 1.7 release notes nor the 1.7.1 milestone, further searching turned up:

  • GH#16352 2016-08-02: "As of Sierra Beta 4, this issue is again relevant." (Go 1.6.3 was released before that, 2016-07-07.)
  • GH#16570 2016-08-02: "Wanted to add this also happens with 1.6.3"
  • 2da5633e 2016-08-02: "fix nanotime for macOS Sierra, again."
  • GH#17234 2016-09-26: "backport 'fix nanotime for macOS Sierra, again' to go 1.6.x maybe"

tordevSZ0, mcs, I made a build of meek-client and meek-client-torbrowser using Go 1.7.1. Please try copying it into your installation and see if it helps:

attachment:meek-0.22-18371-3-go1.7.1.zip
attachment:meek-0.22-18371-3-go1.7.1.zip.asc

If you prefer to build it from source yourself:

git clone https://git.torproject.org/pluggable-transports/meek.git
cd meek
git checkout 0.22-18371-3
(GOOS=darwin GOARCH=amd64 cd meek-client && go build)
(GOOS=darwin GOARCH=amd64 cd meek-client-torbrowser && go build)

comment:26 Changed 7 months ago by mcs

Using either the build from comment:25 or my own build fixes this problem for me. It would be great to have another data point, but go 1.7.1 seems to be the answer.

comment:27 Changed 7 months ago by tordevSZ0

Can confirm that the meek build with go 1.7.1 seems to fix the problem using both 6.0.5 and 6.5a3.

comment:28 Changed 7 months ago by dcf

  • Summary changed from macOS 10.12 TorBrowser meek pluggable transport issues to meek fails on macOS 10.12 when built with Go 1.4.3 or Go 1.6.3

Thanks, tordevSZ0, for making the report and for your cooperation, and thanks mcs for testing. Ticket #20023 is about upgrading Go to 1.7.1. Once that is merged, the problem should be resolved and we can close this ticket.

comment:29 Changed 6 months ago by gk

  • Resolution set to fixed
  • Status changed from needs_information to closed

This should be fixed in 6.0.6 and 6.5a4.

comment:30 Changed 6 months ago by gk

  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening due to build bustage (see #20023).

comment:31 Changed 6 months ago by gk

  • Resolution set to fixed
  • Status changed from reopened to closed

It turns our the segfaulting in #20023 was spurious, closing again.

Note: See TracTickets for help on using tickets.