프로그래머가 SFP+ FTLX8571D3BCV-IT를 읽기는 하는데 쓰기에는 No Acknowledge로 응답함
작은 모듈 교환 재고를 관리하고 있습니다. 노드들이 도시 곳곳에 흩어져 있어서, 남의 스위치마다 거의 매번 SFP를 재코딩해야 합니다. 기가비트 모듈로는 방법이 오래전에 자리 잡았는데, 10기가짜리에서 막혔습니다.
책상 위에 있는 것:
- SFP/SFP+ 케이지가 있는 프로그래머, 전원 3.3V
- Finisar FTLX8571D3BCV-IT와 FTLX1471D3BCV-IT, 둘 다 읽힘
- 오래된 재고에서 나온 Cisco GLC-LH-SM
- HP J4858B와 J4859C
읽기는 안정적으로, 반복해서 되고, 두 뱅크 다 전체가 됩니다. 쓰기는 어느 것도 안 됩니다.
read A0 0x00-0xFF ... OK
read A2 0x00-0xFF ... OK
write A0 vendor name ... No Acknowledge
write A0 serial (bytes 68-83) ... No Acknowledge이미 확인한 것:
- 같은 프로그래머로 일반 기가비트 SFP에 똑같은 작업을 하면 됨, 그러니까 배선이랑 전원은 살아있음
- FTLX8571D3BCV-IT 두 번째 개체를 가져옴, 동작이 바이트 단위까지 똑같음
- GLC-LH-SM에서는 벤더 필드를 건드리기도 전에 No Acknowledge가 바로 날아옴
그러니까 특정 개체의 문제는 아닌 것 같습니다. 이게 모듈 자체의 하드웨어 쓰기 보호인가요, 아니면 SFP+에서는 메모리가 이미 순수 EEPROM이 아니라서 일반적인 I2C 쓰기로는 아예 접근이 안 되는 건가요? 그리고 따로 궁금한 게 HP J4858B/J4859C인데, 일반 프로그래머로 쓰는 사람이 있나요, 아니면 이건 처음부터 막다른 길인가요?
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
여기엔 서로 다른 메커니즘 두 개가 섞여 있고, 고치는 방법도 다릅니다.
첫 번째는 평범한 EEPROM에 하드웨어 쓰기 보호가 걸린 경우입니다. 메모리 칩에는 write protect 핀이 있고, 그게 풀업돼 있는 동안은 읽기는 되고 쓰기는 떨어져 나갑니다. 이 작업을 깊이 파본 사람들이 권하던 방법은 플래싱하는 동안 그 핀을 접지시키는 거였습니다. 일부 기가비트 모듈은 이걸로 충분합니다.
두 번째가 10기가짜리에서 부딪히신 겁니다. SFP+에서는 데이터가 종종 별도 EEPROM이 아니라 모듈 마이크로컨트롤러 뒤에 있습니다. 그 컨트롤러가 A0랑 A2를 읽기용으로는 직접 내주고, 쓰기는 자기만의 명령 시퀀스로만 받아들입니다. 표준 프로그래머는 그 시퀀스를 모르니까 어느 필드를 노리든 상관없이 모든 시도에서 No Acknowledge를 받는 겁니다. 거기엔 접지시킬 게 없어요.
케이지를 실제로 우회하는 데 도움이 되는 방법은 프로그래머 커넥터를 건너뛰고 모듈의 4번, 7번 핀, 즉 I2C 라인에 전선을 직접 납땜하는 겁니다. 후기를 보면 이렇게 한 뒤로 케이지에서는 조용하던 모듈 일부가 써집니다. 거친 방법이고 손이 정확해야 하고, 그 뒤로 모듈이 사는지는 본인 책임입니다.
HP는 완전히 별개입니다. 표준 프로그래머는 안 먹히고, 자체 처리가 필요하고, J4858B/J4859C를 일반 배선으로는 성공을 기대 안 하겠습니다. 목표가 그냥 남의 스위치에서 동작하는 모듈을 얻는 거라면, HP랑 씨름하는 것보다 정직한 메모리를 가진 모듈을 구해서 벤더 이미지를 통째로 밀어넣는 게 더 쌉니다. 256바이트 덤프 중 의미 있는 건 앞의 128바이트고, 나머지는 제조사 예약 영역입니다.
당연히 어떤 벤더도 이런 재코딩을 지원하지 않습니다. 재프로그래밍된 모듈을 들고 지원팀에 가봐야 할 얘기가 없습니다.
몇 가지 확인해주세요, 안 그러면 추측이 됩니다. No Acknowledge가 장치 주소 자체에서 오나요, 아니면 첫 데이터 바이트 이후에 오나요? 프로그래머 로그에서 보통 이게 보입니다. 그리고 쓰시는 프로그래머가 어떤 건가요, 완제품인가요 아니면 자체 배선의 자작품인가요? 이에 따라 케이지의 3.3V에서 뭘 기대할 수 있는지가 달라집니다.
전원 인가 시 동작도 궁금합니다. 모듈을 설치하자마자 실패하는 것과 전원을 몇 분 받은 뒤 실패하는 게 똑같나요? 그리고 네 종류 다 똑같이 동작하나요, 아니면 Finisar랑 HP가 다른가요? HP는 보통 자기만의 실패 원인이 있어서 나머지랑 바로 분리하는 게 낫습니다.
결과 보고합니다. 케이지를 건너뛰고 I2C 라인의 4번, 7번 핀에 직접 납땜했습니다. Finisar는 됐습니다. FTLX8571D3BCV-IT는 써졌고 반대로 읽어서 확인도 됐고, FTLX1471D3BCV-IT도 마찬가지입니다. GLC-LH-SM도 더 이상 No Acknowledge를 안 내고 정상적으로 써집니다.
HP는 끝내 항복 안 했습니다. J4858B는 쓰기는 형식적으로 받아들이는데, 수정한 뒤에 스위치가 모듈을 거부합니다. J4859C도 똑같이 동작하고요. 그러니 저한테는 문제가 절반만 해결됐습니다. Finisar랑 Cisco는 이제 쓰고, HP는 다음 기회까지 미뤄뒀습니다.
HP는 함정이 쓰기 보호보다 더 깊어서, 나온 결과가 예상된 그대로입니다. J4858B에서 바이트 68-83, 그러니까 시리얼 넘버를 수정하면 바이트 124-127의 체크섬이 바뀌고, 그 뒤로 모듈이 거부됩니다. 이건 계산하는 데 문제없는 MSA의 CC_BASE랑 CC_EXT가 아니라, A0의 마지막 네 바이트에 있는 별도의 벤더 체크섬입니다. 다들 아무리 파봐도 알고리즘은 끝내 공개적으로 안 풀렸습니다.
같은 사연의 J9150A도 마찬가지고요. 더 신형인 HP랑 Aruba 모듈에서는 아예 정적 체크섬에서 요청-응답 방식인 HPIDv2로 넘어가서, 거기서는 프로그래머가 원리적으로 무용지물입니다. 그러니 "써지긴 하는데 안 받아들여진다"는 나올 수밖에 없었던 결과, 딱 그겁니다.
모듈 하나가 아니라 재고를 굴리고 계시니, 도구 얘기를 하겠습니다. 저는 Huawei S5731이랑 S6730용, 그리고 HP 6120XG용 재코딩에 Ubiquiti의 UACC-SFP-WIZARD를 갖다 썼습니다. 저렴한 프로그래머치고는 꽤 쓸 만합니다. 다만 Ubiquiti 모듈 자체에는 0x00001011, SFPX, QSFP 같은 형태의 비밀번호 목록이 돌아다니고, 그게 없으면 일부 모듈은 쓰기가 안 열립니다. 이미지로는 FTLX8571D3BCV랑 FTLX8574D3BCV를 자주 쓰고, 가끔 SNR-SFP+W73-3이랑 W37-3도 씁니다.
위의 일반화를 정정하겠습니다, 아무도 시기상조로 인두를 잡지 않도록요. 모든 SFP+에서 메모리가 마이크로컨트롤러 뒤에 숨어있는 건 아닙니다. 제 FTLX8574D3BCV랑 SNR-SFP+W73-3 두 개는 납땜 없이 케이지에 꽂은 일반 프로그래머로 써졌습니다. 그러니 먼저 해당 개체를 확인하고 나서 우회로 들어가는 게 맞습니다.
그리고 write protect 핀 접지도 만능 레시피는 아닙니다. 마이크로컨트롤러가 있는 모듈에서는 아무 소용이 없어요, 거기서는 실패가 메모리가 아니라 컨트롤러 펌웨어에서 오는 거니까요. 이 작업은 정직한 별도 EEPROM이 있는 곳에서만 의미가 있고, 전원을 끈 모듈에서 해야 합니다. 안 그러면 모듈 대신 벽돌을 얻기 십상입니다.