Warum gibt das Pingen eines lokalen Routers "Zielhost nicht erreichbar"zurück?

Question

Warum gibt das Pingen eines lokalen Routers "Zielhost nicht erreichbar"zurück?

Ich habe zwei Tomatenrouter. Einer wird drahtlos mit dem anderen überbrückt.

Ich habe einen neuen Server im Netzwerk. Es läuft Ubuntu Server 11.04.

Sie sind alle so verbunden:

A - Linux PC
B - New Server
C - Mac Mini
D - Macbook
T1 - Tomato 1
T2 - Tomato 2

They are connected like so:

A -----+-T1  ==== wireless bridge ==== T2----- ADSL modem
       |                               | C & D Connected wirelessly to T2
B -----+

A, C & D haben keine Probleme.

Ich habe eine aktive SSH-Sitzung von A nach B und es gibt keinen Verlust.

B, der neue Server kann gelegentlich T2 nicht pingen und kann daher keine Verbindung zum Internet herstellen. Allerdings kann EIN immer kontakt B und B können A und B pingen Wenn das Netzwerk verloren geht, kann B immer noch T1 pingen, aber noch nicht T2, während B die Verbindung zu T2 verloren hat, kann A immer noch T2 pingen.

, Irgendwelche Ideen, was das sein könnte? es gibt nichts, was Hinweise in den Protokollen auf dem Router oder dem Linux-Server gibt.

Eine Sache, die interessant ist, ist, dass ich einen Ping zwischen B und T2 eingerichtet habe. T2 hat die IP-Adresse 192.68.1.1

Hier ist, was ich sehe:

From 192.168.1.1 icmp_seq=26 Destination Host Unreachable
From 192.168.1.1 icmp_seq=27 Destination Host Unreachable
From 192.168.1.1 icmp_seq=28 Destination Host Unreachable
From 192.168.1.1 icmp_seq=29 Destination Host Unreachable
From 192.168.1.1 icmp_seq=30 Destination Host Unreachable
From 192.168.1.1 icmp_seq=31 Destination Host Unreachable
From 192.168.1.1 icmp_seq=33 Destination Host Unreachable
From 192.168.1.1 icmp_seq=34 Destination Host Unreachable
From 192.168.1.1 icmp_seq=35 Destination Host Unreachable
64 bytes from 192.168.1.1: icmp_req=36 ttl=63 time=3.40 ms
64 bytes from 192.168.1.1: icmp_req=37 ttl=63 time=5.70 ms
64 bytes from 192.168.1.1: icmp_req=38 ttl=63 time=2.25 ms
64 bytes from 192.168.1.1: icmp_req=39 ttl=63 time=2.18 ms
64 bytes from 192.168.1.1: icmp_req=40 ttl=63 time=3.12 ms
64 bytes from 192.168.1.1: icmp_req=41 ttl=63 time=2.15 ms
64 bytes from 192.168.1.1: icmp_req=42 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_req=43 ttl=63 time=

Und es Zyklen erreichbar sein und nicht.

Also, ich denke, Sie könnten sagen, die Frage ist, warum antwortet der Router, dass er nicht erreicht werden kann?

5

wireless-networking linux networking tomato

Author: Matt H, 2011-08-05

Source

2 answers

score 2 · Answer 1

"Zielhost Nicht erreichbar" im selben Netzwerksegment zeigt an, dass das Auflösen der IP-Adresse in eine MAC-Adresse mit ARP fehlgeschlagen ist.

Da drahtlose Verbindungen davon ausgehen, dass nur ein Gerät am Clientende vorhanden ist, können Bridges (auch Repeater) nicht über WLAN arbeiten, es sei denn, Sie verwenden spezielle Mittel wie relayd oder WDS. Normalerweise können Sie nicht einmal drahtlose Clientschnittstellen mit Ethernet-Schnittstellen überbrücken. Es gibt nur eine Ausnahme: Einen speziellen Broadcom Wireless-Treiber, der führt "MAC Masquerading" von Arten.

WDS hingegen muss sowohl am Access Point als auch am Client unterstützt werden: In dieser Konfiguration trägt ein WLAN-Paket 4 MAC-Adressen statt nur zwei. Neben den unmittelbaren Absender-und Empfängeradressen gibt es auch die Quell-und Zieladresse. Auf diese Weise ist eine echte Ethernet-Überbrückung möglich.

WDS hat jedoch ein Problem: Normalerweise beschränkt es die Verschlüsselung auf WPA, was unsicher ist. Wir haben ein proprietäre Erweiterung zu WPS, die WPA2 ermöglicht. Daher gibt es nur eine Lösung für eine stabile Ethernet-Überbrückung über WLAN: Die Verwendung von Atheros-Geräten an beiden Enden.

STP hat damit nichts zu tun.

OpenWrt-wiki hat auch einen sehr guten Artikel über client-Modus, wireless - .

score 0 · Answer 2

Da es sich um eine drahtlose Brücke handelt, würde ich eine flockige Verbindung vermuten. STP wäre nicht die wahre Ursache dafür. Ziel ist es, Überbrückungsschleifen zu verhindern, damit Ihr Netzwerk nicht mit Schleifpaketen gesättigt und unbrauchbar wird. Das Ausschalten ist normalerweise eine schlechte Idee, da es Sie jetzt nicht vor dieser Situation schützt.

Wenn der Port "hüpft", blockiert STP die Schnittstelle, während er eine Root-Bridge neu wählt. Es blockiert auch die Schnittstelle, wenn es eine Brückenschleife erkennt. Ich vermuten Sie, dass Ihre Topologie mehr enthält, als Sie in Ihrem Diagramm anzeigen. Hat der neue Server eine andere Schnittstelle?