프로그래머가 정상적으로 덤프되는 SFP+에 WRITE FAIL을 반환함: EEPROM이 죽은 건가, 쓰기를 막는 뭔가가 있는 건가?
매달 고객 호스트용으로 모듈 소량 배치를 리코딩합니다. 별것 없습니다 - 원본 페이지를 읽고, 호스트가 원하는 벤더 문자열을 쓰고, 스위치에 꽂고 넘어가는 거죠. 지금 배치 중 모듈 하나가 읽기는 완벽하게 되는데 쓰기는 전부 거부하고 있어서, 버리기 전에 더 시도해볼 게 있는지 알고 싶습니다.
장비 구성:
- SFP 브레이크아웃 보드가 달린 CH341급 USB 프로그래머
- 진단 기능이 있는 SFP+ 모듈, 콜드 상태에서도 파워 사이클 후에도 읽기 정상
- 같은 장비로 한 시간 전에 같은 트레이의 다른 모듈 세 개는 정상적으로 썼음
쓰기를 누르는 순간 도구가 출력하는 내용:
WRITE FAIL그 직후에 다시 읽어보면 원본 페이지가 바이트 단위로 그대로 나옵니다. 그러니 일부조차도 아무것도 반영되지 않은 겁니다.
시도한 것:
- 모듈을 다시 꽂고 브레이크아웃 보드도 예비품으로 교체
- 전체 페이지 대신 신경 안 쓰는 영역의 바이트 하나만 써봄 - 결과 동일
- 파워 사이클을 여러 번 거쳐도 읽기가 안정적인 걸 확인 - 배선 문제는 아님
읽기는 깨끗한데 쓰기는 절대 안 받는 모듈이면 그냥 수명이 다한 건가요, 아니면 모듈 자체에 의도적으로 쓰기를 거부할 수 있는 뭔가가 있는 건가요?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
읽기는 깨끗, 쓰기는 거부, 그 후에도 원본 페이지는 그대로. 이건 수명이 다한 EEPROM이 보통 보이는 행동이 아닙니다. 죽은 셀이라면 읽기 결과가 이상하게 나오거나 페이지가 절반만 써지지, 아무것도 안 건드려진 채로 깔끔하게 거부하지는 않습니다.
게다가 벤더 영역 바깥의 바이트 하나조차 튕겨났으니, 이건 칩의 특정 영역이 나쁜 게 아니라 그 부품이 쓰기 자체를 통째로 거절하고 있는 겁니다. 뭔가 결론 내리기 전에 짚어볼 게 두 가지 있습니다. 첫째, 실제로 이 모듈을 만든 곳이 어딘지 - 트레이에 뭐라고 라벨이 붙어 있었든, 이미 덤프하신 페이지 안의 벤더 문자열을 기준으로 보세요. 둘째, 전원이 들어온 순간, 버스의 다른 뭔가가 모듈과 대화하기 전에 바로 쓰기를 쏘면 반영이 되는지요. 유력한 설명은 이 답들에 따라 달라지고, 그중 하나는 아예 고장이 아닙니다.
그건 손상이라기보다는 비밀번호 보호처럼 보입니다. SFF-8472는 진단 기능이 있는 모듈이 쓰기를 받아들이기 전에 4바이트 비밀번호를 요구할 수 있게 허용합니다. 아무것도 안 보내거나 틀린 걸 보내면 모듈은 쓰기에 에러로 답하면서도 읽기는 계속 활짝 열려 있는데, 이게 정확히 페이지가 그대로 돌아오는 여러분의 WRITE FAIL입니다. 이건 죽어가는 부품의 증상이 아니라 그 부품의 기능입니다.
이게 벤치에서 의미하는 바는, 이걸 아는 프로그래머라면 제조사나 호스트 비밀번호를 입력할 수 있게 해주고, 잘 만든 것들은 모르는 비밀번호를 브루트포스로 뚫고 쓰기 후 체크섬까지 재계산해준다는 겁니다. CH341급 장비는 체크섬 자동화가 전혀 없어서, 비밀번호를 뚫고 나서도 체크섬은 직접 고쳐야 합니다. 안 그러면 여러분 눈에는 페이지가 맞아 보이는데 호스트는 여전히 거부하는 모듈이 나옵니다.
늘 하는 얘기지만, 저도 몇몇 모듈에서 이걸 겪었고 비밀번호 쪽으로 풀렸습니다. 뭐든 포기하시기 전에 갖고 계신 부품에 직접 시도해보세요.
거기 하나 보태자면, 일부 벤더는 비밀번호가 사실 별로 비밀이 아닙니다. Ubiquiti 트랜시버 비밀번호를 모아둔 목록이 나돌아다니는데 0x00001011 같은 값이나 SFPX, QSFP 같은 그냥 문자열이 들어 있어서, 모듈이 그 생태계에서 나온 거라면 브루트포스 근처에도 가기 전에 알려진 값들부터 시도하는 데 5분이면 됩니다.
범용 프로그래머와 씨름하는 대신 전체 흐름을 이미 알고 있는 도구를 원하신다면, UACC-SFP-WIZARD가 사람들이 많이 찾는 저렴한 선택지입니다. 랩 계측기는 아니지만 모듈 쪽은 제대로 처리해줍니다.
관련해서, Huawei S5731과 S6730 호스트, 그리고 오래된 HP 6120XG용 모듈을 리코딩하면서 겪은 겁니다. 케이지나 브레이크아웃이 모듈보다 더 약한 고리일 때는, 모듈의 4번과 7번 핀 - I2C의 SDA와 SCL 라인 - 에 직접 납땜해서 케이지를 아예 빼고 EEPROM을 구동하는 방법을 씁니다. 지저분하고 잃어도 되는 부품에서만 해야 하지만, 접촉 문제라는 카테고리 전체를 없애줍니다.
여기서 이 방법을 거친 부품들: Finisar FTLX8571D3BCV와 FTLX8574D3BCV, Intel SFP+ LR/SR 모듈, SNR-SFP+W73-3과 SNR-SFP+W37-3, 그리고 HP J9150A까지요.
지금 상황은 파워 사이클을 거쳐도 읽기가 이미 완전히 안정적이니 접촉은 문제가 아닙니다. 비밀번호 쪽부터 쫓아가보세요.
비밀번호가 유력한 답이긴 한데, "비밀번호 입력하면 끝"에서 멈추지는 마세요. 그 직후에 두 가지가 사람들 발목을 잡거든요.
첫째, 일부 부품은 모듈 전원이 꺼졌다 켜지면 입력을 다시 요구하니, 여러 페이지를 순서대로 쓰는 스크립트는 한 번 풀면 세션 내내 유지된다고 가정하지 말고 재입력할 준비를 해야 합니다.
둘째, 체크섬입니다. CH341급 프로그래머로는 이걸 손으로 재계산해야 합니다. 이걸 안 하고 놔두면 모듈은 여전히 잘 읽히고 도구도 성공했다고 보고하지만, 호스트는 조용히 그 모듈을 계속 거부하고, 그러면 다들 다시 하드웨어 탓을 하게 됩니다. 그 모듈이 고객 스위치에 들어가기 전에 페이지를 다시 읽어서 체크섬을 확인하세요.