Android Ubiquiti Bridge network

Question

Eu tenho a seguinte configuração:

máquina debian com configuração:

iface eth0 inet static
   address 192.168.2.1
   netmask 255.255.255.0

A máquina debian está conectada ao Ubiquiti Rocket 5M no modo AP com bridge transparente no ip 192.168.2.2 gw 192.168.2.1

Rocket está conectado a uma estação Ubiquiti 5M Bullet no ip 192.168.2.2 com GW 192.168.2.1

O Rocket é conectado por micro-usb a um adaptador ethernet para o Android s4 enraizado CyanogenMod em 192.168.2.5.

Ocorre a seguinte coisa estranha:

em 192.168.2.1:         ping -b 192.168.2.255 resulta em uma resposta de 192.168.2.2 e 192.168.2.3

em 192.168.2.5          ping -b 192.168.2.255 resulta em uma resposta de 192.168.2 e .3, mas não de .1. No entanto, ping 192.168.2.2 ou ping 192.168.2.3 resulta em nenhuma resposta. Apenas o ping de transmissão funciona.

1) Why can 192.168.2.5 see .2 and .3 only during broadcast ping?

2) Why can 192.168.2.1 and 192.168.2.5 both see 192.168.2.2 and 192.168.2.3 but 192.168.2.1 and 192.168.2.5 can't see each other?

ps: Eu testei substituindo 192.168.2.5 com um laptop windows e todos os dispositivos podem ver uns aos outros. Também no android para configurar eth0 eu fiz:

ifconfig eth0 192.168.2.5; route add default gw 192.168.2.1 dev eth0; netcfg eth0 up

    

Answer 1

[Resposta provisória, aberta à correção]

Normalmente, dentro de uma sub-rede IP, você envia para um IP e não precisa de um gateway como local. A única "decisão" que está sendo feita é ARP, qual porta é esse IP conhecido por ser / na direção de.

Quando seu cliente android remoto pinga um IP, ele envia um pacote unicast em sua única interface ativa para a ponte, mas a ponte é "burra" e apenas encaminha o tráfego unicast pelo link sem fio que chega ao roteador sem o alvo Mac. O roteador não o enviará de volta, pois isso pode criar uma tempestade de camada 2.

Então você tenta um ping bcast que inerentemente não é unicast e parece que a bridge não irá encaminhá-lo cegamente (provavelmente uma boa idéia em termos de congestionamento) mas sim receber e responder a ele. O fato de você não ver uma resposta de .1 suporta isso.

Pode ser uma boa ideia adicionar um roteador no lado mais distante do link sem fio para dividir os domínios de broadcast. Geralmente, você não deseja rajadas de tráfego excessivas sobre o que geralmente é a parte mais ocupada / mais lenta da rede.