Turris Omnia의 ODI DFP-34X-2C2가 1000base-x로만 링크되고 ethtool이 speed 2500을 받지 않음
선반 위 별도 박스 대신 라우터에서 광케이블을 바로 종단시키려고 ISP ONU를 Turris Omnia에 꽂은 ODI DFP-34X-2C2 GPON 스틱으로 교체했습니다. 여기까진 잘 됐습니다. 회선이 등록되고 트래픽도 흐르고, 불만 없습니다. 문제는 속도입니다. 1Gbps를 절대 넘지 않는데, 이 스틱을 산 이유가 바로 2.5G였거든요.
- Turris Omnia, TurrisOS 6.0.4
- SFP 케이지에 ODI DFP-34X-2C2 GPON 스틱 장착, eth2
- 구리 WAN은 뽑아둔 상태, 포트는 케이지가 전담
부팅 후 커널 로그와 속도를 강제로 바꾸려고 했을 때의 결과입니다:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argument링크가 올라온 상태에서 ethtool eth2를 치면 모듈이 1000baseX/Full로만 나오고 그 이상은 없습니다. 위에서 거부된 것도 ethtool이 speed 2500은 advertise할 수 없다고 알려주는 겁니다.
지금까지 시도한 것:
- 스틱에 telnet으로 접속해 자체 셸에서 속도를 설정, 명령은 받아들이지만 결국 1Gbps로 돌아옴
- 구리 WAN을 연결한 상태와 뺀 상태 양쪽에서 재부팅
- dmesg에서 MAC에 2.5G가 제시되는 흔적을 찾아봤지만 아무것도 없음
이건 라우터가 포트를 제한하고 있는 건가요, 아니면 모듈 자체 문제인가요? 그리고 이 스틱으로 eth2를 2500base-x로 올리기 위해 호스트 쪽에서 할 수 있는 게 있을까요?
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
여기서 한계는 Omnia가 아니라 모듈 자체입니다.
호스트가 협상 기준으로 삼는 건 모듈의 EEPROM이 선언하는 능력치입니다. probe 시점에 케이지가 참고할 수 있는 건 그 칩뿐이니까요. 이 스틱은 1000Mbps로 코딩되어 있습니다. 그래서 포트는 inband/1000base-x로 설정되고, phylink가 제시할 2500base-x 모드 자체가 없고, ethtool은 advertise할 대상이 없으니 speed 2500을 거부하는 겁니다. 호스트 쪽에서 어떤 스위치를 만져도 이건 우회할 수 없습니다. ethtool은 포트가 존재한다고 알려준 모드만 요청할 수 있으니까요. 스틱 안의 셸은 모듈의 PON 쪽을 설정하는 것이지 케이지가 MAC 쪽으로 advertise하는 내용을 바꾸는 게 아닙니다. 그래서 telnet으로 바꾼 설정이 사라지고 결국 1Gbps로 돌아오는 겁니다.
그러면 실질적인 선택지는 둘입니다. 모듈을 2.5G를 advertise하도록 재코딩하거나, 처음부터 그렇게 되어 있는 모듈로 교체하는 것. 재코딩 쪽으로 간다면 여분을 하나 준비해 두세요. 호스트가 신뢰하는 식별 페이지를 새로 쓰는 작업이라, 바이트 하나만 잘못돼도 케이지가 아예 인식을 못 하는 모듈이 될 수 있습니다. 그리고 두 속도는 머릿속에서 분리해서 생각하세요. PON 쪽이 내는 속도와 SFP-MAC 링크가 협상하는 속도는 별개의 수치입니다. 돈을 쓰기 전에 실제로 뭘 얻는지부터 따져보세요.
스틱을 탓하기 전에 기기가 어떤 device tree로 부팅하는지부터 확인하세요. Omnia의 케이지는 별도 인터페이스가 아닙니다. 케이지와 구리 WAN 쪽은 똑같은 eth2 하나에 붙은 두 개의 앞단일 뿐이고, 그중 하나만 그때그때 MAC에 연결됩니다. 어느 쪽이 연결되는지는 커널이 부팅 시 로드하는 dtb에 달려 있습니다. 그러니 /boot/dtb가 뭘 가리키는지 보세요. armada-385-turris-omnia-sfp.dtb가 아니라면 구리 쪽을 보고 있는 거라 지금 보이는 수치는 아무 의미가 없습니다.
그리고 mvneta 줄만 말고 dmesg | grep -i sfp 전체를 올려주세요. 여기서 중요한 건 probe 시점에 커널이 모듈에서 읽어낸 내용이고, 보통 그 한 줄이면 답이 나옵니다.
dtb는 이미 SFP 쪽입니다. 스틱을 처음 꽂았을 때 armada-385-turris-omnia-sfp.dtb로 심링크해 뒀어요, 안 그러면 아예 아무것도 안 올라오더라고요. eth2는 케이지가 전담하고 구리 WAN은 계속 뽑아둔 상태입니다.
dmesg | grep -i sfp를 보면 모듈이 인식된 다음 제가 올린 것과 같은 줄, eth2 switched to inband/1000base-x link mode가 나옵니다. 2500에 대한 언급은 어디에도 없고요. ethtool eth2는 링크가 올라와서 트래픽이 흐르는 동안 1000baseX/Full이라고 나오고, ethtool -s eth2 speed 2500은 여전히 Invalid argument로 돌아옵니다. 2500은 아예 advertise하지 않는 거죠. 스틱 안에서 telnet으로 속도를 설정하는 것도 전과 똑같습니다. 받아들이긴 하는데 결국 1Gbps로 돌아옵니다.
같은 보드에서 겪은 비슷한 사례입니다. 1G에 묶이는 게 아니라 아예 안 올라오는 스틱 때문에 여기 들어온 분들을 위해 남깁니다. Turris OS HBS 6.2.4의 Omnia에 꽂은 HALNy HL-GSFP: 커널이 인식하고 포트도 inband/1000base-x로 전환까지 됐는데, 그 뒤 링크가 끊기고 eth2가 끝내 올라오지 않았습니다.
이건 EEPROM 문제가 아닙니다. 그 스틱 안에는 작은 OS가 통째로 들어 있어서 호스트에 응답할 수 있는 상태가 되기까지 1분 가까이 혼자만의 시간이 필요합니다. 콜드 스타트에서는 라우터가 그 시점이 오기 한참 전에 이미 케이지를 probe하고 포기해버려서, 포트가 구리 마그네틱 쪽으로 돌아가 버립니다. U-Boot 딜레이를 늘렸더니 해결됐습니다:
기본값은 3초입니다. 60초로 늘리면 커널이 케이지를 probe할 즈음엔 스틱이 이미 부팅을 마친 상태가 됩니다. 구리 WAN을 뽑아두고 한 번 더 재부팅하는 것도 인식에 도움이 됐습니다. 그리고 스틱 내부를 들여다볼 일이 있다면 시리얼은 38400 8N1입니다.
진단에는 동의합니다만, 비슷한 증상으로 여기 들어온 분들을 위해 한 가지 짚어둘 게 있습니다. 이 보드에서 “2.5G가 안 된다”는 증상이 전부 모듈 탓은 아닙니다. 예전에 일반 phylink validate 코드가 백포트된 OpenWrt 스냅샷이 있었는데, 그게 Omnia 케이지를 아예 망가뜨렸습니다. ethtool은 여전히 2500baseX/Full을 advertise한다고 나오는데 Link detected: no로 표시됐습니다. 그 백포트를 되돌리니 포트가 원래대로 돌아와서 ethtool이 Link detected: yes, 2500Mb/s full duplex로 나왔고, 나중에 온 풀 리퀘스트로 업스트림에서 그 백포트 문제가 정리됐습니다.
구분할 방법은 ethtool이 supported와 advertised에 뭘 나열하는지 보는 겁니다. 거기에 2500baseX/Full이 있는데 링크만 안 올라온다면, 광모듈이 아니라 최근 이미지 업그레이드 이후의 커널과 phylink를 보세요. 반대로 여기 사례처럼 모듈이 스스로 그렇게 선언해서 포트가 1000baseX만 아는 상태라면, 호스트 쪽 소프트웨어로는 그 모드를 만들어낼 수 없습니다. 이건 EEPROM의 nominal bit rate 바이트가 SFF-8472가 정한 그대로 동작하고 있는 것뿐입니다.