Turris Omnia में ODI DFP-34X-2C2 सिर्फ 1000base-x पर link करता है, ethtool speed 2500 लेने को तैयार नहीं
मैंने अपने Turris Omnia में ISP ONU की जगह एक ODI DFP-34X-2C2 GPON stick लगाई ताकि fibre shelf के किसी और box की बजाय सीधे router में terminate हो। वह हिस्सा काम कर गया: line registered है, traffic चल रहा है, कोई शिकायत नहीं। दिक्कत rate की है। यह कभी 1Gbps से ऊपर नहीं जाता, जबकि यह stick खरीदने की पूरी वजह ही 2.5G थी।
- Turris Omnia, TurrisOS 6.0.4
- ODI DFP-34X-2C2 GPON stick SFP cage में, eth2
- copper WAN unplugged, port cage के पास है
Boot के बाद kernel क्या कहता है, और rate push करने पर क्या होता है:
# dmesg | grep mvneta
eth2: switched to inband/1000base-x link mode
# ethtool -s eth2 speed 2500
Invalid argumentlink up रहते हुए ethtool eth2 module को 1000baseX/Full दिखाता है और उससे ऊपर कुछ नहीं, और ऊपर वाला refusal ethtool का यह बताना है कि speed 2500 advertise नहीं की जा सकती।
अब तक क्या किया:
- stick में telnet करके उसी के shell से rate set की; command ले लेता है और फिर वापस 1Gbps पर आ जाता है
- copper WAN लगाकर और निकालकर, दोनों तरह से reboot किए
- dmesg में MAC को 2.5G offer होने से जुड़ा कुछ भी ढूंढा, कुछ नहीं मिला
क्या यह router है जो port को cap कर रहा है, या module खुद? और host-side ऐसा कुछ है जो इस stick के साथ eth2 को 2500base-x पर ला सके?
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
यहां ceiling module खुद है, Omnia नहीं।
Host जिसके against negotiate करता है वह यह है कि module का EEPROM क्या declare करता है वह क्या कर सकता है, क्योंकि probe time पर cage के पास भरोसा करने के लिए वही chip होती है। उस stick पर यह 1000Mbps के लिए coded है। तो port inband/1000base-x के रूप में set हो जाता है, phylink के पास offer करने के लिए कोई 2500base-x mode नहीं होता, और ethtool speed 2500 को इसलिए मना करता है क्योंकि advertise करने के लिए कुछ है ही नहीं। कोई host-side switch इसके आसपास नहीं जाती: ethtool सिर्फ उन modes को माँग सकता है जो port को बताई गई हैं। stick के अंदर का shell module के PON side को configure करता है, यह नहीं कि cage MAC की तरफ क्या advertise करता है, यही वजह है कि तुम्हारा telnet वाला change गायब हो जाता है और तुम वापस 1Gbps पर आ जाते हो।
इससे दो असली options बचते हैं: module को इस तरह re-code करवाओ कि वह 2.5G advertise करे, या उसे ऐसे module से बदल दो जो पहले से करता हो। अगर re-coding वाला रास्ता लेते हो, तो desk पर एक spare रखो। तुम वह identity page फिर से लिख रहे हो जिस पर host भरोसा करता है, और वहां एक गलत byte ऐसा module दे देता है जिसे cage पहचानना ही बंद कर दे। दोनों rates को भी दिमाग में अलग रखो, PON side क्या deliver करता है और SFP-to-MAC link क्या negotiate करता है, ये अलग-अलग numbers हैं, तो इस पर पैसा खर्च करने से पहले पता कर लो कि असल में मिलेगा क्या।
Stick को दोष देने से पहले चेक करो कि box कौन सा device tree boot करता है। Omnia पर cage कोई अलग interface नहीं है: वह और metallic WAN वाला आधा हिस्सा, दोनों एक ही eth2 के दो front ends हैं, और एक समय में इनमें से सिर्फ एक ही MAC तक connected होता है। कौन सा होगा यह इस पर टिका है कि kernel boot पर कौन सा dtb load करता है। तो देखो /boot/dtb किस तरफ point करता है: अगर वह armada-385-turris-omnia-sfp.dtb नहीं है, तो तुम copper side देख रहे हो और numbers का कोई मतलब नहीं।
पूरा dmesg | grep -i sfp भी post करो, सिर्फ mvneta वाली line नहीं। यहां दिलचस्प हिस्सा यह है कि probe time पर kernel module से क्या पढ़ता है, और अक्सर यही एक line में सवाल तय कर देता है।
dtb पहले से ही SFP वाला है, stick लगाते ही मैंने armada-385-turris-omnia-sfp.dtb symlink किया था, वरना कुछ भी up नहीं होता। Cage eth2 का मालिक है और copper WAN unplugged ही रहता है।
dmesg | grep -i sfp module को identified दिखाता है और फिर वही line जो मैंने post की थी, eth2 switched to inband/1000base-x link mode। 2500 के बारे में कहीं कुछ नहीं। link up रहते और traffic pass होते हुए ethtool eth2, 1000baseX/Full report करता है, और ethtool -s eth2 speed 2500 अब भी Invalid argument के साथ वापस आता है, यानी यह 2500 advertise करेगा ही नहीं। stick के अंदर telnet से rate set करना पहले जैसा ही behave करता है, command accept करता है और फिर वापस 1Gbps पर गिर जाता है।
उसी board से जुड़ी एक और कहानी, अगर कोई यहां ऐसी stick लेकर आए जो 1G पर अटकने की बजाय बिल्कुल up ही न हो। Turris OS HBS 6.2.4 पर Omnia में HALNy HL-GSFP: kernel ने इसे identify किया, port inband/1000base-x पर switch भी हुआ, और फिर link गिर गया और eth2 कभी up नहीं हुआ।
यह EEPROM की problem नहीं है। उस stick के अंदर एक पूरा छोटा सा OS रहता है, और host को जवाब देने की हालत में आने से पहले उसे करीब एक मिनट अपने लिए चाहिए। cold start पर router उस point से बहुत पहले cage को probe करके हार मान चुका होता है, तो सारा मामला वापस copper magnetics पर चला जाता है। U-Boot delay बढ़ाने से यहां ठीक हो गया:
Default 3 seconds है; 60 पर जब तक kernel cage को probe करने की बारी पर आता है तब तक stick up हो चुकी होती है। copper WAN निकालकर दोबारा reboot करने से भी detection में मदद मिली। और अगर कभी stick के अंदर देखना हो, इस पर serial 38400 8N1 है।
Diagnosis से सहमत, पर उन सबके लिए एक caveat जो इसी जैसा symptom लेकर यहां आएं। इस board पर हर "2.5G नहीं होगा" module की गलती नहीं होती। एक OpenWrt snapshot था जिसमें generic phylink validate code backport हुआ, और उसने Omnia की cage को सीधे तोड़ दिया: ethtool अब भी 2500baseX/Full advertise करता रहा पर Link detected: no report करता। वह backport revert करने से port वापस वहीं आ गया जहां था, ethtool अब Link detected: yes, 2500Mb/s full duplex पढ़ रहा था, और बाद की एक pull request ने upstream में वह backport सुलझा दिया।
पहचान इसमें है कि ethtool supported और advertised में क्या list करता है। अगर 2500baseX/Full वहां है और link बस up होने से मना कर रहा है, तो optic की बजाय अपने last image upgrade के बाद kernel और phylink देखो। अगर, जैसा यहां है, port को सिर्फ 1000baseX ही पता है क्योंकि module ने खुद के बारे में यही declare किया था, तो कोई host software वह mode नहीं बना सकता। यह EEPROM में वही nominal bit rate byte है जो ठीक वही कर रहा है जो SFF-8472 कहता है उसे करना चाहिए।