Opened 3 years ago

Closed 3 years ago

#20379 closed defect (fixed)

Can't initially connect to bridges after new network connection

Reported by: qbi Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: ln5, teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm running TBB 6.5a3 with 6 obfs4 and 3 scramblesuit bridges. When I change networks (e.g. home -> work or cable -> wifi) and thus get new IP addresses, all URLs I visit in TBB time out. I tried to reload the URLs three or four times with the same result. But if I open the network settings, go to the bridge settings and press the OK button, everything works. So I make no changes to the settings. I just open them and close them.

I copied the log from the TBB interface (I changed the original fingerprint and IP):

12.10.2016 12:28:51.200 [NOTICE] Bootstrapped 5%: Connecting to directory server
12.10.2016 12:28:51.200 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server
12.10.2016 12:28:51.600 [WARN] Proxy Client: unable to connect to 64.137.204.112:50979 ("general SOCKS server failure")
12.10.2016 12:28:52.000 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection
12.10.2016 12:28:52.300 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus
12.10.2016 12:28:52.800 [NOTICE] new bridge descriptor 'Unnamed' (fresh): FP1~NAME1 at IP1
12.10.2016 12:28:52.800 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
12.10.2016 12:28:53.200 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus
12.10.2016 12:28:53.300 [WARN] Proxy Client: unable to connect to IP1 ("general SOCKS server failure")
12.10.2016 12:28:54.800 [NOTICE] new bridge descriptor 'Unnamed' (fresh): FP2~NAME2 at IP2
12.10.2016 12:28:54.800 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
12.10.2016 12:29:05.000 [NOTICE] I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.
12.10.2016 12:29:35.700 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
12.10.2016 12:29:35.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
12.10.2016 12:29:35.700 [NOTICE] Closing old Socks listener on 127.0.0.1:9150
12.10.2016 12:29:36.500 [NOTICE] Delaying directory fetches: DisableNetwork is set.

Steps to reproduce:

  1. Get some bridges.
  2. Change networks (get a new IP address)
  3. Enter an URL --> time out
  4. Open network settings, point the cursor into the field where bridges are set and click on the OK button
  5. Open a new URL or reload the old one --> site will open

Do you need more information? Should I try to log with debug information?

Child Tickets

Change History (19)

comment:1 Changed 3 years ago by gk

I assume this is a recent issue, right? If so, the most helpful thing would be trying to track down when this started. Checking whether the stable Tor Browser has this problem as well might be good, too. Older versions can be found on https://archive.torproject.org/tor-package-archive/torbrowser/.

comment:2 Changed 3 years ago by qbi

I tested with 6.5a2 before the initial connect I entered the bridges I had in my other browser and waited at least ten minutes for a connection. Later I tried a direct connection, which worked, and added the bridges, which also worked. I closed TBB again and tried to restart it with the bridge settings. It was not possible to make an initial connection.

comment:3 Changed 3 years ago by qbi

Same with 6.5a1.

However I noticed that 6.5a2 stopped at the message "Relaisinformationen werden geladen" (Loading relais infos) while 6.5a1 stopped at "Autorisierungszertifikate werden geladen".

comment:4 Changed 3 years ago by qbi

I tested different versions and am now at version TBB 5.5. Also this version shows the behaviour described above.

comment:5 Changed 3 years ago by ln5

Cc: ln5 added

comment:6 Changed 3 years ago by qbi

I did some further testing and here are my notes:

  1. When I had bridges with PTs set, I had problems with the initial connection from version 5.5 to a recent alpha version. The only thing which helped was removing bridge information, start TBB and add them again. After that TBB worked without any problems.
  2. Version 5.5 to 6.0 works with bridges and with changes in networks. So when I changed networks I had to wait for quite some time (>5 minutes) and then bridges started to work. Without bridges TBB worked nearly instantaneous. So I assume there is already some problem here
  3. I tried the network change with version 6.5a1 and waited now for ~30 minutes. I constantly reloaded the site when I got the timeout message from Firefox. So far without success. After I opened the network menu and closed it, the page opened. So 6.5a1 has the problem which I described above.

comment:7 Changed 3 years ago by teor

Cc: teor added

comment:8 Changed 3 years ago by gk

Thanks for looking into it. It seems we can put 1. and 2. on the backburner for now (and maybe have different tickets for them).

6.5a1 is the first alpha that uses 0.2.8.3-alpha, the previous one was on 0.2.8.2-alpha. Do you think you can bisect the problem? Replacing tor in Browser/TorBrowser/Tor with the respective one you compiled should do the trick. Before you start doing that, though, you could make sure whether 0.2.8.3-alpa is really the culprit here by copying tor from 6.5a1 over to a 6.0a5 bundle.

comment:9 Changed 3 years ago by qbi

I'll bisect the problem and report back.

comment:10 Changed 3 years ago by qbi

Here are the preliminary results based on my bisecting efforts. What did I do after starting the bisecting?

  1. make clean
  2. ./autogen.sh
  3. ./configure --disable-asciidoc
  4. make
  5. cp src/or/tor $TBB/Browser/TorBrowser/Tor
  6. Open TBB, go to https://check.torproject.org/ and click on the Q&A as well as the Volunteers link.
  7. Change to another network
  8. Check that the current network connections works without Tor
  9. Open some random links in the Q&A and volunteers page
  10. wait for some minutes
  11. In the good case it usually takes less than five minutes until the connection works. In the bad case it "never" works. Figure out what case it is.
  12. git bisect good/bad
  13. GOTO 1

