vasek00

Вы много написали но информации ноль. Состояние эфира это не про соседей, а про клиента как он видит точки в нужных вам местах. Клиенту по барабану сколько у вас стен и какие они ему важен сигнал RSSI как он слышит роутер или ТД. Есть у вас хоть один клиент на Android.

Для понимания начальной фазы принятия решения клиентом когда он выходит из диапазона одной точки доступа (AP) и переключается на следующую доступную AP. "Поддержка роуминга Wifi на устройствах Apple" - перевод https://support-apple-com.translate.goog/guide/deployment/wi-fi-roaming-support-dep98f116c0f/web?_x_tr_sl=auto&_x_tr_tl=ru&_x_tr_hl=ru&_x_tr_pto=wapp Остановлюсь на начальных этапах: 1. Устройства определяют, когда следует роуминг, сравнивая значение индикатора уровня принимаемого сигнала (RSSI) текущего соединения с RSSI новой точки доступа. После того как сигнал ослабляется до определенного значения (известного как порог срабатывания роуминга ), устройство оценивает кандидатов на роуминг. Учитываемые факторы включают порог срабатывания роуминга, полосу частот и технологию физического уровня (PHY), используемую точкой доступа-кандидатом роуминга. Порог срабатывания и перекрытие ячеек Компьютеры Mac отслеживают и поддерживают текущее соединение BSSID до тех пор, пока RSSI не превысит порог –75 дБм. Устройства iPhone и iPad отслеживают и поддерживают соединение с идентификатором базового набора услуг (BSSID) до тех пор, пока индикатор уровня принимаемого сигнала (RSSI) не превысит –70 дБм. После того как Mac, iPhone или iPad пересекают порог срабатывания роуминга, устройство сканирует BSSID-кандидаты роуминга для текущего идентификатора расширенного набора услуг (ESSID). Антенны на устройствах различаются от модели к модели, и они могут воспринимать границы ячеек иначе, чем ожидалось. Помните об этом, когда проектируете беспроводные соты и рассчитываете перекрытие их сигналов. При измерении перекрытия ячеек всегда лучше использовать целевое устройство. 2. Критерии отбора кандидатов в диапазоны, сети и роуминг Помимо достижения порогового значения роуминга, набор базовых услуг-кандидатов (или точка доступа) должен иметь сигнал, который лучше текущего. Для macOS потенциальный BSS должен иметь RSSI на 12 дБ выше, чем текущий BSS, независимо от того, находится ли Mac в режиме ожидания или передает данные. Для iOS, iPadOS и VisionOS потенциальный BSS должен иметь RSSI на 8 дБ выше, если iPhone, iPad или Apple Vision Pro передает данные, или RSSI на 12 дБ выше, если устройство находится в режиме ожидания. Например, iPhone подключен к SSID, где RSSI текущего соединения может упасть до –75 дБм во время вызова голосовой связи через WLAN (VoWLAN). Когда это происходит, устройство позже ищет BSSID-кандидаты для роуминга, которые имеют RSSI не менее –67 дБм. Если Mac подключен к той же сети и RSSI текущего соединения падает до –75 дБм, устройство ищет кандидата BSSID для роуминга, который имеет RSSI не менее –63 дБм. 3. Поддержка оптимизации роуминга см.ссылку выше. У Samsung он аналогичен - https://docs.samsungknox.com/admin/knox-platform-for-enterprise/kbas/kba-115013403768/ Остановлюсь на начальных этапах: Есть 3 фактора, которые вызывают роуминг на мобильном устройстве Samsung: Слабый сигнал - Мобильные устройства вызывают роуминг-сканирование, чтобы избежать частых ретрансляций от потерянных пакетов. Когда значение текущего AP-полученное значение Полученное значение Сигнальной Силы (RSSI) является слабым (ниже -75dBm), устройство ищет AP с более сильным сигналом. Когда пакеты маяка из подключенного AP не получаются через 2 секунды (6 секунд, если дисплей выключен), мобильное устройство считает его потерянным маяком и запускает роуминг. Когда несколько клиентов подключены к одной и той же AP, подключение может быть затруднено, несмотря на наличие сильного радиосигнала из-за ограниченных ресурсов. В этом случае AP уведомит клиентов о своем текущем трафике через фактор CU в своем маяке. Затем мобильное устройство спровоцировало роуминговое сканирование, если полученное значение CU превышает 70 процентов, а нынешнее значение RSSI - между -65dBM и -75dBm. И так же поддержка оптимизации роуминга. И как мы видели выше есть клиенты которые это не используют, хотя странно как то тот же HONOR X9a Android 13 это не умеет или не включен, или еще что-то.

