एउटै रेडियोमा Wi-Fi क्लाइन्ट र हटस्पट: के बिग्रन्छ
Pi को हटस्पट स्वस्थ देखिन सक्छ, तर त्यसको Wi-Fi अपलिंक अड्किन्छ। VPN लाई दोष दिनुअघि स्थापित रेडियोको इन्टरफेस संयोजन र च्यानल सीमा पढ्नुहोस्।
तपाईंको फोन हटस्पटसँग जोडिएको रहन्छ, तर अपलिंकले केही पनि पार गर्दैन। Pi अझै Wi-Fi एसोसिएसन रिपोर्ट गर्छ, पहुँच बिन्दुले अझै beacon पठाउँछ, र हरेक अनुरोध समय सकिएर टुंगिन्छ। एउटै रेडियोले एकैचोटि दुई भूमिका निर्वाह गर्छ, र अर्कोलाई च्यानल चाहिँदा तीमध्ये एउटा जित्छ। VPN छुनुअघि स्थापित ड्राइभर र फर्मवेयरले त्यस्तो भूमिका-जोडी स्वीकार्छन् कि भनेर निश्चित गर्नुहोस्।
लक्षण रेडियोतर्फ संकेत गर्छ, टनेलतर्फ होइन
असफलतालाई क्रममा हेर्नुहोस्, यो राउटिङ बगजस्तो देखिन छाड्छ। क्लाइन्ट हटस्पटमा जोडिन्छ, ठेगाना लिन्छ र एक-दुई पृष्ठ लोड गर्छ। त्यसपछि स्टेशन इन्टरफेसले रोमिङ, कुञ्जी नवीकरण वा सिग्नलको छोटो खस्काइपछि माथिल्लो राउटरसँग फेरि जोडिन्छ। पहुँच बिन्दुले या त आफ्नो beacon पुनः सुरु गर्छ या आफ्ना क्लाइन्टलाई बाटोबिना छोड्छ, र VPN लग फेरि जोडिने प्रयासले भरिन्छ जो कहिल्यै कारण थिएनन्।
दुई इन्टरफेस नामले दुई रेडियो बन्दैन। wlan0 र पहुँच बिन्दुको इन्टरफेसले एउटै यन्त्र, एउटै च्यानल-अवस्था मेसिन र एउटै फर्मवेयर तालिकाकार साझा गर्छन्। कर्नेलले ठ्याक्कै देखाउँछ कि त्यो यन्त्रले कुन भूमिका र च्यानल संयोजन समर्थन गर्छ, त्यसैले त्यो सूची पढ्नुहोस्, दुवै इन्टरफेस माथि आएकाले जोडी चल्छ भनी मान्नुको सट्टा।
केही बदल्नुअघि संयोजन पढ्नुहोस्
वायरलेस स्ट्याकले आफ्नो सम्झौता इन्टरफेस संयोजनको खण्डमा आदेश iw list को आउटपुटमा बताउँछ। प्रत्येक क्रमाङ्कित संयोजनले अनुमत भूमिका-संख्या, कति इन्टरफेस हुन सक्छन् र ती इन्टरफेसले एकैचोटि कति फरक च्यानल लिन सक्छन् सूचीबद्ध गर्छ। एउटै च्यानलमा एउटा स्टेशन र एउटा पहुँच बिन्दु उल्लेख गर्ने संयोजन यो परिनियोजनलाई चाहिने हो।
iw list | sed -n '/valid interface combinations/,/^$/p'
अङ्क पढ्नुहोस्, केवल शब्दको उपस्थिति होइन। ड्राइभरले स्टेशन मोड र पहुँच बिन्दु मोड छुट्टाछुट्टै समर्थन गर्न सक्छ, जबकि दुवैको एकमात्र वैध संयोजनले एउटा मात्र च्यानल, थोरै इन्टरफेस वा हटस्पटले पूरा गर्न नसक्ने beacon अन्तराल अनुमति दिन्छ। केही फर्मवेयरले स्क्यान वा कुञ्जी नवीकरणका बेला एउटा भूमिका पनि खसाल्छन्, जो क्षमता-सीमाभन्दा डगमगाउने अपलिंकजस्तो देखिन्छ। यदि कुनै संयोजनले दुवै भूमिका सूचीबद्ध गर्दैन भने जोडी समर्थित छैन, डेस्कटपको हटस्पट बटनले जे सुझाव दिए पनि।
cfg80211 इन्टरफेस संयोजनको कागजात फिल्ड र beacon बाधाको वर्णन गर्छ। एउटा एडाप्टरका मानले अर्कोबारे केही भन्दैनन्, त्यसैले आउटपुट मेसिनसँगै राख्नुहोस्, सामान्यीकरण गर्नुको सट्टा।
च्यानल र ठेगाना योजनाले बाँकी तय गर्छ
पहुँच बिन्दु त्यस्तो च्यानलमा बस्नुपर्छ जसलाई रेडियोले सेवा दिन सक्छ, र स्टेशनको अपलिंकले माथिल्लो पहुँच बिन्दु पछ्याउनुपर्छ। यी दुई निर्णय नमिल्दा एउटा भूमिका पुनः सुरु गर्नुपर्छ। धेरै एक-रेडियो एडाप्टरमा हटस्पटले त्यसैले स्टेशनको च्यानल प्रतिबिम्बित गर्छ, र माथिल्लो च्यानल परिवर्तनले हटस्पट पनि केही बेर तल झार्छ।
IP पक्षलाई रेडियोबाट अलग योजना गर्नुहोस्। राउटेड हटस्पटले सामान्यतया 192.168.50.0/24 जस्तो निजी सबनेट प्रयोग गर्छ, Pi 192.168.50.1 मा, त्यही सबनेटभित्र DHCP पूल र Pi रिजोल्भर फर्वार्डरका रूपमा। NetworkManager को साझा मोडले त्यो सबनेटका लागि फर्वार्डिङ र ठेगाना अनुवाद सेट गर्छ, तर रेडियो क्षमता थप्दैन र टनेललाई एकमात्र निकास बनाउँदैन। क्लाइन्ट दोस्रो तहमा ब्रिज छन् कि तेस्रो तहमा राउटेड, VPN नीतिबारे बहस गर्नुअघि लेख्नुहोस्।
परीक्षण क्रम जसले रेडियोलाई राउटिङबाट अलग गर्छ
यन्त्रबाट बाहिरतिर काम गर्नुहोस् र असफल हुने पहिलो चरणमा रोकिनुहोस्। यी पढाइहरू चलिरहेको प्रणालीमा सुरक्षित छन् र कुनै कन्फिगरेसन बदल्दैनन्। क्लाइन्ट जोडिएको र अपलिंक तपाईं डिबग गरिरहेको अवस्थामा हुँदा तिनी चलाउनुहोस्।
iw dev
iw dev wlan0 link
nmcli -t -f DEVICE,STATE,CONNECTION device status
ip -br addr show
sysctl net.ipv4.ip_forward
यदि iw dev wlan0 link कुनै एसोसिएसन देखाउँदैन भने रेडियोको समस्या पहिलो हो र टनेल अप्रासंगिक। यदि अपलिंक जोडिएको छ र क्लाइन्टसँग ठेगाना छैन भने जोडाइ र DHCP अधिकार गलत छन्। यदि क्लाइन्टसँग ठेगाना छ तर पहुँच छैन भने फर्वार्डिङ, अनुवाद वा रिजोल्भर डेलिभरी छुटेको छ। हटस्पटको बाटो र अपलिंकको बाटो दुवै चलेपछि मात्र असफल टनेल परीक्षणको अर्को कुरा बन्छ।
एडाप्टर, ड्राइभर र फर्मवेयरलाई स्वीकृत संयोजन र च्यानल नियमसँगै अभिलेख गर्नुहोस्। पछि कर्नेल वा फर्मवेयर अद्यावधिकले समर्थित सूची बदल्न सक्छ, र त्यही टिप्पणीले रहस्यलाई ज्ञात सीमामा बदल्छ।