EEPROM 재코딩: 비밀번호와 원리

오랜 엔지니어링 논의에서 나온 핵심 통찰은 이렇습니다: 트랜시버 호환성은 펌웨어의 문제가 아니라 I²C로 읽는 EEPROM 안의 식별 문자열의 문제입니다. 스위치가 모듈을 거부하는 이유는 단순히 벤더 문자열을 인식하지 못하기 때문입니다. 이 한 가지 사실만으로 “전부 Cisco로 코딩하면 거의 어디서나 통한다”는 흔한 관행과 코딩 도구 시장 전체가 설명됩니다.

비밀번호가 있는 위치

모듈 메모리의 보호된 영역에 쓰려면 쓰기 전에 고정된 주소에 4바이트 비밀번호를 입력해야 합니다:

자주 언급되는 비밀번호

일부 벤더의 QSFP-DD 모듈은 자체 고정 기본값을 탑재한 채로 출고되며, 일부 마이크로프로세서 기반 모듈은 계속 바뀌는 가변 비밀번호를 사용합니다. 무차별 대입을 시도하는 사람에게는 함정이 됩니다.

무차별 대입이 답이 아닌 이유

전체 메모리 맵을 지키는 제조사 수준의 비밀번호는 무차별 대입으로 뚫는 데 100일 이상이 걸리며, 호스트 수준의 ASCII 비밀번호조차 최대 3일가량 걸립니다. 실용적인 방법은 정품 모듈에서 수집한 알려진 코드와 비밀번호의 데이터베이스를 이용하는 것입니다. 코딩 도구의 진짜 가치는 (단순한) I²C 하드웨어가 아니라 바로 여기에 있습니다.

자작 프로그래머의 함정

• 저가형 CH341A 프로그래머는 SFP 체크섬을 계산하지 않습니다. 유효한 CC_BASE/CC_EXT 없이 이미지를 쓰면 스위치가 거부하는 모듈이 됩니다. 체크섬을 자동으로 다시 계산하는 도구가 필요합니다.
• 일부 스위치는 주소 0x50에만 쓸 수 있어 0x51의 비밀번호에는 스위치 자체에서 접근할 수 없습니다. 제대로 된 프로그래머 보드가 필요합니다.
• EEPROM 쓰기 보호 핀: 일부 공장은 WP를 Vcc에 묶어 두어 현장에서 모듈에 쓰지 못하도록 잠급니다.

현장 사례

• 한 벤더로 코딩된 모듈이 다른 벤더의 스위치에서는 자동 협상이 되지 않다가, 그 스위치 고유의 벤더 문자열로 재코딩하자 즉시 올라온 사례입니다.
• 일부 옵틱스 벤더는 의도적으로 코딩되지 않은 모듈을 출고하며, 구매자가 대상 플랫폼에 맞게 코딩할 것을 전제로 합니다.
• DWDM 모듈의 파장 튜닝도 코딩에 쓰는 것과 같은 관리 인터페이스를 통해 이루어집니다.

CodingBox에서 하는 방법

1. 모듈을 읽습니다. 자동으로 code database에 저장되며, 쓰기 전에 항상 백업이 만들어집니다.
2. 쓰기 보호된 메모리와 비밀번호에서 테이블 주소, 비밀번호 주소, 비밀번호 값을 설정합니다. 데이터베이스에 있는 알려진 비밀번호는 자동으로 적용됩니다.
3. EEPROM editor에서 벤더, 부품 번호 등 식별 정보 필드를 편집합니다. CC_BASE와 CC_EXT는 자동으로 다시 계산됩니다.
4. 선택한 페이지를 씁니다. 그런 다음 다시 읽어 확인합니다. 옵틱스 검증의 명령어로 스위치에서 모듈을 점검합니다.

정당하게 권한이 있는 상호운용성 목적에 한해서만 모듈을 코딩하고, 소속 조직과 벤더의 정책을 따르십시오.

깔끔한 재코딩의 규칙, 즉 필드 형식과 설정해야 할 비트, 맞춰야 할 합계는 벤더 필드, 컴플라이언스 코드, 체크섬에 있습니다.

공장이 같은 단계에서 하는 작업, 그리고 부주의한 쓰기가 망가뜨릴 수 있는 교정 데이터가 어느 영역에 있는지: 제조와 테스트, 컨트롤러와 펌웨어.

편집하기 전에 각 바이트가 무엇을 담고 있는지: SFF-8472 A0h 맵, SFF-8636 상위 페이지 맵, CMIS 상위 페이지 맵, XFP 맵.

벤더별 대상 부품 번호와 그 표기 규칙: OEM 부품 번호; 쓰기 후 각 플랫폼 종류가 무엇을 검사하는지: 플랫폼별 NOS 검증 방식.