Кто-то отписывался например было и такое, что есть ТВ который так же "спит" но зачем, то дергает LAN соединение. Проверьте еще раз настройки сетевой на предмет всяких совпадений шаблонов/включение по лок сети или Magic или Wake или энергосбережения чего-то или еще что-то. Можно войти клиентом по Wifi и включить "Захват сетевых пакетов" (посмотрите в базе как это делается). Далее самым простым анализатором можно Microsoft Network Monitor (менее 10МБ) посмотреть какие с вашего клиента бегут пакеты если они бегут в режиме когда он "спит".

Попалось на глаза - WireProxy https://github.com/pufferffish/wireproxy/releases/tag/v1.0.3 https://github.com/pufferffish/wireproxy https://timeweb.cloud/tutorials/network-security/ustanovka-i-nastrojka-wireproxy Проба минимальна пока. Для нужного проца скачиваем дистрибутив - wireproxy_linux_mipsle.tar.gz или wireproxy_linux_arm64.tar.gz далее распаковать (где угодно, хоть на Windows и переписать на роутер в любое место). В моем случае проверил на ARM роутере : /opt/sbin # ls -l | grep wire -rwxr-xr-x 1 root root 8126464 Apr 19 17:39 wireproxy /opt/sbin # в /opt/etc создадим каталог для конф файлов "wireproxy" /opt/sbin # cd /opt/etc/wireproxy /opt/etc/wireproxy # ls -l -rw-r--r-- 1 root root 244 Jul 19 22:42 wireguard.conf -rw-r--r-- 1 root root 501 Jul 20 10:14 wireproxy.conf /opt/etc/wireproxy # Идем на любую 7 дневку, берем конф файл Wiregaurd [Interface] Address = 192.168.6.227/32 DNS = 1.1.1.1,8.8.8.8 PrivateKey = sLidtr/KaUZd.......j0ShXA= [Peer] publickey=njXho7l.........Ba64zDIWo= AllowedIPs = 0.0.0.0/0, ::/0 Endpoint = gr1.........com:1024 Далее конф для самого wireproxy WGConfig = /opt/etc/wireproxy/wireguard.conf [TCPClientTunnel] BindAddress = 192.168.130.101:64421 Target = gr1........com:1024 #[Socks4] #BindAddress = 127.0.0.1:64422 #BindAddress = 192.168.130.101:64422 [Socks5] #BindAddress = 127.0.0.1:64423 BindAddress = 192.168.130.101:64423 [http] #BindAddress = 127.0.0.1:64424 BindAddress = 192.168.130.101:64424 #Username = aaax #Password = aaax После запуска имеем Для Socks5 есть два вариана : 1. в браузере настройка на роботу с прокси (указать 192.168.130.101:64423), тут все просто в отличие от варианта ниже. ./wireproxy -c /opt/etc/wireproxy/wireproxy.conf 2. в WEB роутера добавить PROXY подключение + профиль для данного канала и естественно пользователя в него, тогда плюсом будет "badvpn-tun2socks" и Клиент в данном профиле speedtest показал IP от ping "gr1...........com [51.хх.хх.хх]" Загрузка проца была солидной в отличие от родного wireguard. Осталось еще с настройкой разобраться # <an app on your LAN> --> localhost:25565 --(wireguard)--> ххх.ххххх.ххх:25565 [TCPClientTunnel] # Flow: <an app on your wireguard network> --(wireguard)--> 172.16.31.2:3422 --> localhost:25545 [TCPServerTunnel]

