W

końcu znalazłem trochę czasu, aby za radą Hendrego zobaczyć, co tak naprawdę wychodzi z mojego telefonu (aktualnie korzystam z radioodbiornika wyposażonego w Android w wersji 6.0). Analogicznie, jak w poradniku przekierowałem streaming pakietów (na razie tylko UDP) z routera Mikrotik do komputera, na którym nasłuchiwał Wireshark filtrując tylko ruch z telefonu. Pierwszym adresem, jaki pojawił się na ekranie po włączeniu WiFi na urządzeniu był:

connectivitycheck.gstatic.com: type AAAA, class IN
connectivitycheck.gstatic.com: type A, class IN

Telefon chciał wiedzieć, na jakie adresy IPv6 oraz IPv4 rozwiązuje w/w domena. Chwila z Google potwierdziła, że jest to adres na podstawie, którego Android “wie”, że posiada dostęp do Internetu:

private static final String DEFAULT_SERVER = "connectivitycheck.gstatic.com";

Ciekawa jest także polityka na podstawie, której podejmowana jest decyzja, czy połączenie to ma być uznane za domyślne (w moim przypadku z włączonych WiFi i LTE zostawało zawsze wybrane WiFi, aby nie generować dodatkowych kosztów / wykorzystywać limitów, gdy w pobliżu są zaufane sieci):

// After a network has been tested this result can be sent with EVENT_NETWORK_TESTED.
// The network should be used as a default internet connection. It was found to be:
// 1. a functioning network providing internet access, or
// 2. a captive portal and the user decided to use it as is.
public static final int NETWORK_TEST_RESULT_VALID = 0;
// After a network has been tested this result can be sent with EVENT_NETWORK_TESTED.
// The network should not be used as a default internet connection. It was found to be:
// 1. a captive portal and the user is prompted to sign-in, or
// 2. a captive portal and the user did not want to use it, or
// 3. a broken network (e.g. DNS failed, connect failed, HTTP request failed).
public static final int NETWORK_TEST_RESULT_INVALID = 1;

Z racji, że korzystam z własnych serwerów DNS (jeden na Mikrotiku, drugi na Raspberry Pi) wymusiłem poprzez statyczne wpisy, aby domena ta dla zapytań “A” oraz “AAAA” rozwiązywała na adres 127.0.0.1. Po wyłączeniu i włączeniu bezprzewodowego połączenia w telefonie – przy ikonce pojawił się znak “!”, oznaczający ograniczoną łączność – oczywiście nie było problemu, abym w przeglądarce i innych aplikacjach mógł swobodnie mieć dostęp do Internetu. Aktywacja LTE teoretycznie nie powinna nic zmienić, ale tym razem po raz pierwszy na pasku aktywności pojawiły się dwie ikony równolegle, a strona ifconfig.me wskazywała, że użyte zostało połączenie LTE, a nie jak zawsze WiFi. Podobną technikę podobno stosował Iran oraz można ją spotkać w przypadku ograniczenia dostępu do gościnnych sieci WiFi:

Android and iOS devices will check Wi-Fi connectivity by sending a DNS query to connectivitycheck.gstatic.com and captive.apple.com…

Więcej informacji: Captive portal popups: the definitive guide [closed]