Programmer balikin WRITE FAIL di SFP+ yang dump-nya bersih: EEPROM mati atau ada yang blokir write?
Kami recode batch kecil modul buat host customer hampir tiap bulan, tidak ada yang eksotis: baca page original-nya, tulis vendor string yang diminta host-nya, pasang modulnya ke switch, lanjut. Satu modul dari batch sekarang nolak tiap write padahal dibaca balik sempurna, dan sebelum saya buang itu, saya mau tau apa masih ada yang bisa dicoba.
Bench:
- programmer USB kelas CH341 dengan breakout board SFP
- modul SFP+, diagnostics capable, kebaca normal dingin maupun setelah power cycle
- rig yang sama nulis tiga modul lain dari tray yang sama sejam sebelumnya
Yang di-print tool-nya begitu saya pencet write:
WRITE FAILBaca ulang langsung setelah itu ngasih saya page original balik byte demi byte, jadi memang tidak ada yang masuk sama sekali, bahkan sebagian pun tidak.
Yang sudah saya coba:
- pasang ulang modulnya dan ganti breakout board-nya dengan yang spare
- tulis satu byte doang di region yang tidak saya pedulikan, bukan full page, hasilnya sama
- confirmed pembacaannya stabil di beberapa kali power cycle, jadi bukan wiring yang marginal
Modul yang kebaca bersih tapi tidak pernah nerima write itu emang cuma worn out, atau ada sesuatu di dalam modulnya sendiri yang bisa nolak write dengan sengaja?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Baca bersih, write ditolak, page original utuh sesudahnya. Itu bukan cara EEPROM worn out biasanya berkelakuan. Cell yang mati ngasih kamu read-back yang jelek atau page yang cuma setengah ke-write, bukan penolakan yang rapi dengan semuanya tidak tersentuh.
Dan berhubung satu byte doang di luar area vendor pun mantul, ini bukan region jelek di chip-nya, ini part-nya yang nolak write secara menyeluruh. Dua hal layak dipastikan dulu sebelum kamu putusin apa-apa. Pertama, siapa yang beneran bikin modulnya: liat dari vendor string di page yang udah kamu dump, bukan dari label di tray-nya. Kedua, apa write-nya masuk kalau kamu tembak itu persis waktu power baru nyala, sebelum yang lain di bus-nya sempat ngomong ke modulnya. Penjelasan yang mungkin beda-beda tergantung jawaban itu, dan salah satunya bukan fault sama sekali.
Itu kebacanya kayak password protection, bukan kerusakan. SFF-8472 ngebolehin modul yang diagnostics-capable buat mensyaratkan password 4-byte sebelum dia nerima write apa pun. Tidak kirim apa-apa, atau kirim yang salah, dan modulnya jawab write-nya dengan error sementara read-nya tetap kebuka lebar, yang persis WRITE FAIL kamu dengan page-nya balik tidak berubah. Itu fitur dari part-nya, bukan gejala dari yang lagi sekarat.
Artinya buat bench kamu: programmer yang ngerti soal ini ngebolehin kamu masukin password manufacturer atau host, dan yang lebih bagus bakal brute force yang tidak diketahui dan itung ulang checksum-nya buat kamu setelah write. Rig kelas CH341 sama sekali tidak punya otomasi checksum, jadi bahkan setelah kamu lewatin password-nya, kamu harus benerin checksum-nya sendiri, kalau tidak kamu bakal berakhir dengan modul yang page-nya kelihatan benar buat kamu tapi tetap ditolak host-nya.
Caveat biasa: saya pernah ketemu ini di beberapa modul dan jalur password-nya berhasil di situ, jadi coba di part kamu sendiri sebelum kamu nyerah sama apa pun.
Nambahin dikit: buat sebagian vendor, password-nya tidak beneran rahasia. Ada koleksi password transceiver Ubiquiti yang beredar dengan entry kayak 0x00001011 dan string polos kayak SFPX dan QSFP, jadi kalau modulnya keluar dari ekosistem itu, cuma butuh lima menit buat coba yang udah diketahui sebelum kamu deket-deket ke brute force.
Dan kalau kamu mau tool yang udah ngerti seluruh flow-nya ketimbang lawan programmer generic, UACC-SFP-WIZARD itu opsi murah yang orang-orang pakai. Bukan instrumen lab, tapi dia handle sisi modulnya dengan benar.
Terkait, dari recode modul buat host Huawei S5731 dan S6730 dan HP 6120XG yang lama. Kalau cage atau breakout-nya yang jadi weak link, bukan modulnya, orang-orang solder langsung ke pin 4 dan 7 di modulnya, itu jalur I2C SDA dan SCL, dan drive EEPROM-nya dengan cage-nya keluar sepenuhnya dari gambaran. Jelek emang, dan cuma dikerjain di part yang kamu udah siap buat direlain, tapi itu ngilangin satu kelas penuh masalah contact.
Part yang udah lewatin itu di sini: Finisar FTLX8571D3BCV dan FTLX8574D3BCV, modul Intel SFP+ LR dan SR, SNR-SFP+W73-3 dan SNR-SFP+W37-3, plus satu HP J9150A.
Di kasus kamu, pembacaannya udah rock solid di beberapa power cycle, jadi contact bukan masalah kamu. Kejar dulu sudut password-nya.
Password itu jawaban yang paling mungkin, tapi jangan berhenti di "ketik password-nya terus beres", soalnya dua hal ini nyokot orang persis setelah itu.
Pertama, di sebagian part, entry-nya diminta lagi setelah modulnya dimatikan, jadi script yang nulis beberapa page berurutan harus siap masukin ulang, jangan asumsi satu unlock nutupin seluruh sesi.
Kedua, checksum-nya. Dengan programmer kelas CH341, kamu itung ulang itu manual. Biarin itu basi dan modulnya tetap kebaca normal, tool kamu lapor sukses, dan host-nya diam-diam tetap nolak modulnya, di titik itu semua orang balik nyalahin hardware-nya. Baca lagi page-nya dan verifikasi sum-nya sebelum modul itu masuk ke switch customer.