LINUX.ORG.RU
решено Форум — Admin  

hostapd + bridge: пакеты то ходят то нет

 ,


0

3

Есть железяка с Ubuntu 22.04 в качестве роутера, в нём две ath10k карточки через hostapd раздают вайфай и три медных интерфейса (не суть важно)

Стандартная конфигурация, в общем: в бридж br0 добавлены пара медных интерфейсов и оба вайфай-интерфейса (2.4 и 5). На br0 висит IP шлюза и DHCP-сервер.

Проблема: иногда (закономерность не понятна) после загрузки вайфай клиенты (с обоих интерфейсов) не могут достучаться до IP br0, причём IP по DHCP они спокойно получают, т.е. на физ уровне пакеты ходят в обе стороны… делаем ребут - и пинг начинает проходить (ну, и прочий траффик). Или не начинает :)

В tcpdump -i br0 вижу ICMP от клиентов (когда пингую IP br0), но ответов нет. iptables очищал для верности, разницы нет.

Что-то мысли кончились куда копать.

Если сброс iptables не влияет - значит проблема ниже. Ты уверен, что там iptables а не nftables?

«wifi down ; wifi up» не пробовал делать вместо ребута?

В dmesg не видно проблем?

мас-адреса клиентов видны в мосте?

когда пинг не ходит на бридже есть arp для адреса клиента?

Хорошо бы на клиенте arping запустить для исключения влияния ip-шного стека.

Встречал (3-4 года назад) кривых клиентов которые очень криво работают с сетями с одинаковыми ssid в разных диапазонах.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

Если сброс iptables не влияет - значит проблема ниже. Ты уверен, что там iptables а не nftables?

да, там нулёвая убунта на минималках, в nft всё чисто.

«wifi down ; wifi up» не пробовал делать вместо ребута?

hostapd перезапускал, толку нет. интерфейсы вайфайные при лежачем hostapd тоже дёргал, аналогично.

мас-адреса клиентов видны в мосте? когда пинг не ходит на бридже есть arp для адреса клиента?

Да, там всё красиво.

# arp -an
? (192.168.55.150) at f0:18:98:38:c8:b7 [ether] on br0

# tcpdump -i br0 icmp -vvnn
tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 s
01:09:55.519639 IP (tos 0x0, ttl 64, id 47547, offset 0, flags [none], proto IC)
    192.168.55.150 > 192.168.55.1: ICMP echo request, id 54550, seq 6, length 64
01:09:56.520395 IP (tos 0x0, ttl 64, id 36605, offset 0, flags [none], proto IC)
    192.168.55.150 > 192.168.55.1: ICMP echo request, id 54550, seq 7, length 64

Хорошо бы на клиенте arping запустить для исключения влияния ip-шного стека.

arping работает без проблем, DHCP тоже, icmp уже не ходит.

Встречал (3-4 года назад) кривых клиентов которые очень криво работают с сетями с одинаковыми ssid в разных диапазонах.

Клиенты тут либо все не работают, либо все работают. Дело не в них.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

гм. то, что работает arping - сильно удивляет, но радует, что это скорее всего не проблема с сетевой картой.

Напоминаю про картинку https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

tcpdump - это af_packet и он видит пакеты только в двух местах.

Если ты видишь входящие и не видишь исходящие, то вариантов 3:

1. Ядро дропает входящие пакеты в ip-стеке. Причин не так много.

Менее вероятные причины.

2. Ядро дропает исходящие пакеты.

3. Ядро отправляет их в другую сторону (смена адресов/маршрутов)

IMHO Если пакет дропает ip-стек, то должны увеличиваться счетчики дропов (netstat -s). В худшем случае запустить dropwatch (https://github.com/nhorman/dropwatch)

Если не видно входящих пакетов в raw/PREROUTING, значит их дропает что-то в бридже или в ingres. Если dropwatch не показывает никакой полезной информации, то хз что дальше делать.

Если пакеты видны в raw/PREROUTING, но их нет в raw/OUTPUT, значит что-то дропает их в ядре ( см. netstat/dropwatch )

сделай скрипт

ip li ip ro brctl show bridge link bridge fdb

выполни его когда все хорошо и когда все сломалось.

Ну и убедиться, что nft/iptables пустой когда все сломалось, а то вдруг по хрону что-то делается.

Я бы еще «ip mon | tee ip_mon.log» в скрине запустил...

vel ★★★★★
()
Ответ на: комментарий от vel

Сегодня на свежую голову начал глядеть в ip route get и tcpdump-ом интерфейсы перебирать и нашёл причину.

Как выяснилось - у меня были настроены Wireguard туннели, но они были неактивны т.к. маршрута по умолчанию наружу в принципе не было - им некуда подключаться. В таблице маршрутизации была только локалка /24 и всё, это меня смутило изначально и я не стал проверять дальше.

Но wg-quick по умолчанию пытается быть слишком умным и навешал всяких правил в ip rule на базе fwmark-ов, которые за каким-то хреном отправляли ответный траффик не в бридж, а в один из этих wg-интерфейсов (который вообще неактивен). Почему в него - фиг поймёт, может случайно (адреса там другие совсем на нём, да и туннель не поднят).

По какой причине оно то работало, то нет - хрен его знает, возможно какой-то race condition при запуске.

Вот такие чудеса… сам дурак, в общем. Всё поотключал, а про wg забыл. Вариант №3 оказался :)

Спасибо за помощь!

blind_oracle ★★★★★
() автор топика
Последнее исправление: blind_oracle (всего исправлений: 1)
Admin