पहुँच बिंदु किसी संबद्ध या गैर-संबद्ध क्लाइंट की शक्ति कैसे निर्धारित करते हैं?


4

मैं यह पता नहीं लगा सकता हूं कि आस-पास के ग्राहकों की सिग्नल पावर तक पहुंच बिंदु कैसे निर्धारित करते हैं।

मुझे यह जानकारी किसी भी वाईफाई पैकेट ट्यूटोरियल में नहीं मिली है, इसलिए मैं केवल यह मान सकता हूं कि बिजली की जानकारी क्लाइंट से नहीं आ रही है, लेकिन एक्सेस प्वाइंट द्वारा निर्धारित की जाती है।

मुझे पता है कि एयरक्रैक नामक एक एप्लिकेशन है जो इस जानकारी को निर्धारित कर सकता है, लेकिन इससे पहले कि मैं उसमें कूदता हूं और चारों ओर खुदाई करता हूं, मैं चाहता हूं कि बिजली की गणना कैसे की जाए। मेरा Google कौशल इतना बुरा नहीं है , इसलिए मुझे आश्चर्य है कि अब तक मैं इसके बारे में कोई जानकारी नहीं खोद पाया। निश्चित रूप से अगर एयरक्रैक कर सकता है, तो यह जानकारी बाहर है!

मैं उम्मीद कर रहा था कि यहां के उपयोगकर्ता मुझे सही दिशा में इंगित कर सकते हैं?

इनाम के बारे में

मुझे लगता है कि यह एक इनाम का उपयोग करने का प्रयास करने का समय है। अपने उत्तरों में, कृपया सभी लिंक पोस्ट करें जो आप पा सकते हैं कि यह समझने में किसी की सहायता करेगा कि यह पावर डिटेक्शन कैसे काम करता है। एयरक्रैक में इसे कैसे लागू किया जाता है, इस बारे में विशिष्ट जानकारी एकदम सही होगी!

अपडेट करें:

उदाहरण के तौर पर, एयरक्रैक-एनजी सूट का उपयोग करते हुए, ऐसा लगता है कि net_read () में buf [2] से पावर वैल्यू खींची गई है। मेरा मानना ​​है कि यह मूल्य अंततः net_cmd से आता है, जिसके परिणामस्वरूप net_send और net_get () में युग्मित कॉल होते हैं। मुझे लगता है कि net_get () में कॉल के कारण जो भी हेडर जानकारी भेजी जाती है उसमें net_get () पढ़ता है, और यह हेडर इंगित करता है कि कितने डेटा को बफ़र buf [] में कॉपी किया जाना चाहिए।

लेकिन अब मुझे जो नहीं मिल रहा है वह है - यह निश्चित रूप से लगता है कि buf [] net_read_exact () को कॉल से भर जाता है, जो सॉकेट से सिर्फ डेटा पढ़ रहा है। यदि यह मामला है, और यदि बिजली एक ड्राइवर विस्तार है, तो बफर में बिजली का मूल्य क्यों है? यदि वह बफर वास्तव में सॉकेट डेटा द्वारा भरा गया है, तो इसका मतलब यह नहीं है कि बिजली क्लाइंट / स्टेशन द्वारा भेजी जाती है? मेरा मानना ​​है कि एपी / ड्राइवर बिजली की जानकारी की आपूर्ति के प्रभारी हैं, जैसे कि सभी ने कहा है, लेकिन बस यह हिस्सा नहीं मिलता है।


मैंने हमेशा सोचा था कि इसे खोए हुए पैकेजों के प्रतिशत के साथ कुछ करना है, लेकिन हार्डवेयर के माध्यम से ऐसा लगता है ।
एलेक्स

एक एपी को अपना काम करने के लिए सिग्नल स्ट्रेंथ स्तर की आवश्यकता नहीं है।
BatchyX

@BatchyX कुछ APs (जैसे, मिक्रोटिक द्वारा) ग्राहकों को डिस्कनेक्ट करने के लिए कॉन्फ़िगर किया जा सकता है यदि सिग्नल की ताकत निर्दिष्ट सीमा से नीचे आती है। एक ही SSID के साथ कई APs के साथ क्षेत्र को कवर करते समय इसका उपयोग करने का इरादा है, ताकि जो ग्राहक किसी अन्य AP द्वारा बेहतर कवर किए गए स्थान पर चले गए हैं उन्हें एक बेहतर AP पर स्विच करने के लिए मजबूर किया जाए। इस तरह के मजबूर वियोग ग्राहक स्टेशनों के लिए अक्सर एक ही एपी के कनेक्शन को यथासंभव लंबे समय तक रखने की कोशिश करते हैं, लेकिन कम बिट दर पर स्विच करते हैं, जो एक ही चैनल का उपयोग करके अन्य सभी ग्राहकों के लिए सेवा को नीचा दिखाते हैं।
सर्गेई व्लासोव

