IC-prog가 SFP 덤프 256바이트를 주는데 뒷부분이 앞부분 복사본이고 A2 페이지는 안 읽힘 (HP 2530-24G)
작은 통신사 네트워크를 관리하고 있고, 저가 모듈을 HP용으로 정기적으로 재플래싱하고 있어요. 늘 하는 작업이에요: 중국산 1.25G WDM에 정품 모듈 이미지를 넣어서 스위치가 군말 없이 받아들이게 만드는 거요. 도너는 J4859C, 대상 장비는 HP 2530-24G J9776A예요.
책상 위에 있는 것:
- HP 2530-24G J9776A 스위치
- OptiCin이랑 Fiberstore 모듈, 1.25G WDM
- 미니 USB 프로그래머 NAG
- Windows용 IC-prog, 이걸로 읽고 씀
덤프는 256바이트로 뜨는데, 뒷반이 앞반이랑 바이트 단위로 완전히 똑같아요:
IC-prog, 0x00-0x7F: прочитано
IC-prog, 0x80-0xFF: тот же самый блок, байт в байт
на части модулей при чтении: No Acknowledge received이미 해본 것:
- 모듈을 다시 꽂아보고, 소켓 접점을 청소하고, 래치도 바꿔봄
- 서로 다른 배치의 모듈 세 개를 돌려봤는데 양상이 똑같음
- USB 포트, 케이블, 컴퓨터를 바꿔봤는데 아무것도 안 변함
DDM이랑 서비스 바이트가 있는 두 번째 페이지가 필요한데 그게 아예 안 보여요. 이게 IC-prog의 한계인가요, 프로그래머 보드가 이상한 건가요, 아니면 모듈들이 원래 이렇게 동작하는 건가요?
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
여기엔 독립적인 문제가 두 개 있고, 둘 다 모듈 쪽이 아니에요.
첫 번째는 IC-prog 자체예요. 얘는 주소 지정 모델이 선형이라 페이지 전환을 아예 못 하고, A2에는 원리적으로 닿을 수가 없어요. 덤프 뒷반에서 보고 계신 건 사실 같은 A0을 두 번째로 읽은 거예요. 에러도 안 띄우는데, 얘 입장에서는 다 정상이니까요.
두 번째는 보드예요. 이 미니 USB 프로그래머에서는 VccR(15번 핀)이 +5V에 물려 있는데, SFF-8431상으로는 이게 떠 있어야 하고, 거기다 전원이랑 그라운드 배선이 일부 모듈을 정상 모드로 못 들어가게 만들어요.
No Acknowledge received가 나오는 것도 그래서고요. 전부가 아니라 이 배선을 싫어하는 모듈에서만요.정상적으로 되는 것들:
i2cdump -y 3 0x50이랑i2cdump -y 3 0x51이에요. 두 페이지를 다 읽고 쓰는 오픈 소스 Python 스크립트도 있고요.기준은 간단해요. 0x51이 응답하기 시작하는 순간부터는 도구랑 씨름하는 게 아니라 그냥 평범한 모듈 메모리 작업이 되는 거예요.
소프트웨어랑 하드웨어를 분리해보세요, 안 그러면 저녁 내내 추측만 하게 돼요. 아무 Linux나 켜서 모듈이 두 번째 주소에 아예 응답하는지부터 보세요:
버스 번호는 본인 것으로 바꾸시고요. 0x50은 읽히는데 0x51이 조용하면, 이미 덤프를 뭘로 보고 있는지가 아니라 모듈에 정상 전원이 들어가고 있는지가 문제예요. 그리고 같은 프로그래머로 확실히 살아있는 도너 J4859C를 찍으면 뭐가 나오는지도 알려주세요. 거기서도 두 번째 페이지가 안 열리면 저가 모듈은 이 얘기랑 상관없고, 소프트웨어랑 보드 조합 쪽을 파야 해요.
도너부터 제일 먼저 돌려봤어요. 같은 소켓, 같은 IC-prog에서 살아있는 J4859C도 정확히 똑같은 그림이 나와요. 256바이트, 뒷반이 앞반을 반복하고요. 그러니까 저가 모듈 문제가 아니에요. 어댑터로 Linux에서도 확인해봤어요:
같은 모듈에서 정품 유틸리티는
No Acknowledge received를 내놓는데, IC-prog는 말없이 첫 페이지 복사본을 보여주면서 다 정상인 척해요. 대상 모듈은 OptiCin이고, 이미지는 바로 이 J4859C에서 뜨고 있어요.쓰기 자체에 대해서도 하나 보탤게요. 256바이트 덤프에서 의미 있는 건 앞 128바이트고, 그다음은 제조사 영역이라 보통 아예 안 건드려도 돼요. HP용으로는 J4858C랑 J4859C 이미지를 쓰는데, WDM은 몇 번은 그냥 일반 LX 이미지로도 충분했어요. 스위치가 모듈을 받아들이면서 파장은 안 봤거든요.
근데 다 써지는 건 절대 아니에요. 3Com 3CSFP91이랑 3CSFP92, 그리고 브랜드 Allied Telesis 모듈에서는 쓰기가 아예 안 먹혔어요. 읽기는 정상인데 쓰기는 적용이 안 돼요. WP가 잠겨 있는 거예요. 그러니까 프로그래머를 바꾼 뒤에 A2는 읽히는데 쓰기가 조용히 어디론가 사라진다면, 원인은 소프트웨어가 아닌 데서 찾으세요.
'그다음은 평범한 메모리 작업'이라는 말에 단서 하나만 달게요. 어디서나 평범한 건 아니에요. 일부 모듈은 아예 EEPROM이 아니에요. Medick SFP-10G-BX에는 C8051F392 마이크로컨트롤러가 들어 있어서 A0/A2를 에뮬레이션하고 패스워드를 요구하거나 챌린지에 응답할 수 있어요. 쓰기 시점 전까지는 겉보기엔 평범한 메모리처럼 보여요. 제가 겪어본 것 중 제일 골치 아팠던 건 키가 걸린 HP/Aruba의 인터랙티브 EEPROM이었는데, 거기는 전용 유틸리티 없이는 손댈 수가 없어요.
그리고 어댑터를 직접 조립하신다면 핀을 헷갈리지 마세요: TX_Disable은 3번 핀, Mod_Abs는 6번 핀, VeeR은 9번 핀이에요. 지인들 사이에서 '안 읽힌다'던 모듈의 절반은 벤더 보호가 아니라 소켓을 잘못 조립한 거였어요.
요즘 쓰는 것들 중에서는 SNR SFP Writer, SFPTotal Plus 시리즈, CH341 기반 자작 보드가 있어요. 보통 SFP, XFP, GBIC, QSFP용 소켓이 달린 보드일 뿐이고 가끔 3D 프린팅 케이스에 들어 있기도 해요. 범용 소프트웨어는 없고 벤더마다 각자 유틸리티가 있고, 이미지는 펌웨어 데이터베이스나 전문 포럼에서 구해요.
하드웨어보다 값진 포인트가 두 가지 있어요. 첫째, 많은 모듈에 4바이트 패스워드가 걸려 있는데 대부분 예전에 공개됐지만, 잘못 찍으면 저렴하지 않은 모듈이 벽돌이 돼요. 둘째, 메모리를 건드리기 전에 모듈이 애초에 살아있는지부터 확인하세요. A0h/A2h에서 온도, 전압, 바이어스 전류, TX/RX를 보고, Junos라면
show interfaces diagnostics optics, Huawei라면display interface transceiver로 확인한 다음, 래치랑 접점, 렌즈를 청소하고, 그다음 확실히 정상인 모듈로 교체해보세요. '죽은' 모듈 중 일부는 이렇게 하고 나면 펌웨어 손 안 대도 살아나고, 부하는 그다음에 iperf3로 확인하시면 돼요.결과 보고할게요. CH341 보드를 조립했고, Linux에서 0x51이 바로 응답했고, 두 번째 페이지가 통째로 읽혀요, 앞 128바이트 중복도 전혀 없고요. J4859C 이미지를 OptiCin에 넣었더니 HP 2530-24G J9776A가 아무 말 없이 모듈을 받아들였고, DDM 값도 말이 되고, 하루 종일 부하를 걸어도 에러 없이 잘 돌아갔어요.
IC-prog는 더 유혹당하지 않게 아예 지웠어요. 옆에 굴러다니던 3Com 3CSFP91은 정말로 안 써져요. 읽기는 되는데 쓰기가 적용이 안 되니까 WP 얘기가 딱 맞아떨어지네요. 감사합니다, 질문 닫을게요.