Quali checksum EEPROM vanno ricalcolati dopo aver modificato vendor name e PN in un'immagine SFP

Il tuo programmatore sta facendo quello che gli strumenti basati su CH341 fanno normalmente, cioè niente. Scrivono i byte che gli passi e non toccano mai i campi checksum. I programmatori vendor ricalcolano alla scrittura, ed è per questo che chi usa solo quelli non ci sbatte mai contro ed è convinto che tutto l'argomento sia immaginario.

Due cose da chiarire prima di scrivere qualsiasi strumento. Primo, cosa ha riletto l'immagine dopo la scrittura - lo stesso strumento che l'ha scritta, o qualcosa di indipendente? Un lettore che ti serve la propria cache mostrerà volentieri un byte che non è mai arrivato nel chip. Secondo, hai calcolato tu stesso la somma sui byte da 0 a 62 dell'immagine modificata e l'hai confrontata con il byte 63, o stai solo confrontando il byte 63 con il dump originale? Invariato e corretto non sono lo stesso test, e le tue note mostrano solo il primo.

Vale la pena anche nominare l'host che lo rifiuta. Alcuni leggono i campi identità e non verificano niente, altri validano rigorosamente e scartano il modulo nel momento in cui una somma non torna. Stessa immagine, verdetto diverso.

Ce ne sono due e sono somme stupide a 8 bit, nessun CRC coinvolto da nessuna parte.

• CC_BASE sta al byte 63 ed è gli 8 bit bassi della somma dei byte da 0 a 62
• CC_EXT sta al byte 95 e copre i byte da 64 a 94

Vendor name e vendor PN vivono entrambi nell'area base, quindi la tua modifica ha invalidato CC_BASE mentre CC_EXT è rimasto legittimamente corretto. Le modifiche a numero di serie e date code colpiscono invece l'intervallo esteso, e allora è il byte 95 a diventare non aggiornato. Ricalcolare l'uno o l'altro sono due righe sul buffer: somma l'intervallo, maschera con 0xFF, memorizza nel byte somma.

Se preferisci non farlo a mano, esiste della strumentazione. py-sfp-eeprom costruisce e valida immagini EEPROM da Python (python3 -m sfp_eeprom), e sfppi gira su un Raspberry Pi, controlla le somme e si offre di sistemarle. Entrambi sono un'abitudine migliore di hex editor più calcolo mentale, perché la modalità di fallimento è silenziosa - il modulo rilegge esattamente quello che hai scritto e solo l'host si lamenta mai.

Far tornare giuste le due somme MSA è necessario e, a seconda della porta in cui stai inserendo il modulo, non sufficiente.

Cisco è l'esempio più consumato: il controllo di identità non è solo le stringhe. Qualcuno anni fa ha capito che il valore che un modulo codificato Cisco porta si può riprodurre con niente di più esotico di xxd -r -p | md5sum, dandogli in pasto il byte del codice vendor e poi i byte del nome. In quei dump codice e nome sono legati l'uno all'altro - Finisar sta dietro 02, Methode dietro 0E. Fai in modo che i due non siano d'accordo e un Catalyst 2960X sputa fuori di nuovo il modulo, comandi di sblocco o no.

È di solito per questo che un dump copiato da un modulo funzionante smette di funzionare una volta che qualcuno ci ha incollato dentro una stringa vendor diversa. Le somme sono a posto, l'identità non è più autoconsistente.

Piccola correzione all'impostazione «sistemi le due somme e hai finito»: quella vale per i campi MSA, non per l'idea di ogni vendor di cosa sia un'immagine valida.

HP è il controesempio ricorrente. Modifica il numero di serie in un'immagine J4858B, byte da 68 a 83, e cambiano anche i byte da 124 a 127 di A0 - un checksum vendor che sta oltre i byte MSA CC_BASE e CC_EXT. Quel caso è stato rimasticato a lungo e nessuno ha mai pubblicato l'algoritmo; la gente ha confermato che quei byte contano e il thread è finito lì. Stessa storia segnalata su J4859C e J9150A. Più avanti l'hardware HP e Aruba è passato a uno schema challenge response (HPIDv2), che in un'EEPROM non puoi proprio falsificare.

Quindi prima di investire in strumentazione, capisci cosa valida l'host di destinazione: due somme additive per un host semplice, un'identità internamente consistente per Catalyst, e su alcuni pezzi HP un campo non documentato che non riprodurrai.