CodingBox Q&A Ask question

Il programmatore legge l'SFP+ FTLX8571D3BCV-IT, ma in scrittura risponde No Acknowledge

Asked Active Viewed 110 AI translation from Русский
6

Gestisco un piccolo fondo di scambio moduli: i nodi sono sparsi per la città, e sotto quasi ogni switch altrui bisogna ricodificare l'SFP. Con i moduli gigabit lo schema è collaudato da tempo, ma sul dieci giga mi sono bloccato.

Cosa c'è sul tavolo:

  • programmatore con cage per SFP/SFP+, alimentazione 3,3 V
  • Finisar FTLX8571D3BCV-IT e FTLX1471D3BCV-IT, si leggono entrambi
  • Cisco GLC-LH-SM da vecchie scorte
  • HP J4858B e J4859C

La lettura viene fuori stabile e ripetibile, entrambi i banchi per intero. La scrittura non va in nessuna variante:

read  A0 0x00-0xFF ... OK
read  A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No Acknowledge

Cosa ho già controllato:

  • le stesse operazioni sui normali SFP gigabit con lo stesso programmatore passano, quindi il circuito e l'alimentazione sono vivi;
  • ho preso un secondo esemplare di FTLX8571D3BCV-IT, comportamento identico byte per byte;
  • sul GLC-LH-SM il No Acknowledge arriva subito, ancora prima di provare a toccare i campi vendor.

Quindi non è questione dell'esemplare specifico. È una protezione hardware in scrittura nel modulo stesso, oppure nell'SFP+ la memoria non è più una EEPROM nuda e con la normale scrittura via I2C lì semplicemente non si entra? E a parte mi interessano gli HP J4858B/J4859C: qualcuno li scrive con un programmatore normale, o è un vicolo cieco già in partenza?

Comments 6

Accepted answer

Qui si sono mescolati due meccanismi diversi, e si curano in modo diverso.

Il primo: normale EEPROM con protezione hardware in scrittura. Il chip di memoria ha un pin write protect, e finché è tirato su, la lettura passa ma la scrittura cade. Il metodo che consigliava chi ci ha lavorato a fondo è mettere a massa quel pin durante il flashing. Su parte dei moduli gigabit basta questo.

Il secondo: quello in cui ti sei imbattuto sul dieci giga. Negli SFP+ i dati spesso non stanno in una EEPROM separata ma dietro il microcontrollore del modulo: è lui stesso a restituire A0 e A2 in lettura e accetta la scrittura solo con la propria sequenza di comandi. Un programmatore standard quella sequenza non la conosce e ottiene No Acknowledge su qualsiasi tentativo, indipendentemente dal campo che stai puntando. Lì non c'è niente da mettere a massa.

Quello che aiuta davvero ad aggirare la cage: si salda con fili direttamente ai piedini 4 e 7 del modulo, cioè sulla linea I2C, bypassando il connettore del programmatore. Da quanto si racconta, dopo questo si scrive parte dei moduli che nella cage tacevano. Metodo grezzo, servono mani ferme, e dopo il modulo vive a tuo rischio.

HP è un discorso a parte. I programmatori standard non li prendono, lì serve una gestione propria, e su J4858B/J4859C con circuiteria normale non mi aspetterei successo. Se l'obiettivo è semplicemente ottenere un modulo funzionante in uno switch altrui, costa meno non torturare l'HP, ma prendere un modulo con memoria onesta e caricarci dentro l'immagine del vendor per intero: dei 256 byte del dump sono significativi i primi 128, il resto è riserva del produttore.

Nessun vendor, ovviamente, supporta una ricodifica del genere: con un modulo riflashato non c'è nulla con cui andare in supporto.

3 Russialambdaops44RU Show original (Русский) AI translation