@SergeyVlasov: आप धीमी दरों का विज्ञापन न करके एक ही चीज हासिल कर सकते हैं।
बैचैक्स

जवाबों:


4

दरअसल, इस जानकारी को निर्धारित करने वाला एप्लिकेशन है airodump-ng, नहीं aircrack-ng । से airodump-ngप्रलेखन , शक्ति स्तर के रूप में निर्धारित कर रहे हैं:

PWR - कार्ड द्वारा सूचित सिग्नल स्तर। इसका संकेत चालक पर निर्भर करता है [...]

ठीक है, देखते हैं कि क्या हम बेहतर कर सकते हैं। airodump-ng.cफ़ाइल के नवीनतम स्रोत कोड के माध्यम से देखते हुए, हम देखते हैं कि dump_add_packet(...)फ़ंक्शन में पावर सेट हो गई है :

/* only update power if packets comes from
 * the AP: either type == mgmt and SA != BSSID,
 * or FromDS == 1 and ToDS == 0 */
if (...)
    ap_cur->power_lvl[ap_cur->power_index] = ri->ri_power;

एब्सट्रैक्शन, स्ट्रक्चर्स और फंक्शन पॉइंटर्स की कई परतों के माध्यम से खुदाई करने के बाद, मैंने पाया कि यह डेटा फ़ाइल linux_read(...)में परिभाषित फ़ंक्शन से भरा है osdep/linux.c। यह वह जगह है जहां संरचना ri_powerमें चर riडेटा से भरा होता है, और वास्तव में यह ड्राइवर विशिष्ट प्रतीत होता है।

अधिकांश चालक रेडियोटैप मानक का पालन करते हैं (जैसा कि नीचे दिए गए पुराने प्रिज्म 54 मानक के विपरीत है), जिसमें एंटीना शक्ति, शोर और क्षीणन के निर्धारण के लिए कई पूर्वनिर्धारित क्षेत्र हैं । इन क्षेत्रों का उपयोग चर airodump-ngमें भरने के लिए सीधे किया जाता है ri_power। इनमें से कुछ पहले से ही डेसीबल या पावर वैल्यू में उपलब्ध हैं।

airodump-ngप्रदर्शित सिग्नल पावर की गणना करने के लिए या तो एंटीना सिग्नल फील्ड (dBm में) या dB एंटीना सिग्नल फील्ड (dB में) का उपयोग करेगा। अन्य क्षेत्रों के लिए भी इसी तरह के कदमों का उपयोग किया जाता है, क्योंकि वे ऊपर से जुड़े रैडियोटैप विनिर्देश में पूर्व निर्धारित हैं। उदाहरण के लिए, ri_powerdB एंटीना सिग्नल फील्ड का उपयोग निम्न प्रकार से किया जा सकता है:

case IEEE80211_RADIOTAP_DB_ANTSIGNAL:
    if(!got_signal) {
        if( *iterator.this_arg < 127 )
            ri->ri_power = *iterator.this_arg;
        else
            ri->ri_power = *iterator.this_arg - 255;

        got_signal = 1;
    }
    break;

जैसा कि पहले उल्लेख किया गया है, कुछ डिवाइस (पुराने) prism54 विनिर्देश (रेडियोटैप के बजाय ) का अनुसरण करते हैं , जो एक निश्चित-लंबाई वाले हेडर का उपयोग करता है। इस स्थिति में, बफर से सीधे RX शक्ति (ध्यान दें कि यह पूर्ण स्रोत कोड नहीं है, बस भरने के लिए लिए गए पथ दिखाता है ri_power):

if (tmpbuf[7] == 0x40)
    ri->ri_power = tmpbuf[0x33];
else
    ri->ri_power = *(unsigned int *)( tmpbuf + 0x5C );

धन्यवाद, मैं एक सूट के रूप में एयरक्रैक का उल्लेख कर रहा था, और विशेष रूप से आवेदन नहीं। मुझे अपने स्रोत कोड के माध्यम से खुदाई करने के बाद अपना प्रश्न अपडेट करना चाहिए था। मैं airserv-ng और airodump-ng का उपयोग कर रहा हूं, और चूंकि यह ओपनरट पर चल रहा है, इसलिए ri_power net_read () में नेटवर्क सेट किया गया है। मैंने आज रेडियोटैप देखा, लेकिन यह मत सोचिए कि डेटा का उपयोग ओपनरैट-विशिष्ट कार्यान्वयन द्वारा किया जाता है। मैं यह पता लगाने के लिए पीछे की ओर ट्रेस कर रहा हूं कि buf [2] सेट किया गया है, क्योंकि यह वह जगह है जहां से पावर वैल्यू आती है। मेरा मानना ​​है कि जादू net_get () में होता है। क्या आप मुझे बताएंगे कि क्या आपको लगता है कि मैं यहां सही रास्ते पर हूं?
दवे

