रास्पबेरी पाई वाईफ़ाई पुल पर राउटर या इंटरनेट पते को पिंग नहीं कर सकती है


10

मैंने हाल ही में इस ट्यूटोरियल के "एथरोस" संस्करण (हम इसे 'राउटर 2' कहेंगे) का उपयोग करके डीडीआर-डब्ल्यूआरटी के एक प्रकार के रूप में डीडीआर-डब्ल्यूआरटी चलाने वाले एक डब्ल्यूएनआर 220 वी 3 राउटर की स्थापना की है , जो एक मेडियलिंक वायरलेस-एन राउटर (हम) को दोहरा रहा है। इसे 'राउटर 1' कहेंगे)। यह पूरी तरह से मेरे एंड्रॉइड फोन और विंडोज कंप्यूटर के लिए पूरी तरह से वाईफाई पर काम करता है और जब सीधे ईथरनेट के माध्यम से जुड़ा होता है, लेकिन जब मैं अपने रास्पबेरी पाई में प्लग करता हूं, या तो जब रास्पियन (घरघराहट) या रास्पबैम चलाते हैं, तो मुझे स्थानीय नेटवर्क से बाहर कोई कनेक्शन नहीं मिल सकता है।

रास्पबेरी पाई 'राउटर 2' सहित स्थानीय सबनेट पर किसी भी अन्य डिवाइस को पिंग (और पिंग किया जा सकता है), जिसमें वह सीधे जुड़ा हुआ है, और यह राउटर 1 से डीएचसीपी प्राप्त करने में सक्षम है, लेकिन जब मैं कोशिश नहीं करता पिंग राउटर 1, मुझे "डेस्टिनेशन होस्ट अनरेचेबल" मिलता है, और अगर मैं google.com, superuser.com जैसे इंटरनेट पर कुछ भी पिंग करने की कोशिश करता हूं, तो मुझे "डेस्टिनेशन होस्ट अनरीचेबल" मिलता है।

यहाँ नेटवर्क पर एक और कंप्यूटर है:

ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_req=1 ttl=127 time=38.7 ms
64 bytes from 192.168.0.100: icmp_req=2 ttl=127 time=1.67 ms
64 bytes from 192.168.0.100: icmp_req=3 ttl=127 time=1.73 ms
64 bytes from 192.168.0.100: icmp_req=4 ttl=127 time=3.56 ms
--- 192.168.0.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 1.672/11.418/38.705/15.772 ms

यहां राउटर 1:

ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.107 icmp_seq=1 Destination Host Unreachable
From 192.168.0.107 icmp_seq=2 Destination Host Unreachable
From 192.168.0.107 icmp_seq=3 Destination Host Unreachable
From 192.168.0.107 icmp_seq=4 Destination Host Unreachable
From 192.168.0.107 icmp_seq=5 Destination Host Unreachable
From 192.168.0.107 icmp_seq=6 Destination Host Unreachable
--- 192.168.0.1 ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7007ms
pipe 3

192.168.0.107 रास्पबेरी पाई का पता है:

ifconfig
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:db:c9
          inet addr:192.168.0.107  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3753 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1262 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:595127 (581.1 KiB)  TX bytes:112407 (109.7 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:285 errors:0 dropped:0 overruns:0 frame:0
          TX packets:285 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:27703 (27.0 KiB)  TX bytes:27703 (27.0 KiB)

यहाँ रूटिंग टेबल है:

sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

और यहाँ डीएचसीपी अनुरोध है:

sudo dhclient -v eth0
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/xx:xx:xx:xx:db:c9
Sending on   LPF/eth0/xx:xx:xx:xx:db:c9
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
RTNETLINK answers: File exists
bound to 192.168.0.107 -- renewal in 274691 seconds.

बाकी सब कुछ ठीक काम करता है, लेकिन मैंने इस रैप्सबेरी पाई को दो अलग-अलग छवियों (रास्पबम और रास्पबियन) और दो अलग-अलग रास्पबेरी पाई और बिना किसी कॉन्फ़िगरेशन के काम करने की कोशिश की है। रास्पियन छवि को राउटर 1 से सीधे जुड़ा होने पर काम करने के रूप में परीक्षण किया गया है। यह समस्या दो साल पहले के इस अनुत्तरित प्रश्न के समान लगती है , सिवाय इसके कि ऐसा लगता है कि वह उस डिवाइस के लिए वाईफाई का उपयोग कर रहा था जो कनेक्ट करने में विफल रहा, और वह वास्तव में कुछ रुक-रुक कर संपर्क कर रहा था। इसके अलावा पिंग की प्रतिक्रिया राउटर से थी, डिवाइस से नहीं। इस समस्या का कारण क्या हो सकता है?

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

अद्यतन : मैंने एक संभावित दिलचस्प बात निर्धारित की है, जो यह है कि जब मैक एड्रेस क्लोनिंग बंद हो जाती है, तो पुनरावर्तक पुल कार्य करना बंद कर देता है - रास्पबेरी पाई को पिंग करने वाली एकमात्र चीज राउटर 2 है, और इसमें कोई कनेक्टिविटी नहीं है (या राउटर तक पहुंच नहीं है) 1) केवल राउटर 2 से जुड़ी किसी भी चीज से - विंडोज मशीन सहित। हालाँकि, जो मैक एड्रेस क्लोन किया जा रहा है, वही मैक एड्रेस है जो वास्तव में वैसे भी राउटर 2 के इंटरफेस द्वारा उपयोग किया जाता है ("स्थिति" पृष्ठ के अनुसार)। मेरे पास राउटर 1 और राउटर 2 दोनों चक्रों में पावर है और इससे कोई फर्क नहीं पड़ता। मुझे समझ नहीं आ रहा है कि मैक एड्रेस क्लोनिंग यहां क्यों प्रासंगिक है। मैक एड्रेस क्लोनिंग के साथ, जब मैं राउटर में स्वयं ssh करता हूं, तो राउटरबेरी पाई को राउटर पिंग कर सकता है, लेकिन राउटर 1 नहीं।

एक अन्य छोटी बात यह है कि जब मैक एड्रेस क्लोनिंग होती है और मैं वास्तव में नेटवर्क पर अन्य कंप्यूटरों को पिंग कर सकता हूं, तो आर्किंग उसी डिवाइस के लिए मैक पते को रिटर्न करता है जो पिंग्स का जवाब दे रहा है।

अद्यतन 2: syslog मानों की जाँच करने से, मैंने पाया कि मैक पते से संबंधित यह त्रुटि संदेश था:

Jan  1 00:00:08 Router 2 kern.err kernel: [    6.770000] ath: eeprom contains invalid mac address: ff:ff:ff:ff:ff:ff
Jan  1 00:00:08 Router 2 kern.err kernel: [    6.780000] ath: random mac address will be used: fa:55:da:33:19:a9

जाहिरा तौर पर यह एक ज्ञात समस्या है जो लोग मैक एड्रेस क्लोनिंग का उपयोग करके हल कर रहे हैं। मुझे बिल्कुल यकीन नहीं है कि यादृच्छिक मैक पते एक समस्या क्यों हैं, और मैक पते क्लोनिंग के अन्य परिणाम क्या हैं।


यदि आपके पास राउटर 2 के लिए वायरलेस क्लाइंट है, तो क्या आप रास्पबेरी से वायरलेस क्लाइंट के लिए / से पिंग कर सकते हैं?
MariusMatutiae

हाँ। आप या तो रूटर 1 पर या रूटर 2. एक वायरलेस ग्राहक से रास्पबेरी पिंग कर सकते हैं
पॉल

राउटर 1 पर, क्या आपके पास डीएचसीपी या डीएनएसमास्क सक्षम है?
MariusMatutiae

डीएचसीपी हाँ, मैं dnsmasq के बारे में नहीं जानता। राउटर 1 पर वेबयूआई में इसके लिए कोई सेटिंग नहीं है।
पॉल

यही कारण है कि NAT चूसता है। आपको इसके बजाय वास्तव में WDS का उपयोग करना चाहिए। (प्रत्येक डिवाइस में वही मैक पता प्रतीत होता है क्योंकि NAT का उपयोग उस बिंदु तक पहुंचाने के लिए किया जा रहा है जिसे वह अपने क्लाइंट से बात कर रहा है।)
डेविड श्वार्ट्ज

जवाबों:


1

विस्तृत समस्या वर्णन के लिए +1।

जैसा कि मैंने आपको रास्पबेरी पाई में खोले गए धागे पर सुझाव दिया था , आप जांच सकते हैं कि क्या आपका मुख्य राउटर आरपीआई की आर्क टेबल में सूचीबद्ध है: arp -nया यदि आपके पास iproute2 स्थापित है ip neigh:।

यदि आवश्यक हो तो आप इस कमांड के साथ आरपी कैश में राउटर जोड़ सकते हैं: arp -s <ROUTER_IP> <ROUTER_MAC>और देखें कि क्या आपके पास अभी भी समस्या है

आप यह भी जांच सकते हैं कि क्या आपका आरपीआई एआरपी के सभी पैकेटों को सूँघकर अपेक्षा के अनुरूप एआरपी अनुरोध भेजता है। अपनी आरपीआई पर, दौड़ें:tcpdump arp

आप डीडी-डब्ल्यूआरटी रिपीटर और राउटर पर जुड़े किसी अन्य होस्ट पर भी एक ही कमांड चला सकते हैं। एआरपी अनुरोध प्रसारित होते ही आपको उन्हें अपने लान में देखना चाहिए।


1

नया वाईफाई रिपीटर लगाते समय मेरे पास एक ही मुद्दा था। समझौता समाधान रास्पबेरी पाई के लिए स्थिर आईपी सेट है।


0

यह निदान करने के लिए एक मुश्किल है, क्योंकि निश्चित रूप से आपका सिस्टम सही तरीके से कॉन्फ़िगर किया गया लगता है। इसलिए, चेक विकल्पों की एक लंबी सूची के माध्यम से जाने के बजाय, मैं आपको चीजों के परीक्षण के लिए कुछ विचार दूंगा।

एक चीज जो मैं करने की कोशिश करूंगा वह है राउटर 1 के बजाय डिफॉल्ट गेटवे को राउटर 2 में बदलना।

इंटरफ़ेस eth0 को बाँधने के लिए पिंग को मजबूर करने के लिए एक और चीज़ है:

 ping -I 192.168.0.107 192.168.0.1
 ping -I eth0          192.168.0.1

ये दोनों आदेश थोड़े अलग हैं, दोनों को आजमाना चाहिए। उम्मीद है, वे अलग-अलग आउटपुट देंगे, जो एक गलती का संकेत होगा।

फिर मैं / etc / network / interfaces की जाँच करूँगा: क्या इसमें कुछ लाइने हैं

  auto eth0
  iface eth0 inet dhcp

फिर मैं इंटरफ़ेस को फिर से शुरू करने की कोशिश करूंगा:

  ifdown eth0
  ifup eth0

और फिर फिर से धीरज रखो।

जब सब कहा और किया जाता है, तो एक को ध्यान में रखना चाहिए कि यह एक सॉफ्टवेयर समस्या नहीं है। यदि आप इस वेब पेज पर जाते हैं तो आप निम्नलिखित अनुभव पढ़ सकते हैं:

मैंने एक और रास्पबेरी पाई का आदेश दिया था और एसडी कार्ड को फिर से कॉपी किया था, उस एक में बूट किया था, और इंटरनेट ने ठीक काम किया। मैंने एसडी कार्ड निकाला और पुरानी रास्पबेरी पी में डाल दिया और उसी सटीक केबल और ईथरनेट कॉर्ड को झुका दिया, लेकिन यह अभी भी काम नहीं किया ...।

इसके अलावा, आपको यह ध्यान रखना चाहिए कि केबल के साथ समस्या होने की संभावना है। केबल काम नहीं कर रहे / काम नहीं कर रहे हैं। RX या TX में एक समस्या के कारण कई फ्रेम गिर सकते हैं, सिग्नल की गुणवत्ता मामूली हो सकती है, और इसी तरह। इस मामले में, टीसीपी जैसे प्रोटोकॉल आईसीएमपी या यूडीपी की तुलना में बेहतर व्यवहार करते हैं क्योंकि वे पैकेट को फिर से प्रसारित करते हैं जो लक्ष्य द्वारा प्राप्त नहीं किए गए हैं, जिससे आपको ठीक से काम करने वाले कनेक्शन का गलत प्रभाव पड़ता है। यह गलत प्रभाव तब तक रहता है जब तक कि आप कनेक्शन की गति को माप नहीं लेते।


दो पिंग कमांड के जवाब में कोई अंतर नहीं है। वही जो मैंने ऊपर चिपकाया था। / Etc / नेटवर्क / इंटरफेस फाइल raspbmc केस में खाली है, raspbian मामले में "auto lo" "iface lo inet loopback" "iface eth0 inet dhcp" है। इंटरफ़ेस को पुनरारंभ करना किसी भी मामले में कुछ भी नहीं करता है। यह निश्चित रूप से रास्पबेरी पी के साथ कोई समस्या नहीं है, क्योंकि मेरे पास दो अलग-अलग रास्पबेरी पाई हैं, जिनमें से न तो काम करते हैं जब राउटर 2 में प्लग किया जाता है, लेकिन दोनों राउटर में सीधे प्लग करते समय काम करते हैं 1.
पॉल

-1

इसी तरह की समस्या मुझे कुछ समय पहले हुई थी। मेरा समाधान /etc/resolv.confफ़ाइल को जोड़कर संपादित कर रहा था nameserver 8.8.4.4, और उपयोग करके इंटरफेस को पुनरारंभ करके /etc/init.d/networking restart। इससे मेरा काम बनता है।


ओपी Destination Host Unreachableत्रुटि के रूप में उल्लेख करता है, जो सुझाव देता है कि DNS ठीक काम करता है। कोई DNS त्रुटि की तरह कुछ सामने आए गए हैं cannot resolveया Unknown host
jornane
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.