2022-05-28 15:10:30 +02:00
|
|
|
//go:build: cgo
|
|
|
|
|
|
|
|
package netxlite
|
|
|
|
|
|
|
|
/*
|
|
|
|
// On Unix systems, getaddrinfo is part of libc. On Windows,
|
|
|
|
// instead, we need to explicitly link with winsock2.
|
|
|
|
#cgo windows LDFLAGS: -lws2_32
|
|
|
|
|
|
|
|
#ifndef _WIN32
|
|
|
|
#include <netdb.h> // for getaddrinfo
|
|
|
|
#else
|
|
|
|
#include <ws2tcpip.h> // for getaddrinfo
|
|
|
|
#endif
|
|
|
|
*/
|
|
|
|
import "C"
|
|
|
|
|
|
|
|
import (
|
|
|
|
"context"
|
|
|
|
"errors"
|
|
|
|
"net"
|
|
|
|
"runtime"
|
|
|
|
"syscall"
|
|
|
|
"unsafe"
|
|
|
|
)
|
|
|
|
|
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
|
|
|
// getaddrinfoResolverNetwork returns the "network" that is actually
|
|
|
|
// been used to implement the getaddrinfo resolver.
|
|
|
|
//
|
|
|
|
// This is the CGO_ENABLED=1 implementation of this function, which
|
|
|
|
// always returns the string "system", because in this scenario
|
|
|
|
// we are actually calling the getaddrinfo libc function.
|
|
|
|
func getaddrinfoResolverNetwork() string {
|
|
|
|
return "system"
|
|
|
|
}
|
|
|
|
|
|
|
|
// getaddrinfoLookupANY attempts to perform an ANY lookup using getaddrinfo.
|
|
|
|
//
|
|
|
|
// This is the CGO_ENABLED=1 implementation of this function.
|
|
|
|
//
|
|
|
|
// Arguments:
|
|
|
|
//
|
|
|
|
// - ctx is the context for deadline/timeout/cancellation
|
|
|
|
//
|
|
|
|
// - domain is the domain to lookup
|
|
|
|
//
|
|
|
|
// This function returns the list of looked up addresses, the CNAME, and
|
|
|
|
// the error that occurred. On error, the list of addresses is empty. The
|
|
|
|
// CNAME may be empty on success, if there's no CNAME, but may also be
|
|
|
|
// non-empty on failure, if the lookup result included a CNAME answer but
|
|
|
|
// did not include any A or AAAA answers.
|
2022-05-28 15:10:30 +02:00
|
|
|
func getaddrinfoLookupANY(ctx context.Context, domain string) ([]string, string, 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
|
|
|
return getaddrinfoStateSingleton.LookupANY(ctx, domain)
|
2022-05-28 15:10:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// getaddrinfoSingleton is the getaddrinfo singleton.
|
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
|
|
|
var getaddrinfoStateSingleton = newGetaddrinfoState(getaddrinfoNumSlots)
|
2022-05-28 15:10:30 +02:00
|
|
|
|
|
|
|
// getaddrinfoSlot is a slot for calling getaddrinfo. The Go standard lib
|
|
|
|
// limits the maximum number of parallel calls to getaddrinfo. They do that
|
|
|
|
// to avoid using too many threads if the system resolver for some
|
|
|
|
// reason doesn't respond. We need to do the same. Because OONI does not
|
|
|
|
// need to be as general as the Go stdlib, we'll use a small-enough number
|
|
|
|
// of slots, rather than checking for rlimits, like the stdlib does,
|
|
|
|
// e.g., on Unix. This struct represents one of these slots.
|
|
|
|
type getaddrinfoSlot struct{}
|
|
|
|
|
|
|
|
// getaddrinfoState is the state associated to getaddrinfo.
|
|
|
|
type getaddrinfoState struct {
|
|
|
|
// sema is the semaphore that only allows a maximum number of
|
|
|
|
// getaddrinfo slots to be active at any given time.
|
|
|
|
sema chan *getaddrinfoSlot
|
|
|
|
|
|
|
|
// lookupANY is the function that actually implements
|
|
|
|
// the lookup ANY lookup using getaddrinfo.
|
|
|
|
lookupANY func(domain string) ([]string, string, error)
|
|
|
|
}
|
|
|
|
|
|
|
|
// getaddrinfoNumSlots is the maximum number of parallel calls
|
|
|
|
// to getaddrinfo we may have at any given time.
|
|
|
|
const getaddrinfoNumSlots = 8
|
|
|
|
|
|
|
|
// newGetaddrinfoState creates the getaddrinfo state.
|
|
|
|
func newGetaddrinfoState(numSlots int) *getaddrinfoState {
|
|
|
|
state := &getaddrinfoState{
|
|
|
|
sema: make(chan *getaddrinfoSlot, numSlots),
|
|
|
|
lookupANY: nil,
|
|
|
|
}
|
|
|
|
state.lookupANY = state.doLookupANY
|
|
|
|
return state
|
|
|
|
}
|
|
|
|
|
|
|
|
// lookupANY invokes getaddrinfo and returns the results.
|
|
|
|
func (state *getaddrinfoState) LookupANY(ctx context.Context, domain string) ([]string, string, error) {
|
|
|
|
if err := state.grabSlot(ctx); err != nil {
|
|
|
|
return nil, "", err
|
|
|
|
}
|
|
|
|
defer state.releaseSlot()
|
|
|
|
return state.doLookupANY(domain)
|
|
|
|
}
|
|
|
|
|
|
|
|
// grabSlot grabs a slot for calling getaddrinfo. This function may block until
|
|
|
|
// a slot becomes available (or until the context is done).
|
|
|
|
func (state *getaddrinfoState) grabSlot(ctx context.Context) error {
|
|
|
|
// Implementation note: the channel has getaddrinfoNumSlots capacity, hence
|
|
|
|
// the first getaddrinfoNumSlots channel writes will succeed and all the
|
|
|
|
// subsequent ones will block. To unblock a pending request, we release a
|
|
|
|
// slot by reading from the channel.
|
|
|
|
select {
|
|
|
|
case state.sema <- &getaddrinfoSlot{}:
|
|
|
|
return nil
|
|
|
|
case <-ctx.Done():
|
|
|
|
return ctx.Err()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// releaseSlot releases a previously acquired slot.
|
|
|
|
func (state *getaddrinfoState) releaseSlot() {
|
|
|
|
<-state.sema
|
|
|
|
}
|
|
|
|
|
|
|
|
// doLookupANY calls getaddrinfo. We assume that you've already grabbed a
|
|
|
|
// slot and you're defer-releasing it when you're done.
|
|
|
|
//
|
|
|
|
// This function is adapted from cgoLookupIPCNAME
|
|
|
|
// https://github.com/golang/go/blob/go1.17.6/src/net/cgo_unix.go#L145
|
|
|
|
//
|
|
|
|
// SPDX-License-Identifier: BSD-3-Clause.
|
|
|
|
func (state *getaddrinfoState) doLookupANY(domain string) ([]string, string, error) {
|
|
|
|
var hints C.struct_addrinfo // zero-initialized by Go
|
|
|
|
hints.ai_flags = getaddrinfoAIFlags
|
|
|
|
hints.ai_socktype = C.SOCK_STREAM
|
|
|
|
hints.ai_family = C.AF_UNSPEC
|
|
|
|
h := make([]byte, len(domain)+1)
|
|
|
|
copy(h, domain)
|
|
|
|
var res *C.struct_addrinfo
|
|
|
|
// From https://pkg.go.dev/cmd/cgo:
|
|
|
|
//
|
|
|
|
// "Any C function (even void functions) may be called in a multiple
|
|
|
|
// assignment context to retrieve both the return value (if any) and the
|
|
|
|
// C errno variable as an error"
|
|
|
|
code, err := C.getaddrinfo((*C.char)(unsafe.Pointer(&h[0])), nil, &hints, &res)
|
|
|
|
if code != 0 {
|
|
|
|
return nil, "", state.toError(int64(code), err, runtime.GOOS)
|
|
|
|
}
|
|
|
|
defer C.freeaddrinfo(res)
|
|
|
|
return state.toAddressList(res)
|
|
|
|
}
|
|
|
|
|
|
|
|
// toAddressList is the function that converts the return value from
|
|
|
|
// the getaddrinfo function into a list of strings.
|
|
|
|
//
|
|
|
|
// This function is adapted from cgoLookupIPCNAME
|
|
|
|
// https://github.com/golang/go/blob/go1.17.6/src/net/cgo_unix.go#L145
|
|
|
|
//
|
|
|
|
// SPDX-License-Identifier: BSD-3-Clause.
|
|
|
|
func (state *getaddrinfoState) toAddressList(res *C.struct_addrinfo) ([]string, string, error) {
|
|
|
|
var (
|
|
|
|
addrs []string
|
|
|
|
canonname string
|
|
|
|
)
|
|
|
|
for r := res; r != nil; r = r.ai_next {
|
|
|
|
if r.ai_canonname != nil {
|
|
|
|
canonname = C.GoString(r.ai_canonname)
|
|
|
|
}
|
|
|
|
// We only asked for SOCK_STREAM, but check anyhow.
|
|
|
|
if r.ai_socktype != C.SOCK_STREAM {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
addr, err := state.addrinfoToString(r)
|
|
|
|
if err != nil {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
addrs = append(addrs, addr)
|
|
|
|
}
|
|
|
|
if len(addrs) < 1 {
|
|
|
|
return nil, canonname, ErrOODNSNoAnswer
|
|
|
|
}
|
|
|
|
return addrs, canonname, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// errGetaddrinfoUnknownFamily indicates we don't know the address family.
|
|
|
|
var errGetaddrinfoUnknownFamily = errors.New("unknown address family")
|
|
|
|
|
|
|
|
// addrinfoToString is the function that converts a single entry
|
|
|
|
// in the struct_addrinfos linked list into a string.
|
|
|
|
//
|
|
|
|
// This function is adapted from cgoLookupIPCNAME
|
|
|
|
// https://github.com/golang/go/blob/go1.17.6/src/net/cgo_unix.go#L145
|
|
|
|
//
|
|
|
|
// SPDX-License-Identifier: BSD-3-Clause.
|
|
|
|
func (state *getaddrinfoState) addrinfoToString(r *C.struct_addrinfo) (string, error) {
|
|
|
|
switch r.ai_family {
|
|
|
|
case C.AF_INET:
|
|
|
|
sa := (*syscall.RawSockaddrInet4)(unsafe.Pointer(r.ai_addr))
|
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
|
|
|
addr := net.IPAddr{IP: getaddrinfoCopyIP(sa.Addr[:])}
|
2022-05-28 15:10:30 +02:00
|
|
|
return addr.String(), nil
|
|
|
|
case C.AF_INET6:
|
|
|
|
sa := (*syscall.RawSockaddrInet6)(unsafe.Pointer(r.ai_addr))
|
|
|
|
addr := net.IPAddr{
|
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
|
|
|
IP: getaddrinfoCopyIP(sa.Addr[:]),
|
|
|
|
Zone: getaddrinfoIfNametoindex(int(sa.Scope_id)),
|
2022-05-28 15:10:30 +02:00
|
|
|
}
|
|
|
|
return addr.String(), nil
|
|
|
|
default:
|
|
|
|
return "", errGetaddrinfoUnknownFamily
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// getaddrinfoCopyIP copies a net.IP.
|
2022-05-28 15:10:30 +02:00
|
|
|
//
|
|
|
|
// This function is adapted from copyIP
|
|
|
|
// https://github.com/golang/go/blob/go1.17.6/src/net/cgo_unix.go#L344
|
|
|
|
//
|
|
|
|
// SPDX-License-Identifier: BSD-3-Clause.
|
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
|
|
|
func getaddrinfoCopyIP(x net.IP) net.IP {
|
2022-05-28 15:10:30 +02:00
|
|
|
if len(x) < 16 {
|
|
|
|
return x.To16()
|
|
|
|
}
|
|
|
|
y := make(net.IP, len(x))
|
|
|
|
copy(y, x)
|
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
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
|
|
|
// getaddrinfoIfNametotindex converts an IPv6 scope index into an interface name.
|
2022-05-28 15:10:30 +02:00
|
|
|
//
|
|
|
|
// This function is adapted from ipv6ZoneCache.update
|
|
|
|
// https://github.com/golang/go/blob/go1.17.6/src/net/interface.go#L194
|
|
|
|
//
|
|
|
|
// SPDX-License-Identifier: BSD-3-Clause.
|
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
|
|
|
func getaddrinfoIfNametoindex(idx int) string {
|
2022-05-28 15:10:30 +02:00
|
|
|
iface, err := net.InterfaceByIndex(idx) // internally uses caching
|
|
|
|
if err != nil {
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
return iface.Name
|
|
|
|
}
|