Stick GPON DFP-34X-2C2 baru muncul di dmesg setelah puluhan detik, lalu link di 1G
Saya lagi mengganti ONT operator dengan stick GPON SFP di box Linux yang jadi terminasi WAN kami, dan stick-nya sama sekali nggak berperilaku seperti transceiver. Colok masuk dan cage-nya diam saja selama setengah menit atau lebih, cukup lama sampai saya dua kali mengira modulnya mati, dan begitu kernel akhirnya menyadarinya, link-nya menetap di kecepatan gigabit, yang bikin percuma seluruh maksud dari usaha ini.
Di meja saya:
- box router Linux, cage SFP digerakkan oleh kernel SFP layer, kernel mainline
- stick GPON ODI DFP-34X-2C2
- stick Huawei MA5671a sebagai sampel kedua
- modul fiber 1G biasa yang langsung muncul di cage yang sama, jadi cage-nya sendiri nggak masalah
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control offYang sudah dicoba:
- lepas-pasang ulang stick-nya dan mendiamkannya beberapa menit sebelum menyentuh interface-nya, dan waiting time itu selalu ada, bukan cuma di pemasangan pertama
- bounce interface-nya setelah terdeteksi, yang nggak mengubah apa pun soal mode yang dinegosiasikan
- MA5671a menunjukkan kemunculan lambat yang sama, jadi ini bukan satu sampel yang cacat
Apakah ini memang begini caranya stick GPON berperilaku di host Linux, atau ada yang salah di sisi saya? Sebenarnya apa yang terjadi di antara pemasangan dan deteksi di sini?
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 7
Sebelum mulai menebak-nebak, ada dua hal yang perlu dipastikan dulu. Pertama, post dmesg yang utuh sejak pemasangan, bukan grep dua baris. Anda bilang cage-nya ada di belakang kernel SFP layer dan saya nggak punya alasan buat meragukan itu, tapi baris-baris yang Anda filter keluar itu justru yang menunjukkan berapa kali modulnya di-probe, apa yang menyerah di tengah jalan, dan berapa lama tiap percobaan makan waktu.
Kedua, apa yang diklaim interface-nya sendiri bisa dilakukan begitu stick-nya akhirnya up, dan apakah 2500baseX muncul di mana pun dalam mode yang diadvertise? Dan kecepatan berapa yang dikasih ISP di sisi PON, karena kalau itu paket gigabit, berarti link yang Anda dapat itu sudah benar dan nggak ada yang perlu diperbaiki.
Sayangnya ini perilaku yang memang diharapkan, dan ini bukan salah host Anda.
Stick GPON itu bukan transceiver dengan chip EEPROM di dalamnya. Itu komputer Linux kecil di SoC-nya sendiri, yang dijejalkan ke shell SFP, dan EEPROM yang dibaca host Anda lewat I2C itu diemulasikan oleh sistem itu. Nggak ada yang menjawab di bus sampai firmware stick-nya sendiri selesai boot cukup jauh buat melayani halaman-halaman itu, makanya Anda duduk menunggu puluhan detik sementara modul normal langsung menjawab. Keheningan sebelum baris modul Anda itu adalah proses boot-nya.
Separuh masalah Anda yang satunya adalah apa yang diadvertise halaman emulasi itu sering kali salah begitu saja. Interface sisi host di stick semacam ini itu 2500BASE-X, tapi EEPROM-nya bilang sesuatu yang lain, jadi SFP layer mempercayainya begitu saja dan menetap di mode gigabit. Kedua separuh masalah ini ditangani di kernel lewat per-module quirk, bukan sesuatu yang bisa Anda konfigurasi, dan OEM DFP-34X-2C2 kena salah satu quirk itu persis karena alasan ini.
Apakah sampel Anda kena quirk itu tergantung string vendor dan part yang dilaporkannya, dan itu beda-beda antar rebadge, jadi bandingkan apa yang dicetak baris dmesg Anda dengan apa yang dicocokkan quirk-nya sebelum menganggap Anda sudah aman.
Buat menegaskan kenapa pendekatan quirk ini perlu sama sekali: SFF-8472 mengasumsikan device memori pasif yang menjawab dalam timing I2C biasa. Nggak ada satu pun di situ yang mempertimbangkan device yang butuh setengah menit boot sebelum bisa bicara, jadi host yang mengikuti standar itu punya hak penuh buat menyerah pada modulnya atau mempercayai mode bit yang akhirnya dia baca.
Soal rebadge di atas itu jebakan praktisnya. Pencocokannya berdasarkan string vendor dan part, jadi stick fisik yang sama yang dijual dengan nama lain bakal lolos dari quirk itu sepenuhnya dan Anda balik lagi ke link gigabit tanpa alasan yang jelas. Dan jangan bikin apa pun yang bergantung pada modulnya hadir segera setelah boot, karena race itu nggak bisa dimenangkan di sini.
Berharap vendor stick-nya memperbaiki isi EEPROM mereka juga terlalu optimis. Waktu masalah ini diangkat, bahkan ISP besar cuma dapat respons yang sangat minim dari mereka.
Masalah sejenis muncul juga di router konsumer, jadi setidaknya Anda nggak sendirian. Pemilik Archer BE800, BE900, dan GE800 dengan stick di port combo SFP+ 10G dapat 1 Gbit/s, padahal yang mereka bayar itu 2.5. Daftar stick TP-Link sendiri yang dilaporkan jalan di port itu adalah ODI DFP-34X-2C2, Huawei MA5671A, dan Nokia G-010SA, daftar pendek part yang sama yang selalu jadi ujung-ujungnya buat semua orang.
Saran pertama di sana adalah firmware plus lepas-pasang ulang, dan bagian lepas-pasang ulang itu bukan omong kosong, modul yang belum klik sempurna sampai mentok memang bisa fallback. Build beta akhirnya membuka konfigurasi port, satu per model:
Dengan salah satu dari itu terpasang di box, mode port SFP jadi bisa diset lewat telnet, interface-nya di-drop dulu,
ip link set eth1 downdan seterusnya.Tetap saja ini workaround, bukan fix, perlu diingat. Setahun kemudian, keluhan yang sama masih masuk, dan bukan cuma soal stick: satu orang punya AOC JT-AOC-SFP-15 dari JT-COM di port itu, satu lagi DAC SFP+ 10G pasif dari Ampcom, dan keduanya mentok di 1 Gbit/s.
Perlu tahu juga failure mode lainnya sebelum ada yang menyarankan pindahin stick-nya ke NIC. Di OpenWrt 19.07 di x86 dengan Intel X520 dan kmod-ixgbe, MA5671a langsung ditolak sebagai SFP unsupported. Set allow_unsupported_sfp lewat file config module biasa sama sekali nggak berpengaruh di situ, parameternya harus dikasih pas modulnya di-load:
Dan meskipun begitu, driver-nya tetap menolak, karena EEPROM stick-nya dari awal memang nggak mendeskripsikan transceiver normal dan flag itu nggak bisa menutupi itu. Kalau Anda memang berakhir di NIC, buktikan dulu port-nya pakai modul 1000BASE-T, LX, atau SX biasa, kalau nggak Anda bakal debug card-nya dan stick-nya sekaligus di saat yang sama.
Tapi hati-hati jangan campur adukkan dua hal itu. allow_unsupported_sfp itu ada di dalam ixgbe dan menentukan apakah driver itu mau menjalankan optik tertentu sama sekali, itu keputusan yang beda dari yang sedang dibahas di sini. Waiting time yang panjang dan mode yang salah itu datang dari generic SFP layer yang membaca halaman emulasi dan menyerahkan hasilnya ke phylink, dan di situlah letak per-module quirk-nya.
Di board dengan cage SFP yang proper, flag ixgbe itu nggak ada dan bukan fix-nya, dan di X520 daftar quirk juga nggak akan menyelamatkan Anda. Gejalanya sama di permukaan, tapi layer di baliknya beda, dan kalau ini dicampur adukkan, ujung-ujungnya orang malah rebuild driver buat nggak ada gunanya.
Satu batas lagi yang perlu digambar selagi Anda di sini: bikin host melihat stick-nya dan bikin OLT menerimanya itu dua masalah yang independen, dan yang kedua bisa jauh lebih parah.
Ada kasus yang terdokumentasi dengan baik soal Xicom DFP-34X-2C2 yang di-load dengan identity hasil salinan dari ZTE ZXHN F601 pakai setmac dan query OMCI, GPON serial, PLOAM password, LOID, hardware serial, dan firmware string, semuanya. Stick-nya ranging sampai state O5 lalu diam saja di situ, nggak ada ONU ID yang diberikan dan nggak ada traffic, karena mencapai O5 cuma berarti ranging-nya berhasil, sementara MIB upload masih harus cocok dengan ONT profile yang diharapkan OLT-nya. Nggak ada satu pun di thread itu yang menemukan fix-nya.
Jadi begitu Anda berhasil dapat 2500BASE-X secara lokal, jangan anggap bagian sulitnya sudah lewat. Di tempat operator mengikat service profile ke satu model ONT tertentu, bisa jadi nggak ada kombinasi field hasil salinan yang bikin stick pihak ketiga diterima.