vasek00

В 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%, это подключение к точке у которой сигнал сильнее.

Возможно еще применение параметра "rssi-threshold" не ко всему wifi диапазону, а к конкретному устройству (естественно оно должно быть зарег. с постоянным MAC)

На других форумах есть упоминания "упертых" устройств : - Realme 11 и его аналогичное поведение (держаться до последнего) при наличии "krv" - Honor 50 "как зацепится за точку, не оторвать, только когда WiFi на нём выкл/вкл, то выбирает тут что сильнее"

Про параметр "rssi-threshold" interface WifiMaster1/AccessPoint0 ... rssi-threshold -75 Работает корректно, но нужно учесть, что это отключение клиента и вновь подключение WEB показал просто "Переход", а не "Быстрый переход" (клиент может 802.11r) или "Переход по РМК-кешу" (клиент не может 802.11r). Сам "Переход" : Отстрел клиента при параметре -75 на ТД Июл 14 12:42:01 ndm Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(a8:МАС:6c) had been aged-out and disassociated (RSSI low limit reached). Подключение клиента к другой ТД Июл 14 12:42:01 ndm Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(a8:МАС:6c) had re-associated from 52:МАС-ТД:e6. Июл 14 12:42:04 ndm Network::Interface::Mtk::WifiMonitor: "WifiMaster1/AccessPoint0": STA(a8:МАС:6c) set key done in WPA3/WPA3PSK.

При обсуждение с ТП по данному поведению и ответ - beamforming отношения не имеет, явных проблем в работе связки KN-1811 + Buddy 6 на ширине 160 МГц не обнаружено, а так же что можно было бы улучшить или исправить в текущем варианте. На работу же rate control KN-1811 повлиять невозможно. Попробуем еще раз на 42A17 сменив положение Buddy 6.

Samsung A34 подключен на WPA3 с плюшками 802.11/kv (на WPA2 плюшки имеются все 802.11/krv). Видно при каком RSSI принимает решения о переходе по PMK-кэшу (FT было бы если он подключился на WPA2). В конф файле клиента "gNeighborLookupThreshold=76". T0 точка подключения, далее перемещение и T1 переключение. На графике все время по оси X по моему 2мин.

Берем клиента HONOR X9a Android 13 - по Wifi 1х1/80. Роутер про него сказал что он может WPA3. 802.11krv. Проверим его работу по бесшовному роумингу. 1. Подключаемся клиентом к роутеру1 - WPA3/krv 2. Переходим к другому роутеру2 (ТД) - и не чего не происходит, до тех пор пока уровень RSSI не станет -92 -93. Клиент разрывает соединение с роутером1, далее 4G, далее подключился к роутеру2. 3. Идем обратно от роутера2 (ТД) к роутеру1 и чудо на RSSI = -75 он переключился к роутеру1. Но как оказалось чуда не было это просто на роутере2 (ТД) стоит параметр interface WifiMaster1/AccessPoint0 ... rssi-threshold -75 ... если бы его не было, то итог был бы опять уровень до -92/93 разрыв и подключение. Все это как то странно так как имеем на нем WCNSS_qcom_cfg.ini в котором стоит -76 gNeighborScanTimerPeriod=200 gNeighborLookupThreshold=76 *********************** gNeighborScanChannelMinTime=20 gNeighborScanChannelMaxTime=30 gMaxNeighborReqTries=3 # Legacy (non-ESE, non-802.11r) Fast Roaming Support # To enable, set FastRoamEnabled=1 # To disable, set FastRoamEnabled=0 FastRoamEnabled=1 # Check if the AP to which we are roaming is better than current AP in # terms of RSSI. Checking is disabled if set to Zero.Otherwise it will # use this value as to how better the RSSI of the new/roamable AP should # be for roaming RoamRssiDiff=5 # To enable, set gRoamIntraBand=1 (Roaming within band) # To disable, set gRoamIntraBand=0 (Roaming across band) gRoamIntraBand=0 Samsung как то выдерживает данное значение -75 переключается в любом случае.

На Buddy 6 на 42А17 c контроллером 1811 ошибка на Buddy 6 - "WifiDriverIo - invalid argument" Все работает кажется.

По проще.

