ODI DFP-34X-2C2 di Turris Omnia cuma link di 1000base-x, ethtool tidak mau menerima speed 2500
Saya mengganti ONU ISP dengan stick GPON ODI DFP-34X-2C2 di Turris Omnia saya supaya fiber-nya berakhir di router, bukan di kotak lain di rak. Bagian itu jalan: line-nya registered, traffic mengalir, tidak ada keluhan. Masalahnya di rate-nya. Tidak pernah naik di atas 1Gbps, padahal 2.5G itu alasan utama saya beli stick ini.
- Turris Omnia, TurrisOS 6.0.4
- stick GPON ODI DFP-34X-2C2 di SFP cage, eth2
- copper WAN dicabut, cage-nya yang memegang port-nya
Yang dikatakan kernel setelah boot, dan yang terjadi waktu saya coba paksa rate-nya:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentethtool eth2 waktu link-nya up menunjukkan modulnya sebagai 1000baseX/Full dan tidak ada yang lebih tinggi, dan penolakan di atas itu ethtool memberi tahu saya bahwa speed 2500 tidak bisa diadvertise.
Yang sudah dicoba:
- telnet ke stick-nya dan set rate-nya dari shell-nya sendiri; command-nya diterima lalu balik lagi ke 1Gbps
- reboot dengan dan tanpa copper WAN terpasang
- cek dmesg cari apa pun soal MAC yang ditawari 2.5G, tidak ada apa-apa
Apakah ini router yang membatasi port-nya, atau modulnya sendiri? Dan apakah ada sesuatu di sisi host yang bisa membuat eth2 naik di 2500base-x dengan stick ini?
Comments 5
Batasnya di sini adalah modulnya sendiri, bukan Omnia-nya.
Yang dinegosiasikan host itu apa yang dideklarasikan EEPROM modulnya bisa dilakukan, karena pada saat probe chip itu satu-satunya yang bisa dipegang cage-nya. Di stick itu dia di-coding untuk 1000Mbps. Jadi port-nya diset sebagai inband/1000base-x, tidak ada mode 2500base-x untuk ditawarkan phylink, dan ethtool menolak speed 2500 karena tidak ada apa pun untuk diadvertise dengan itu. Tidak ada switch di sisi host yang bisa mengakali itu: ethtool cuma bisa minta mode yang memang diberitahukan ada di port-nya. Shell di dalam stick-nya mengonfigurasi sisi PON dari modulnya, bukan apa yang diadvertise cage-nya ke MAC, dan itulah persis kenapa perubahan telnet kamu menguap dan kamu balik lagi ke 1Gbps.
Itu menyisakan dua opsi nyata: minta modulnya di-recode supaya mengadvertise 2.5G, atau ganti dengan yang memang sudah begitu. Kalau kamu ambil jalur re-coding, siapkan cadangan di meja. Kamu menulis ulang halaman identitas yang dipercaya host, dan satu byte yang salah di situ bisa membuat modulnya berhenti dikenali sama sekali oleh cage-nya. Ingat juga dua rate ini berbeda: apa yang dikirim sisi PON dan apa yang dinegosiasikan link SFP-ke-MAC itu angka yang terpisah, jadi hitung dulu apa yang benar-benar kamu dapat sebelum keluar uang untuk ini.
Sebelum menyalahkan stick-nya, cek device tree apa yang di-boot kotaknya. Cage di Omnia bukan interface tambahan: cage itu dan bagian WAN metalik adalah dua front end ke satu eth2 yang sama, dan cuma satu yang benar-benar terhubung ke MAC pada satu waktu. Yang mana itu tergantung dtb yang dimuat kernel waktu boot. Jadi lihat /boot/dtb menunjuk ke mana: kalau bukan armada-385-turris-omnia-sfp.dtb, kamu sedang melihat sisi copper-nya dan angka-angkanya tidak berarti apa-apa.
Post juga dmesg | grep -i sfp lengkap, bukan cuma baris mvneta-nya. Yang dibaca kernel dari modulnya pada saat probe itu bagian yang menarik di sini, dan biasanya menjawab pertanyaannya dalam satu baris.
dtb-nya memang sudah yang SFP, saya symlink armada-385-turris-omnia-sfp.dtb waktu pertama kali pasang stick-nya, kalau tidak begitu tidak ada apa pun yang naik sama sekali. Cage-nya memegang eth2 dan copper WAN-nya tetap dicabut.
dmesg | grep -i sfp menunjukkan modulnya teridentifikasi lalu baris yang sama yang saya posting, eth2 switched to inband/1000base-x link mode. Tidak ada apa pun soal 2500 di mana pun. ethtool eth2 melaporkan 1000baseX/Full sementara link-nya up dan traffic mengalir, dan ethtool -s eth2 speed 2500 tetap balik dengan Invalid argument, jadi memang tidak akan mengadvertise 2500 sama sekali. Set rate lewat telnet di dalam stick-nya berperilaku sama seperti sebelumnya, diterima lalu jatuh kembali ke 1Gbps.
Cerita yang berdekatan dari board yang sama, kalau-kalau ada yang mendarat di sini dengan stick yang sama sekali tidak mau naik, bukan yang cuma stuck di 1G. HALNy HL-GSFP di Omnia dengan Turris OS HBS 6.2.4: kernel-nya mengidentifikasi stick-nya, port-nya bahkan switch ke inband/1000base-x, lalu link-nya drop dan eth2 tidak pernah naik.
Yang itu bukan masalah EEPROM. Ada satu OS kecil yang hidup di dalam stick itu, dan dia butuh sekitar satu menit untuk dirinya sendiri sebelum berada dalam kondisi bisa menjawab host. Pada cold start, router-nya sudah selesai probe cage-nya dan menyerah jauh sebelum titik itu, jadi port-nya balik ke copper magnetics. Memperpanjang delay U-Boot memperbaikinya di sini:
Default-nya 3 detik; di 60 stick-nya sudah selesai naik pada saat kernel akhirnya sampai ke giliran probe cage-nya. Mencabut copper WAN dan reboot untuk kedua kalinya juga membantu deteksinya. Dan kalau kamu pernah perlu melihat isi stick-nya, serial-nya di 38400 8N1.
Setuju dengan diagnosisnya, dengan satu catatan untuk siapa pun yang mendarat di sini dengan gejala serupa. Tidak semua "tidak bisa 2.5G" di board ini soal modulnya. Pernah ada OpenWrt snapshot di mana kode phylink validate generik di-backport, dan itu langsung merusak cage Omnia: ethtool tetap mengadvertise 2500baseX/Full tapi melaporkan Link detected: no. Me-revert backport itu mengembalikan port-nya ke keadaan semula, ethtool membaca Link detected: yes, 2500Mb/s full duplex, dan pull request berikutnya membereskan backport itu di upstream.
Tandanya ada di apa yang ethtool sebut sebagai supported dan advertised. Kalau 2500baseX/Full ada di situ dan link-nya cuma menolak untuk naik, lihat kernel dan phylink setelah image upgrade terakhir kamu, bukan optiknya. Kalau, seperti di sini, port-nya cuma pernah tahu 1000baseX karena memang itu yang dideklarasikan modulnya tentang dirinya sendiri, tidak ada software host yang bisa memunculkan mode itu. Itu adalah byte nominal bit rate di EEPROM yang melakukan persis seperti kata SFF-8472.