Chiarisci un paio di cose, altrimenti viene fuori un indovinello. Il No Acknowledge arriva già sull'indirizzo del dispositivo stesso, o già dopo il primo byte di dati? Di solito dal log del programmatore si vede. E che programmatore hai, un dispositivo pronto o un fatto in casa con circuiteria propria? Da questo dipende cosa aspettarsi in generale dai 3,3 V sulla cage.

Interessa anche il comportamento all'alimentazione: il rifiuto è uguale subito dopo l'inserimento del modulo e dopo che è stato un paio di minuti sotto tensione? E tutti e quattro i tipi si comportano allo stesso modo o Finisar e HP si differenziano: HP di solito ha cause di rifiuto proprie, meglio separarle subito dal resto.

3 RussiadwdmmonkRU Show original (Русский) AI translation

Riporto sul risultato. Mi sono saldato sulla linea I2C direttamente ai piedini 4 e 7, bypassando la cage. I Finisar sono andati: l'FTLX8571D3BCV-IT si è scritto ed è stato confermato dalla rilettura, anche l'FTLX1471D3BCV-IT. Il GLC-LH-SM ha smesso di dare No Acknowledge e si scrive normalmente.

Gli HP non si sono ancora arresi. Il J4858B accetta formalmente la scrittura, ma dopo la modifica il modulo viene respinto dallo switch, il J4859C si comporta allo stesso modo. Quindi per me la domanda è chiusa a metà: Finisar e Cisco ora li scrivo, l'HP l'ho messo da parte fino a tempi migliori.

1 KazakhstanlinkguruKZ Show original (Русский) AI translation

Con HP la trappola è più profonda di una semplice protezione in scrittura, quindi il tuo risultato è quello atteso. Sul J4858B quando modifichi i byte 68-83, cioè il numero di serie, cambia il checksum nei byte 124-127, e dopo questo il modulo viene respinto. Non sono i CC_BASE e CC_EXT dell'MSA, calcolarli non è un problema, ma un checksum vendor separato negli ultimi quattro byte di A0. L'algoritmo non è mai stato scomposto pubblicamente, per quanto ci abbiano armeggiato.

Il J9150A è dalla stessa storia. E nei moduli HP e Aruba più recenti sono passati del tutto da un checksum statico a uno schema richiesta-risposta, HPIDv2, e lì il programmatore è inutile in linea di principio. Quindi "si scrive ma non viene accettato" è esattamente quello che doveva venire fuori.

1 Kazakhstanlambdaowl20KZ Show original (Русский) AI translation

Visto che hai un parco e non un solo modulo, dico la mia sullo strumento. Per la ricodifica per Huawei S5731 e S6730 e per HP 6120XG mi sono adattato lo UACC-SFP-WIZARD di Ubiquiti: come programmatore economico è abbastanza valido. Solo che sui moduli Ubiquiti stessi girano liste di password, voci del tipo 0x00001011, SFPX, QSFP, e senza quelle parte dei moduli non si apre in scrittura. Tra le immagini che uso ho FTLX8571D3BCV e FTLX8574D3BCV, più raramente SNR-SFP+W73-3 e W37-3.

3 Russiaportrunner91RU Show original (Русский) AI translation

Correggo la generalizzazione sopra, così nessuno afferra il saldatore prima del tempo: non in ogni SFP+ la memoria è nascosta dietro un microcontrollore. A me l'FTLX8574D3BCV e un paio di SNR-SFP+W73-3 si sono scritti con un programmatore normale in cage, senza nessuna saldatura. Quindi prima vale la pena verificare l'esemplare specifico, e solo dopo andare a cercare la via traversa.

La messa a massa del pin write protect, tra l'altro, non è nemmeno una ricetta universale: su un modulo con microcontrollore non dà nulla, lì il rifiuto viene non dalla memoria ma dal firmware del controllore. Questa operazione ha senso solo dove c'è una EEPROM separata onesta, e va fatta a modulo scollegato dall'alimentazione, altrimenti si rischia facilmente di ottenere un mattone al posto di un modulo.

2 UkrainecoremonkUA Show original (Русский) AI translation
Log in to comment. Log in