Bir SFP image'inde vendor name ve PN düzenledikten sonra hangi EEPROM checksum'ları yeniden hesaplanmalı
Tezgah işi: küçük bir SFP+ modül partisini, müşterinin kitinin beklediği vendor string ve part number'ı taşıyacak şekilde yeniden kodluyorum. Düzenlemenin kendisi bir hex editöründe önemsiz, yazma geçiyor, geri okuma yazdığımla byte byte eşleşiyor - ve host modülü yine de dışarı atıyor.
- jenerik SFP+ modülleri, A0 sayfası elle düzenlendi
- CH341 tabanlı programlayıcı, birlikte gelen araçla
- düzenlenen alanlar: vendor name ve vendor part number, başka hiçbir şeye dokunulmadı
- aynı modüle geri yazılan el değmemiş bir dump sorunsuz çalışıyor, yani yazma yolunun kendisi sorun değil
Düzenlemeden sonra karşılaştırdığım:
edited fields : vendor name, vendor PN
byte 63 CC_BASE : identical to the original image
byte 95 CC_EXT : identical to the original image
host : rejects the module, checksum errorYani payload değişirken sum byte'ları açıkça kıpırdamadı. Bunun için kendi aracımı yazmaya gitmeden önce: bu iki sum gerçekte hangi byte aralıklarını kapsıyor, düz toplamsal sum'lar mı yoksa CRC şeklinde bir şey mi, ve her modülde elle aritmetik yapmayayım diye bunları yeniden hesaplayan bakımlı bir araç var mı?
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 4
Programlayıcın, CH341 tabanlı araçların normalde yaptığını yapıyor, yani hiçbir şey. Sana verdiğin byte'ları yazıyorlar ve checksum alanlarına asla dokunmuyorlar. Vendor programlayıcıları yazarken yeniden hesaplıyor, bu yüzden sadece onları kullananlar buna hiç takılmıyor ve tüm konunun hayali olduğuna ikna oluyor.
Herhangi bir araç yazmadan önce netleştirmeye değer iki şey var. Birincisi, yazmadan sonra image'i ne okudu - onu yazan aynı araç mı, yoksa bağımsız bir şey mi? Sana kendi cache'ini sunan bir okuyucu, chip'e hiç inmemiş bir byte'ı mutlulukla gösterir. İkincisi, düzenlenmiş image'in 0'dan 62'ye byte'ları üzerindeki toplamı kendin mi hesapladın ve bunu byte 63 ile karşılaştırdın, yoksa sadece byte 63'ü orijinal dump'la mı karşılaştırıyorsun? Değişmemiş olmak ile doğru olmak aynı test değil, ve notların sadece ilkini gösteriyor.
Onu reddeden host'u adlandırmaya da değer. Bazıları kimlik alanlarını okur ve hiçbir şey doğrulamaz, bazıları sıkı doğrular ve bir sum bozulduğu anda modülü düşürür. Aynı image, farklı hüküm.
İkisi de var ve ikisi de aptal 8 bit sum, hiçbir yerde CRC yok.
Vendor name ve vendor PN ikisi de base alanında yaşıyor, yani düzenlemen CC_BASE'i geçersiz kıldı, CC_EXT ise meşru şekilde doğru kaldı. Seri numarası ve tarih kodu düzenlemeleri bunun yerine extended aralığa vuruyor, ve o zaman bayatlayan byte 95 oluyor. İkisinden birini yeniden hesaplamak buffer üzerinde iki satır: aralığı topla, 0xFF ile maskele, sum byte'ına yaz.
Elle uğraşmak istemiyorsan, araçlar var. py-sfp-eeprom, Python'dan EEPROM image'leri oluşturuyor ve doğruluyor (
python3 -m sfp_eeprom), vesfppibir Raspberry Pi üzerinde çalışıp sum'ları kontrol ediyor ve düzeltmeyi teklif ediyor. İkisi de hex editör artı zihinden aritmetikten daha iyi bir alışkanlık, çünkü hata modu sessiz - modül tam olarak yazdığın gibi geri okunuyor ve şikayet eden sadece host oluyor.İki MSA sum'ını doğru almak gerekli, ve hangi host'un portuna taktığına bağlı olarak, yeterli değil.
Cisco iyi bilinen örnek: kimlik kontrolü sadece string'lerden ibaret değil. Biri yıllar önce, Cisco kodlu bir modülün taşıdığı değerin, vendor code byte'ı ve ardından name byte'larının beslendiği
xxd -r -p | md5sum'dan daha egzotik bir şeyle üretilemeyeceğini çözmüş. O dump'larda kod ve isim birbirine bağlı - Finisar 02'nin arkasında oturuyor, Methode 0E'nin arkasında. İkisini uyuşmaz bırak, bir Catalyst 2960X modülü unlock komutları olsun olmasın yine tükürür.Genelde çalışan bir modülden kopyalanan bir dump'ın, biri içine farklı bir vendor string yapıştırdıktan sonra çalışmayı bırakmasının nedeni bu. Sum'lar iyi, kimlik artık kendi içinde tutarlı değil.
"İki sum'ı düzelt ve bitir" çerçevesine küçük bir düzeltme: bu MSA alanları için geçerli, her üreticinin geçerli bir image fikri için değil.
HP kalıcı karşı örnek. Bir J4858B image'inde seri numarasını, byte 68'den 83'e, düzenle, A0'ın 124'ten 127'ye byte'ları da değişiyor - MSA CC_BASE ve CC_EXT byte'larının ötesinde oturan bir vendor checksum'ı. Bu, uzun uzadıya tartışıldı ve algoritmayı kimse hiç yayınlamadı; insanlar byte'ların önemli olduğunu doğruladı ve konu orada bitti. Aynı hikaye J4859C ve J9150A çevresinde de bildirildi. Daha sonraki HP ve Aruba donanımı bir challenge response şemasına (HPIDv2) geçti, ki bunu bir EEPROM'da hiç sahte üretemezsin.
O yüzden araca yatırım yapmadan önce, hedef host'un neyi doğruladığını çöz: sıradan bir host için iki toplamsal sum, Catalyst için kendi içinde tutarlı bir kimlik, ve bazı HP parçalarında yeniden üretemeyeceğin belgelenmemiş bir alan.