Копать это не в данном случае, просто настройки дров еще раз сделать. AX200 на стационаре + выведены антенны на стол (кабель ~1м и антенны 5dBi) проблем нет в обе стороны. Дрова 23.60.0.10 от 01.05.2024. WPA3, Win11. Что в AC/AX роли не играет, ну чуток разные скорости будут но для моего интернета 200+100Мбит не принципиально. В настройках практически многие параметры выкл. т.1 прием -R -P 30 до 0.35Gb, т.2 передача -P 30 клиента до 0,15Gb -> интернет iperf3 сервер. Тут комментарии, что это два проводных на интернет в сумме 300Мбит на прием, а на передачу один. т.3 передача 0.8-0.9Gb, т.4 прием -R -P 30 клиента до 1.2Gb -> LAN iperf3 сервер И так уже давно на draft 4.х. Комментарии по графику это новый netdata 1.4х на ARM пока не удобно выделять интерфейсы, он их суммирует (нужно разделять). Если так принципиален вывод Могу проделать тест на 866Мбит получу на прием 70-75% от канальной = 600-650Мбит и передача чуток будет поменьше но ни как не UPLOAD = 0.9 Mbs

Настройка согласно конф файла. 1. Два WG канала, один на основной канале "connect", второй на втором (резервном) "connect via GigabitEthernet0/Vlan9". На провайдерах DNS выключен. interface Wireguard0 ip global 65445 endpoint 162.ххх.ххх.ххх:5000 connect interface Wireguard1 ip global 64765 endpoint 185.ххх.ххх.ххх:5060 connect via GigabitEthernet0/Vlan9 2. По умолчанию в основном профиле интерфейсы определяются по "ip global" их последовательность - PPPoE0(65469, Основной)/Vlan9(65453, Резервное подключение)/Wireguard0(65445, Резервное подключение)/Wireguard1(64765, Резервное подключение) interface PPPoE0 ip global 65469 interface GigabitEthernet0/Vlan9 ip global 65453 3. В двух созданных профилях активна только WG на остальных интерфейсах галок нет ip policy Policy0 permit global Wireguard0 *** галка "permit" no permit global GigabitEthernet0/Vlan9 no permit global PPPoE0 no permit global Wireguard1 ip policy Policy2 permit global Wireguard1 *** галка "permit" no permit GigabitEthernet0/Vlan9 no permit global PPPoE0 no permit global Wireguard0 4. Так как "endpoint" представлен в IP то Wireguard без проблем поднимается, в WEB - подключено. Ни какого DNS в данном случае не нужно. Вопрос тогда что у вас в "endpoint" - IP или мнемоника (xxxxxx.xxx:port). В моем случае 4.2.В.0 - есть "бзик" после перезапуска WG1 не активен, только после перезапуска в WEB "Другие подключения" кнопки на данном интерфейсе. Но он тянется с более ранних draft версий. Если же WG1 поднять на основном провайдере PPPoE, то проблем с ним так же не будет после перезапуска роутера - оба ОК.

1. Думаю нужно ознакомится с https://help.keenetic.com/hc/ru/articles/360007279039-Mesh-Wi-Fi так же обратить внимание на метрики, так же есть команда как это все посмотреть. 2. Клиенты часто норовят подключиться к дальней точке с плохим сигналом. И не соскочат пока не перезагрузишь их или дальний ретранслятор. А это странно так как КЛИЕНТ ВСЕГДА подключается/выбирает точку у которой сигнал RSSI лучше, т.е. если от одной -60 а от другой -50 то он клиент будет подключен к той у которой -50. Данный вопрос требует уточнения значения данногопараметра только не по "галкам" тут 3 а тут 2. Покажите любой доступной программой/анализатором уровень в данной точке. Колонка AirPlay с аккумулятором. С чего то решила подключиться к центру дома. Смотрим выше. Походите с анализатором на клиенте и оцените Wifi эфир в помещение от того как вы разместили ТД/роутер в данном помещение.

