Turris Omnia menolak stick GPON MA5671A yang sudah di-unlock: eth2 tidak pernah up di Turris OS 5.0.3
Lagi coba mengganti terminal ISP di rack rumah dengan stick GPON langsung di router, supaya fiber-nya masuk ke satu box saja, bukan dua. Stick-nya terdeteksi, dan di situ saja kabar baiknya berakhir.
- Turris Omnia di Turris OS 5.0.3, kernel stock
- Stick GPON Huawei MA5671A dengan firmware unlocked, di-set ke SGMII 1G
- Pigtail SC/APC dari soket dinding ke stick
- eth2 adalah port SFP-nya
Modulnya terdeteksi tapi interface-nya tidak pernah aktif:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66beth2 tetap down setelah itu, no carrier, tidak ada apa-apa di counter.
Yang sudah saya coba sejauh ini:
- flash ulang stick-nya ke firmware stock, malah dapat EEPROM read error
- paksa rate-nya dengan ethtool -s eth2 1000 autoneg off duplex full, setelah itu interface-nya diam di 10 Mbit half duplex
- pindahkan stick yang sama ke router MikroTik, di situ dia mau up begitu port speed-nya di-set manual
Jadi modulnya sendiri hidup dan sisi fiber-nya baik-baik saja. Apa sebenarnya di stick ini yang ditolak kernel, dan stick GPON mana yang benar-benar mau up di Omnia, bukannya ditolak?
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
Ini masalah di sisi host, bukan modul yang mati. EEPROM di stick-stick GPON yang dialihfungsikan ini mendeklarasikan encoding yang tidak bisa dipetakan oleh driver sfp mainline, makanya phylink menolak menaikkan port-nya, dan baris yang kamu tempel itu driver-nya bilang persis itu. Bukti kamu sendiri mengarah ke hal yang sama: stick yang identik bisa link di MikroTik begitu port speed-nya di-set manual, jadi optiknya dan sisi PON-nya baik-baik saja.
Satu-satunya hal yang benar-benar mengubah keadaan buat saya adalah kernel yang cukup baru untuk membawa quirk per-modul itu, yang di Omnia berarti branch testing HBD dengan kernel 5.4. Perlu diingat ini kemenangan sebagian dan sangat tergantung stick mana yang kamu punya. Di kernel itu:
Jadi kalau kamu mau Omnia-nya jalan sekarang, bukan nanti-nanti, DFP-34G-2C2 yang akan saya pasang di cage-nya. Tes dulu di box kamu sendiri sebelum memutuskan, hasilnya di sini jelas beda-beda antar stick, bahkan antar revisi firmware dari stick yang sama.
Dua hal yang perlu dipastikan dulu sebelum ada yang mulai menebak-nebak. Pertama, 5.0.3 itu dari branch yang mana dan kernel apa yang dilaporkan uname? Quirk SFP per-modul yang dibutuhkan stick-stick GPON yang dialihfungsikan ini masuk belakangan, jadi kernel stable yang dirilis dan kernel testing berperilaku sangat berbeda dengan modul yang persis sama.
Kedua, apakah serial ONU-nya sudah terdaftar di sisi provider? Stick yang tidak pernah diotorisasi di OLT akan diam saja terlihat mati, dan banyak provider yang sama sekali menolak mendaftarkan ONU pihak ketiga.
Dan waktu kamu colokkan, apakah port-nya sempat berpindah ke inband/1000base-x, atau log-nya berhenti persis di pesan encoding itu?
Branch stable, kernel stock untuk 5.0.3, tidak ada yang custom di atasnya. Sisi provider bukan masalahnya di sini, ini fiber yang sama dan stick-nya membawa serial yang terdaftar.
Log-nya berhenti di baris encoding, port-nya tidak pernah berpindah ke inband/1000base-x. Yang saya dapat tergantung firmware-nya. Dengan yang unlocked:
ditambah transmit fault yang dilaporkan modulnya. Dengan firmware stock malah tidak sampai sejauh itu:
Dan seperti sudah disebut, memaksa rate-nya sama sekali tidak berpengaruh: setelah ethtool -s eth2 1000 autoneg off duplex full interface-nya tetap diam di 10 Mbit half duplex.
Satu mode kegagalan lagi yang perlu disingkirkan di router yang sama, karena kelihatannya mirip tapi sama sekali tidak ada hubungannya dengan encoding. Sebuah HALNy HL-GSFP di Turris OS HBS 6.2.4 terdeteksi, port-nya bahkan berpindah ke inband/1000base-x, lalu link-nya drop dan eth2 tetap down.
Penyebabnya: stick itu sebenarnya komputer kecil tersendiri. Dia butuh kira-kira satu menit untuk menyalakan firmware-nya sendiri, dan baru setelah itu dia menjawab cage-nya dengan sesuatu yang masuk akal. Cold boot bikin router-nya sudah melihat ke cage jauh sebelum titik itu, jadi deteksinya gagal dan box-nya diam-diam kembali ke magnetics WAN tembaga. Memperpanjang boot delay menyelesaikannya:
Enam puluh detik dibanding default tiga detik, dan orang lain dengan stick yang sama sudah mengonfirmasinya. Dua hal lagi yang membantu: cabut kabel WAN tembaga dan reboot sekali lagi, dan login ke modulnya sendiri untuk lihat statenya, lewat serial di 38400 8N1 atau lewat SSH di 192.168.77.154 port 22666.