Возможно стоит обратить внимание на такое. При переходе с 42A16 на 42А17 например если посмотреть по компонентам то например будут обновлены - Контроллер Wi-Fi-системы, Режим точки доступа/ретранслятора, Режим клиента Wi-Fi, Режим усилителя/ретранслятора, Клиент и сервер OpenVPN, Контроль состояния интернет-подключения (Ping Check), Клиент динамической службы DNS (DDNS), Последовательный интерфейс для 4G/3G USB-модемов, Интерфейс NDIS для 4G/3G USB-модемов, Интерфейс QMI для 4G/3G USB-модемов, Ethernet-адаптеры с интерфейсом USB, Контроль доступа к папкам, Модули ядра подсистемы Traffic Control, Модули ядра подсистемы USB over IP, Пакет расширения Xtables-addons для Netfilter = пусть хоть с такой записью "Мелкие недочеты/улучшение в коде/оптимизация кода". Может конечно изменение в них не влияет на работу поэтому и не указывают, а может проще оценить возникшую проблему после обновления или это все для WEB.

Начните с

Попробовал еще раз Torrserv на ARM с 512. Торрент Аватар 2 на 104GB 4К. 1. Вариант кеш на SSD диске начал с 512Мбит опустился до 256Мбит - проблем не возникло, скорость интернета плавала до 134Мбит. Кеш был с лихвой. 2. Вариант переместил кеш на память 120Мбит - проблем так же не возникло. Были варианты когда данные из кеша выгребались быстро Лучше все таки кеш на SSD, но тут вопрос какого сделать его размера чтоб не сильно его убить.

Все есть [I] Jan 1 00:00:04 kernel: ndmpart: di: active = 1, backup = 2, current = 1 ... [I] Jan 1 00:00:04 kernel: 0x000000180000-0x000000360000 : "Kernel_1" [I] Jan 1 00:00:04 kernel: 0x000000360000-0x000002bc0000 : "RootFS_1" [I] Jan 1 00:00:04 kernel: 0x000000180000-0x000002bc0000 : "Firmware_1" [I] Jan 1 00:00:04 kernel: 0x000002bc0000-0x000002dc0000 : "Config_1" .... [I] Jan 1 00:00:04 kernel: 0x000004140000-0x000006b80000 : "Firmware_2" [I] Jan 1 00:00:04 kernel: 0x000006b80000-0x000006d80000 : "Config_2" ...

Тут скорей всего вопрос по переменной которую надо где то хранить и менять, судя по всему 4.2 [I] Jan 1 00:00:04 kernel: ndmpart: U-Boot partition is up to date [I] Jan 1 00:00:04 kernel: ndmpart: di: active = 1, backup = 2, current = 1 и это U-boot. Если это так, то думаю ждать тогда не чего, уже было упоминание, что запись для пользователей в данную область не желательна. Хотя есть storage раздел в котором например можно хранить сертификаты для OpenVPN (ca), а в настройках его просто указывать на данный каталог/storage.

Возможно есть сервис на телефоне который делает такие запросы на прямую. Опять же я имел в виду настройки на смартфоне - Подключения - Другие - Персональный DNS-сервер (Отключен/Автоматически/Персональный).

Для того что клиент обращался к Adguardhome он должен об этом знать -> вопрос что использует данный клиент в качестве DSN сервера в своих настройках?

Так как у вас ссылка на "table 42" то это не 4.2 (но может и в 4.1 уже есть). Появилась информация не давно что в ПО и как раз вопрос про WG ip hotspot policy {interface} ({access} | {policy}) Данная команда для политики, а не для конкретного клиента, но можно попробовать ip hotspot policy Wireguard3 Policy0 ip hotspot ... policy Wireguard3 Policy0 ... ip policy Policy0 description Cloud permit global Wireguard0 возможно теперь уже проще. Wireguard3 это удаленный доступ клиентов по WG к роутеру, а Policy0 это политика уже на Wireguard0 выход в интернет. А для того чтоб с Ultra клиенты на Hopper и далее в интернет что-то было сделано? Hopper ------ Инет---Ultra[5.1=WG]----[WG=5.100]Hopper[100.0/24]----Клиенты ~ # ip ro show table 42 default via 192.168.5.100 dev nwg0 192.168.100.0/24 via 192.168.5.100 dev nwg0 Ultra ----- Клиенты---[1.0/24]Ultra[5.1=WG]----[WG=5.100]Hopper---Инет ????????