Более точно опишите. Про WG = два канала, на каждом поднят свой WG, так же есть два профиля в котором есть по WG (и только). Проблем нет. DNS правда хитрый - на WG их нет, но стоит AGH на основном канале.

Увидел, отправил

Я вам в лс вчера написал, сейчас перегружу и будет в сломанном состояние. Все можно смотреть - "сломано"

Все что открывается или не открывается относиться к работе DNS или к размеру MTU.

После вечернего "хождения" по WEB в мобильном приложение, данная страница стала открываться. Так же и на странице /internet-filter/content-filter все ОК (выключено). Перезагрузка - все ломает Входим в мобильное приложение - в Сетевых правилах -> "Интернет фильтры" Выкл (на WEB ПК крутится проверка доступности), передергиваем Сетевые правила "Интернет фильтры" на "Публичный" и обратно на "Выключено" тогда на WEB ПК все ОК. По странице Клиенты, аналогично после перезапуска роутера "Список клиентов" пуст, идем в мобильное "Мои сети"->"Политика доступа для незарег.устройств" с текущего без выхода на любой например на по умолчанию - проверяем на WEB ПК все ОК -> возвращаю на значение "Нет доступа в интернет" и так же все ОК. Ладно хоть так тогда.

Да конечно

Данные компоненты не установлены - SkyDNS/NextDNS и Captive portal только "Фильтрация контента и блокировка рекламы при помощи облачных сервисов" Да на 1811 стоит только NextDNS + "Фильтрация контента и блокировка рекламы при помощи облачных сервисов"

На 1811 все ок со списком клиентов, без сброса 2710 видимо не обойтись.

Peak новый WEB - список клиентов на FF и на Chromium.

В Android есть - wpa_supplicant Переход Sams A34 (на MTK и Android 14, wifi папка - wlan_common_rc, indoorchannel.info, p2p_supplicant_overlay.conf, wlan_vendor_rc, wpa_supplicant.conf, wpa_supplicant_overlay.conf) с 1811 на B6 (rssi-threshold -75) и обратно на 1811. Переход Sams A50 (на exynos 9610 и так же свой wifi чип) Сам процесс на A34 Переход Sams A50

Написал же выше Если вы про WCNSS_qcom_cfg то он же для "qcom" или для Qualcomm чипов wifi.

Выше речь шла о gNeighborLookupThreshold=76

Была ранее программка - WifiFixer_20190321-01_Apkpure через нее можно менять некоторые параметры https://apkpure.com/ru/wififixer/de.resolution.wififixer Дельта - это чтоб обратно к этой точке не подключился

Если вы про WCNSS_qcom_cfg то он же для "qcom"

т.е. у вас с переключением вопросов нет.

system/vendor/etc/wifi

Какой порог принятия решения RSSI на переключение (это тот который FT), так как тот который не может понятно, что сидит до упора. Хотел убедиться, что у других порог с которого он принимает решение такой же -75/76.

По клиентам можете чуток по подробней? Ну есть же стандарты, вопрос скорей всего на все ли 100% они реализованы на клиентах, а если не стандарты, а рекомендации, то да каждый вендор решает по своему. А по клиентам : - "нормальный" это если есть порог на котором он принимает решение + плюшки хотя бы kv + плюшка r желательна - "не нормальный" у которого нет порога принятия решения (до разрыва) + плюшки тут видимо уже не помогают - возможно есть еще какой, то "неведанный" Единственное, что у всех реализовано на 100%, это подключение к точке у которой сигнал сильнее.