GPON stick DFP-34X-2C2 dmesg'de ancak onlarca saniye sonra görünüyor ve sonra 1G'de link kuruyor
WAN'ımızı sonlandıran Linux kutusunda operatör ONT'sini bir SFP GPON stick ile değiştiriyorum, ve stick hiçbir şekilde bir transceiver gibi davranmıyor. Takıyorsunuz, cage yarım dakika ya da daha uzun süre sessiz kalıyor, o kadar ki iki kere modülün öldüğünü düşündüm, kernel sonunda fark ettiğinde de link gigabit hızında oturuyor, bu da işin amacını baştan boşa çıkarıyor.
Test düzeneği:
- Linux router kutusu, SFP cage'i kernel SFP layer'ı sürüyor, mainline kernel
- ODI DFP-34X-2C2 GPON stick
- ikinci örnek olarak bir Huawei MA5671a stick
- aynı cage'de anında görünen sıradan bir 1G fiber modül, yani cage'in kendisi sorunsuz
$ 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 offŞimdiye kadar denediklerim:
- stick'i yeniden takıp interface'e dokunmadan birkaç dakika bekledim, bekleme her seferinde var, sadece ilk takışta değil
- tespitten sonra interface'i indirip kaldırdım, negotiate edilen mod konusunda hiçbir şey değişmiyor
- MA5671a da aynı yavaş görünmeyi gösteriyor, yani tek bir kötü örnek değil
Bu gerçekten GPON stick'lerin bir Linux host'unda davranış biçimi mi, yoksa benim tarafımda bir şey mi yanlış? Takma ile tespit arasında burada gerçekte ne oluyor?
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
Tahminler başlamadan önce netleştirilmeye değer iki şey var. Birincisi, iki satırlık bir grep yerine takıldığı andan itibaren kırpılmamış dmesg'i paylaşın. Cage'in kernel SFP layer'ının arkasında olduğunu söylüyorsunuz, buna şüphem yok, ama filtrelediğiniz satırlar modülün kaç kez probe edildiğini, arada neyin vazgeçtiğini ve her denemenin ne kadar sürdüğünü gösteren satırlar.
İkincisi, stick sonunda ayağa kalktığında interface'in kendisi ne yapabildiğini iddia ediyor, advertised mode'lar arasında herhangi bir yerde 2500baseX görünüyor mu? Ve ISP size PON tarafında hangi hızı veriyor, çünkü bu bir gigabit planıysa aldığınız link doğru olandır ve düzeltilecek bir şey yok.
Ne yazık ki beklenen davranış bu, ve host'unuzla ilgisi yok.
Bir GPON stick, içinde EEPROM çipi olan bir transceiver değildir. Kendi SoC'si üzerinde çalışan, bir SFP kabuğuna sıkıştırılmış küçük bir Linux bilgisayardır, ve host'unuzun I2C üzerinden okuduğu EEPROM o sistem tarafından emüle edilir. Stick'in kendi firmware'i o sayfaları sunacak kadar boot olana kadar bus'ta hiçbir şey cevap vermez, normal bir modül anında cevap verirken sizin onlarca saniye orada oturmanızın sebebi de bu. Modül satırınızdan önceki o sessizlik, boot'un kendisi.
Probleminizin ikinci yarısı, emüle edilen sayfaların reklam ettiği şeyin sık sık yanlış olması. Bu stick'lerdeki host tarafı interface 2500BASE-X'tir, EEPROM ise başka bir şey söyler, bu yüzden SFP layer'ı bunu olduğu gibi kabul edip gigabit moduna oturur. Her iki yarı da kernel'de konfigüre edebileceğiniz bir şey yerine modül başına quirk'lerle ele alınır, OEM DFP-34X-2C2 de tam bu yüzden o quirk'lerden birine yakalanmış.
Örneğinizin buna denk gelip gelmediği bildirdiği vendor ve part string'lerine bağlı, ve bunlar rebadge'ler arasında değişiyor, o yüzden kapsandığınızı varsaymadan önce dmesg satırınızın yazdığıyla quirk'ün eşleştiği şeyi karşılaştırın.
Quirk yaklaşımının neden gerekli olduğunu vurgulamak gerekirse: SFF-8472, sıradan I2C zamanlamaları içinde cevap veren pasif bir bellek cihazı varsayar. İçinde konuşabilmeden önce yarım dakika boot'a ihtiyaç duyan bir cihazı öngören hiçbir şey yok, bu yüzden standardı takip eden bir host'un modülden vazgeçmeye ya da sonunda okuduğu mode bit'lerine güvenmeye tam hakkı var.
Yukarıdaki rebadge noktası pratikteki tuzak. Eşleştirme vendor ve part string'leri üzerinden yapılıyor, yani aynı fiziksel stick başka bir isimle satıldığında quirk'ü tamamen kaçırıyor ve belirgin bir sebep olmadan yine gigabit bir link'e dönüyorsunuz. Ve modülün boot'tan kısa süre sonra mevcut olmasına dayanan hiçbir şey kurmayın, çünkü burada o yarış kazanılamaz.
Stick vendor'larının EEPROM içeriklerini düzeltmesini ummak da iyimserlik. Bu problemler gündeme geldiğinde, büyük ISP'ler bile onlardan pek az geri dönüş aldı.
Aynı sınıftan problem tüketici router'larında da çıkıyor, en azından yalnız değilsiniz. 10G SFP+ combo portunda bir stick olan Archer BE800, BE900 ve GE800 sahipleri, parasını ödedikleri 2.5 yerine 1 Gbit/s alıyor, TP-Link'in o portlarda çalıştığı bildirilen kendi stick listesi de ODI DFP-34X-2C2, Huawei MA5671A ve Nokia G-010SA, yani herkesin sonunda elinde bulduğu aynı kısa parça listesi.
Oradaki ilk tavsiye firmware artı yeniden takmaktı, ve yeniden takma kısmı saçma değil, sonuna kadar oturmamış bir modül gerçekten geri düşüyor. Beta build'ler sonunda port konfigürasyonunu açığa çıkardı, model başına bir tane:
Kutuda bunlardan biri varken SFP port modu telnet üzerinden ayarlanabilir hale geliyor, önce interface düşürülüyor,
ip link set eth1 downve benzeri.Yine de bu bir workaround, bir fix değil. Bir yıl sonra aynı şikayetler gelmeye devam etti, sadece stick'lerle ilgili de değil: birinde o portta JT-COM'dan bir JT-AOC-SFP-15 AOC vardı, birinde Ampcom'dan pasif bir 10G SFP+ DAC, ikisi de 1 Gbit/s'te kaldı.
Birisi stick'i bir NIC'e taşımayı önermeden önce bilinmeye değer başka bir failure mode var. Intel X520 ve kmod-ixgbe ile x86 üzerinde OpenWrt 19.07'de, bir MA5671a desteklenmeyen bir SFP olarak basitçe reddediliyor. allow_unsupported_sfp'yi olağan modül config dosyaları üzerinden ayarlamak orada hiçbir işe yaramıyor, parametrenin modül yüklenirken verilmesi gerekiyor:
Bununla bile driver onu reddetmeye devam ediyor, çünkü stick'in EEPROM'u zaten normal bir transceiver'ı tarif etmiyor ve flag bunun üstünü örtemiyor. Bir NIC'e geçerseniz, önce portu sıradan bir 1000BASE-T, LX ya da SX modülüyle kanıtlayın, yoksa aynı anda hem kartı hem stick'i debug ediyorsunuz demektir.
Yine de ikisini birbirine karıştırmamaya dikkat edin. allow_unsupported_sfp ixgbe'nin içinde yaşar ve o driver'ın verili bir optiği sürmeye hiç niyetli olup olmadığına karar verir, bu burada verilen karardan farklı bir karar. Uzun bekleme ve yanlış mod, generic SFP layer'ının emüle edilmiş sayfaları okuyup sonucu phylink'e teslim etmesinden geliyor, modül başına quirk'lerin oturduğu yer de orası.
Düzgün bir SFP cage'i olan bir board'da ixgbe flag'i yoktur ve zaten fix de o değildir, bir X520'de de quirk listesi sizi kurtarmaz. Yüzeyde aynı semptom, altında farklı katman, ikisini karıştırmak da insanların boşu boşuna driver yeniden derlemesiyle sonuçlanıyor.
Bu arada çizilmeye değer bir sınır daha: host'un stick'i görmesini sağlamakla OLT'nin onu kabul etmesini sağlamak birbirinden bağımsız problemler, ikincisi çok daha kötü olabilir.
Bir ZTE ZXHN F601'den setmac ve OMCI sorgularıyla kopyalanan kimlikle - GPON serial, PLOAM parolası, LOID, hardware serial ve firmware string'i, hepsi - yüklenmiş bir Xicom DFP-34X-2C2 vakası iyi belgelenmiş durumda. Stick O5 durumuna kadar range'liyor ve sonra öylece oturuyor, ONU ID atanmıyor ve trafik yok, çünkü O5'e ulaşmak sadece ranging'in çalıştığı anlamına geliyor, MIB upload'ının hâlâ OLT'nin beklediği ONT profiliyle eşleşmesi gerekiyor. O konuda kimse bir fix üretmedi.
Yani yerel olarak 2500BASE-X'i elde ettiğinizde, zor kısmın geride kaldığını varsaymayın. Operatörün bir servis profilini tek bir belirli ONT modeline bağladığı yerde, kopyalanan alanların üçüncü parti bir stick'i kabul ettirecek hiçbir kombinasyonu olmayabilir.