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

feat(webconnectivitylte): classic computes XBlockingFlags #1446

Merged
merged 20 commits into from
Jan 19, 2024

Conversation

bassosimone
Copy link
Contributor

@bassosimone bassosimone commented Jan 16, 2024

This diff modifies the "classic" analysis engine to compute XBlockingFlags. While there, make sure that the flags we compute make sense thus fixing analysis bugs in the previously used "orig" engine.

Part of ooni/probe#2640.

bassosimone added a commit that referenced this pull request Jan 16, 2024
This PR contains yak shaving before doing
ooni/probe#2640.

We extracted this PR from #1446.
XNullNullFlags: 8, // analysisFlagNullNullSuccessfulHTTPS
XStatus: 1, // StatusSuccessSecure
XBlockingFlags: 32, // AnalysisBlockingFlagSuccess
XNullNullFlags: 8, // analysisFlagNullNullSuccessfulHTTPS
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good. We're basically moving the success from XNullNullFlags (which is still ignored per the code changes in this pull request) to XBlockingFlags, which seems correct.

@@ -79,7 +79,7 @@ func dnsBlockingBOGON() *TestCase {
DNSExperimentFailure: nil,
DNSConsistency: "inconsistent",
XStatus: 4256, // StatusExperimentConnect | StatusAnomalyConnect | StatusAnomalyDNS
XDNSFlags: 1, // AnalysisFlagDNSBogon
XDNSFlags: 5, // AnalysisFlagDNSBogon | AnalysisDNSFlagUnexpectedAddrs
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change happens because bogons are also unexpected addresses. I think this is fine because we may have cases (some of which @hellais observed for Telstra, IIRC) where a bogon is serving us the correct result but we still want to note somewhere that we have seen a bogon even though such a bogon seems WAI.

XBlockingFlags: 32, // AnalysisBlockingFlagSuccess
XStatus: 2, // StatusSuccessCleartext
XDNSFlags: 4, // AnalysisDNSFlagUnexpectedAddrs
XBlockingFlags: 33, // AnalysisBlockingFlagDNSBlocking | AnalysisBlockingFlagSuccess
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even when we're successful, we want to note that we're not sure about the addresses.

XBlockingFlags: 32, // AnalysisBlockingFlagSuccess
XStatus: 1, // StatusSuccessSecure
XDNSFlags: 4, // AnalysisDNSFlagUnexpectedAddrs
XBlockingFlags: 33, // AnalysisBlockingFlagDNSBlocking | AnalysisBlockingFlagSuccess
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

@@ -92,7 +92,7 @@ func httpDiffWithInconsistentDNS() *TestCase {
TitleMatch: false,
XStatus: 96, // StatusAnomalyHTTPDiff | StatusAnomalyDNS
XDNSFlags: 4, // AnalysisDNSFlagUnexpectedAddrs
XBlockingFlags: 35, // AnalysisBlockingFlagSuccess | AnalysisBlockingFlagDNSBlocking | AnalysisBlockingFlagTCPIPBlocking
XBlockingFlags: 17, // AnalysisBlockingFlagDNSBlocking | AnalysisBlockingFlagHTTPDiff
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous success flag was a bug of the "orig" analysis engine.

@@ -37,7 +37,7 @@ func redirectWithConsistentDNSAndThenConnectionRefusedForHTTP() *TestCase {
HTTPExperimentFailure: "connection_refused",
XStatus: 8320, // StatusExperimentHTTP | StatusAnomalyConnect
XDNSFlags: 0,
XBlockingFlags: 32, // AnalysisBlockingFlagSuccess
XBlockingFlags: 2, // AnalysisBlockingFlagTCPIPBlocking
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous success flag was a bug of the "orig" analysis engine.

@@ -75,7 +75,7 @@ func redirectWithConsistentDNSAndThenConnectionRefusedForHTTPS() *TestCase {
HTTPExperimentFailure: "connection_refused",
XStatus: 8320, // StatusExperimentHTTP | StatusAnomalyConnect
XDNSFlags: 0,
XBlockingFlags: 32, // AnalysisBlockingFlagSuccess
XBlockingFlags: 2, // AnalysisBlockingFlagTCPIPBlocking
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous success flag was a bug of the "orig" analysis engine.

@@ -113,7 +113,7 @@ func redirectWithConsistentDNSAndThenConnectionResetForHTTP() *TestCase {
HTTPExperimentFailure: "connection_reset",
XStatus: 8448, // StatusExperimentHTTP | StatusAnomalyReadWrite
XDNSFlags: 0,
XBlockingFlags: 8, // AnalysisBlockingFlagHTTPBlocking
XBlockingFlags: 12, // AnalysisBlockingFlagTLSBlocking | AnalysisBlockingFlagHTTPBlocking
Copy link
Contributor Author

@bassosimone bassosimone Jan 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous HTTP blocking flag was a bug of the "orig" analysis engine.

@@ -151,7 +151,7 @@ func redirectWithConsistentDNSAndThenConnectionResetForHTTPS() *TestCase {
HTTPExperimentFailure: "connection_reset",
XStatus: 8448, // StatusExperimentHTTP | StatusAnomalyReadWrite
XDNSFlags: 0,
XBlockingFlags: 8, // AnalysisBlockingFlagHTTPBlocking
XBlockingFlags: 4, // AnalysisBlockingFlagTLSBlocking
Copy link
Contributor Author

@bassosimone bassosimone Jan 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous HTTP blocking flag was a bug of the "orig" analysis engine.

@@ -182,7 +182,7 @@ func redirectWithConsistentDNSAndThenNXDOMAIN() *TestCase {
HTTPExperimentFailure: "dns_nxdomain_error",
XStatus: 8224, // StatusExperimentHTTP | StatusAnomalyDNS
XDNSFlags: 0,
XBlockingFlags: 8, // AnalysisBlockingFlagHTTPBlocking
XBlockingFlags: 1, // AnalysisBlockingFlagDNSBlocking
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous HTTP blocking flag was a bug of the "orig" analysis engine.

@@ -220,7 +220,7 @@ func redirectWithConsistentDNSAndThenEOFForHTTP() *TestCase {
HTTPExperimentFailure: "eof_error",
XStatus: 8448, // StatusExperimentHTTP | StatusAnomalyReadWrite
XDNSFlags: 0,
XBlockingFlags: 8, // AnalysisBlockingFlagHTTPBlocking
XBlockingFlags: 12, // AnalysisBlockingFlagTLSBlocking | AnalysisBlockingFlagHTTPBlocking
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we correctly recognize more causes of blocking

@@ -258,7 +258,7 @@ func redirectWithConsistentDNSAndThenEOFForHTTPS() *TestCase {
HTTPExperimentFailure: "eof_error",
XStatus: 8448, // StatusExperimentHTTP | StatusAnomalyReadWrite
XDNSFlags: 0,
XBlockingFlags: 32, // AnalysisBlockingFlagSuccess
XBlockingFlags: 4, // AnalysisBlockingFlagTLSBlocking
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous success flag was a bug of the "orig" analysis engine.

@@ -297,7 +297,7 @@ func redirectWithConsistentDNSAndThenTimeoutForHTTP() *TestCase {
HTTPExperimentFailure: "generic_timeout_error",
XStatus: 8704, // StatusExperimentHTTP | StatusAnomalyUnknown
XDNSFlags: 0,
XBlockingFlags: 8, // AnalysisBlockingFlagHTTPBlocking
XBlockingFlags: 12, // AnalysisBlockingFlagTLSBlocking | AnalysisBlockingFlagHTTPBlocking
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we correctly recognize more causes of blocking.

@@ -336,7 +336,7 @@ func redirectWithConsistentDNSAndThenTimeoutForHTTPS() *TestCase {
HTTPExperimentFailure: "generic_timeout_error",
XStatus: 8704, // StatusExperimentHTTP | StatusAnomalyUnknown
XDNSFlags: 0,
XBlockingFlags: 32, // AnalysisBlockingFlagSuccess
XBlockingFlags: 4, // AnalysisBlockingFlagTLSBlocking
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous success flag was a bug of the "orig" analysis engine.

@bassosimone bassosimone changed the title WIP: compute extended flags for LTE feat(webconnectivitylte): let classic compute extended blocking flags Jan 19, 2024
@bassosimone bassosimone changed the title feat(webconnectivitylte): let classic compute extended blocking flags feat(webconnectivitylte): classic computes XBlockingFlags Jan 19, 2024
@bassosimone bassosimone marked this pull request as ready for review January 19, 2024 11:57
@bassosimone bassosimone requested a review from hellais as a code owner January 19, 2024 11:57
@bassosimone bassosimone merged commit 41bedb5 into master Jan 19, 2024
11 checks passed
@bassosimone bassosimone deleted the issue/2640 branch January 19, 2024 12:38
Murphy-OrangeMud pushed a commit to Murphy-OrangeMud/probe-cli that referenced this pull request Feb 13, 2024
This PR contains yak shaving before doing
ooni/probe#2640.

We extracted this PR from ooni#1446.
Murphy-OrangeMud pushed a commit to Murphy-OrangeMud/probe-cli that referenced this pull request Feb 13, 2024
This diff modifies the "classic" analysis engine to compute
XBlockingFlags. While there, make sure that the flags we compute make
sense thus fixing analysis bugs in the previously used "orig" engine.

Part of ooni/probe#2640.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant