Programator czyta SFP+ FTLX8571D3BCV-IT, ale na zapis odpowiada No Acknowledge
Prowadzę niewielki fundusz wymienny modułów: węzły rozrzucone po mieście, i niemal pod każdy cudzy switch trzeba przekodować SFP. Z modułami gigabitowymi schemat od dawna dopracowany, a na dziesiątce utknąłem.
Co na stole:
- programator z klatką pod SFP/SFP+, zasilanie 3,3 V
- Finisar FTLX8571D3BCV-IT i FTLX1471D3BCV-IT, oba się czytają
- Cisco GLC-LH-SM ze starych zapasów
- HP J4858B i J4859C
Odczyt zdejmuje się stabilnie i powtarzalnie, oba banki w całości. Zapis nie idzie w żadnym wariancie:
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No AcknowledgeCo już sprawdziłem:
- te same operacje na zwykłych gigabitowych SFP tym samym programatorem przechodzą, więc obwiązka i zasilanie żyją;
- wziąłem drugi egzemplarz FTLX8571D3BCV-IT, zachowanie bajt w bajt takie samo;
- na GLC-LH-SM No Acknowledge przylatuje od razu, jeszcze przed próbą dotknięcia pól vendorskich.
Wychodzi na to, że nie chodzi o konkretny egzemplarz. Czy to sprzętowa ochrona zapisu w samym module, czy w SFP+ pamięć to już nie goła EEPROM i zwykłym zapisem po I2C tam po prostu nie da się trafić? I osobno interesuje mnie HP J4858B/J4859C: pisze je ktoś zwykłym programatorem, czy to z góry ślepy zaułek?
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 6
Tu wymieszały się dwa różne mechanizmy, i leczy się je inaczej.
Pierwszy - zwykła EEPROM ze sprzętową ochroną zapisu. Kostka pamięci ma wyprowadzenie write protect, i póki jest podciągnięte, odczyt idzie, a zapis odpada. Sposób, jaki doradzali ludzie, którzy zajmowali się tym na poważnie, to posadzić to wyprowadzenie na masę na czas przeszywania. Na części modułów gigabitowych to wystarcza.
Drugi - to, z czym zderzyłeś się na dziesiątce. W SFP+ dane często leżą nie w osobnej EEPROM, a za mikrokontrolerem modułu: on sam oddaje A0 i A2 do odczytu, a zapis przyjmuje tylko przez własną sekwencję komend. Standardowy programator takiej sekwencji nie zna i dostaje No Acknowledge na każdą próbę, niezależnie od tego, w które pole celujesz. Nie ma tam czego uziemiać.
Co realnie pomaga obejść klatkę: lutuje się przewody wprost do nóżek 4 i 7 modułu, czyli na linii I2C, z pominięciem złącza programatora. Z relacji wynika, że potem daje się zapisać część modułów, które w klatce milczały. Sposób prymitywny, ręce muszą być pewne, a moduł po tym żyje już na twoją odpowiedzialność.
HP to osobna piosenka. Standardowe programatory ich nie biorą, potrzebna jest własna obróbka, i na J4858B/J4859C przy zwykłej obwiązce nie spodziewałbym się sukcesu. Jeśli zadanie to po prostu dostać działający moduł w cudzym switchu, taniej wychodzi nie męczyć HP, tylko wziąć moduł z uczciwą pamięcią i zalać w niego cały obraz vendorski: z 256 bajtów dumpa znaczące jest pierwsze 128, reszta to rezerwa producenta.
Żaden vendor takiego przekodowania oczywiście nie wspiera: z przeszytym modułem do supportu nie ma z czym iść.
Doprecyzuj kilka rzeczy, inaczej wyjdzie wróżenie. No Acknowledge przylatuje już na samym adresie urządzenia, czy dopiero po pierwszym bajcie danych? Z logu programatora zwykle to widać. I co masz za programator - gotowe urządzenie czy samoróbka na własnej obwiązce? Od tego zależy, czego w ogóle oczekiwać od 3,3 V na klatce.
Ciekawe jest jeszcze zachowanie przy podaniu zasilania: odmowa jest taka sama zaraz po instalacji modułu i po tym, jak postał pod zasilaniem parę minut? I wszystkie cztery typy zachowują się tak samo, czy Finisar i HP się różnią: HP zwykle ma swoje własne przyczyny odmowy, lepiej je od razu odseparować od reszty.
Zdaję relację z wyniku. Spaiłem się na linii I2C wprost do nóżek 4 i 7, z pominięciem klatki. Finisar poszły: FTLX8571D3BCV-IT zapisał się i potwierdził odczytem zwrotnym, FTLX1471D3BCV-IT też. GLC-LH-SM przestał wypluwać No Acknowledge i pisze się normalnie.
HP tak i nie ustąpiło. J4858B formalnie przyjmuje zapis, ale po edycji moduł jest odrzucany przez switch, J4859C zachowuje się tak samo. Więc dla mnie sprawa zamknięta w połowie: Finisar i Cisco teraz zapisuję, HP odłożyłem na bok do lepszych czasów.
Z HP pułapka jest głębsza niż ochrona zapisu, więc twój wynik jest oczekiwany. Na J4858B przy edycji bajtów 68-83, czyli numeru seryjnego, zmienia się suma kontrolna w bajtach 124-127, i moduł po tym jest odrzucany. To nie MSA-owe CC_BASE i CC_EXT, ich policzenie to nie problem, tylko osobna suma vendorska w ostatnich czterech bajtach A0. Algorytmu publicznie nigdy nie rozgryziono, ile by w nim nie dłubano.
J9150A z tej samej historii. A w nowszych modułach HP i Aruba w ogóle odeszły od statycznej sumy na rzecz schematu zapytanie-odpowiedź, HPIDv2, i tam programator jest bezużyteczny w zasadzie z definicji. Więc „zapisuje się, ale nie jest przyjmowany" to dokładnie to, co miało wyjść.
Skoro masz park, a nie jeden moduł, powiem o narzędziu. Do przekodowania dla Huawei S5731 i S6730 oraz dla HP 6120XG przystosowałem UACC-SFP-WIZARD od Ubiquiti - jako tani programator jest całkiem żywy. Tylko po samych modułach Ubiquiti krążą listy haseł, wpisy typu 0x00001011, SFPX, QSFP, i bez nich część modułów nie otwiera się na zapis. Z obrazów mam w użyciu FTLX8571D3BCV i FTLX8574D3BCV, rzadziej SNR-SFP+W73-3 i W37-3.
Poprawię uogólnienie powyżej, żeby nikt przedwcześnie nie chwytał za lutownicę: nie w każdym SFP+ pamięć jest schowana za mikrokontrolerem. U mnie FTLX8574D3BCV i para SNR-SFP+W73-3 pisały się zwykłym programatorem w klatce, bez żadnego lutowania. Więc najpierw warto sprawdzić konkretny egzemplarz, a dopiero potem leźć w obejście.
Uziemienie wyprowadzenia write protect, nawiasem mówiąc, też nie jest uniwersalnym przepisem: w module z mikrokontrolerem nic to nie daje, odmowa idzie tam nie od pamięci, a od firmware'u kontrolera. Ta operacja ma sens tylko tam, gdzie stoi uczciwa osobna EEPROM, i robić ją trzeba na module odłączonym od zasilania, inaczej łatwo o cegłę zamiast modułu.