Por que o ping de um roteador local retorna “Destination Host Unreachable”?

Question

Eu tenho dois roteadores de tomate. Uma é conectada sem fio com a outra.

Eu tenho um novo servidor na rede. Está executando o Ubuntu Server 11.04.

Eles estão todos conectados assim:

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 não enfrenta problemas.

Eu tenho uma sessão SSH ativa para B de A e não há nenhuma perda.

B, o novo servidor ocasionalmente não pode fazer o ping T2 e, portanto, não pode se conectar à Internet. No entanto, A sempre pode contatar B e B pode fazer ping A e B Quando a rede é perdida, B ainda pode pingar T1, mas não T2, mas ao mesmo tempo que B perdeu a conexão para T2, A ainda pode pingar T2.

Alguma idéia sobre o que isso poderia ser? Não há nada que dê pistas em qualquer um dos logs do roteador ou do servidor linux.

Uma coisa interessante é que eu configurei um ping entre B e T2. T2 tem o endereço IP 192.68.1.1

Aqui está o que estou vendo:

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=

E ele roda para ser acessível e não.

Então, eu acho que você poderia dizer que a pergunta é: por que o roteador está respondendo que não pode ser acessado?

    

Answer 1

“Host de destino inacessível” no mesmo segmento de rede indica que a resolução do endereço IP para um endereço MAC usando ARP falhou.

Como os links sem fio presumem que há apenas um dispositivo no lado do cliente, as pontes (repetidores também, btw) não funcionam via Wi-Fi, a menos que sejam usados meios especiais, como relayd ou WDS. Normalmente, você nem consegue interligar interfaces do cliente sem fio a interfaces Ethernet. Há apenas uma exceção: um driver sem fio especial da Broadcom que realiza “MAC Masquerading” de tipos.

O

WDS, por outro lado, deve ser suportado no ponto de acesso e no cliente: Nesta configuração, um pacote sem fio transporta 4 endereços MAC em vez de apenas dois. Além dos endereços imediatos de remetente e destinatário, há também o endereço de origem e de destino. Dessa forma, a verdadeira ponte Ethernet é possível.

O WDS tem um problema: normalmente, ele limita a criptografia ao WPA, que é inseguro. A Atheros desenvolveu uma extensão proprietária para o WPS que permite o WPA2. Como tal, há apenas uma solução para Ethernet estável ponte sobre WiFi: Usando dispositivos Atheros em ambas as extremidades.

STP não tem nada a ver com isso.

O wiki OpenWrt também tem um artigo muito bom sobre modo de cliente sem fio .

    

Answer 2

Como é uma ponte sem fio, suspeito de uma conexão esquisita. STP não seria a causa real disso. Sua finalidade é impedir loops em ponte para que sua rede não fique saturada de pacotes em loop e se torne inutilizável. Desligá-lo geralmente é uma má idéia, já que agora não vai protegê-lo dessa situação.

se a porta estiver "pulando", o STP bloqueará a interface enquanto ele reelita uma ponte raiz. Ele também bloqueará a interface se detectar um loop de ponte. Eu suspeito que há mais na sua topologia do que você está mostrando no seu diagrama. O novo servidor tem outra interface?