Ricodifica dell’EEPROM: password e meccanismi

Anni di discussioni tecniche si riducono a un punto: la compatibilità dei ricetrasmettitori non è una questione di firmware — sono le stringhe di identificazione nell’EEPROM, lette via I²C. Uno switch rifiuta un modulo semplicemente perché non riconosce la stringa del produttore. Questo solo fatto spiega la pratica diffusa di «codificare tutto come Cisco — funziona quasi ovunque» e l’intero mercato degli strumenti di codifica.

Dove risiedono le password

Scrivere nelle aree protette della memoria del modulo richiede una password di 4 byte inserita a un indirizzo fisso prima della scrittura:

Password citate comunemente

I moduli QSFP-DD di alcuni produttori vengono spediti con valori predefiniti fissi propri, e alcuni moduli basati su microprocessore usano una password variabile che cambia — una trappola per chi tenta la forza bruta.

Perché la forza bruta non è la soluzione

Una password a livello di produttore che protegge l’intera mappa di memoria richiede nell’ordine di 100+ giorni per essere forzata; anche una password ASCII a livello host richiede fino a circa tre giorni. La via pratica è un database di codici e password noti catturati da moduli originali — è lì che risiede il vero valore di uno strumento di codifica, non nell’hardware I²C (che è semplice).

Insidie dei programmatori fai-da-te

• I programmatori CH341A economici non calcolano il checksum dell’SFP. Scrivere un’immagine senza un CC_BASE/CC_EXT valido produce un modulo che lo switch rifiuterà. Serve uno strumento che ricalcoli i checksum automaticamente.
• Alcuni switch scrivono solo all’indirizzo 0x50, quindi la password a 0x51 non può essere raggiunta dallo switch stesso — serve una vera scheda di programmazione.
• Il pin di protezione in scrittura dell’EEPROM — alcune fabbriche collegano WP a Vcc, così il modulo resta bloccato in scrittura sul campo.

Casi dal campo

• Moduli codificati come un produttore non facevano autonegoziazione su uno switch di un altro; ricodificati con la stringa del produttore proprio dello switch, si attivavano immediatamente.
• Alcuni produttori di ottiche spediscono di proposito moduli non codificati, aspettandosi che l’acquirente li codifichi per la piattaforma di destinazione.
• I moduli DWDM vengono sintonizzati sulla lunghezza d’onda tramite la stessa interfaccia di gestione usata per la codifica.

Come farlo in CodingBox

1. Leggere il modulo; viene salvato automaticamente nel code database e viene eseguito un backup prima di qualunque scrittura.
2. Impostare indirizzo della tabella, indirizzo della password e valore della password in Memoria protetta in scrittura e password — le password note dal database vengono applicate automaticamente.
3. Modificare il produttore, il codice prodotto e gli altri campi di identità nell’EEPROM editor. CC_BASE e CC_EXT vengono ricalcolati automaticamente.
4. Scrivere le pagine selezionate, quindi rileggere per verificare. Controllare il modulo sullo switch con i comandi in Verifica delle ottiche.

Codificare i moduli solo per l’interoperabilità a cui si ha diritto, seguendo le politiche della propria organizzazione e dei produttori.

Le regole dietro a una ricodifica pulita — formati dei campi, quali bit impostare e quali somme correggere — sono in Campi del produttore, Codici di conformità e Checksum.

Cosa fa la fabbrica nello stesso passaggio, e quali aree contengono la calibrazione che una scrittura incauta può distruggere: Produzione e collaudo, Controller e firmware.

Quale byte contiene cosa prima di modificare: Mappa A0h di SFF-8472, Mappa della pagina superiore di SFF-8636, Mappa delle pagine superiori CMIS, Mappa XFP.

Codici prodotto di destinazione e la loro grammatica per produttore: Codici prodotto OEM; cosa controlla ciascuna classe di piattaforma dopo la scrittura: Come ogni NOS convalida un modulo.