Nenhuma rota entre clientes até o ping de um deles (e não de outro)

Question

3 itens de hardware envolvidos:

1. Roteador Netgear R7000 com DD-WRT v24-sp2 (08/15/14) kongac (24865M) - é banda dupla.
2. Servidor de impressão baseado em Raspberry Pi modelo B, com Raspbian (Debian para Raspberry). Conectado a WiFi (banda 2,4 GHz) com adaptador USB ALFA AWUS050H, impressora HP LaserJet 3055 conectada via USB. Executando o CUPS 1.5.3 e o SANE. Nada mais além disso, e simples instalação Raspbian.
3. Desktop executando o Windows 8.1 com o Asus PCE68U. Conectado a 5GHz WiFi no mesmo roteador. Na verdade, aqui todos os meus outros dispositivos, como laptops, telefones, etc., se comportam da mesma forma.

Problema: Não consigo entrar em contato com o servidor de impressão a partir da área de trabalho, a menos que eu faça ping no desktop do servidor de impressão. Eu faço isso fazendo login no roteador via ssh, e depois via outra sessão ssh para o servidor de impressão. Quando eu faço ping no desktop, os primeiros 4-5 pacotes são perdidos, e então ele começa a funcionar. Ele funciona por alguns minutos depois que eu paro de fazer ping. Em seguida, ele pára novamente e não consigo mais me conectar ao servidor de impressão.

A página CUPS não está respondendo, o ping para o servidor de impressão fornece

Reply from 192.168.xxx.xxx: Destination host unreachable.

Às vezes (principalmente quando tento conectar-me à página do CUPS ou imprimo enquanto faço ping):

Request timed out.

O roteador pode ser pingado / contatado por ambos, desktop e servidor de impressão, o tempo todo.

O Dmesg no servidor recebe muito:

wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by [router's 2.4GHz MAC]

mas não regularmente. Às vezes é a cada 4 segundos, às vezes é tranquilo por 10 minutos. Nenhuma outra coisa na dmesg durante esse período.

Pergunta: O que pode estar errado? Como isso parece meio estranho, e não parece ser consistente (às vezes funciona meia hora após o ping, e às vezes pára depois de 10 segundos), eu ficaria grato por qualquer conselho sobre como investigar o problema mais profundamente.

Notas:

Ambos os clientes, servidor de impressão e desktop, obtêm suas configurações de rede do mesmo servidor DHCP (concessões estáticas fora do intervalo de DHCP). É dnsmasq rodando no servidor. Ambos obtêm o IP na mesma sub-rede, com uma máscara de rede de 255.255.255.0.

    

Answer 1

Isso geralmente indica uma incompatibilidade de máscara de sub-rede.

Para que o PC envie pacotes para a impressora, ele precisa do endereço MAC da impressora. Isso é feito com uma solicitação arp who has ip xx.xx.xx.xx

Isso é enviado para o endereço de broadcast da rede local. Se a impressora tiver uma máscara de sub-rede diferente, ela poderá não ver a solicitação se a máscara de sub-rede do PC não incluir o IP da impressora e, portanto, o computador não receber resposta e não obtiver o MAC da impressora. .

Quando a impressora insere o PC, envia a solicitação arp e, como sua máscara de sub-rede inclui o PC, o PC responde com seu MAC. No entanto, neste ponto, o PC adiciona o endereço MAC da impressora à sua tabela arp e, assim, pode se comunicar com o PC.

Depois de um tempo, a entrada ARP no PC expirará e não poderá se comunicar com a impressora até que as comunicações recebidas voltem a ocorrer.

    

Answer 2

Parece que você tem algum isolamento da camada 2 causado por haver várias mídias da camada 1: um quadro sem IP enviado para o MAC ff: ff: ff: ff: ff: ff como é feito em uma solicitação ARP não parece estar abrangendo ambas as bandas WiFi.

Não está claro como os dois hosts podem trocar dados; é meu palpite que os sistemas linux estão honrando um redirecionamento de algum tipo que a caixa do Windows está ignorando. tcpdump -env no servidor de impressão pode revelar algumas dicas. arp -a em todos os sistemas antes de os comms estarem funcionando e durante o tempo também pode ser útil. Uma entrada aparece para cada host, em cada host? Apenas para completar, pode ser possível configurar estatisticamente a tabela ARP como um kludge, mas eu não recomendo gastar muito tempo aqui.

Além disso, talvez fazer ping 255.255.255.255 do sistema Windows possa dar início às comunicações, nesse ínterim, já que isso ocorreria na camada IP que parece estar funcionando, e echo-reply pela impressora instale temporariamente qualquer entrada ARP necessária.

Minhas sugestões gerais para remediar o problema incluem examinar e alternar as opções de ponte de interface em seu roteador, bem como ativar a funcionalidade proxy arp , que pode servir para mascarar adequadamente a fragmentação de rede que suspeito existir entre as duas bandas. proxy arp teria seu roteador respondendo a solicitações de who-has para o IP da sua impressora, portanto, sua caixa do Windows sabe que precisa enviar o tráfego da impressora para o roteador. O roteador tem que ligar a comunicação entre as duas bandas, independentemente ...