Сеть Android Ubiquiti Bridge

Question

У меня есть следующие настройки:

Машина Debian с конфигурацией:

iface eth0 inet static
   address 192.168.2.1
   netmask 255.255.255.0

Машина Debian подключена к Ubiquiti Rocket 5M в режиме AP с прозрачным мостом на IP 192.168.2.2 gw 192.168.2.1

Ракета подключена к станции Ubiquiti 5M Bullet по IP 192.168.2.2 с GW 192.168.2.1

Ракета подключена через микро-USB к сетевому адаптеру на рутированном андроиде Samsung s4 под управлением Cyanogenmod на 192.168.2.5.

Происходит следующая странная вещь:

на 192.168.2.1:ping -b 192.168.2.255 приводит к ответу от 192.168.2.2 и 192.168.2.3

на 192.168.2.5 ping -b 192.168.2.255 дает ответ от 192.168.2 и .3, но не .1. Однако ping 192.168.2.2 или ping 192.168.2.3 дает ответа. Работает только широковещательный пинг.

1) Почему 192.168.2.5 могут видеть .2 и .3 только во время широковещательного пинга?

2) Почему 192.168.2.1 и 192.168.2.5 могут одновременно видеть 192.168.2.2 и 192.168.2.3, но 192.168.2.1 и 192.168.2.5 не могут видеть друг друга?

PS: я протестировал замену 192.168.2.5 на ноутбук с Windows, и все устройства могут видеть друг друга. Также на андроиде для настройки eth0 я сделал:

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

Answer 1

[Предварительный ответ, открытый для исправления]

Обычно в пределах одной IP-подсети вы отправляете IP-адрес и не нуждаетесь в шлюзе в качестве его локального. Единственное принимаемое "решение" - это ARP, для которого этот IP-порт, как известно, находится в / в направлении.

Когда ваш удаленный Android-клиент пропингует IP-адрес, он отправляет одноадресный пакет на свой единственный активный интерфейс к мосту, но мост "тупой" и просто перенаправляет одноадресный трафик по беспроводному каналу, который попадает на маршрутизатор, на котором отсутствует целевой Mac. Маршрутизатор не отправит его обратно, поскольку это может создать шторм второго уровня.

Затем вы пробуете пинг bcast, который по своей сути не является одноадресным, и кажется, что мост не будет слепо пересылать его (вероятно, хорошая идея с точки зрения перегрузки), а вместо этого получит и ответит на него. Тот факт, что вы не видите ответ от .1, подтверждает это.

Это может быть хорошей идеей добавить маршрутизатор на удаленной стороне беспроводной линии связи для разделения широковещательных доменов, обычно вы не хотите, чтобы чрезмерные всплески трафика проходили над тем, что часто является самой загруженной / самой медленной частью сети.