Turris Omnia, kilidi açık bir MA5671A GPON stick'i reddediyor: Turris OS 5.0.3'te eth2 hiç gelmiyor
Ev rafımdaki ISP terminalini, fiberin iki kutu yerine tek kutuda son bulması için, doğrudan router'daki bir GPON stick ile değiştirmeye çalışıyorum. Stick tanınıyor, iyi haberler de orada bitiyor.
- Turris OS 5.0.3'te Turris Omnia, stock kernel
- kilidi açık firmware'li, SGMII 1G'ye ayarlı Huawei MA5671A GPON stick
- duvar soketinden stick'e giden SC/APC pigtail
- eth2 SFP portu
Modül algılanıyor ama interface hiç aktive olmuyor:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66bOndan sonra eth2 down kalıyor, carrier yok, sayaçlarda hiçbir şey yok.
Şimdiye kadar denediklerim:
- stick'i stock firmware'e geri flaşladım, bunun yerine bir EEPROM read error alıyorum
- ethtool -s eth2 1000 autoneg off duplex full ile hızı zorladım, bundan sonra interface 10 Mbit half duplex'te oturuyor
- aynı stick'i bir MikroTik router'a taktım, orada port hızı elle ayarlanınca geliyor
Yani modülün kendisi hayatta ve fiber tarafı sorunsuz. Kernel'in stick'te itiraz ettiği şey ne, bir de hangi GPON stick'ler reddedilmek yerine gerçekten bir Omnia'da geliyor?
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
Bu host tarafında bir sorun, ölü bir modül değil. Bu amacı değiştirilmiş GPON stick'lerindeki EEPROM, mainline sfp driver'ının eşleyemeyeceği bir encoding bildiriyor, phylink de bu yüzden portu kaldırmayı reddediyor, yapıştırdığın satır da driver'ın tam olarak bunu söylemesi. Kendi kanıtın da aynı yöne işaret ediyor: aynı stick, port hızı elle ayarlanınca bir MikroTik'te linkleniyor, yani optikler ve PON tarafı sorunsuz.
Benim için işe yarayan tek şey, per-module quirk'leri taşıyacak kadar yeni bir kernel oldu, Omnia'da bu kernel 5.4'lü HBD testing branch'i demekti. Uyarayım, bu kısmi bir kazanım ve büyük ölçüde hangi stick'e sahip olduğuna bağlı. O kernel'de:
Yani Omnia'yı sonunda değil de şimdi çalışır istiyorsan, kafese koyacağım şey DFP-34G-2C2 olurdu. Karar vermeden önce kendi kutunda test et, buradaki sonuçlar stick'ler arasında, hatta aynı stick'in firmware revizyonları arasında bile açıkça değişiyor.
Kimse tahmine başlamadan önce netleştirmekte fayda olan iki şey var. Önce, o 5.0.3 hangi branch'ten ve uname ne kernel raporluyor? Bu amacı değiştirilmiş GPON stick'lerin ihtiyaç duyduğu per-module SFP quirk'leri sonradan geldi, yani shipped bir stable kernel ile bir testing kernel, tam olarak aynı modülle çok farklı davranıyor.
İkincisi, ONU serial provider tarafında kayıtlı mı? OLT'de hiç yetkilendirilmeyen bir stick orada ölü gibi durur, üstelik pek çok provider third party bir ONU'yu kaydetmeyi zaten reddediyor.
Bir de taktığında, port hiç inband/1000base-x'e geçiyor mu, yoksa log tam o encoding mesajında mı duruyor?
Stable branch, 5.0.3 için stock kernel, üstüne özel bir şey yok. Provider tarafı burada sorun değil, aynı fiber ve stick kayıtlı serial'i taşıyor.
Log encoding satırında duruyor, port hiç inband/1000base-x'e geçmiyor. Aldığım sonuç firmware'e bağlı. Kilidi açık olanla:
artı modülün bildirdiği bir transmit fault. Stock firmware'le bu kadar bile ileri gitmiyor:
Söylediğim gibi, hızı zorlamak da hiçbir şeyi değiştirmiyor: ethtool -s eth2 1000 autoneg off duplex full'dan sonra interface hâlâ 10 Mbit half duplex'te oturuyor.
Aynı router'da ekarte edilmesi gereken başka bir arıza modu daha, çünkü benzer görünüyor ama encoding ile hiçbir ilgisi yok. Turris OS HBS 6.2.4'te bir HALNy HL-GSFP algılandı, port inband/1000base-x'e bile geçti, sonra link düştü ve eth2 down kaldı.
Sebep: o stick kendi başına küçük bir bilgisayar. Kendi firmware'ini bir dakikaya yakın bir sürede ayağa kaldırıyor, ancak ondan sonra kafese anlamlı bir şey söylüyor. Soğuk boot'ta router kafese o noktadan çok önce bakıyor, algılama başarısız oluyor ve kutu sessizce bakır WAN magnetics'ine geri düşüyor. Boot delay'i uzatmak sorunu çözdü:
Default üç yerine altmış saniye, aynı stick'e sahip başka biri de bunu doğruladı. İşe yarayan iki şey daha: bakır WAN kablosunu çıkarıp bir kez daha reboot etmek, bir de modülün kendisine girip hangi durumda olduğuna bakmak, 38400 8N1'de seri üzerinden veya 192.168.77.154 port 22666'da SSH üzerinden.