Клиенты не могут подключаться друг к другу по WLAN. Нет ответа на ARP-запросы.

Я установил WLAN с точкой доступа, которая соединяет клиентов с интернетом. Сначала все казалось работать правильно, пока я не заметил, что клиенты не могут взаимодействовать друг с другом.

Вот детали: Один компьютер подключен к интернету через eth0 и выполняет функции точки доступа через wlan1. На нем работает hostapd и dnsmasq, и он использует NAT для подключения других клиентов к интернету.

Клиент A             Клиент B
192.168.1.143        192.168.1.235
      \                /
       \              /
        \            /
         Точка доступа, AP
         wlan1: 192.168.1.1
         eth0:  192.168.0.xxx

На данный момент клиенты могут успешно подключаться к интернету. Они могут подключаться (например, через ssh) к точке доступа. И точка доступа может ssh к клиентам.

Теперь проблема в том, что клиент A не может подключиться к клиенту B и наоборот. Используя tcpdump на точке доступа, я вижу, что клиент A отправляет ARP-запросы для клиента B. Но клиент B никогда не получает эти запросы и, следовательно, не может ответить. Поэтому запись в таблице arp для клиента B неполная (и наоборот).

Для тестирования я вручную установил записи таблицы arp для обоих клиентов с помощью arp -s <ip> <hw_addr>. И теперь все работает успешно. Клиенты могут подключаться друг к другу и могут подключаться к интернету. Но на самом деле я не хочу вручную устанавливать записи таблицы arp для всех клиентских машин.

Теперь мой вопрос: В чем тут проблема? Как таблицы arp должны обновляться автоматически? На что мне стоит обратить внимание? Это проблема на точке доступа (маршрутная таблица, hostapd, dnsmasq и т.д.)? Или это проблема на клиентских машинах?

ps: На каких-либо машинах не установлены правила arptables:

$ arptables -L
Цепочка INPUT (политика ACCEPT)

Цепочка OUTPUT (политика ACCEPT)

Редактировать: В конце концов, я нашел проблему:

После повторной проверки конфигурации я в конце концов протестировал это с помощью другого USB Wi-Fi адаптера. И я был действительно удивлён, увидев, что все работает тогда. ARP-запросы получались и отвечали клиентами. Ping и ssh между любыми клиентами также работали.

Чтобы быть уверенным, я вернулся к первому USB Wi-Fi адаптеру. И снова ARP-запросы не были получены (и отвечены) клиентами. Таким образом, я могу подтвердить, что это не было проблемой в конфигурации hostapd или в таблицах arp ядра. Проблема заключалась в драйвере для Wi-Fi адаптера.

Вот детали:

1. ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac 2T2R DB WLAN Adapter

   • Работает некорректно.
   • ARP-запросы получаются точкой доступа, но они не доходят до клиентов.

2. ID 0bda:b812 Realtek Semiconductor Corp.

   • Работает удовлетворительно.
   • ARP-запросы и ответы ARP между произвольными клиентами работают правильно.

Вы можете либо настроить конфигурацию так, чтобы ap_isolate = 0.

Либо установить ap_isolate = 1 и затем hair_mode (что запрашивает мосту отправлять кадры обратно через тот же интерфейс):

echo 1 > /sys/devices/virtual/net/br-lan/lower_wlan.name/brport/hairpin_mode

Я столкнулся с той же проблемой, описанной выше: широковещательные ARP-запросы не получали ответы от одного клиента к другому. Однако ARP-запросы от клиента к AP (и наоборот) работали.

Я пробовал все возможные параметры конфигурации hostap без успеха. Решением было использовать другой Wi-Fi адаптер (тестировал несколько раз):

• Адаптер, который не работал, был TP-Link TL-WN722N v2 (чипсет: Realtek RTL8188EU) + установлен соответствующий драйвер из репозитория aircrack-ng
• Предшественник TP-Link TL-WN722N v1 (чипсет: Atheros Communications AR9271) работал как ожидалось.