Turris Omnia एक unlocked MA5671A GPON stick को मना कर देता है: Turris OS 5.0.3 पर eth2 कभी up नहीं होता
अपने home rack में ISP terminal को router में सीधे लगी GPON stick से replace करने की कोशिश कर रहा हूँ, ताकि fibre दो box की बजाय एक ही box में उतरे। Stick recognise हो जाती है, और अच्छी खबर यहीं खत्म होती है।
- Turris OS 5.0.3 पर Turris Omnia, stock kernel
- unlocked firmware वाली Huawei MA5671A GPON stick, SGMII 1G पर set
- wall socket से stick में SC/APC pigtail
- eth2 ही SFP port है
Module detect होता है पर interface कभी activate नहीं होता:
# dmesg | grep sfp
SFP module encoding does not support 8b10b nor 64b66bउसके बाद eth2 down ही रहता है, no carrier, counters में कुछ नहीं।
अब तक जो try किया:
- stick को वापस stock firmware पर flash किया, जिससे इसकी जगह EEPROM read error मिलता है
- ethtool -s eth2 1000 autoneg off duplex full से rate force किया, जिसके बाद interface 10 Mbit half duplex पर बैठ जाता है
- same stick को एक MikroTik router में लगाकर देखा, वहाँ port speed हाथ से set करते ही ये up हो जाती है
तो module खुद जिंदा है और fibre वाली side ठीक है। Stick में ऐसा क्या है जिस पर kernel को ऐतराज़ है, और कौन सी GPON sticks Omnia पर actually up होती हैं, refuse होने की बजाय?
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 4
ये host-side problem है, dead module नहीं। इन repurposed GPON sticks का EEPROM ऐसी encoding declare करता है जिसे mainline sfp driver map नहीं करेगा, इसलिए phylink port को up लाने से मना कर देता है, और जो line आपने paste की वो driver का यही कहना है, बस साफ शब्दों में। आपका अपना evidence भी यही इशारा करता है: same stick MikroTik पर port speed हाथ से set करते ही link हो जाती है, तो optics और PON वाली side ठीक हैं।
मेरे लिए जिस चीज़ से फर्क पड़ा वो था एक kernel जो per-module quirks ले जाने के लिए काफी नई हो, Omnia पर इसका मतलब था kernel 5.4 वाली HBD testing branch। चेतावनी: ये आधी-अधूरी जीत है और काफी हद तक इस पर depend करती है कि आपके पास कौन सी stick है। उस kernel पर:
तो अगर आपको Omnia eventually नहीं बल्कि अभी काम करता चाहिए, तो मैं cage में DFP-34G-2C2 ही डालूँगा। Commit करने से पहले अपने box पर test करें, यहाँ results साफ तौर पर stick से stick और यहाँ तक कि same stick की firmware revisions के बीच भी बदलते हैं।
कोई guess करना शुरू करे उससे पहले दो चीज़ें पक्की करने लायक हैं। पहली, वो 5.0.3 किस branch से है और uname क्या kernel report करता है? इन repurposed GPON sticks को जिन per-module SFP quirks की ज़रूरत है वो बाद में आए, तो एक shipped stable kernel और एक testing वाला, बिल्कुल same module के साथ बहुत अलग behave करते हैं।
दूसरी, क्या ONU serial provider की तरफ registered है? जो stick OLT पर कभी authorise नहीं होती वो dead जैसी दिखती रहेगी, और बहुत सारे providers किसी third-party ONU को register करने से सीधे मना कर देते हैं।
और जब इसे plug करते हैं, क्या port कभी inband/1000base-x में switch होता है, या log ठीक उसी encoding message पर रुक जाता है?
Stable branch, 5.0.3 के लिए stock kernel, ऊपर कुछ भी custom नहीं। Provider वाली side यहाँ problem नहीं है, वही fibre है और stick में registered serial है।
Log encoding वाली line पर रुक जाता है, port कभी inband/1000base-x में flip नहीं होता। मुझे क्या मिलता है ये firmware पर depend करता है। Unlocked वाली के साथ:
साथ में module का report किया हुआ एक transmit fault। Stock firmware के साथ तो इतनी दूर भी नहीं पहुँचता:
और जैसा कहा, rate force करने से बिल्कुल कुछ नहीं होता: ethtool -s eth2 1000 autoneg off duplex full के बाद भी interface 10 Mbit half duplex पर ही बैठा रहता है।
Same router पर rule out करने लायक एक और failure mode, क्योंकि ये similar दिखती है पर encoding से इसका कोई लेना-देना नहीं। Turris OS HBS 6.2.4 पर एक HALNy HL-GSFP detect हुई, port inband/1000base-x में switch भी हो गया, फिर link drop हो गया और eth2 down रह गया।
वजह: वो stick अपने आप में एक छोटा computer है। अपनी firmware लाने में लगभग एक मिनट लगाती है, और उसके बाद ही cage को कोई sensible जवाब देती है। Cold boot में router उस बिंदु से काफी पहले cage में झाँक लेता है, तो detection fail हो जाता है और box चुपचाप copper WAN magnetics पर fall back कर जाता है। Boot delay बढ़ाने से ठीक हो गया:
Default तीन की जगह साठ second, और same stick वाले किसी और ने भी इसे confirm किया। दो और चीज़ों से मदद मिली: copper WAN cable unplug करके एक बार फिर reboot करना, और module में खुद login करके देखना कि वो किस state में है, serial पर 38400 8N1 पर या SSH से 192.168.77.154 port 22666 पर।