એક રેડિયો પર Wi-Fi ક્લાઇન્ટ અને હોટસ્પોટ: શું તૂટે છે

તમારો ફોન હોટસ્પોટ સાથે જોડાયેલો રહે છે, જ્યારે અપલિંક કંઈ પસાર કરતું નથી. 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 સત્તા ખોટા છે. જો ક્લાઇન્ટ પાસે સરનામું હોય પણ પહોંચ ન હોય, ફોરવર્ડિંગ, અનુવાદ કે રિઝોલ્વર વિતરણ ખૂટે છે. જ્યારે હોટસ્પોટનો માર્ગ અને અપલિંકનો માર્ગ બંને કામ કરે ત્યારે જ નિષ્ફળ ટનલ પરીક્ષણની આગળની વસ્તુ બને છે.

એડેપ્ટર, ડ્રાઇવર અને ફર્મવેરને સ્વીકૃત સંયોજન અને ચેનલ નિયમ સાથે નોંધો. પછીનું કર્નલ કે ફર્મવેર અપડેટ સમર્થિત યાદી બદલી શકે છે, અને તે જ નોંધ રહસ્યને જાણીતી મર્યાદામાં બદલે છે.