Checksum EEPROM mana yang harus diitung ulang setelah edit vendor name dan PN di image SFP

Programmer kamu ngelakuin apa yang biasanya dilakuin tool berbasis CH341, yaitu tidak ada apa-apa. Mereka nulis byte yang kamu kasih dan tidak pernah nyentuh field checksum. Programmer vendor itung ulang waktu write, makanya orang yang cuma pernah pakai itu tidak pernah kena ini dan yakin seluruh topik ini imajiner.

Dua hal layak dipastikan sebelum kamu nulis tooling apa pun. Pertama, apa yang baca image-nya balik setelah write - tool yang sama yang nulis itu, atau sesuatu yang independen? Reader yang nyajiin cache-nya sendiri bakal dengan senang hati nunjukin byte yang tidak pernah beneran masuk ke chip-nya. Kedua, apa kamu itung sendiri sum-nya di byte 0 sampai 62 dari image yang diedit terus bandingin itu sama byte 63, atau kamu cuma bandingin byte 63 terhadap dump original? Tidak berubah dan benar itu bukan test yang sama, dan catatan kamu cuma nunjukin yang pertama.

Juga layak sebutin nama host yang nolak itu. Sebagian baca field identity-nya dan tidak verifikasi apa-apa, yang lain validasi ketat dan buang modulnya begitu satu sum-nya salah. Image yang sama, vonis yang beda.

Ada dua, dan itu sum 8-bit yang dumb, tidak ada CRC yang terlibat sama sekali.

• CC_BASE duduk di byte 63 dan itu 8 bit rendah dari sum byte 0 sampai 62
• CC_EXT duduk di byte 95 dan cover byte 64 sampai 94

Vendor name dan vendor PN dua-duanya tinggal di base area, jadi edit kamu bikin CC_BASE invalid sementara CC_EXT tetap legitimately benar. Edit serial number dan date code malah kena extended range, dan di situ byte 95 yang jadi basi. Ngitung ulang salah satunya cuma dua baris di atas buffer-nya: sum range-nya, mask sama 0xFF, simpan ke sum byte-nya.

Kalau kamu tidak mau bikin sendiri, ada tooling-nya. py-sfp-eeprom build dan validasi image EEPROM dari Python (python3 -m sfp_eeprom), dan sfppi jalan di Raspberry Pi, cek sum-nya dan nawarin buat benerin itu. Dua-duanya kebiasaan yang lebih baik daripada hex editor plus itung manual, soalnya failure mode-nya diam-diam - modulnya kebaca balik persis kayak yang kamu tulis dan cuma host-nya yang komplain.

Membenerin dua sum MSA itu perlu, dan tergantung port siapa yang kamu tancepin, itu belum cukup.

Cisco itu contoh yang udah biasa banget: pengecekan identity-nya bukan cuma soal string. Ada yang udah cari tau bertahun-tahun lalu bahwa nilai yang dibawa modul yang di-coding Cisco bisa direproduksi cuma pakai xxd -r -p | md5sum, dikasih byte vendor code terus byte name-nya. Di dump-dump itu code dan name-nya keiket satu sama lain - Finisar duduk di belakang 02, Methode di belakang 0E. Biarin dua itu tidak sepakat dan Catalyst 2960X bakal muntahin modulnya lagi, ada unlock command atau tidak ada.

Itu biasanya kenapa dump yang di-copy dari modul yang jalan berhenti jalan begitu ada yang paste vendor string yang beda ke situ. Sum-nya baik-baik saja, identity-nya yang sudah tidak self consistent lagi.

Koreksi kecil buat framing "benerin dua sum-nya terus beres": itu berlaku buat field MSA, bukan buat ide tiap vendor soal image yang valid.

HP itu counterexample yang tetap berlaku. Edit serial number di image J4858B, byte 68 sampai 83, dan byte 124 sampai 127 di A0 ikut berubah - checksum vendor yang duduk lewat byte MSA CC_BASE dan CC_EXT. Itu udah dibahas panjang lebar dan tidak ada yang pernah publish algoritmanya; orang-orang confirmed byte-nya penting dan thread-nya berhenti di situ. Cerita yang sama dilaporin soal J4859C dan J9150A. Belakangan hardware HP dan Aruba pindah ke skema challenge response (HPIDv2), yang sama sekali tidak bisa kamu forge di EEPROM.

Jadi sebelum kamu invest di tooling, cari tau dulu apa yang divalidasi host tujuannya: dua additive sum buat host biasa, identity yang internally consistent buat Catalyst, dan di sebagian part HP, field yang tidak terdokumentasi yang tidak bakal bisa kamu reproduksi.