Turris Omnia में ALLNET ALL4781-VDSL2-SFP stick हर 30 से 120 minutes में resync होती है
आख़िरकार मैंने अपनी VDSL2 line ISP box से हटाकर Turris Omnia पर ही terminate कर दी, ज्यादातर इसलिए ताकि PPPoE bridge mode वाली किसी दूसरी device की बजाय router पर ही चले। Setup वाला हिस्सा सुहाना था: stick को cage में बिठाओ और WAN interface खुद module पर चला जाता है, metallic socket तस्वीर से बाहर हो जाता है, internal link अपने आप up हो जाता है। Green LED DSL sync track करती है, orange वाली router की तरफ वाली side।
- Turris Omnia, modem-facing interface पर PPPoE configured
- SFP cage में ALLNET ALL4781-VDSL2-SFP modem stick
- VDSL2 line जो पूरे 100 Mbit down पर train होती है
option ifname 'eth1.7', क्योंकि मेरी line को VLAN 7 tag चाहिए
दस मिनट की configuration plus एक reboot, और ये line rate पर up हो गया। Problem ये है कि ये टिकता नहीं। आधे घंटे से दो घंटे के बीच कहीं DSL desync हो जाती है, और वापस आने में दो से तीन minute लगते हैं:
LCP terminated by peer
Modem hangup
eth1: link is downमैंने अब तक जो किया:
- stick reseat किया और router reboot किया, बाद का interval same रहा
- DSL patch cable बदला और stick को line के पहले socket पर move किया
- copper WAN cable unplug कर दी ताकि interface पर कुछ भी fight न कर सके
इनमें से किसी से pattern नहीं बदला। ये stick है, मेरी line है, या Omnia जिस तरह cage drive करता है वो बात है? क्या कोई इस modem stick को बिना resyncs के long term चला रहा है?
Comments 4
ये जानी-पहचानी bad combination है: firmware 3.4, ऐसी line पर जो actually 100 Mbit कर सकती है। Stick वैसे टूटी हुई नहीं है - एक और Omnia जिसे मैं जानता हूँ, same module को VDSL2 profile 17a line पर काफी समय से चला रहा है और एक बार भी resync नहीं हुआ, यही वजह है कि इस चीज़ पर reports इस तरह बँट जाती हैं। कौन सी line किस group में गिरेगी ये कोई datasheet पहले से नहीं बताता।
दो बातें, इसी क्रम में।
पहली, firmware के बारे में vendor के पास जाएँ। उन्होंने माना है कि 3.4 वहाँ गड़बड़ करता है जहाँ line 100 Mbit तक पहुँच सकती है, और नई build कुछ खर्च नहीं करती, तो उसे न चलाने की कोई वजह नहीं।
दूसरी, बाद में LEDs देखते रहें। Green पहले जाना मतलब DSL, orange मतलब cage वाली side। अगर नई build पर भी green गिरती रहती है, तो firmware आपकी line पर पूरी कहानी नहीं थी।
Outcome के बारे में सच बताऊँ, क्योंकि आप वैसे भी पूछेंगे: मुझे कम से कम एक ऐसी line पता है जहाँ update से कुछ नहीं बदला और resyncs same तीस मिनट से दो घंटे पर चलते रहे। इस stick के साथ stability build जितना ही line characteristics पर depend करती लगती है, तो firmware को सबसे सस्ता try समझें, guaranteed fix नहीं। अगर उसके बाद भी drop होता रहे, तो unglamorous fallback यही है कि आगे फिर से एक modem लगा दें और PPPoE session router पर
eth1.7के ऊपर ही रखें - आपका मौजूदा config भी बना रहेगा और sync के पीछे भागना बंद हो जाएगा।Stick पर कौन सी firmware है? circulation में एक से ज्यादा build हैं और वो fast lines पर same तरीके से behave नहीं करतीं, तो पहले यही पक्का करना है।
Router को दोष देने से पहले दो और बातें। जिस पल ये drop होता है, क्या green LED बुझ जाती है, या वो जली रहती है जबकि orange वाली हिलती है? इससे पता चलेगा कि DSL sync खो गई है या सिर्फ Omnia की तरफ वाला link। और क्या drop से पहले के मिनटों में stick से खुद कुछ काम की चीज़ निकाल सकते हैं - attainable rate, SNR margin, error counters? जो sync अपने आखिरी second तक rate बनाए रखता है वो बिल्कुल अलग कहानी है उससे जो पहले धीरे-धीरे नीचे रेंगता है।
Stick पर firmware 3.4 है।
मैं box के पास बैठा और लगातार तीन drops पकड़े: green पहले बुझती है, orange पूरे समय जली रहती है। मतलब router की तरफ वाला link कभी हिलता नहीं, DSL sync ही मरती है और PPPoE session उसके पीछे-पीछे गिरता है। इससे ये भी साफ होता है कि
LCP terminated by peerएक cause नहीं बल्कि consequence है, जिसका मुझे शक तो था पर proof नहीं था।Counters पर मेरे पास आपको देने को कुछ नहीं। Attainable rate, margin, error counts - मुझे कहीं भी stick इनमें से कुछ expose करती नहीं दिखती, और router मुझे बस sync rate दिखाता है, और कुछ नहीं। वो figure गायब होने के आखिरी second तक line rate पर बना रहता है, तो पहले कुछ रेंगता नहीं, बस चला जाता है। जबसे ISP modem line के आगे था तबसे profile भी नहीं बदला।
अलग stick, same cage, testing करते समय जानने लायक।
मेरे पास एक Omnia में HALNy HL-GSFP GPON stick थी: kernel ने बिना किसी शिकायत के इसे पकड़ लिया, port inband/1000base-x में flip हो गया, और फिर eth2 वहाँ हमेशा के लिए down बैठा रहा। ये timing की बात थी, compatibility की नहीं। Module का अपना एक छोटा OS है और उसे किसी भी चीज़ का जवाब देने से पहले लगभग एक मिनट चाहिए, जबकि cage को power-on के कुछ ही second बाद probe कर लिया जाता है। Probe को कोई मिलता नहीं, router चुपचाप metallic WAN पर बना रहता है और SFP interface कभी जागता नहीं। u-boot में
fw_setenv bootdelay 60ने इसे हमेशा के लिए ठीक कर दिया।इससे session के बीच में होने वाला resync explain नहीं होगा, तो ये आपका जवाब नहीं है। पर अगर कभी drop के बाद reboot करें और खुद को वापस copper पर पाएँ, तो यही mechanism है जिसे आप देख रहे हैं, कोई dead module नहीं।