Turris Omnia, Luleey LL-XS2510 XPON stick को 1000baseX पर pin कर देता है और ethtool कभी 2.5G offer नहीं करता
मेरा fibre WAN एक Turris Omnia में आता है और एक hop कम करने के लिए मैं ISP वाले box से हटकर XPON stick पर आया। stick एक 2.5G part है, Omnia का cage 2.5G करता है, और फिर भी सब कुछ 1G पर ही टिक जाता है।
- Turris Omnia, Turris OS 7.0.2 HBS, kernel 5.15.148
- Luleey LL-XS2510 XPON SFP, RTL960x based, DFP-34X-2C2 family
- link eth2 पर terminate होता है, service खुद ठीक काम करती है
mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Fullethtool eth2 कभी कोई 2500baseX mode list ही नहीं करता, supported और advertised sets 1000baseX/Full पर ही रुक जाते हैं, तो चुनने के लिए मेरे पास पहले तो कुछ है ही नहीं।
जो try किया:
- stick लगी रहने पर reboot, और copper WAN unplug करके cold start
- module के अंदर
flash set LAN_SDS_MODE 6, फिर दोनों तरफ का reboot, कोई बदलाव नहीं - ऐसा कुछ ढूंढने के लिए ethtool output line by line पढ़ा जो rate force कर दे
क्या यह module अपनी 2.5G capability छुपा रहा है, या host ही mode offer करने से मना कर रहा है? और क्या कोई ऐसा रास्ता है जो stick को दोबारा लिखने पर खत्म न हो?
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 6
पूरा
ethtool eth2output और dmesg से sfp वाली lines post करें, सिर्फ link message नहीं। दिलचस्प हिस्सा यह है कि host ने module को किस capability का मान लिया: अगर phylink ने inband/1000base-x पर settle किया, तो यह module के अपने EEPROM से लिया, और router पर जो भी configure करें, driver ने जो mode कभी देखा ही नहीं वह जुड़ने वाला नहीं।Omnia पर cage 2.5G तक ठीक है, तो hardware यहां आपको सीमित नहीं कर रहा। यह भी बताएं कि host पर हाल में कुछ बदला तो नहीं, image upgrade समेत।
dmesg, हर boot पर identical:
ethtool eth2supported और advertised दोनों sets में 1000baseX/Full देता है, और Link detected: yes, 1000Mb/s full duplex पर। output में कहीं भी 1G से ऊपर कुछ नहीं दिखता।stick पर
flash set LAN_SDS_MODE 6चल तो जाता है और module के reboot में भी बना रहता है, पर host side इस पर बिल्कुल react नहीं करता: वही message, वही 1G। जबसे stick लगी है router इसी image पर है, तो वापस जाने के लिए कुछ नहीं है।यह host का module की बात पर आंख मूंदकर भरोसा करना है। sfp driver EEPROM पढ़ता है, एक part देखता है जो 1000base-x declare करता है, और eth2 को inband/1000base-x पर pin कर देता है; फिर phylink के पास offer करने को कोई 2.5G mode नहीं बचता, जो ठीक वही ethtool output है जो आपने post किया। RTL960x के अंदर LAN_SDS_MODE से जो आप set करते हैं वह module के अपने serdes को छूता है, router को यह क्या advertise करता है उसे नहीं, तो यह negotiated mode बदलने वाला कभी था ही नहीं।
बाहर निकलने के दो रास्ते हैं, और मुझे बस यही दो पता हैं। या तो module का EEPROM फिर से लिखें ताकि वह 2.5G advertise करे, जो DFP-34X-2C3 पर known trick है, पर आपका 2C2 है और मैं वही offsets मान कर नहीं चलूंगा। या host को patch करें: sfp.c में इस module के लिए एक quirk जोड़ें और उसके साथ एक kernel चलाएं, stick को बिना छुए।
कुल मिलाकर मैं host को patch करूंगा। एक ऐसी stick में bricked EEPROM जिसे आप आसानी से reflash नहीं कर सकते, उस kernel से कहीं बुरी शाम है जिसे आप वापस roll back कर सकते हैं।
module के बजाय host को शक के घेरे में रखने की एक और वजह। OpenWrt snapshots पर एक दौर था जब backported generic phylink validate code ने Omnia के SFP cage को सीधा तोड़ दिया था: ethtool फिर भी 2500baseX/Full advertise करता था और port बस Link detected: no report करता था। यह साफ-साफ उस kernel commit तक bisect हुआ, backport हटाने से link वापस 2500Mb/s full duplex पर आ गया, और एक follow-up fix ने इसे बंद कर दिया।
आपसे अलग symptom, वही सबक। mvneta और phylink वाले boards पर host software तय करता है कि cage को क्या करने दिया जाए, और अपना खुद का बनाना शुरू करने से पहले एक known-good image को fallback के तौर पर रखना फायदेमंद रहता है।
अगर Turris OS पर custom kernel वाला रास्ता लेते हैं, तो पहले एक snapshot लें:
schnapps create "Before new kernel", फिरopkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipkऔर reboot करें। अगर kernel गड़बड़ करे तो router को अलग करने के बजाय आप वापस roll back कर सकते हैं।दूसरी चीज़ जिसका ज़िक्र बाद तक कोई नहीं करता: 2.5 Gbps का link 2.5 Gbps का traffic नहीं होता। Omnia में लगा Armada CPU इसे एक ही queue पर push नहीं करेगा, तो wire पर number के throughput बनने से पहले packet steering और RPS tuning का plan रखें।
किसी अलग stick के साथ यह पढ़ने वाले किसी और के लिए एक असंबंधित trap: कुछ PON modules अपना खुद का operating system चलाते हैं और जवाब देने में लगभग एक मिनट लेते हैं, तो cold boot पर router cage को बहुत जल्दी probe कर लेता है और copper magnetics पर fall back हो जाता है। U-Boot में
fw_setenv bootdelay 60इसका सामान्य इलाज है। आपका case नहीं, क्योंकि आपका module फौरन detect हो जाता है।loop बंद करते हैं: patched host जीता। modified sfp.c के साथ एक kernel बनाया, पहले schnapps snapshot लिया,
--force-reinstallसे ipk install किया और reboot किया।ethtool eth2अब 2500baseX/Full list करता है और link 2.5 Gbps पर आ जाता है।आखिर में module के साथ कुछ नहीं किया गया। LAN_SDS_MODE जहां था वहीं रहा और irrelevant निकला, तो मुझे कभी EEPROM छूना ही नहीं पड़ा।
Throughput के लिए दूसरी सलाह भी चाहिए थी। reboot के फौरन बाद box एक ही queue पर link rate से काफी नीचे बैठा रहा; packet steering tune करने के बाद WAN आखिरकार वही करता है जिसके लिए stick खरीदी गई थी।