मैं आपके उत्तर को संपादित करने जा रहा था, लेकिन लगा कि मुझे नहीं करना चाहिए, बस के मामले में - मुझे लगता है कि आपका मतलब है कि एरोडम्प-एनजी एंटीना क्षेत्रों का उपयोग करेगा, क्योंकि एयरमोन-एनजी का उपयोग केवल इंटरफ़ेस मोड में मॉनिटर करने के लिए किया जाता है।
दवे

और अब तक वास्तव में अच्छा जवाब देने के लिए धन्यवाद - मुझे नहीं लगता कि मैंने नेट पर अभी तक ऐसा कुछ पाया है। :) मुझे लगता है कि मैं इस को खत्म करने के करीब हूं, लेकिन मुझे थोड़ी सलाह की जरूरत है।
दवे

@ अपनी दूसरी टिप्पणी के बारे में बताएं, अच्छी पकड़। मैंने उत्तर को संपादित किया, लेकिन यह सुपर यूजर है - आप अन्य लोगों के पोस्ट को संपादित करने के लिए स्वागत से अधिक हैं :) के बारे में net_read(), मैंने उस का कुछ उल्लेख देखा, लेकिन यह सोचा कि इसका उपयोग केवल गिरावट के मामलों में किया गया था जहां चालक एक WLAN के रूप में नहीं पता चला है (या रेडियोटैप / प्रिज्म 54 नहीं है)। मैं चारों ओर कुछ और खुदाई करूंगा, लेकिन आप ऐसा कर सकते हैं जैसे आप सही रास्ते पर हैं। उस फ़ंक्शन में एक ब्रेकपॉइंट के airodump-ngतहत आग लगाना gdbऔर सुनिश्चित करना चाहते हैं ताकि यह सुनिश्चित हो सके कि फ़ंक्शन कॉल डीरेफेरेंस है।
ब्रेकथ्रू

दुर्भाग्य से, मैं gdb अभी तक एक्लिप्स के माध्यम से स्थापित नहीं कर पाया हूं, जो ब्रेकप्वाइंट सेट करने में सक्षम हो ... जो कि थोड़ा काम ले सकता है। मैं एक राउटर पर कोड चला रहा हूं और इसे करने के तरीके के बारे में जानकारी पा चुका हूं, लेकिन इसे अभी तक काम नहीं किया है। जब आप कहते हैं कि ड्राइवर को WLAN के रूप में नहीं पाया गया है, तो विशेष रूप से आप कह रहे हैं कि विकल्प मोड / etc / config / wireless में AP पर सेट नहीं है?
डेव

1

मुझे पूरा यकीन नहीं है कि आप क्या पूछ रहे हैं।

एक्सेस पॉइंट में रेडियो रिसीवर होते हैं, स्वाभाविक रूप से, और उन रिसीवर में स्वचालित लाभ के साथ एनालॉग सेक्शन होते हैं, जिससे हार्डवेयर प्राप्त सिग्नल की शक्ति प्राप्त कर सकता है। हार्डवेयर ड्राइवर तब OS- निर्भर तरीके से अन्य सॉफ़्टवेयर को यह जानकारी उपलब्ध कराता है।

यही कारण है कि एयरक्रैक ड्राइवरों और हार्डवेयर के बारे में एक बड़ी बात करता है ।


हां, यह मैं अपने प्रश्न में कहना चाहता हूं - चूंकि यह पैकेट की जानकारी में नहीं है, इसलिए यह हार्डवेयर पर निर्भर होना चाहिए। तो बड़ा सवाल यह है - एक राउटर पर कौन से उपकरण उपलब्ध हैं जो मुझे किसी भी मनमाने ग्राहक के लिए सिग्नल की शक्ति निर्धारित करने की अनुमति देंगे, संबद्ध या नहीं?
डेव

चूंकि यह वाई-फाई मानक का हिस्सा नहीं है, इसलिए कोई मानक उत्तर नहीं है। आपके पास उपलब्ध उपकरण पूरी तरह से विशिष्ट राउटर, ड्राइवर और वाई-फाई रेडियो हार्डवेयर पर निर्भर करते हैं।
पुरानी प्रो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.