IC-prog restituisce 256 byte di dump SFP, ma la seconda metà è una copia della prima, la pagina A2 non si legge (HP 2530-24G)
Gestisco la rete di un piccolo operatore, riflasho regolarmente moduli economici per farli passare da HP. Il compito è il solito: caricare nei WDM cinesi 1.25G l'immagine di un modulo originale, così lo switch li accetta senza protestare. Donatore: J4859C, ferro di destinazione: HP 2530-24G J9776A.
Sul tavolo ho:
- switch HP 2530-24G J9776A
- moduli OptiCin e Fiberstore, 1.25G WDM
- programmatore mini-USB NAG
- IC-prog su Windows, leggo e scrivo tramite quello
Il dump viene fuori a 256 byte, ma la seconda metà coincide con la prima byte per byte:
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge receivedCosa ho già provato:
- rimesso il modulo, pulito i contatti nel socket, cambiato la linguetta
- passato tre moduli di lotti diversi, quadro identico
- cambiato porta USB, cavo e macchina, niente è cambiato
Mi serve la seconda pagina, dove ci sono DDM e i byte di servizio, e semplicemente non la vedo. È un limite di IC-prog, una scheda del programmatore storta, o sono i moduli stessi a comportarsi così?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 7
Qui ci sono due difetti indipendenti, e nessuno dei due è nei moduli.
Il primo è IC-prog stesso. Ha un modello di indirizzamento lineare, non sa commutare le pagine e non arriva ad A2 in linea di principio. Quello che vedi nella seconda metà del dump è la stessa A0, letta una seconda volta. Non mostrerà un errore, perché dal suo punto di vista è tutto onesto.
Il secondo è la scheda. Su questo programmatore mini-USB VccR (pin 15) è piazzato su +5 V, mentre secondo SFF-8431 dovrebbe restare libero, più alimentazione e massa sono cablate in modo che parte dei moduli non entri in modalità normale. Da qui il
No Acknowledge received: non su tutti in fila, ma su quelli a cui questo cablaggio non piace.Cosa funziona normalmente:
i2cdump -y 3 0x50ei2cdump -y 3 0x51, c'è uno script Python open source che legge e scrive entrambe le pagine.Criterio semplice: appena 0x51 inizia a rispondere, da lì in poi è normale lavoro con la memoria del modulo, non una lotta con lo strumento.
Separa software e hardware, altrimenti indovinerai fino a sera. Prendi un Linux qualsiasi e guarda se il modulo risponde affatto al secondo indirizzo:
Metti il numero del tuo bus. Se 0x50 si legge e 0x51 tace, la domanda non è più con cosa guardi il dump, ma se arriva al modulo un'alimentazione normale. E di' cosa restituisce con lo stesso programmatore un J4859C donatore sicuramente vivo: se anche a lui la seconda pagina non si apre, i moduli economici non c'entrano, bisogna scavare nella combinazione software più scheda.
Il donatore l'ho testato per primo: un J4859C vivo, nello stesso socket e nello stesso IC-prog, dà esattamente lo stesso quadro: 256 byte, la seconda metà ripete la prima. Quindi non è questione di moduli economici. Ho controllato anche su Linux tramite l'adattatore:
L'utility nativa sullo stesso modulo restituisce
No Acknowledge received, mentre IC-prog mostra silenziosamente una copia della prima pagina e fa finta che vada tutto bene. I moduli di destinazione sono OptiCin, l'immagine la prendo proprio da questo J4859C.Aggiungo sulla scrittura in sé. Nel dump di 256 byte sono significativi i primi 128 byte, oltre c'è la zona del produttore, di solito si può anche non toccarla affatto. Per HP carichiamo immagini da J4858C e J4859C, per il WDM un paio di volte è bastata la normale immagine LX: lo switch accettava il modulo e non guardava la lunghezza d'onda.
Ma non si scrive affatto tutto. Su 3Com 3CSFP91 e 3CSFP92, così come sui brandizzati Allied Telesis, la scrittura non è partita per niente: si legge normalmente, ma la scrittura non si applica, WP bloccato. Quindi se dopo il cambio di programmatore A2 si legge ma la scrittura sparisce silenziosamente nel nulla, la causa non cercarla nel software.
Faccio una precisazione su «da lì in poi è il normale lavoro con la memoria». Normale non lo è ovunque. Una parte dei moduli non è affatto EEPROM: nel Medick SFP-10G-BX c'è un microcontrollore C8051F392, che emula A0/A2 ed è capace di chiedere una password o rispondere a una challenge. Da fuori sembra memoria normale esattamente fino al momento della scrittura. Il caso più pesante che mi sia capitato è l'EEPROM interattiva di HP/Aruba con le chiavi, lì senza un'utility già pronta non c'è niente da fare.
E se ti costruisci l'adattatore da solo, non confondere i piedini: TX_Disable è il pin 3, Mod_Abs è il pin 6, VeeR è il pin 9. Metà dei moduli «illeggibili» che ho visto tra conoscenti si è rivelata un socket assemblato storto, non una protezione del vendor.
Di quello che si usa adesso: SNR SFP Writer, la serie SFPTotal Plus e le schede fatte in casa su CH341, di solito è solo una scheda con socket per SFP, XFP, GBIC e QSFP, a volte in una custodia stampata in 3D. Software universale non esiste, ogni vendor ha la sua utility, le immagini si tirano fuori da database di firmware e dai forum di settore.
Due punti che costano più dell'hardware. Primo: molti moduli hanno una password a 4 byte, la maggior parte è pubblicata da tempo, ma se sbagli ti ritrovi un mattone da un modulo niente affatto economico. Secondo: prima di entrare nella memoria, assicurati che il modulo sia vivo. Temperatura, tensione, corrente di bias e TX/RX da A0h/A2h,
show interfaces diagnostics opticssu Junos odisplay interface transceiversu Huawei, poi pulizia di linguette, contatti e lenti, poi sostituzione con uno sicuramente funzionante. Parte dei moduli «morti» dopo questo rivive senza alcun firmware, e il carico lo verifichi solo dopo con iperf3.Riferisco l'esito. Ho montato una scheda su CH341, su Linux 0x51 ha risposto subito, la seconda pagina si legge per intero, nessun duplicato dei primi 128 byte. Ho caricato l'immagine J4859C nell'OptiCin, l'HP 2530-24G J9776A ha accettato il modulo in silenzio, il DDM mostra valori sensati, ha girato ventiquattr'ore sotto carico senza errori.
Ho disinstallato IC-prog, per non farmi più tentare. Il 3Com 3CSFP91 che giaceva lì vicino davvero non si scrive: si legge, ma la scrittura non si applica, quindi sul WP torna tutto. Grazie, domanda chiusa.