ValdikSS

Похоже, я столкнулся с этой проблемой во время отладки Wi-Fi-чипа на своём устройстве. Отлаживал 2 суток, был уверен, что проблема в прошивке чипа, но перезагрузка роутера решила проблему и она ушла бесследно (пока что). До перезагрузки аптайм роутера был около 30 дней. Подробности здесь: https://github.com/orangepi-xunlong/linux-orangepi/issues/98#issuecomment-5376727263 (это сообщение и ниже) Коротко: пока клиент в активном режиме, весь трафик ходит без проблем. Но как только клиент уходит в сон, отправляя Null data frame с флагом PWR MGT = 1 в сторону точки, multicast-трафик «перестаёт приходить» клиенту, любой, включая ARP-запросы. У меня нет записи трафика, чтобы понять, не приходили ли пакеты или приходили неправильные, но так как здесь выше выложили скриншоты с ошибками MIC, я подозреваю, что проблема как-то связана с пересогласованием GTK и/или с буферизацией multicast-трафика во время сна клиента (во время тестирования я отключал PMF, использовался WPA2-PSK). Во время тестирования клиент, конечно же, бесчисленное количество раз перезагружался, переаутентифицировался на точке, и ничего не помогало. Клиент был отключён часами, и проблема не уходила. Поэтому подозреваю, что где-то как-то неправильно кешируется состояние определённого MAC-адреса в драйвере (MAC клиента сменить не додумался). После перезагрузки роутера тестировал смену GTK в разных режимах (ставил время смены ключа в 5 минут, по умолчанию оно выполняется каждые 24 часа), проблему воспроизвести не удалось (уже неделя прошла).

@grishairk у вас установлен автовыбор канала 5 ГГц? Зафиксируйте на каком-то обычном, 44, например. Если поможет, то в Samsung используется другой/устаревший crda.

В IPv6 адрес источника и адрес назначения имеет значительный вес и в выборе адреса, с которого подключаться (их легко может быть 10 на интерфейсе), и в приоритете адреса, к которому подключаться. ULA source address имеет приоритет ниже, чем IPv4 source. Если вы открываете обычный сайт, у которого A (IPv4) и AAAA (IPv6) записи на домене (IPv6 глобальный, разумеется), подключение будет устанавливаться через IPv4. IPv6 будет использоваться только для IPv6-only сайтов (даже у ULA-ULA приоритет ниже, чем IPv4-IPv4). Потому что с точки зрения спецификации ULA-адреса считаются предназначенными для локальной сети, и нет резона их использовать при подключении к GUA-адресам. Приоритеты заложены во все операционные системы и меняются только на стороне клиента, а не роутера/сервера. https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/ https://www.infoblox.com/blog/ipv6-coe/ula-is-broken-in-dual-stack-networks/

На Viva (KN-1910) используется Beacon Interval = 100, DTIM Interval = 1 (клиентам просыпаться каждый beacon). Я бы хотел выставить DTIM Interval = 3, чтобы телефоны и другие батарейные устройства слушали броадкаст/мультикаст каждые 300 мс, а не 100, а нельзя! Правда, моё устройство сообщает Listen Inteval = 3, что и так фактически устанавливает его в 3 для этого устройства.

В прошивке 5.1.1 перестали работать старые параметры, которые ранее работали. После обновления существующие asc просто пропали, и заново вернуть их не получается: (config)> interface Wireguard0 wireguard asc 16 60 360 0 0 0 0 0 0 Wireguard::Interface error[75507312]: "Wireguard0": invalid ASC parameters. С внедрением нового синтаксиса старые настройки не применяются. Откатился на версию 5.0.12 — проблема ушла, снова могу устанавливать параметры и подключаться. Написал в поддержку об этой проблеме.

В моём случае, при наличии поддержки роуминга + включённого band steering, у uwe5622 едет крыша и он перестаёт ассоциироваться с любыми сетями. Проще всего разделить сети 2.4 ГГц и 5 ГГц (дать им разные названия), это решит проблему.

У меня есть устройства с Wi-Fi-адаптером Allwinner AW859A / Cdtech 20U5622, с чипом uwe5622, у которых также проблемы при включённом 802.11r на Keenetic. Пытаюсь понять, связанные ли это проблемы, потому что сейчас отлаживаю драйвер uwe5622 на стенде с двумя Keenetic, объединёнными в mesh.

Только 2.4.

Вы можете разобрать что-либо из этого и посмотреть, какой Wi-Fi-чип установлен?

Если бы было именно так, то и проблемы бы не было. А проблема в том, что запросы на любой_ip_адрес:53 перенаправляются на 192.168.1.1:53.

Не работает! Применил opkg dns-override, сохранил конфигурацию, перезагрузился, на всякий случай дважды, убедился, что в выводе show run есть строка opkg dns-override, и всё равно перехватывающие правила есть.

Перехват есть, 4.1.2. Вероятно, у вас иная конфигурация, для которой перехват не применяется. См. https://forum.keenetic.com/topic/16431-неотключаемый-перехват-dns-запросов-в-отдельном-сегменте/?do=findComment&comment=167233 # iptables-save | grep _NDM_HOTSPOT_DNSREDIR :_NDM_HOTSPOT_DNSREDIR - [0:0] -A _NDM_DNS_REDIRECT -j _NDM_HOTSPOT_DNSREDIR -A _NDM_HOTSPOT_DNSREDIR -i br0 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br0 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br0 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br0 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 5351 -j REDIRECT --to-ports 41301 -A _NDM_HOTSPOT_DNSREDIR -i br0 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 5351 -j REDIRECT --to-ports 41301 -A _NDM_HOTSPOT_DNSREDIR -i br1 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 5351 -j REDIRECT --to-ports 41301 -A _NDM_HOTSPOT_DNSREDIR -i br2 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 53 -j REDIRECT --to-ports 41100 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 1900 -j REDIRECT --to-ports 41300 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p udp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m udp --dport 5351 -j REDIRECT --to-ports 41301 -A _NDM_HOTSPOT_DNSREDIR -i ovpn_br1 -p tcp -m mark --mark 0xffffaaa -m pkttype --pkt-type unicast -m tcp --dport 1900 -j REDIRECT --to-ports 41300

Как это относится к обсуждаемой теме?

Например, nslookup ya.ru 3.3.3.3 Эта команда выполнит лукап ya.ru через резолвер на IP-адресе 3.3.3.3. На этом адресе нет резолвера, при обычной настройке команда должна завершаться с ошибкой. Если же выдаётся IP-адрес домена ya.ru — запрос был перехвачен роутером.