ooni-probe-cli/internal/model/netx.go

319 lines
9.9 KiB
Go
Raw Normal View History

package model
//
// Network extensions
//
import (
"context"
"crypto/tls"
"net"
"net/http"
"syscall"
"time"
"github.com/lucas-clemente/quic-go"
)
// DNSResponse is a parsed DNS response ready for further processing.
type DNSResponse interface {
// Query is the query associated with this response.
Query() DNSQuery
// Bytes returns the bytes from which we parsed the query.
Bytes() []byte
// Rcode returns the response's Rcode.
Rcode() int
// DecodeHTTPS returns information gathered from all the HTTPS
// records found inside of this response.
DecodeHTTPS() (*HTTPSSvc, error)
// DecodeLookupHost returns the addresses in the response matching
// the original query type (one of A and AAAA).
DecodeLookupHost() ([]string, error)
// DecodeNS returns all the NS entries in this response.
DecodeNS() ([]*net.NS, error)
}
// The DNSDecoder decodes DNS responses.
type DNSDecoder interface {
// DecodeResponse decodes a DNS response message.
//
// Arguments:
//
// - data is the raw reply
//
// This function fails if we cannot parse data as a DNS
// message or the message is not a response.
//
// Regarding the returned response, remember that the Rcode
// MAY still be nonzero (this method does not treat a nonzero
// Rcode as an error when parsing the response).
DecodeResponse(data []byte, query DNSQuery) (DNSResponse, error)
}
// DNSQuery is an encoded DNS query ready to be sent using a DNSTransport.
type DNSQuery interface {
// Domain is the domain we're querying for.
Domain() string
// Type is the query type.
Type() uint16
// Bytes serializes the query to bytes. This function may fail if we're not
// able to correctly encode the domain into a query message.
//
// The value returned by this function WILL be memoized after the first call,
// so you SHOULD create a new DNSQuery if you need to retry a query.
Bytes() ([]byte, error)
// ID returns the query ID.
ID() uint16
}
// The DNSEncoder encodes DNS queries to bytes
type DNSEncoder interface {
// Encode transforms its arguments into a serialized DNS query.
//
// Every time you call Encode, you get a new DNSQuery value
// using a query ID selected at random.
//
// Serialization to bytes is lazy to acommodate DNS transports that
// do not need to serialize and send bytes, e.g., getaddrinfo.
//
// You serialize to bytes using DNSQuery.Bytes. This operation MAY fail
// if the domain name cannot be packed into a DNS message (e.g., it is
// too long to fit into the message).
//
// Arguments:
//
// - domain is the domain for the query (e.g., x.org);
//
// - qtype is the query type (e.g., dns.TypeA);
//
// - padding is whether to add padding to the query.
//
// This function will transform the domain into an FQDN is it's not
// already expressed in the FQDN format.
Encode(domain string, qtype uint16, padding bool) DNSQuery
}
// DNSTransport represents an abstract DNS transport.
type DNSTransport interface {
// RoundTrip sends a DNS query and receives the reply.
RoundTrip(ctx context.Context, query DNSQuery) (DNSResponse, error)
// RequiresPadding returns whether this transport needs padding.
RequiresPadding() bool
// Network is the network of the round tripper (e.g. "dot").
Network() string
// Address is the address of the round tripper (e.g. "1.1.1.1:853").
Address() string
// CloseIdleConnections closes idle connections, if any.
CloseIdleConnections()
}
// SimpleDialer establishes network connections.
type SimpleDialer interface {
// DialContext behaves like net.Dialer.DialContext.
DialContext(ctx context.Context, network, address string) (net.Conn, error)
}
// Dialer is a SimpleDialer with the possibility of closing open connections.
type Dialer interface {
// A Dialer is also a SimpleDialer.
SimpleDialer
// CloseIdleConnections closes idle connections, if any.
CloseIdleConnections()
}
// HTTPClient is an http.Client-like interface.
type HTTPClient interface {
Do(req *http.Request) (*http.Response, error)
CloseIdleConnections()
}
// HTTPTransport is an http.Transport-like structure.
type HTTPTransport interface {
feature: merge measurex and netx archival layer (1/N) (#663) This diff introduces a new package called `./internal/archival`. This package collects data from `./internal/model` network interfaces (e.g., `Dialer`, `QUICDialer`, `HTTPTransport`), saves such data into an internal tabular data format suitable for on-line processing and analysis, and allows exporting data into the OONI data format. The code for collecting and the internal tabular data formats are adapted from `measurex`. The code for formatting and exporting OONI data-format-compliant structures is adapted from `netx/archival`. My original objective was to _also_ (1) fully replace `netx/archival` with this package and (2) adapt `measurex` to use this package rather than its own code. Both operations seem easily feasible because: (a) this code is `measurex` code without extensions that are `measurex` related, which will need to be added back as part of the process; (b) the API provided by this code allows for trivially converting from using `netx/archival` to using this code. Yet, both changes should not be taken lightly. After implementing them, there's need to spend some time doing QA and ensuring all nettests work as intended. However, I am planning a release in the next two weeks, and this QA task is likely going to defer the release. For this reason, I have chosen to commit the work done so far into the tree and defer the second part of this refactoring for a later moment in time. (This explains why the title mentions "1/N"). On a more high-level perspective, it would also be beneficial, I guess, to explain _why_ I am doing these changes. There are two intertwined reasons. The first reason is that `netx/archival` has shortcomings deriving from its original https://github.com/ooni/netx legacy. The most relevant shortcoming is that it saves all kind of data into the same tabular structure named `Event`. This design choice is unfortunate because it does not allow one to apply data-type specific logic when processing the results. In turn, this choice results in complex processing code. Therefore, I believe that replacing the code with event-specific data structures is clearly an improvement in terms of code maintainability and would quite likely lead us to more confidently change and evolve the codebase. The second reason why I would like to move forward these changes is to unify the codepaths used for measuring. At this point in time, we basically have two codepaths: `./internal/engine/netx` and `./internal/measurex`. They both have pros and cons and I don't think we want to rewrite whole experiments using `netx`. Rather, what we probably want is to gradually merge these two codepaths such that `netx` is a set of abstractions on top of `measurex` (which is more low-level and has a more-easily-testable design). Because saving events and generating an archival data format out of them consists of at least 50% of the complexity of both `netx` and `measurex`, it seems reasonable to unify this archival-related part of the two codebases as the first step. At the highest level of abstraction, these changes are part of the train of changes which will eventually lead us to bless `websteps` as a first class citizen in OONI land. Because `websteps` requires different underlying primitives, I chose to develop these primitives from scratch rather than wrestling with `netx`, which used another model. The model used by `websteps` is that we perform each operation in isolation and immediately we save the results, while `netx` creates whole data structures and collects all the events happening via tracing. We believe the model used by `websteps` to be better because it does not require your code to figure out everything that happened after the measurement, which is a source of subtle bugs in the current implementation. So, when I started implementing websteps I extracted the bits of `netx` that could also be beneficial to `websteps` into a separate library, thus `netxlite` was born. The reference issue describing merging the archival of `netx` and `measurex` is https://github.com/ooni/probe/issues/1957. As of this writing the issue still references the original plan, which I could not complete by the end of this Sprint, so I am going to adapt the text of the issue to only refer to what was done in here next. Of course, I also need follow-up issues.
2022-01-14 12:13:10 +01:00
// Network returns the network used by the transport, which
// should be one of "tcp" and "quic".
Network() string
// RoundTrip performs the HTTP round trip.
RoundTrip(req *http.Request) (*http.Response, error)
// CloseIdleConnections closes idle connections.
CloseIdleConnections()
}
// HTTPSSvc is the reply to an HTTPS DNS query.
type HTTPSSvc struct {
// ALPN contains the ALPNs inside the HTTPS reply.
ALPN []string
// IPv4 contains the IPv4 hints (which may be empty).
IPv4 []string
// IPv6 contains the IPv6 hints (which may be empty).
IPv6 []string
}
// QUICListener listens for QUIC connections.
type QUICListener interface {
// Listen creates a new listening UDPLikeConn.
Listen(addr *net.UDPAddr) (UDPLikeConn, error)
}
// QUICDialer dials QUIC sessions.
type QUICDialer interface {
// DialContext establishes a new QUIC session using the given
// network and address. The tlsConfig and the quicConfig arguments
// MUST NOT be nil. Returns either the session or an error.
//
// Recommended tlsConfig setup:
//
// - set ServerName to be the SNI;
//
// - set RootCAs to NewDefaultCertPool();
//
// - set NextProtos to []string{"h3"}.
//
// Typically, you want to pass `&quic.Config{}` as quicConfig.
DialContext(ctx context.Context, network, address string,
cli: upgrade to lucas-clemente/quic-go@v0.27.0 (#715) * quic-go upgrade: replaced Session/EarlySession with Connection/EarlyConnection * quic-go upgrade: added context to RoundTripper.Dial * quic-go upgrade: made corresponding changes to tutorial * quic-go upgrade: changed sess variable instances to qconn * quic-go upgrade: made corresponding changes to tutorial * cleanup: remove unnecessary comments Those comments made sense in terms of illustrating the changes but they're going to be less useful once we merge. * fix(go.mod): apparently we needed `go1.18.1 mod tidy` VSCode just warned me about this. It seems fine to apply this change as part of the pull request at hand. * cleanup(netxlite): http3dialer can be removed We used to use http3dialer to glue a QUIC dialer, which had a context as its first argument, to the Dial function used by the HTTP3 transport, which did not have a context as its first argument. Now that HTTP3 transport has a Dial function taking a context as its first argument, we don't need http3dialer anymore, since we can use the QUIC dialer directly. Cc: @DecFox * Revert "cleanup(netxlite): http3dialer can be removed" This reverts commit c62244c620cee5fadcc2ca89d8228c8db0b96add to investigate the build failure mentioned at https://github.com/ooni/probe-cli/pull/715#issuecomment-1119450484 * chore(netx): show that test was already broken We didn't see the breakage before because we were not using the created transport, but the issue of using a nil dialer was already present before, we just didn't see it. Now we understand why removing the http3transport in c62244c620cee5fadcc2ca89d8228c8db0b96add did cause the breakage mentioned at https://github.com/ooni/probe-cli/pull/715#issuecomment-1119450484 * fix(netx): convert broken integration test to working unit test There's no point in using the network here. Add a fake dialer that breaks and ensure we're getting the expected error. We've now improved upon the original test because the original test was not doing anything while now we're testing whether we get back a QUIC dialer that _can be used_. After this commit, I can then readd the cleanup commit c62244c620cee5fadcc2ca89d8228c8db0b96add and it won't be broken anymore (at least, this is what I expected to happen). * Revert "Revert "cleanup(netxlite): http3dialer can be removed"" This reverts commit 0e254bfc6ba3bfd65365ce3d8de2c8ec51b925ff because now we should have fixed the broken test. Co-authored-by: decfox <decfox> Co-authored-by: Simone Basso <bassosimone@gmail.com>
2022-05-06 12:24:03 +02:00
tlsConfig *tls.Config, quicConfig *quic.Config) (quic.EarlyConnection, error)
// CloseIdleConnections closes idle connections, if any.
CloseIdleConnections()
}
getaddrinfo: fix CGO_ENABLED=0 and record resolver type (#765) After https://github.com/ooni/probe-cli/pull/764, the build for CGO_ENABLED=0 has been broken for miniooni: https://github.com/ooni/probe-cli/runs/6636995859?check_suite_focus=true Likewise, it's not possible to run tests with CGO_ENABLED=0. To make tests work with `CGO_ENABLED=0`, I needed to sacrifice some unit tests run for the CGO case. It is not fully clear to me what was happening here, but basically `getaddrinfo_cgo_test.go` was compiled with CGO being disabled, even though the ``//go:build cgo` flag was specified. Additionally, @hellais previously raised a valid point in the review of https://github.com/ooni/probe-cli/pull/698: > Another issue we should consider is that, if I understand how > this works correctly, depending on whether or not we have built > with CGO_ENABLED=0 on or not, we are going to be measuring > things in a different way (using our cgo inspired getaddrinfo > implementation or using netgo). This might present issues when > analyzing or interpreting the data. > > Do we perhaps want to add some field to the output data format that > gives us an indication of which DNS resolution code was used to > generate the the metric? This comment is relevant to the current commit because https://github.com/ooni/probe-cli/pull/698 is the previous iteration of https://github.com/ooni/probe-cli/pull/764. So, while fixing the build and test issues, let us also distinguish between the CGO_ENABLED=1 and CGO_ENABLED=0 cases. Before this commit, OONI used "system" to indicate the case where we were using net.DefaultResolver. This behavior dates back to the Measurement Kit days. While it is true that ooni/probe-engine and ooni/probe-cli could have been using netgo in the past when we said "system" as the resolver, it also seems reasonable to continue to use "system" top indicate getaddrinfo. So, the choice here is basically to use "netgo" from now on to indicate the cases in which we were built with CGO_ENABLED=0. This change will need to be documented into ooni/spec along with the introduction of the `android_dns_cache_no_data` error. ## Checklist - [x] I have read the [contribution guidelines](https://github.com/ooni/probe-cli/blob/master/CONTRIBUTING.md) - [x] reference issue for this pull request: https://github.com/ooni/probe/issues/2029 - [x] if you changed anything related how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/ooni/spec/pull/242
2022-05-30 07:34:25 +02:00
// SimpleResolver is a simplified resolver that only allows to perform
// an ordinary lookup operation and to know the resolver's name.
type SimpleResolver interface {
// LookupHost behaves like net.Resolver.LookupHost.
LookupHost(ctx context.Context, hostname string) (addrs []string, err error)
getaddrinfo: fix CGO_ENABLED=0 and record resolver type (#765) After https://github.com/ooni/probe-cli/pull/764, the build for CGO_ENABLED=0 has been broken for miniooni: https://github.com/ooni/probe-cli/runs/6636995859?check_suite_focus=true Likewise, it's not possible to run tests with CGO_ENABLED=0. To make tests work with `CGO_ENABLED=0`, I needed to sacrifice some unit tests run for the CGO case. It is not fully clear to me what was happening here, but basically `getaddrinfo_cgo_test.go` was compiled with CGO being disabled, even though the ``//go:build cgo` flag was specified. Additionally, @hellais previously raised a valid point in the review of https://github.com/ooni/probe-cli/pull/698: > Another issue we should consider is that, if I understand how > this works correctly, depending on whether or not we have built > with CGO_ENABLED=0 on or not, we are going to be measuring > things in a different way (using our cgo inspired getaddrinfo > implementation or using netgo). This might present issues when > analyzing or interpreting the data. > > Do we perhaps want to add some field to the output data format that > gives us an indication of which DNS resolution code was used to > generate the the metric? This comment is relevant to the current commit because https://github.com/ooni/probe-cli/pull/698 is the previous iteration of https://github.com/ooni/probe-cli/pull/764. So, while fixing the build and test issues, let us also distinguish between the CGO_ENABLED=1 and CGO_ENABLED=0 cases. Before this commit, OONI used "system" to indicate the case where we were using net.DefaultResolver. This behavior dates back to the Measurement Kit days. While it is true that ooni/probe-engine and ooni/probe-cli could have been using netgo in the past when we said "system" as the resolver, it also seems reasonable to continue to use "system" top indicate getaddrinfo. So, the choice here is basically to use "netgo" from now on to indicate the cases in which we were built with CGO_ENABLED=0. This change will need to be documented into ooni/spec along with the introduction of the `android_dns_cache_no_data` error. ## Checklist - [x] I have read the [contribution guidelines](https://github.com/ooni/probe-cli/blob/master/CONTRIBUTING.md) - [x] reference issue for this pull request: https://github.com/ooni/probe/issues/2029 - [x] if you changed anything related how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/ooni/spec/pull/242
2022-05-30 07:34:25 +02:00
// Network returns the resolver type. It should be one of:
//
// - go: means we're using whatever resolver the Go stdlib uses
// depending on the current build configuration;
getaddrinfo: fix CGO_ENABLED=0 and record resolver type (#765) After https://github.com/ooni/probe-cli/pull/764, the build for CGO_ENABLED=0 has been broken for miniooni: https://github.com/ooni/probe-cli/runs/6636995859?check_suite_focus=true Likewise, it's not possible to run tests with CGO_ENABLED=0. To make tests work with `CGO_ENABLED=0`, I needed to sacrifice some unit tests run for the CGO case. It is not fully clear to me what was happening here, but basically `getaddrinfo_cgo_test.go` was compiled with CGO being disabled, even though the ``//go:build cgo` flag was specified. Additionally, @hellais previously raised a valid point in the review of https://github.com/ooni/probe-cli/pull/698: > Another issue we should consider is that, if I understand how > this works correctly, depending on whether or not we have built > with CGO_ENABLED=0 on or not, we are going to be measuring > things in a different way (using our cgo inspired getaddrinfo > implementation or using netgo). This might present issues when > analyzing or interpreting the data. > > Do we perhaps want to add some field to the output data format that > gives us an indication of which DNS resolution code was used to > generate the the metric? This comment is relevant to the current commit because https://github.com/ooni/probe-cli/pull/698 is the previous iteration of https://github.com/ooni/probe-cli/pull/764. So, while fixing the build and test issues, let us also distinguish between the CGO_ENABLED=1 and CGO_ENABLED=0 cases. Before this commit, OONI used "system" to indicate the case where we were using net.DefaultResolver. This behavior dates back to the Measurement Kit days. While it is true that ooni/probe-engine and ooni/probe-cli could have been using netgo in the past when we said "system" as the resolver, it also seems reasonable to continue to use "system" top indicate getaddrinfo. So, the choice here is basically to use "netgo" from now on to indicate the cases in which we were built with CGO_ENABLED=0. This change will need to be documented into ooni/spec along with the introduction of the `android_dns_cache_no_data` error. ## Checklist - [x] I have read the [contribution guidelines](https://github.com/ooni/probe-cli/blob/master/CONTRIBUTING.md) - [x] reference issue for this pull request: https://github.com/ooni/probe/issues/2029 - [x] if you changed anything related how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/ooni/spec/pull/242
2022-05-30 07:34:25 +02:00
//
// - system: means we've been compiled with `CGO_ENABLED=1`
// so we can bypass the go resolver and call getaddrinfo directly;
getaddrinfo: fix CGO_ENABLED=0 and record resolver type (#765) After https://github.com/ooni/probe-cli/pull/764, the build for CGO_ENABLED=0 has been broken for miniooni: https://github.com/ooni/probe-cli/runs/6636995859?check_suite_focus=true Likewise, it's not possible to run tests with CGO_ENABLED=0. To make tests work with `CGO_ENABLED=0`, I needed to sacrifice some unit tests run for the CGO case. It is not fully clear to me what was happening here, but basically `getaddrinfo_cgo_test.go` was compiled with CGO being disabled, even though the ``//go:build cgo` flag was specified. Additionally, @hellais previously raised a valid point in the review of https://github.com/ooni/probe-cli/pull/698: > Another issue we should consider is that, if I understand how > this works correctly, depending on whether or not we have built > with CGO_ENABLED=0 on or not, we are going to be measuring > things in a different way (using our cgo inspired getaddrinfo > implementation or using netgo). This might present issues when > analyzing or interpreting the data. > > Do we perhaps want to add some field to the output data format that > gives us an indication of which DNS resolution code was used to > generate the the metric? This comment is relevant to the current commit because https://github.com/ooni/probe-cli/pull/698 is the previous iteration of https://github.com/ooni/probe-cli/pull/764. So, while fixing the build and test issues, let us also distinguish between the CGO_ENABLED=1 and CGO_ENABLED=0 cases. Before this commit, OONI used "system" to indicate the case where we were using net.DefaultResolver. This behavior dates back to the Measurement Kit days. While it is true that ooni/probe-engine and ooni/probe-cli could have been using netgo in the past when we said "system" as the resolver, it also seems reasonable to continue to use "system" top indicate getaddrinfo. So, the choice here is basically to use "netgo" from now on to indicate the cases in which we were built with CGO_ENABLED=0. This change will need to be documented into ooni/spec along with the introduction of the `android_dns_cache_no_data` error. ## Checklist - [x] I have read the [contribution guidelines](https://github.com/ooni/probe-cli/blob/master/CONTRIBUTING.md) - [x] reference issue for this pull request: https://github.com/ooni/probe/issues/2029 - [x] if you changed anything related how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/ooni/spec/pull/242
2022-05-30 07:34:25 +02:00
//
// - udp: is a custom DNS-over-UDP resolver;
//
// - tcp: is a custom DNS-over-TCP resolver;
//
// - dot: is a custom DNS-over-TLS resolver;
//
// - doh: is a custom DNS-over-HTTPS resolver;
//
// - doh3: is a custom DNS-over-HTTP3 resolver.
//
// See https://github.com/ooni/probe/issues/2029#issuecomment-1140805266
// for an explanation of why it would not be proper to call "netgo" the
// resolver we get by default from the standard library.
Network() string
getaddrinfo: fix CGO_ENABLED=0 and record resolver type (#765) After https://github.com/ooni/probe-cli/pull/764, the build for CGO_ENABLED=0 has been broken for miniooni: https://github.com/ooni/probe-cli/runs/6636995859?check_suite_focus=true Likewise, it's not possible to run tests with CGO_ENABLED=0. To make tests work with `CGO_ENABLED=0`, I needed to sacrifice some unit tests run for the CGO case. It is not fully clear to me what was happening here, but basically `getaddrinfo_cgo_test.go` was compiled with CGO being disabled, even though the ``//go:build cgo` flag was specified. Additionally, @hellais previously raised a valid point in the review of https://github.com/ooni/probe-cli/pull/698: > Another issue we should consider is that, if I understand how > this works correctly, depending on whether or not we have built > with CGO_ENABLED=0 on or not, we are going to be measuring > things in a different way (using our cgo inspired getaddrinfo > implementation or using netgo). This might present issues when > analyzing or interpreting the data. > > Do we perhaps want to add some field to the output data format that > gives us an indication of which DNS resolution code was used to > generate the the metric? This comment is relevant to the current commit because https://github.com/ooni/probe-cli/pull/698 is the previous iteration of https://github.com/ooni/probe-cli/pull/764. So, while fixing the build and test issues, let us also distinguish between the CGO_ENABLED=1 and CGO_ENABLED=0 cases. Before this commit, OONI used "system" to indicate the case where we were using net.DefaultResolver. This behavior dates back to the Measurement Kit days. While it is true that ooni/probe-engine and ooni/probe-cli could have been using netgo in the past when we said "system" as the resolver, it also seems reasonable to continue to use "system" top indicate getaddrinfo. So, the choice here is basically to use "netgo" from now on to indicate the cases in which we were built with CGO_ENABLED=0. This change will need to be documented into ooni/spec along with the introduction of the `android_dns_cache_no_data` error. ## Checklist - [x] I have read the [contribution guidelines](https://github.com/ooni/probe-cli/blob/master/CONTRIBUTING.md) - [x] reference issue for this pull request: https://github.com/ooni/probe/issues/2029 - [x] if you changed anything related how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/ooni/spec/pull/242
2022-05-30 07:34:25 +02:00
}
// Resolver performs domain name resolutions.
type Resolver interface {
// A Resolver is also a SimpleResolver.
SimpleResolver
// Address returns the resolver address (e.g., 8.8.8.8:53).
Address() string
// CloseIdleConnections closes idle connections, if any.
CloseIdleConnections()
// LookupHTTPS issues an HTTPS query for a domain.
LookupHTTPS(
ctx context.Context, domain string) (*HTTPSSvc, error)
// LookupNS issues a NS query for a domain.
LookupNS(ctx context.Context, domain string) ([]*net.NS, error)
}
// TLSDialer is a Dialer dialing TLS connections.
type TLSDialer interface {
// CloseIdleConnections closes idle connections, if any.
CloseIdleConnections()
// DialTLSContext dials a TLS connection. This method will always return
// to you a oohttp.TLSConn, so you can always safely cast to it.
DialTLSContext(ctx context.Context, network, address string) (net.Conn, error)
}
// TLSHandshaker is the generic TLS handshaker.
type TLSHandshaker interface {
// Handshake creates a new TLS connection from the given connection and
// the given config. This function DOES NOT take ownership of the connection
// and it's your responsibility to close it on failure.
//
// Recommended tlsConfig setup:
//
// - set ServerName to be the SNI;
//
// - set RootCAs to NewDefaultCertPool();
//
// - set NextProtos to []string{"h2", "http/1.1"} for HTTPS
// and []string{"dot"} for DNS-over-TLS.
//
// QUIRK: The returned connection will always implement the TLSConn interface
// exposed by ooni/oohttp. A future version of this interface may instead
// return directly a TLSConn to avoid unconditional castings.
Handshake(ctx context.Context, conn net.Conn, tlsConfig *tls.Config) (
net.Conn, tls.ConnectionState, error)
}
// UDPLikeConn is a net.PacketConn with some extra functions
// required to convince the QUIC library (lucas-clemente/quic-go)
// to inflate the receive buffer of the connection.
//
// The QUIC library will treat this connection as a "dumb"
// net.PacketConn, calling its ReadFrom and WriteTo methods
// as opposed to more efficient methods that are available
// under Linux and (maybe?) FreeBSD.
//
// It seems fine to avoid performance optimizations, because
// they would complicate the implementation on our side and
// our use cases (blocking and heavy throttling) do not seem
// to require such optimizations.
//
// See https://github.com/ooni/probe/issues/1754 for a more
// comprehensive discussion of UDPLikeConn.
type UDPLikeConn interface {
// An UDPLikeConn is a net.PacketConn conn.
net.PacketConn
// SetReadBuffer allows setting the read buffer.
SetReadBuffer(bytes int) error
// SyscallConn returns a conn suitable for calling syscalls,
// which is also instrumental to setting the read buffer.
SyscallConn() (syscall.RawConn, error)
}
// UnderlyingNetworkLibrary defines the basic functionality from
// which the network extensions depend. By changing the default
// implementation of this interface, we can implement a wide array
// of tests, including self censorship tests.
type UnderlyingNetworkLibrary interface {
// ListenUDP creates a new model.UDPLikeConn conn.
ListenUDP(network string, laddr *net.UDPAddr) (UDPLikeConn, error)
getaddrinfo: fix CGO_ENABLED=0 and record resolver type (#765) After https://github.com/ooni/probe-cli/pull/764, the build for CGO_ENABLED=0 has been broken for miniooni: https://github.com/ooni/probe-cli/runs/6636995859?check_suite_focus=true Likewise, it's not possible to run tests with CGO_ENABLED=0. To make tests work with `CGO_ENABLED=0`, I needed to sacrifice some unit tests run for the CGO case. It is not fully clear to me what was happening here, but basically `getaddrinfo_cgo_test.go` was compiled with CGO being disabled, even though the ``//go:build cgo` flag was specified. Additionally, @hellais previously raised a valid point in the review of https://github.com/ooni/probe-cli/pull/698: > Another issue we should consider is that, if I understand how > this works correctly, depending on whether or not we have built > with CGO_ENABLED=0 on or not, we are going to be measuring > things in a different way (using our cgo inspired getaddrinfo > implementation or using netgo). This might present issues when > analyzing or interpreting the data. > > Do we perhaps want to add some field to the output data format that > gives us an indication of which DNS resolution code was used to > generate the the metric? This comment is relevant to the current commit because https://github.com/ooni/probe-cli/pull/698 is the previous iteration of https://github.com/ooni/probe-cli/pull/764. So, while fixing the build and test issues, let us also distinguish between the CGO_ENABLED=1 and CGO_ENABLED=0 cases. Before this commit, OONI used "system" to indicate the case where we were using net.DefaultResolver. This behavior dates back to the Measurement Kit days. While it is true that ooni/probe-engine and ooni/probe-cli could have been using netgo in the past when we said "system" as the resolver, it also seems reasonable to continue to use "system" top indicate getaddrinfo. So, the choice here is basically to use "netgo" from now on to indicate the cases in which we were built with CGO_ENABLED=0. This change will need to be documented into ooni/spec along with the introduction of the `android_dns_cache_no_data` error. ## Checklist - [x] I have read the [contribution guidelines](https://github.com/ooni/probe-cli/blob/master/CONTRIBUTING.md) - [x] reference issue for this pull request: https://github.com/ooni/probe/issues/2029 - [x] if you changed anything related how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/ooni/spec/pull/242
2022-05-30 07:34:25 +02:00
// DefaultResolver returns the default resolver.
DefaultResolver() SimpleResolver
// NewSimpleDialer returns a new SimpleDialer.
NewSimpleDialer(timeout time.Duration) SimpleDialer
}