Które sumy kontrolne EEPROM trzeba przeliczyć po edycji vendor name i PN w obrazie SFP

Twój programator robi to, co narzędzia na bazie CH341 zwykle robią, czyli nic. Zapisują bajty, jakie im podasz, i nigdy nie ruszają pól sum kontrolnych. Programatory producenckie przeliczają je przy zapisie, dlatego ludzie, którzy używają tylko takich, nigdy na to nie trafiają i są przekonani, że cały temat jest wymyślony.

Dwie rzeczy warto ustalić, zanim usiądziesz do pisania jakiegokolwiek narzędzia. Po pierwsze, co odczytało obraz z powrotem po zapisie - to samo narzędzie, które zapisywało, czy coś niezależnego? Czytnik serwujący ci własny cache chętnie pokaże bajt, który nigdy nie wylądował w chipie. Po drugie, czy sam wyliczyłeś sumę po bajtach 0 do 62 edytowanego obrazu i porównałeś to z bajtem 63, czy tylko porównujesz bajt 63 z oryginalnym dumpem? „Niezmieniony" i „poprawny" to nie ten sam test, a twoje notatki pokazują tylko pierwszy.

Warto też nazwać hosta, który to odrzuca. Niektóre czytają pola tożsamości i niczego nie weryfikują, inne walidują ściśle i odrzucają moduł w momencie, gdy suma się nie zgadza. Ten sam obraz, inny werdykt.

Są dwie i to głupie sumy 8-bitowe, żadnego CRC nigdzie w tym nie ma.

• CC_BASE siedzi w bajcie 63 i jest dolnymi 8 bitami sumy bajtów 0 do 62
• CC_EXT siedzi w bajcie 95 i obejmuje bajty 64 do 94

Vendor name i vendor PN oba mieszkają w obszarze base, więc twoja edycja unieważniła CC_BASE, podczas gdy CC_EXT zostało zgodnie z prawem poprawne. Edycje numeru seryjnego i date code trafiają za to w zakres extended, i wtedy to bajt 95 się dezaktualizuje. Przeliczenie którejkolwiek to dwie linijki nad buforem: zsumuj zakres, zamaskuj przez 0xFF, zapisz do bajtu sumy.

Jeśli wolisz tego nie robić ręcznie, jest gotowe narzędzie. py-sfp-eeprom buduje i waliduje obrazy EEPROM z Pythona (python3 -m sfp_eeprom), a sfppi działa na Raspberry Pi, sprawdza sumy i oferuje ich naprawę. Każde z nich to lepszy nawyk niż edytor hex plus arytmetyka w głowie, bo tryb awarii jest cichy - moduł czyta się z powrotem dokładnie tak, jak zapisałeś, i tylko host się skarży.

Poprawne ustawienie dwóch sum MSA jest konieczne i, zależnie od tego, w czyj port wpinasz, niewystarczające.

Cisco to wyświechtany przykład: sprawdzanie tożsamości to nie tylko stringi. Ktoś lata temu rozpracował, że wartość, jaką niesie moduł zakodowany przez Cisco, da się odtworzyć niczym bardziej egzotycznym niż xxd -r -p | md5sum, podając bajt kodu producenta, a potem bajty nazwy. W tych dumpach kod i nazwa są ze sobą powiązane - Finisar siedzi za 02, Methode za 0E. Niech te dwa się nie zgadzają, a Catalyst 2960X znów wypluje moduł, z komendami odblokowania czy bez.

Właśnie dlatego dump skopiowany z działającego modułu przestaje działać, gdy ktoś wklei do niego inny string producenta. Sumy są w porządku, tożsamość przestaje być spójna sama ze sobą.

Mała poprawka do ramowania „popraw dwie sumy i gotowe": to trzyma się dla pól MSA, nie dla wyobrażenia każdego producenta o poprawnym obrazie.

HP to stały kontrprzykład. Edytuj numer seryjny w obrazie J4858B, bajty 68 do 83, i bajty 124 do 127 w A0 też się zmieniają - suma kontrolna producenta siedząca za bajtami MSA CC_BASE i CC_EXT. To było długo przeżuwane i nikt nigdy nie opublikował algorytmu; ludzie potwierdzili, że te bajty mają znaczenie, i na tym wątek się skończył. Ta sama historia zgłaszana przy J4859C i J9150A. Późniejszy sprzęt HP i Aruba przeszedł na schemat wyzwanie-odpowiedź (HPIDv2), którego w EEPROM w ogóle się nie sfałszuje.

Więc zanim zainwestujesz w narzędzia, ustal, co dokładnie waliduje docelowy host: dwie sumy addytywne dla zwykłego hosta, spójną wewnętrznie tożsamość dla Catalyst, a przy niektórych częściach HP nieudokumentowane pole, którego i tak nie odtworzysz.