GPON stick DFP-34X-2C2 dmesg में दसियों second बाद दिखता है, फिर 1G पर link हो जाता है
मैं हमारे WAN को terminate करने वाले Linux box पर operator ONT की जगह एक SFP GPON stick लगा रहा हूं, और यह stick किसी transceiver जैसा बर्ताव बिल्कुल नहीं करता। इसे लगाओ तो cage आधे मिनट या उससे ज़्यादा देर चुप रहता है, इतनी देर कि मैंने दो बार मान लिया कि module dead है, और जब kernel को आखिरकार पता चलता है तो link gigabit speed पर settle हो जाता है, जिससे पूरी exercise का मतलब ही खत्म हो जाता है।
Bench:
- Linux router box, SFP cage kernel SFP layer से चलता है, mainline kernel
- ODI DFP-34X-2C2 GPON stick
- दूसरे sample के तौर पर एक Huawei MA5671a stick
- एक आम 1G fibre module जो उसी cage में तुरंत दिख जाता है, यानी cage खुद ठीक है
$ 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अब तक जो try किया:
- stick को reseat करके इंटरफ़ेस को छेड़े बिना कई मिनट छोड़ा, और यह wait हर बार होता है, सिर्फ पहली बार insert करने पर नहीं
- detect होने के बाद interface को bounce किया, negotiated mode में कोई फ़र्क़ नहीं पड़ा
- MA5671a में भी वही धीमा appearance दिखा, यानी यह एक खराब sample की बात नहीं है
क्या Linux host पर GPON sticks ऐसे ही बर्ताव करते हैं, या मेरी तरफ़ से कुछ गलत हो रहा है? insertion और detection के बीच असल में हो क्या रहा है?
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
अंदाज़े लगाने से पहले दो चीज़ें clear कर लेते हैं। पहली, insertion से आगे का पूरा untrimmed dmesg post करो, दो लाइन के grep के बजाय। तुमने कहा cage kernel SFP layer के पीछे है और मुझे इस पर शक नहीं, लेकिन जो लाइनें तुमने filter कर दीं वही बताती हैं कि module कितनी बार probe हुआ, बीच में क्या-क्या give up हुआ और हर attempt में कितना समय लगा।
दूसरी, एक बार stick आखिरकार up हो जाए तो interface खुद क्या claim करता है कि वह क्या कर सकता है, और advertised modes में कहीं 2500baseX दिखता है क्या? और PON side पर ISP तुम्हें कौन सी speed दे रहा है, क्योंकि अगर plan gigabit का है तो जो link मिल रहा है वही सही है और ठीक करने को कुछ नहीं है।
दुर्भाग्य से यह expected behaviour है, और गलती तुम्हारे host की नहीं है।
GPON stick में EEPROM chip वाला transceiver नहीं होता। यह असल में अपने SoC पर चलने वाला एक छोटा सा Linux computer है, जिसे SFP shell में ठूंस दिया गया है, और तुम्हारा host I2C पर जो EEPROM पढ़ता है वह उसी सिस्टम का emulate किया हुआ है। जब तक stick का अपना firmware इतना boot नहीं हो जाता कि वे pages serve कर सके, तब तक bus पर कोई जवाब नहीं आता, यही वजह है कि एक normal module तुरंत जवाब देता है जबकि यहां तुम कई second बैठे रहते हो। तुम्हारी module line से पहले की वह खामोशी दरअसल boot है।
तुम्हारी problem का दूसरा हिस्सा यह है कि emulated pages जो advertise करते हैं वह अक्सर बस गलत होता है। इन sticks पर host-side interface 2500BASE-X है, और EEPROM कुछ और ही कहता है, इसलिए SFP layer उसे जस का तस मान लेती है और gigabit mode पर settle हो जाती है। दोनों हिस्सों को kernel में per-module quirks से handle किया जाता है, कोई configure करने वाली चीज़ नहीं, और OEM DFP-34X-2C2 को ठीक इसी वजह से उन quirks में से एक मिला हुआ है।
तुम्हारा sample उस quirk पर पड़ता है या नहीं यह इस पर निर्भर करता है कि वह कौन से vendor और part strings report करता है, और ये rebadge के हिसाब से अलग-अलग होती हैं, इसलिए यह मान लेने से पहले कि तुम cover हो, अपनी dmesg line में जो print होता है उसकी तुलना quirk जिससे match करता है उससे करो।
यह समझने के लिए कि quirk वाला तरीका आखिर क्यों चाहिए: SFF-8472 यह मान कर चलता है कि memory device passive है और सामान्य I2C timings में जवाब दे देगा। इसमें कहीं यह सोचा ही नहीं गया कि किसी device को बात करने से पहले आधे मिनट के boot की ज़रूरत पड़ सकती है, इसलिए standard को follow करने वाले host को पूरा हक़ है कि वह module को छोड़ दे या जो mode bits आखिर में पढ़े उन्हीं पर भरोसा कर ले।
ऊपर वाला rebadge का मुद्दा असली trap है। matching vendor और part strings पर होती है, इसलिए वही physical stick अलग नाम से बिकने पर quirk से पूरी तरह छूट जाता है और तुम बिना किसी साफ़ वजह के फिर gigabit link पर आ जाते हो। और ऐसा कुछ भी मत बनाओ जो इस पर निर्भर हो कि module boot के फ़ौरन बाद present हो, क्योंकि यह race यहां जीती नहीं जा सकती।
यह उम्मीद रखना कि stick vendors अपने EEPROM contents ठीक कर देंगे, यह भी बहुत आशावादी सोच है। जब ये problems उठाई गईं, तो बड़े-बड़े ISPs को भी उनसे कुछ खास जवाब नहीं मिला।
यही तरह की problem consumer routers पर भी दिखती है, तो कम से कम तुम अकेले नहीं हो। Archer BE800, BE900 और GE800 के मालिकों को 10G SFP+ combo port में stick लगाने पर जिस 2.5 के लिए पैसे दिए उसकी जगह 1 Gbit/s मिलता है, और TP-Link की अपनी लिस्ट में उन ports में काम करने वाली जो sticks report हुई हैं वे हैं ODI DFP-34X-2C2, Huawei MA5671A और Nokia G-010SA, यानी आखिर में सबके हाथ वही छोटी सी list लगती है।
पहली सलाह थी firmware plus reseating, और reseating वाली बात बकवास नहीं है, जो module पूरी तरह click करके नहीं बैठा हो वह सच में fall back कर जाता है। Beta builds में आखिरकार port configuration मिल गया, हर model के लिए अलग:
इनमें से किसी एक build के साथ SFP port mode telnet से set होने लगता है, पहले interface को drop करना पड़ता है,
ip link set eth1 downवगैरह।फिर भी यह workaround है, fix नहीं, ध्यान रहे। एक साल बाद भी वही शिकायतें आ रही थीं, और सिर्फ sticks को लेकर नहीं: किसी के पास उस port में JT-COM का JT-AOC-SFP-15 AOC था, किसी और के पास Ampcom का passive 10G SFP+ DAC, और दोनों ही 1 Gbit/s पर अटके रहे।
इससे पहले कि कोई stick को NIC पर ले जाने का सुझाव दे, एक और failure mode जान लेना ज़रूरी है। x86 पर OpenWrt 19.07 में Intel X520 और kmod-ixgbe के साथ, MA5671a को unsupported SFP कहकर सीधे refuse कर दिया जाता है। आम module config files में allow_unsupported_sfp सेट करने का वहां कोई असर नहीं होता, यह parameter module load करते वक़्त ही देना पड़ता है:
और उसके बावजूद driver इसे reject ही करता है, क्योंकि stick का EEPROM शुरू से ही किसी normal transceiver का description नहीं देता और यह flag उसे छुपा नहीं सकती। अगर तुम आखिर में NIC पर ही जाते हो, तो पहले port को किसी आम 1000BASE-T, LX या SX module से prove करो, वरना तुम card और stick दोनों को एक साथ debug कर रहे होगे।
बस ध्यान रहे इन दोनों को मिलाना मत। allow_unsupported_sfp ixgbe के अंदर रहता है और यह तय करता है कि वह driver किसी दिए गए optic को चलाने को तैयार है या नहीं, जो यहां हो रहे decision से बिल्कुल अलग बात है। लंबा wait और गलत mode generic SFP layer से आते हैं जो emulated pages पढ़कर नतीजा phylink तक पहुंचाती है, और वहीं पर per-module quirks बैठे होते हैं।
जिस board में असली SFP cage होता है वहां ixgbe वाला flag होता ही नहीं और वह fix भी नहीं है, और X520 पर quirk list भी तुम्हें नहीं बचाएगी। ऊपर से symptom एक जैसा दिखता है, नीचे layer अलग होती है, और इन दोनों को गड्डमड्ड करना ही वह वजह है जिससे लोग बेकार में drivers rebuild करते रह जाते हैं।
इसी दौरान एक और boundary खींच लेना ठीक रहेगा: host को stick दिखना और OLT का उसे accept करना, ये दो अलग-अलग problems हैं, और दूसरी वाली कहीं ज़्यादा खराब हो सकती है।
एक अच्छी तरह documented case है जिसमें एक Xicom DFP-34X-2C2 पर ZTE ZXHN F601 से setmac और OMCI queries से copy की गई identity load की गई - GPON serial, PLOAM password, LOID, hardware serial और firmware string, सब कुछ। stick O5 state तक range होकर बस वहीं बैठ जाता है, कोई ONU ID assign नहीं होता और कोई traffic नहीं चलता, क्योंकि O5 तक पहुंचना सिर्फ इतना बताता है कि ranging काम कर गई, जबकि MIB upload को अब भी उस ONT profile से match करना होता है जो OLT को चाहिए। उस thread में किसी ने भी fix नहीं निकाला।
इसलिए जब locally 2500BASE-X मिल भी जाए, तो यह मत मान लेना कि मुश्किल हिस्सा पीछे छूट गया है। जहां operator किसी service profile को एक ख़ास ONT model से बांध देता है, वहां शायद copied fields का कोई भी सेट third-party stick को accept नहीं करा पाएगा।