Bir Turris Omnia'daki ODI DFP-34X-2C2 sadece 1000base-x'te link veriyor, ethtool speed 2500'ü kabul etmiyor
Turris Omnia'mda ISP ONU'sunu bir ODI DFP-34X-2C2 GPON stick ile değiştirdim, ki fiber rafta başka bir kutu yerine router'da sonlansın. O kısım çalıştı: hat register oldu, trafik akıyor, şikayet yok. Sorun hız. Hiçbir zaman 1Gbps'in üzerine çıkmıyor, ve 2,5G bu stick'i almamın tüm sebebiydi.
- Turris Omnia, TurrisOS 6.0.4
- SFP kafesinde ODI DFP-34X-2C2 GPON stick, eth2
- bakır WAN çıkarılmış, kafes portun sahibi
Bir boot'tan sonra kernel'ın söyledikleri, ve hızı zorlamaya çalıştığımda olanlar:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentLink up iken ethtool eth2, modülü 1000baseX/Full olarak gösteriyor, daha yüksek bir şey yok, ve yukarıdaki ret, ethtool'un bana speed 2500'ün advertise edilemeyeceğini söylemesi.
Şimdiye kadar denenenler:
- stick'e telnet ile girip hızı kendi shell'inden ayarlamak; komutu alıyor ve sonra 1Gbps'e geri dönüyor
- bakır WAN takılı ve takılı değilken reboot'lar
- MAC'e 2,5G teklif edilmesiyle ilgili bir şey için dmesg'i taradım, hiçbir şey yok
Bu portu sınırlayan router mı, yoksa modülün kendisi mi? Ve bu stick ile eth2'yi 2500base-x'te up getirecek host tarafında bir şey var mı?
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 5
Buradaki tavan Omnia değil, modülün kendisi.
Host'un neye karşı negotiate ettiği, modülün EEPROM'unun ne yapabileceğini beyan ettiği şey, çünkü probe anında kafesin elindeki tek şey o chip. O stick'te 1000Mbps için kodlanmış. Yani port inband/1000base-x olarak kuruluyor, phylink'in teklif edeceği bir 2500base-x modu yok, ve ethtool speed 2500'ü reddediyor çünkü onu advertise edecek hiçbir şey yok. Host tarafında hiçbir switch bunu aşamaz: ethtool sadece porta var olduğu söylenen modları isteyebilir. Stick'in içindeki shell, modülün PON tarafını konfigüre ediyor, kafesin MAC'e doğru advertise ettiğini değil, ki telnet değişikliğinin buharlaşıp 1Gbps'e geri dönmenin sebebi tam olarak bu.
Bu da iki gerçek seçenek bırakıyor: modülün 2,5G advertise edecek şekilde yeniden kodlanmasını sağlamak, veya onu zaten öyle olan biriyle değiştirmek. Yeniden kodlama yoluna gidersen masada bir yedek bulundur. Host'un güvendiği kimlik sayfasını yeniden yazıyorsun, ve oradaki yanlış bir byte sana kafesin artık hiç tanımadığı bir modül kazandırır. Ayrıca iki hızı kafanda ayrı tut, PON tarafının verdiği ile SFP-to-MAC linkinin negotiate ettiği ayrı rakamlar, o yüzden buna para harcamadan önce gerçekte ne kazanacağını hesapla.
Stick'i suçlamadan önce kutunun hangi device tree'yi boot ettiğini kontrol et. Omnia'daki kafes ekstra bir interface değil: o ve metalik WAN yarısı, tek ve aynı eth2 üzerine iki ön uç, ve herhangi bir anda sadece biri MAC'e bağlı. Hangisi olduğu, kernel'ın boot'ta yüklediği dtb'ye bağlı. Yani /boot/dtb'nin neyi gösterdiğine bak: armada-385-turris-omnia-sfp.dtb değilse, bakır tarafına bakıyorsun demektir ve rakamların hiçbir anlamı yok.
Ayrıca sadece mvneta satırını değil, tam dmesg | grep -i sfp çıktısını paylaş. Kernel'ın probe anında modülden okuduğu şey buradaki ilginç kısım, ve genelde soruyu tek satırda çözer.
dtb zaten SFP olanı, stick'i ilk taktığımda armada-385-turris-omnia-sfp.dtb'yi symlink'ledim, yoksa hiçbir şey up gelmiyordu. Kafes eth2'nin sahibi ve bakır WAN çıkarılmış durumda kalıyor.
dmesg | grep -i sfp, modülün tanındığını ve sonra paylaştığım aynı satırı gösteriyor, eth2 switched to inband/1000base-x link mode. Hiçbir yerde 2500 ile ilgili bir şey yok. ethtool eth2, link up ve trafik geçerken 1000baseX/Full raporluyor, ve ethtool -s eth2 speed 2500 hâlâ Invalid argument ile geri geliyor, yani 2500'ü hiç advertise etmeyecek. Stick'in içinde telnet üzerinden hızı ayarlamak öncekiyle aynı davranıyor, kabul ediyor ve sonra 1Gbps'e geri düşüyor.
Aynı karttan, 1G'de takılı kalan yerine hiç up gelmeyen bir stick'le buraya düşen biri için komşu bir hikaye. Turris OS HBS 6.2.4'teki bir Omnia'da HALNy HL-GSFP: kernel onu tanıdı, port hatta inband/1000base-x'e geçti, ve sonra link düştü ve eth2 hiç up gelmedi.
O bir EEPROM sorunu değil. O stick'in içinde yaşayan koca bir mini OS var, ve host'a cevap verebilecek herhangi bir durumda olmadan önce kendine yaklaşık bir dakika istiyor. Soğuk bir başlangıçta router, o noktadan çok önce kafesi probe edip pes etmiş oluyor, yani port bakır magnetiklere geri dönüyor. U-Boot gecikmesini uzatmak burada çözdü:
Varsayılan 3 saniye; 60'ta kernel kafesi probe etmeye geldiğinde stick up gelmeyi bitirmiş oluyor. Bakır WAN'ı çıkarıp ikinci kez reboot etmek de algılamaya yardımcı oldu. Ve bir stick'in içine bakman gerekirse, üzerindeki seri 38400 8N1.
Teşhise katılıyorum, benzer bir belirtiyle buraya gelecek herkes için bir uyarıyla. Bu karttaki her "2,5G yapmıyor" modül değildir. Generic phylink validate kodunun backport edildiği bir OpenWrt snapshot'ı vardı, ve bu Omnia kafesini doğrudan bozdu: ethtool hâlâ 2500baseX/Full advertise ediyordu ama Link detected: no raporluyordu. O backport'u geri almak portu eski haline döndürdü, ethtool Link detected: yes, 2500Mb/s full duplex okuyordu, ve daha sonraki bir pull request backport'u upstream'de düzeltti.
İpucu ethtool'un desteklenen ve advertise edilen olarak listelediği şeyde. 2500baseX/Full oradaysa ve link basitçe up gelmeyi reddediyorsa, optiğe değil son image yükseltmenden sonraki kernel ve phylink'e bak. Eğer, burada olduğu gibi, port modülün kendisi hakkında beyan ettiği şey bu olduğu için sadece 1000baseX biliyorsa, hiçbir host yazılımı modu var edemez. Bu, EEPROM'daki nominal bit rate byte'ının SFF-8472'nin söylediği tam olarak şeyi yapması.