Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

torsf: TestRunWithExistingTor hangs forever #2540

Closed
bassosimone opened this issue Sep 22, 2023 · 2 comments
Closed

torsf: TestRunWithExistingTor hangs forever #2540

bassosimone opened this issue Sep 22, 2023 · 2 comments
Assignees
Labels
bug Something isn't working needs investigation This issue needs extra data and investigation ooni/probe-engine priority/high releaseBlocker This issue blocks releasing

Comments

@bassosimone
Copy link
Contributor

The TestRunWithExistingTor test runs for a long time (probably ~forever) and logs these messages:

2023/09/22 17:10:07 WebRTC: Collecting a new Snowflake. Currently at [0/1]
2023/09/22 17:10:07 snowflake-00385b62d1499f5d  connecting...
2023/09/22 17:10:07 WebRTC: DataChannel created.
2023/09/22 17:10:07 WebRTC: Created offer
2023/09/22 17:10:07 WebRTC: Set local description
2023/09/22 17:10:07 WebRTC: PeerConnection created.
2023/09/22 17:10:07 Negotiating via HTTP rendezvous...
2023/09/22 17:10:07 Target URL:  snowflake-broker.torproject.net.global.prod.fastly.net
2023/09/22 17:10:07 Front URL:   cdn.sstatic.net
2023/09/22 17:10:07 HTTP rendezvous response: 403 Forbidden
2023/09/22 17:10:07 WebRTC: closing DataChannel
2023/09/22 17:10:07 WebRTC: closing PeerConnection
2023/09/22 17:10:07 WebRTC: Closing
2023/09/22 17:10:07 WebRTC: Unexpected error, no answer.  Retrying...

I am going to disable this integration test, but we must fix this issue before releasing 😅 .

To reproduce:

go test -run TestRunWithExistingTor -v -count 1 ./internal/experiment/torsf
@bassosimone bassosimone added bug Something isn't working priority/high needs investigation This issue needs extra data and investigation ooni/probe-engine labels Sep 22, 2023
@bassosimone bassosimone self-assigned this Sep 22, 2023
@bassosimone bassosimone added the releaseBlocker This issue blocks releasing label Sep 22, 2023
bassosimone added a commit to ooni/probe-cli that referenced this issue Sep 22, 2023
This diff makes the policy previously known as loadable and now know as
the static policy easier to use, by having a constructor that reads from
a key-value store and by passing it a fallback policy to use.

With this design, it should be possible to have code that uses the
static policy if applied, falling back to whatever policy we are
otherwise constructing into the NewNetwork constructor.

In a subsequent commit, I will hook this code into NewNetwork, so that
we can override the policy by changing the filesystem.

While there, notice several failures in the test suite and apply
workarounds (see ooni/probe#2539,
ooni/probe#2540,
ooni/probe#2541).

Part of ooni/probe#2531.
@bassosimone
Copy link
Contributor Author

bassosimone added a commit to ooni/probe-cli that referenced this issue Oct 6, 2023
We're doing this due to problems with `cdn.sstatic.net`:

- https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000315.html
- https://forum.torproject.org/t/problems-with-snowflake-since-2023-09-20-broker-failure-unexpected-error-no-answer/9346

The reference issue is ooni/probe#2540.

While there, fix a typo in a test name.

---------

Co-authored-by: Simone Basso <bassosimone@gmail.com>
@bassosimone
Copy link
Contributor Author

We have fixed the underlying issue (thanks @cohosh!). And I am going to close this PR. However, I am not very fond of how much static configuration is embedded into the probe source code. I'm wondering of whether there is a way for us to have the check-in API tell us which is the proper SNI for Snowflake. This would reduce the need to release frequently. In any case, this topic is probably best being addressed as a new, separate issue.

Murphy-OrangeMud pushed a commit to Murphy-OrangeMud/probe-cli that referenced this issue Feb 13, 2024
…#1297)

This diff makes the policy previously known as loadable and now know as
the static policy easier to use, by having a constructor that reads from
a key-value store and by passing it a fallback policy to use.

With this design, it should be possible to have code that uses the
static policy if applied, falling back to whatever policy we are
otherwise constructing into the NewNetwork constructor.

In a subsequent commit, I will hook this code into NewNetwork, so that
we can override the policy by changing the filesystem.

While there, notice several failures in the test suite and apply
workarounds (see ooni/probe#2539,
ooni/probe#2540,
ooni/probe#2541).

Part of ooni/probe#2531.
Murphy-OrangeMud pushed a commit to Murphy-OrangeMud/probe-cli that referenced this issue Feb 13, 2024
We're doing this due to problems with `cdn.sstatic.net`:

- https://lists.torproject.org/pipermail/anti-censorship-team/2023-September/000315.html
- https://forum.torproject.org/t/problems-with-snowflake-since-2023-09-20-broker-failure-unexpected-error-no-answer/9346

The reference issue is ooni/probe#2540.

While there, fix a typo in a test name.

---------

Co-authored-by: Simone Basso <bassosimone@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs investigation This issue needs extra data and investigation ooni/probe-engine priority/high releaseBlocker This issue blocks releasing
Projects
None yet
Development

No branches or pull requests

1 participant