Apa yang dihitung Catalyst 2960X dari dump SFP: kode vendor, nama, dan MD5, dan kenapa salinan dump-nya nggak lolos
Saya mengurus jaringan provider, koleksi modulnya campur aduk, jadi rutin harus menyiapkan modul buat switch tertentu. Saya mau akhirnya paham mekanisme pengecekannya, bukan asal coba-coba dump.
Yang saya pakai:
- Cisco Catalyst 2960X-24PS-L, yang paling rewel di koleksi saya
- QTECH QSW-3750-28TX-AC dan D-Link DGS-3420, di situ modul yang sama naik dengan tenang
- modul SNR-SFP+SR dan SFP-10G-BX
Di dump modul yang diterima Catalyst, di bagian awal saya lihat byte kode vendor dan setelah itu nama dalam ASCII:
0E 43 49 53 43 4F ...Yang sudah saya coba: ambil dump dari modul yang naik di C2960X-24PS-L, lalu tulis ulang ke modul lain cuma nama vendor dari dump itu saja. Di QTECH dan D-Link, setelah itu semuanya naik, tapi Catalyst nggak menerima modul semacam itu, padahal byte yang sudah diperbaiki cocok satu-satu dengan donornya.
Dari situ pertanyaan saya soal mekanisme pengecekannya. Apa sebenarnya yang dihitung Cisco dan dari byte mana, di mana hasilnya disimpan di dalam modul, dan kenapa nama vendor yang ditulis ulang dari dump yang jalan itu nggak cukup? Yang penting buat saya logikanya, sisanya saya urus sendiri.
Comments 6
Mekanismenya di situ sederhana dan sudah lama dibongkar. Yang dicek bukan satu field terpisah, tapi kombinasi: byte kode vendor plus byte nama vendor. Dari urutan itu diambil MD5-nya, dan hasilnya disimpan di dalam modulnya sendiri, switch-nya menghitung hal yang sama dan membandingkan.
Bisa direproduksi pakai utility standar, nggak perlu apa pun yang khusus:
Masukkan kode dan nama vendor Anda sendiri, dan Anda dapat nilai yang seharusnya disimpan di modulnya. Dari kode yang benar-benar muncul di dump: 02 - Finisar, 0E - Methode, 11 sering muncul juga, tapi punya siapa itu nggak pernah berhasil diidentifikasi. Kalau pasangan kode-nama sudah cocok dan hash-nya sesuai, modulnya lolos di C2960X-24PS-L.
Menanggapi yang sebelumnya: tunjukkan apa yang sebenarnya ada di modul penerima Anda. Byte kode vendor apa yang masih tersisa di situ dan nama apa yang ada di sebelahnya? Dari deskripsinya, Anda memindahkan namanya, tapi kode atau hash-nya sendiri masih dari modul aslinya, dan kalau begitu kombinasinya jadi nggak nyambung, dan Catalyst menolaknya dengan sangat sah. Cek ketiga hal itu sekaligus, jangan cuma field yang kelihatan di output switch-nya.
Sudah saya cek, semuanya cocok dengan versi Anda. Di donornya 0E lalu CISCO, dan di penerima saya memang menulis ulang namanya, tapi kode vendornya tetap yang asli, dan hash-nya juga masih yang lama. Saya jalankan kedua kombinasi lewat xxd -r -p dan md5sum: punya donor nilainya cocok dengan yang ada di modul, punya saya yang dirakit manual tidak.
Jadi yang perlu dipindahkan itu kombinasinya secara utuh, bukan satu field saja. Sekarang setidaknya sudah jelas ke mana harus lihat dan apa yang perlu dicocokkan sebelum pasang modulnya ke port.
Konsekuensi penting yang terus-menerus dilupakan: kalau kode vendor dan namanya nggak cocok, modulnya nggak akan lolos di Catalyst bahkan waktu switch-nya sudah mengizinkan modul unsupported. Itu persis kenapa dump orang lain jalan cuma sesekali - dump itu diperbaiki cuma sebagian, sementara pengecekannya melihat kombinasinya.
Dari situ kesimpulan praktis soal volumenya: di dump 256-byte, yang signifikan itu 128 byte pertama, setelah itu masuk zona pabrikan. Nggak perlu bawa seluruh image-nya, tapi paruh pertamanya harus dipindahkan secara konsisten, termasuk field yang nggak kelihatan mata di output switch-nya.
Ngomong-ngomong, nggak semua bisa diselesaikan dengan dump. Di Medick SFP-10G-BX yang duduk di situ bukan memori, tapi mikrokontroler C8051F392: dia mengemulasikan A0 dan A2 dan bisa saja memegang password atau vendor challenge. Di situ mau dicocokkan sampai ke byte pun kombinasinya, dari luar tetap nggak akan diterima. Dari tool yang benar-benar saya pakai ada SNR SFP Writer dan SFPTotal Plus, rekan-rekan saya juga punya buatan sendiri berbasis CH341.
Sedikit koreksi, biar nggak membingungkan orang yang datang ke sini belakangan. MD5 ini sama sekali nggak ada hubungannya dengan checksum MSA: CC_BASE dan CC_EXT dari SFF-8472 dihitung dengan penjumlahan byte sederhana dan gampang dihitung ulang. Pengecekan vendor ini hidup di atasnya dengan aturannya sendiri, dan menolak modulnya persis di saat checksum MSA-nya sudah benar semua - dari situlah muncul kesan dump-nya sudah benar tapi modulnya tetap nggak diterima.
Cisco di sini, ngomong-ngomong, jauh dari kasus terburuk: mekanismenya setidaknya bisa dipahami dan direproduksi. Yang paling berat itu HP dan Aruba, di mana memorinya berperilaku interaktif dan minta key - di situ dump saja sudah nggak cukup.