This repository has been archived by the owner on Dec 11, 2019. It is now read-only.
Browser doesn't connect to TOR on initial launch. #14517
Assignees
Milestone
Comments
|
I believe this is Windows only - works great on macOS and Linux. On Windows when connecting, I get the following via stdout: When looking at the tor logs though, version 3.3.7 is used and it appears to launch successfully |
|
After receiving the above, I manually deleted the 1st relaunch (which did not work) had the following on stdout: 2nd relaunch (which does work) has this output via stdout Subsequent relaunches do not work |
|
Can you share, from two consecutive runs, the following things?
|
riastradh-brave
added a commit
that referenced
this issue
Jun 22, 2018
The tor daemon writes the control port first, and then the auth cookie. Currently we _read_ them in that order too, which means the following sequence of events might happen: 1. tor writes controlport 2. we read new controlport 3. we read stale control_auth_cookie and give up 4. tor writes control_auth_cookie Because I inexplicably wasn't thinking about it earlier, I put in two kludges to work around this: - We check the mtimes on the control port and control_auth_cookie, which is the basis on which we give up in step (2). Alone, this would be harmless, but: - We rename controlport to controlport.ack so we never read a stale version -- but that means if we give up on control_auth_cookie then we get wedged. This changes brave to read the auth cookie first, and then the control port. If we successfully read the auth cookie, _then_ we are guaranteed that the control port has been written, since the control port write happens before the auth cookie write. Since the read order is correct now, the kludges should be safely eliminable and the logic simplified. However, I will defer that simplification to a subsequent change. fix #14517 Auditors: @diracdeltas @bsclifton Test Plan: 1. Launch Brave. 2. Confirm private tabs with Tor work. 3. Exit Brave. 4. Relaunch Brave. 5. Confirm private tabs with Tor still work. The symptom that this fixes is that in step (5), Brave thinks that Tor can't connect to the network, but the tor daemon reports in $BRAVE/tor/dta/tor.log that it did successfully connect to the network. This seems to happen only on Windows.
riastradh-brave
added a commit
that referenced
this issue
Jun 22, 2018
The tor daemon writes the control port first, and then the auth cookie. Currently we _read_ them in that order too, which means the following sequence of events might happen: 1. tor writes controlport 2. we read new controlport 3. we read stale control_auth_cookie and give up 4. tor writes control_auth_cookie Because I inexplicably wasn't thinking about it earlier, I put in two kludges to work around this: - We check the mtimes on the control port and control_auth_cookie, which is the basis on which we give up in step (2). Alone, this would be harmless, but: - We rename controlport to controlport.ack so we never read a stale version -- but that means if we give up on control_auth_cookie then we get wedged. This changes brave to read the auth cookie first, and then the control port. If we successfully read the auth cookie, _then_ we are guaranteed that the control port has been written, since the control port write happens before the auth cookie write. Since the read order is correct now, the kludges should be safely eliminable and the logic simplified. However, I will defer that simplification to a subsequent change. fix #14517 Auditors: @diracdeltas @bsclifton Test Plan: 1. Launch Brave. 2. Confirm private tabs with Tor work. 3. Exit Brave. 4. Relaunch Brave. 5. Confirm private tabs with Tor still work. The symptom that this fixes is that in step (5), Brave thinks that Tor can't connect to the network, but the tor daemon reports in $BRAVE/tor/dta/tor.log that it did successfully connect to the network. This seems to happen only on Windows.
10 tasks
diracdeltas
pushed a commit
that referenced
this issue
Jun 22, 2018
The tor daemon writes the control port first, and then the auth cookie. Currently we _read_ them in that order too, which means the following sequence of events might happen: 1. tor writes controlport 2. we read new controlport 3. we read stale control_auth_cookie and give up 4. tor writes control_auth_cookie Because I inexplicably wasn't thinking about it earlier, I put in two kludges to work around this: - We check the mtimes on the control port and control_auth_cookie, which is the basis on which we give up in step (2). Alone, this would be harmless, but: - We rename controlport to controlport.ack so we never read a stale version -- but that means if we give up on control_auth_cookie then we get wedged. This changes brave to read the auth cookie first, and then the control port. If we successfully read the auth cookie, _then_ we are guaranteed that the control port has been written, since the control port write happens before the auth cookie write. Since the read order is correct now, the kludges should be safely eliminable and the logic simplified. However, I will defer that simplification to a subsequent change. fix #14517 Auditors: @diracdeltas @bsclifton Test Plan: 1. Launch Brave. 2. Confirm private tabs with Tor work. 3. Exit Brave. 4. Relaunch Brave. 5. Confirm private tabs with Tor still work. The symptom that this fixes is that in step (5), Brave thinks that Tor can't connect to the network, but the tor daemon reports in $BRAVE/tor/dta/tor.log that it did successfully connect to the network. This seems to happen only on Windows.
|
Fixed with #14526 |
bsclifton
pushed a commit
that referenced
this issue
Jun 23, 2018
The tor daemon writes the control port first, and then the auth cookie. Currently we _read_ them in that order too, which means the following sequence of events might happen: 1. tor writes controlport 2. we read new controlport 3. we read stale control_auth_cookie and give up 4. tor writes control_auth_cookie Because I inexplicably wasn't thinking about it earlier, I put in two kludges to work around this: - We check the mtimes on the control port and control_auth_cookie, which is the basis on which we give up in step (2). Alone, this would be harmless, but: - We rename controlport to controlport.ack so we never read a stale version -- but that means if we give up on control_auth_cookie then we get wedged. This changes brave to read the auth cookie first, and then the control port. If we successfully read the auth cookie, _then_ we are guaranteed that the control port has been written, since the control port write happens before the auth cookie write. Since the read order is correct now, the kludges should be safely eliminable and the logic simplified. However, I will defer that simplification to a subsequent change. fix #14517 Auditors: @diracdeltas @bsclifton Test Plan: 1. Launch Brave. 2. Confirm private tabs with Tor work. 3. Exit Brave. 4. Relaunch Brave. 5. Confirm private tabs with Tor still work. The symptom that this fixes is that in step (5), Brave thinks that Tor can't connect to the network, but the tor daemon reports in $BRAVE/tor/dta/tor.log that it did successfully connect to the network. This seems to happen only on Windows.
|
Verified on Windows 10 x64 using
|
bsclifton
pushed a commit
that referenced
this issue
Jun 25, 2018
The tor daemon writes the control port first, and then the auth cookie. Currently we _read_ them in that order too, which means the following sequence of events might happen: 1. tor writes controlport 2. we read new controlport 3. we read stale control_auth_cookie and give up 4. tor writes control_auth_cookie Because I inexplicably wasn't thinking about it earlier, I put in two kludges to work around this: - We check the mtimes on the control port and control_auth_cookie, which is the basis on which we give up in step (2). Alone, this would be harmless, but: - We rename controlport to controlport.ack so we never read a stale version -- but that means if we give up on control_auth_cookie then we get wedged. This changes brave to read the auth cookie first, and then the control port. If we successfully read the auth cookie, _then_ we are guaranteed that the control port has been written, since the control port write happens before the auth cookie write. Since the read order is correct now, the kludges should be safely eliminable and the logic simplified. However, I will defer that simplification to a subsequent change. fix #14517 Auditors: @diracdeltas @bsclifton Test Plan: 1. Launch Brave. 2. Confirm private tabs with Tor work. 3. Exit Brave. 4. Relaunch Brave. 5. Confirm private tabs with Tor still work. The symptom that this fixes is that in step (5), Brave thinks that Tor can't connect to the network, but the tor daemon reports in $BRAVE/tor/dta/tor.log that it did successfully connect to the network. This seems to happen only on Windows.
bsclifton
pushed a commit
that referenced
this issue
Jun 26, 2018
The tor daemon writes the control port first, and then the auth cookie. Currently we _read_ them in that order too, which means the following sequence of events might happen: 1. tor writes controlport 2. we read new controlport 3. we read stale control_auth_cookie and give up 4. tor writes control_auth_cookie Because I inexplicably wasn't thinking about it earlier, I put in two kludges to work around this: - We check the mtimes on the control port and control_auth_cookie, which is the basis on which we give up in step (2). Alone, this would be harmless, but: - We rename controlport to controlport.ack so we never read a stale version -- but that means if we give up on control_auth_cookie then we get wedged. This changes brave to read the auth cookie first, and then the control port. If we successfully read the auth cookie, _then_ we are guaranteed that the control port has been written, since the control port write happens before the auth cookie write. Since the read order is correct now, the kludges should be safely eliminable and the logic simplified. However, I will defer that simplification to a subsequent change. fix #14517 Auditors: @diracdeltas @bsclifton Test Plan: 1. Launch Brave. 2. Confirm private tabs with Tor work. 3. Exit Brave. 4. Relaunch Brave. 5. Confirm private tabs with Tor still work. The symptom that this fixes is that in step (5), Brave thinks that Tor can't connect to the network, but the tor daemon reports in $BRAVE/tor/dta/tor.log that it did successfully connect to the network. This seems to happen only on Windows.
bsclifton
pushed a commit
that referenced
this issue
Jun 27, 2018
The tor daemon writes the control port first, and then the auth cookie. Currently we _read_ them in that order too, which means the following sequence of events might happen: 1. tor writes controlport 2. we read new controlport 3. we read stale control_auth_cookie and give up 4. tor writes control_auth_cookie Because I inexplicably wasn't thinking about it earlier, I put in two kludges to work around this: - We check the mtimes on the control port and control_auth_cookie, which is the basis on which we give up in step (2). Alone, this would be harmless, but: - We rename controlport to controlport.ack so we never read a stale version -- but that means if we give up on control_auth_cookie then we get wedged. This changes brave to read the auth cookie first, and then the control port. If we successfully read the auth cookie, _then_ we are guaranteed that the control port has been written, since the control port write happens before the auth cookie write. Since the read order is correct now, the kludges should be safely eliminable and the logic simplified. However, I will defer that simplification to a subsequent change. fix #14517 Auditors: @diracdeltas @bsclifton Test Plan: 1. Launch Brave. 2. Confirm private tabs with Tor work. 3. Exit Brave. 4. Relaunch Brave. 5. Confirm private tabs with Tor still work. The symptom that this fixes is that in step (5), Brave thinks that Tor can't connect to the network, but the tor daemon reports in $BRAVE/tor/dta/tor.log that it did successfully connect to the network. This seems to happen only on Windows.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
Browser doesn't connect to TOR on initial launch.
Test plan / Steps to Reproduce
Actual result:
Browser doesn't connect to TOR on initial launch.
Expected result:
Browser should connect to TOR on initial launch.
Reproduces how often:
100%
Brave Version
0.23.14
about:brave info:
Brave: 0.23.14
V8: 6.7.288.46
rev: f4da855
Muon: 7.1.1
OS Release: 10.0.17134
Update Channel: Beta
OS Architecture: x64
OS Platform: Microsoft Windows
Node.js: 7.9.0
libchromiumcontent: 67.0.3396.87
Reproducible on current live release:
No
Additional Information
follow up to 14503 issue
The text was updated successfully, but these errors were encountered: