Raspberry pi không thể ping bộ định tuyến hoặc địa chỉ internet qua cầu wifi


10

Gần đây tôi đã thiết lập bộ định tuyến WNR2000v3 chạy DD-WRT như một loại cầu lặp sử dụng phiên bản "Atheros" của hướng dẫn này (chúng tôi sẽ gọi đây là 'bộ định tuyến 2'), đang lặp lại bộ định tuyến Medialink Wireless-N (chúng tôi ' sẽ gọi đây là 'bộ định tuyến 1'). Điều này hoạt động hoàn hảo cho điện thoại Android và máy tính Windows của tôi cả qua wifi và khi được kết nối trực tiếp qua ethernet, nhưng khi tôi cắm Raspberry pi, khi chạy Raspbian (wheezy) hoặc Raspbmc, tôi không thể nhận được bất kỳ kết nối nào ngoài mạng cục bộ.

Raspberry pi có thể ping (và được ping bởi) bất kỳ thiết bị nào khác trên mạng con cục bộ, bao gồm 'bộ định tuyến 2', được kết nối trực tiếp và có thể nhận DHCP từ bộ định tuyến 1, nhưng khi tôi thử và ping router 1, tôi nhận được "Destination Host Unreachable" và nếu tôi thử ping bất cứ thứ gì trên internet như google.com, superuser.com, tôi cũng nhận được "Destination Host Unreachable".

Đây là một máy tính khác trên mạng:

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

Đây là bộ định tuyến 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 là địa chỉ của Raspberry Pi:

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)

Đây là bảng định tuyến:

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

Và đây là yêu cầu DHCP:

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.

Mọi thứ khác đều hoạt động tốt, nhưng tôi đã thử rapsberry pi này với hai hình ảnh khác nhau (Raspbmc và raspbian) và hai pis mâm xôi khác nhau và không có cấu hình nào hoạt động. Hình ảnh raspbian đã được kiểm tra là hoạt động khi kết nối trực tiếp với Bộ định tuyến 1. Vấn đề này có vẻ rất giống với câu hỏi chưa được trả lời này từ hai năm trước, ngoại trừ trong trường hợp đó có vẻ như anh ta đang sử dụng wifi cho thiết bị không kết nối được và ông thực sự đã nhận được một số kết nối không liên tục. Ngoài ra phản hồi ping có từ bộ định tuyến, không phải thiết bị. Điều gì có thể gây ra vấn đề này?

Chỉnh sửa: Tôi cũng cần lưu ý rằng hai mâm xôi khác nhau có địa chỉ IP khác nhau, một trong số đó bị ràng buộc IP-MAC và không có xung đột IP nào tôi thấy trong bảng DHCP, nhưng cùng một vấn đề.

Cập nhật : Tôi đã xác định một điều có khả năng thú vị, đó là khi tắt chức năng Nhân bản địa chỉ MAC, cầu lặp lại ngừng hoạt động - điều duy nhất có thể ping raspberry pi là bộ định tuyến 2 và không có kết nối (hoặc truy cập vào bộ định tuyến 1) từ mọi thứ chỉ được kết nối với bộ định tuyến 2 - bao gồm cả máy Windows. Tuy nhiên, địa chỉ mac đang được nhân bản là cùng một địa chỉ mac thực sự được sử dụng bởi các giao diện của bộ định tuyến 2 (theo trang "trạng thái"). Tôi có nguồn điện đã đạp cả bộ định tuyến 1 và bộ định tuyến 2 hai lần và điều đó không có gì khác biệt. Tôi không hiểu tại sao nhân bản địa chỉ MAC có liên quan ở đây. Khi địa chỉ MAC được nhân bản, khi tôi ssh vào chính bộ định tuyến, bộ định tuyến có thể ping Raspberry pi, nhưng không phải bộ định tuyến 1.

Một điều nhỏ nữa là khi nhân bản Địa chỉ MAC được bật và tôi thực sự có thể ping các máy tính khác trên mạng, arping trả về cùng một địa chỉ mac cho mọi thiết bị phản hồi ping.

Cập nhật 2: Từ việc kiểm tra các giá trị nhật ký hệ thống, tôi thấy rằng có thông báo lỗi này liên quan đến địa chỉ MAC:

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

Rõ ràng đây là một vấn đề được biết đến mà mọi người đang giải quyết bằng cách nhân bản địa chỉ MAC. Tôi không chắc chắn chính xác tại sao các địa chỉ MAC ngẫu nhiên là một vấn đề và những hậu quả khác mà nhân bản địa chỉ MAC đang gặp phải.


Nếu bạn có máy khách không dây đến bộ định tuyến 2, bạn có thể ping đến / từ quả mâm xôi đến máy khách không dây không?
MariusMatutiae

Đúng. Bạn có thể ping quả mâm xôi từ máy khách không dây trên bộ định tuyến 1 hoặc bộ định tuyến 2.
Paul

Trên bộ định tuyến 1, bạn có bật DHCP hoặc dnsmasq không?
MariusMatutiae

DHCP có, tôi không biết về dnsmasq. Không có cài đặt nào cho nó trong webUI trên bộ định tuyến 1.
Paul

Đây là lý do tại sao NAT hút. Bạn thực sự nên sử dụng WDS thay thế. (Mọi thiết bị dường như có cùng một địa chỉ MAC vì NAT đang được sử dụng để thuyết phục điểm truy cập mà nó đang nói với khách hàng của nó.)
David Schwartz

Câu trả lời:


1

+1 cho mô tả vấn đề chi tiết.

Như tôi đã đề xuất về luồng bạn đã mở trong raspberry pi , bạn có thể kiểm tra xem bộ định tuyến chính của bạn có được liệt kê trong bảng arp của RP không: arp -nhoặc nếu bạn đã cài đặt iproute2 : ip neigh.

Nếu cần, bạn có thể thêm bộ định tuyến vào bộ đệm arp bằng lệnh này: arp -s <ROUTER_IP> <ROUTER_MAC>và xem liệu bạn có còn gặp sự cố không

Bạn cũng có thể kiểm tra xem RPi của bạn có gửi yêu cầu ARP như mong đợi hay không bằng cách đánh hơi tất cả các gói ARP. Trên RPi của bạn, hãy chạy:tcpdump arp

Bạn cũng có thể chạy cùng một lệnh trên bộ lặp DD-WRT và trên bất kỳ máy chủ nào khác được kết nối trên bộ định tuyến 1. Khi các yêu cầu ARP được phát, bạn sẽ thấy chúng trên lan của mình.


1

Tôi gặp vấn đề tương tự khi cài đặt Wifi Repeater mới. Giải pháp bị xâm phạm được đặt IP tĩnh cho Raspberry Pi.


0

Đây là một mẹo khó để chẩn đoán, vì tất nhiên hệ thống của bạn có vẻ được cấu hình đúng. Vì vậy, thay vì đi qua một danh sách dài các tùy chọn kiểm tra, tôi sẽ cung cấp cho bạn một số ý tưởng để thử nghiệm.

Một điều tôi sẽ thử là thay đổi cổng mặc định sang bộ định tuyến 2, thay vì bộ định tuyến 1.

Một điều nữa là buộc ping liên kết với giao diện eth0:

 ping -I 192.168.0.107 192.168.0.1
 ping -I eth0          192.168.0.1

Hai lệnh này hơi khác nhau, cả hai nên được thử. Hy vọng, họ sẽ đưa ra các kết quả đầu ra khác nhau, đó sẽ là dấu hiệu của một lỗi.

Sau đó, tôi sẽ kiểm tra / etc / mạng / giao diện: nó có chứa một vài dòng như

  auto eth0
  iface eth0 inet dhcp

Sau đó, tôi sẽ thử khởi động lại giao diện:

  ifdown eth0
  ifup eth0

và sau đó lại tỉnh táo.

Khi tất cả được nói và thực hiện, người ta nên nhớ rằng nó không cần phải là một vấn đề phần mềm. Nếu bạn vào trang Web này, bạn có thể đọc kinh nghiệm sau:

Tôi đã đặt mua một quả mâm xôi pi khác và chỉ cần chụp lại thẻ sd, khởi động trong đó và internet hoạt động tốt. Tôi lấy thẻ sd ra và đặt nó vào pi mâm xôi cũ và nối cùng dây cáp và dây ethernet chính xác nhưng nó vẫn không hoạt động ....

Ngoài ra, bạn nên nhớ rằng có khả năng xảy ra sự cố với cáp. Cáp không hoạt động / không làm việc đối tượng. Một vấn đề trong RX hoặc TX có thể khiến nhiều khung hình bị giảm, chất lượng tín hiệu không đáng kể, v.v. Trong trường hợp này, các giao thức như TCP hoạt động tốt hơn ICMP hoặc UDP vì chúng truyền lại các gói mà mục tiêu không nhận được, cho bạn ấn tượng sai về kết nối hoạt động đúng. Ấn tượng sai này kéo dài cho đến khi bạn đo tốc độ kết nối, tất nhiên.


Không có sự khác biệt giữa phản ứng với hai lệnh ping. Tương tự những gì tôi đã dán ở trên. Tệp / etc / network / interface trống trong trường hợp raspbmc, trong trường hợp raspbian có "auto lo" "iface lo inet loopback" "iface eth0 inet dhcp". Khởi động lại giao diện không có gì trong cả hai trường hợp. Đây chắc chắn không phải là vấn đề với pi mâm xôi, bởi vì tôi có hai quả mâm xôi khác nhau, cả hai đều không hoạt động khi cắm vào bộ định tuyến 2 nhưng cả hai đều hoạt động khi cắm trực tiếp vào bộ định tuyến 1.
Paul

-1

Vấn đề tương tự tôi đã có một thời gian trước đây. Giải pháp của tôi là chỉnh sửa /etc/resolv.conftập tin bằng cách thêm nameserver 8.8.4.4và khởi động lại giao diện bằng cách sử dụng /etc/init.d/networking restart. Nó làm việc cho tôi.


OP đề cập đến Destination Host Unreachablelỗi, có vẻ như đề xuất DNS hoạt động tốt. Một lỗi DNS sẽ mang lại một cái gì đó như cannot resolvehoặc Unknown host.
jornane
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.