Turris Omnia가 언락된 MA5671A GPON 스틱을 거부: Turris OS 5.0.3에서 eth2가 절대 안 올라옴
집 랙의 ISP 단말기를 GPON 스틱으로 바로 라우터에 꽂아서 대체하려고 합니다. 그러면 광케이블이 박스 두 개가 아니라 한 개로 들어오니까요. 스틱은 인식되는데, 좋은 소식은 거기까지입니다.
- Turris OS 5.0.3 위의 Turris Omnia, 스톡 커널
- 펌웨어 언락된 Huawei MA5671A GPON 스틱, SGMII 1G로 설정
- 벽면 소켓에서 스틱까지 SC/APC 피그테일
- eth2가 SFP 포트임
모듈은 인식되는데 인터페이스가 절대 활성화되지 않습니다.
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66b그 뒤로 eth2는 계속 down이고, carrier도 없고, 카운터에도 아무것도 안 찍힙니다.
지금까지 해본 것:
- 스틱을 스톡 펌웨어로 되돌려 플래시, 대신 EEPROM read error가 뜸
- ethtool -s eth2 1000 autoneg off duplex full로 속도 강제, 그러면 인터페이스가 10 Mbit half duplex에 머무름
- 같은 스틱을 MikroTik 라우터로 옮김, 거기서는 포트 속도를 손으로 설정하면 올라옴
그러니까 모듈 자체는 살아있고 광 쪽도 멀쩡합니다. 스틱의 뭐가 커널의 마음에 안 드는 걸까요? 그리고 실제로 Omnia에서 거부당하지 않고 올라오는 GPON 스틱은 뭐가 있나요?
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 4
이건 호스트 쪽 문제지 죽은 모듈이 아닙니다. 이런 용도 변경된 GPON 스틱의 EEPROM은 메인라인 sfp 드라이버가 매핑하지 못하는 인코딩을 선언하고 있고, 그래서 phylink가 포트를 올리길 거부하는 거예요. 붙여넣으신 그 줄이 드라이버가 정확히 그렇게 말하는 겁니다. 직접 증명하신 것도 같은 방향을 가리킵니다. 동일한 스틱이 MikroTik에서는 포트 속도를 손으로 설정하는 순간 링크가 되니까, 옵틱이랑 PON 쪽은 멀쩡한 거죠.
저한테 실제로 도움이 된 건 모듈별 특이사항을 담을 만큼 새로운 커널이었고, Omnia에서는 커널 5.4가 들어간 HBD testing 브랜치였습니다. 다만 이건 부분적인 성공이고 어떤 스틱을 갖고 있느냐에 크게 좌우된다는 걸 미리 말씀드립니다. 그 커널에서:
그러니 나중이 아니라 지금 당장 Omnia를 돌리고 싶으시면 DFP-34G-2C2를 케이지에 넣는 걸 추천합니다. 결과가 스틱마다, 심지어 같은 스틱의 펌웨어 리비전마다도 분명히 다르게 나오니까 확정하기 전에 본인 박스에서 직접 테스트해보세요.
아무도 추측하기 전에 확인해야 할 게 두 가지 있습니다. 먼저, 그 5.0.3이 어느 브랜치에서 나온 거고 uname은 어떤 커널을 보고하나요? 이런 용도 변경된 GPON 스틱들이 필요로 하는 모듈별 SFP 특이사항 처리는 나중에 들어갔기 때문에, 배포된 stable 커널과 testing 커널은 똑같은 모듈을 두고도 완전히 다르게 동작합니다.
둘째, ONU 시리얼이 프로바이더 쪽에 등록돼 있나요? OLT에서 인증받지 못한 스틱은 그냥 죽은 것처럼 앉아 있을 거고, 서드파티 ONU 등록 자체를 거부하는 프로바이더도 많습니다.
그리고 꽂았을 때 포트가 inband/1000base-x로 바뀌기는 하나요, 아니면 로그가 그 encoding 메시지에서 딱 멈추나요?
Stable 브랜치, 5.0.3 스톡 커널이고 위에 커스텀한 건 없습니다. 프로바이더 쪽은 여기서 문제가 아니고, 같은 광케이블이고 스틱에는 등록된 시리얼이 들어있습니다.
로그는 encoding 줄에서 멈추고, 포트는 inband/1000base-x로 절대 안 바뀝니다. 뭐가 나오는지는 펌웨어에 달려 있어요. 언락된 걸로는:
거기에 모듈이 보고하는 transmit fault가 더해집니다. 스톡 펌웨어로는 그만큼도 못 갑니다.
그리고 말씀드린 대로 속도를 강제해도 아무 효과가 없습니다. ethtool -s eth2 1000 autoneg off duplex full 뒤에도 인터페이스는 여전히 10 Mbit half duplex에 머뭅니다.
같은 라우터에서 배제해봐야 할 또 다른 실패 유형입니다. 비슷해 보이지만 encoding이랑은 전혀 상관없거든요. Turris OS HBS 6.2.4에서 HALNy HL-GSFP는 인식이 됐고, 포트도 inband/1000base-x로 바뀌기까지 했는데, 그러다 링크가 끊기고 eth2가 down 상태로 남았습니다.
원인은 그 스틱이 그 자체로 작은 컴퓨터라는 겁니다. 자체 펌웨어를 띄우는 데 1분 가까이 걸리고, 그러고 나서야 케이지에 제대로 응답합니다. 콜드 부팅하면 라우터가 그보다 훨씬 전에 케이지를 들여다보니까 인식이 실패하고, 박스는 조용히 구리선 WAN 마그네틱으로 되돌아갑니다. 부팅 딜레이를 늘리니 해결됐습니다.
기본값 3초 대신 60초로요. 같은 스틱을 쓰는 다른 분도 이걸로 확인해줬습니다. 도움이 된 두 가지 더. 구리선 WAN 케이블을 뽑고 한 번 더 재부팅하는 것, 그리고 모듈 자체에 로그인해서 상태를 확인하는 것(시리얼 38400 8N1 또는 SSH로 192.168.77.154 포트 22666)입니다.