The output I got after the first round of bisecting is:

git bisect start
# bad: [7010e8593978ff52e4f81e959f39e6215cd72a15] changes file for 20389
git bisect bad 7010e8593978ff52e4f81e959f39e6215cd72a15
# good: [9a4cac74fd2f4bb300830e06ff56f74ccf91e373] A day has passed.
git bisect good 9a4cac74fd2f4bb300830e06ff56f74ccf91e373
# bad: [6cc3397e26ff37d6f01471b83e0e5bb1b5aa8eee] Merge remote-tracking branch 'teor/fallback-script' into maint-0.2.8
git bisect bad 6cc3397e26ff37d6f01471b83e0e5bb1b5aa8eee
# bad: [ff3e90070fd21788ac2c1c9116f18c9b888c750a] Merge branch 'maint-0.2.7'
git bisect bad ff3e90070fd21788ac2c1c9116f18c9b888c750a
# bad: [8a41d2a1d9eb65268d0f36e39d0ade77f5a39307] Merge branch 'maint-0.2.7'
git bisect bad 8a41d2a1d9eb65268d0f36e39d0ade77f5a39307
# bad: [34b4da709d04a64e52f023f7fa54fdbab270546f] Fix a bunch more memory leaks in the tests.
git bisect bad 34b4da709d04a64e52f023f7fa54fdbab270546f
# good: [11e3db3ee876c8cc161d6bb019cbb19a1b623b6c] clean up whitespace
git bisect good 11e3db3ee876c8cc161d6bb019cbb19a1b623b6c
# bad: [cd14405a431cf351abe79441214899cfee5eb670] Merge remote-tracking branch 'origin/maint-0.2.7'
git bisect bad cd14405a431cf351abe79441214899cfee5eb670
# bad: [aaa27b995c03f6fe07849021e0302ecd9b720551] changes file for #16563
git bisect bad aaa27b995c03f6fe07849021e0302ecd9b720551
# good: [c44a94606a27e3dd9eb02083c05d87f9fe049b91] Use __FUNCTION__ instead of __PRETTY_FUNCTION__
git bisect good c44a94606a27e3dd9eb02083c05d87f9fe049b91
# good: [bfd9dccdb8692a8d1d04c1c4004bc4bd3236c7b1] Merge remote-tracking branch 'origin/maint-0.2.7'
git bisect good bfd9dccdb8692a8d1d04c1c4004bc4bd3236c7b1
# good: [20ec030d9b6ff0e403e37d2161f3e53dfd6dd622] Fix compilation with openssl 1.1 by forcibly disabling some tests
git bisect good 20ec030d9b6ff0e403e37d2161f3e53dfd6dd622
# good: [41782bf3ac0ce1d2b3363585e652dfe944a9a58e] Merge remote-tracking branch 'tvdw/fix-16563'
git bisect good 41782bf3ac0ce1d2b3363585e652dfe944a9a58e
# first bad commit: [aaa27b995c03f6fe07849021e0302ecd9b720551] changes file for #16563

I'll do some rechecking over the next days, because this was a highly manual process which is prone to errors. Also it depends on the network conditions. So I want to see if I can reproduce this result. If it is done, I'll report back.

comment:11 in reply to:  6 ; Changed 3 years ago by arma

Replying to qbi:

  1. I tried the network change with version 6.5a1 and waited now for ~30 minutes. I constantly reloaded the site when I got the timeout message from Firefox. So far without success. After I opened the network menu and closed it, the page opened. So 6.5a1 has the problem which I described above.

Sounds like this one could be #19969. That bug started in 0.2.8.1-alpha.

comment:12 in reply to:  11 Changed 3 years ago by arma

Replying to arma:

Sounds like this one could be #19969. That bug started in 0.2.8.1-alpha.

Here's one of the ChangeLog stanzas from the #19969 fix:

  o Major bugfixes (clients on flaky network connections);
    - When Tor leaves standby because of a new application request, open
      circuits as needed to serve that request. Previously, we would
      potentially wait a very long time. Fixes part of bug 19969; bugfix
      on 0.2.8.1-alpha.

comment:13 Changed 3 years ago by gk

Status: newneeds_information

qbi: Could you test whether arma was right in comment:11? The fix for #19969 landed on master.

comment:14 in reply to:  13 Changed 3 years ago by gk

Replying to gk:

qbi: Could you test whether arma was right in comment:11? The fix for #19969 landed on master.

6.5a4 should have this fix as well. If it is #19969.

comment:15 Changed 3 years ago by qbi

I just upgraded to 6.5a4 and couldn't reproduce the behaviour anymore.

comment:16 Changed 3 years ago by qbi

It also works with current master (c35d481f56284ebeafc2860eed27c9833d631983), but my impression is that it takes quite long to get a working connection. I had to reload pages two to three times.

comment:17 in reply to:  15 Changed 3 years ago by gk

Resolution: duplicate
Status: needs_informationclosed

Replying to qbi:

I just upgraded to 6.5a4 and couldn't reproduce the behaviour anymore.

Great. Resolving this as duplicate of #19969 then, thanks!

comment:18 Changed 3 years ago by gk

Resolution: duplicate
Status: closedreopened

Upon closer inspection #19969 got reopened and might describe a related but not this issue. Anyway, fixed by switching to 0.2.9.5-alpha.

comment:19 Changed 3 years ago by gk

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.