Цитата: sfstudio от 20/10/2019, 13:27

1. глянуть в лог на тему буковок FT при коннекте клиентов, глянуть iw scan на тему анонсов.
2. всегда бегают по верх дефолтового бриджа, nvram_set 2860 IAPPDebug 4 && reboot
3. эт радио, буферизация, неравномерность обслуживания и т.д. и т.п. Запросто может быть и 10мс в зависимости от клиентов, конфига, состояния эфира и т.д.. Нет ну можно кастрировать всё включая агрегацию powersave и т.д., пинг будет короткий и как вкопанный. Только по скорости вернёмся на уовень 802.11g по сути. А тут ещё и MBSSID....

Да обновиться бы до 11го там с конфигом MBSSID косяк в UI пофикшен кроме прочего, хоть вы видимо на него и не наступили.

Далее, не видел ни одного сяоми (и прочего китайского хлама) что бы поддерживало K/R. От слова совсем. Т.е. переключаться он будет совсем топорно теряя сеть с вероятность 50/50 и часто когда уже PER зашкалил и пакеты во всю теряются. Так что только костылями на стороне телефона можно попробовать обойти, см раздел по роумингу там они есть.

Чем меньше городушек - тем шелковистее волосы.

 

Цитата: sfstudio от 20/10/2019, 13:42

Ну и да, поддержка K/R ещё не гарантия нормальной миграции (см Sony), а отсутсвие её не означает что клиент не может бесшовно мигрировать (см Intel).

Однако чаще всего наличие поддержки K/R даёт шанс на нормальную мигруцию.

Что качается каналов надо поминить что клиенты без поддержки K чаще всего будут мигрировать между АП на разных каналах с полным отвалом, т.к. время  скана 5ГГц диапазона занимает до 7сек.

 

Цитата: sfstudio от 20/10/2019, 13:48

С точки зрения миграции самая беспробленая сеть это где все AP на одном канале. Там львиная доля даже безродных китайских клиентов без каких либо K/R после подгонки уровней сможет нормально мигрировать без полного отвала.

Появляются АП на разных каналах - доля клиентов нормально мигрирующих резко сокращается и тут уже клиенты без поддержки K чаще всего будут в пролёте.

А вот R по сути влияет лишь на длину фазы аутентификации на новой АП, причём только первой аутентификации дальше что с ним, что без него используется PMKCache и соединение всегда идёт по короткой процедуре. В любом случае R это десятки мс экономии на первой аутентификации "нового" для АП клиента.

Однако многие клиенты не видя анонсов MDIE появляющихся в эфире при включении R попросту всегда дропают связь. Причём если поправить в коде логику и анонсить MDIE не зависимо включен и работает ли R бесшовность миграции сохраняется, хотя никакой FT(R) не работает. =) Муркетинг да, он такой беспощадный.

 

Цитата: sfstudio от 20/10/2019, 17:35

ББрр только дошло. Городушки с вланами эт только ради того что бы провода до компа от провов не тянуть??

Дык может эт. По нормальному сделать таки? Дотянуть 2 шнурка до ПК раз комп это и есть роутер, а ME1 воткнуть в режиме АП тупо. Ибо я фиг знает чем подобное может аукнуться. Никто вашу схему близко не проверял. Грубо гря всё что нельзя сделать из UI никак не проверялось от слова вообще и не факт что не вылезет какой-нить побочки.

Более того, встроенные свитчи очень куцие на тему длины очереди, да и mac table там общий и всего 2к записей. Лучше бы ну его нафиг.

Помниться были там чудеса с попыткой разрулить вланы только средствами свитча. Уже не помню в чём соль, но отказался от этой схемы и перешёл на софтовый вариант. Года уже 3+ прошло.

Цитата: sfstudio от 20/10/2019, 17:46

Можно попробовать сделать так. Ну раз сервер есть. Отказаться от 10го влана и приземления его свитчами, настройить MBSSID2VLAN (WLAN VLAN в UI) каждому интерфейсу свой влан. Затем собрать эти вланы уже на сервере в бридж. До кучи получиться ещё и возможность фильтрации на сервере на уровне бриджа ebtables.

iaap как ходил так и будет ходить без тегов обеспечивание общение между собой АПшек для нужд миграции.

Т.е. оставить только протягивание провов, а изоляцию радио сделать полную со сбором назад всего этого уже на уровне сервера. На стороне AP будут бриджи VLAN<=>MBSSID и съёмом и одеванием тэгов будет заниматься уже софт или сетёвка AP в зависимости от конфига. Да, будет выше нагрузка на cpu но этот вариант абсолютно точно работающий корректно и обкатанный за исключением транзита хвостов от провов.

Цитата: edo1 от 21/10/2019, 06:26

ся бы до 11го

сделал

nvram_set 2860 IAPPDebug 4 && reboot

сделал, в логах было что-то про iapp при старте, но потом при перемещении клиентов пусто.

нашёл "подозрительный" процесс (ralinkiappd), подключился через strace - просто висит на select, больше ничего не делает. это нормально?

(я писал уже, что начал с "отлавливания" служебных пакетов через tcpdump - и ничего не нашёл)

 

глянуть в лог на тему буковок FT при коннекте клиентов

буковки FT для айфона есть, вот, например, сходил с айфоном в соседнюю комнату, ssh-сессия на нём не прервалась:

Oct 21 04:12:56 kernel: ASSOC - Assign AID=1 to 5GHz AP e4:e4:ab:90:b9:ee, FT mode
Oct 21 04:12:56 kernel: ASSOC - HT support STA. Update AP OperaionMode=3 , fAnyStationIsLegacy=1, fAnyStation20Only=1, fAnyStationNonGF=1
Oct 21 04:12:56 kernel: ASSOC - VHT support STA

это означает, что айфон декларирует, что умеет FT, правильно? но это же не значит, что FT между точками у меня работает, насколько я понимаю.

 

а вот с сяоми, ssh-сессия прервалась (выглядит это так - уровень сигнала wifi вырос, потом значок wifi пропал, появился 4g, потом вернулся значок wifi с восклицательным знаком, потом обычный значок wifi):

Oct 21 04:18:28 kernel: ReASSOC - Assign AID=1 to 5GHz AP 18:01:f1:27:21:26
Oct 21 04:18:28 kernel: ReASSOC - HT support STA. Update AP OperaionMode=3 , fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Oct 21 04:18:28 kernel: ReASSOC - VHT support STA
Oct 21 04:18:37 kernel: 5GHz AP AUTH - receive DE-AUTH(seq-2958) from 18:01:f1:27:21:26, reason=4
Oct 21 04:18:37 kernel: ASSOC - Assign AID=1 to 5GHz AP 18:01:f1:27:21:26
Oct 21 04:18:37 kernel: ASSOC - HT support STA. Update AP OperaionMode=3 , fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Oct 21 04:18:37 kernel: ASSOC - VHT support STA

получается, мой сяоми не умеет FT, но это же не самоцель. он попытался переключиться бесшовно, но что-то пошло не так, верно?

Далее, не видел ни одного сяоми (и прочего китайского хлама) что бы поддерживало K/R. От слова совсем. Т.е. переключаться он будет совсем топорно теряя сеть с вероятность 50/50 и часто когда уже PER зашкалил и пакеты во всю теряются

вот именно к позывам переключиться у меня претензий нет - через несколько секунд после перехода в другую комнату мой сяоми  (почему я пишу "мой" - там же надцать устройств, и для каждого несколько версий только родной прошивки) начинает перебираться на ближнюю точку, хотя пока ещё видит старую. ещё бы он это делал не сбрасывая tcp-соединения - было бы совсем хорошо.

Цитата: edo1 от 21/10/2019, 06:29

Цитата: sfstudio от 20/10/2019, 17:35

ББрр только дошло. Городушки с вланами эт только ради того что бы провода до компа от провов не тянуть??

да. если один провод я уберу в плинтус, то три провода (1 до точки + 2 провайдера) уже никак

и vlan'ы-то работают, мне бы с wifi/роумингом разобраться )

Цитата: edo1 от 21/10/2019, 07:14

хм, достал старый разбитый телефон (тоже сяоми, max 2), с ним:

Oct 21 04:51:13 kernel: ReASSOC - Assign AID=3 to 5GHz AP 38:e6:0a:ba:1c:b7
Oct 21 04:51:13 kernel: ReASSOC - HT support STA. Update AP OperaionMode=3 , fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Oct 21 04:51:13 kernel: ReASSOC - VHT support STA

и ssh-сессия не порвалась!

btw, reassoc может быть без k/r?!? или раз пишет про reassoc - то работает k/r?

Цитата: edo1 от 21/10/2019, 07:43

эт радио, буферизация, неравномерность обслуживания и т.д. и т.п. Запросто может быть и 10мс в зависимости от клиентов, конфига, состояния эфира и т.д.. Нет ну можно кастрировать всё включая агрегацию powersave и т.д., пинг будет короткий и как вкопанный. Только по скорости вернёмся на уовень 802.11g по сути. А тут ещё и MBSSID....

имелось в виду, что быть может где-то стоит подкрутить в сторону меньшей оптимистичности и соединение будет формально на более низкой скорости, но и задержки упадут?

я сейчас вижу скорости соединения с телефонами на 5ГГц 300+мбит/с, это красиво, конечно, но необходимость таких скоростей в реальной жизни под сомнением.

BTW, MBSSID у меня нет, если это играет какую-то роль.

Цитата: zrain от 21/10/2019, 10:40

Цитата: sfstudio от 20/10/2019, 13:48

С точки зрения миграции самая беспробленая сеть это где все AP на одном канале.

А это не повлияет на общую стабильность и скорость сети?

 

Цитата: sfstudio от 21/10/2019, 19:42

Ёмкость сети упадёт ессно, а стабильность смотря что под ней понимать. =) Стабильно обрывы при миграции на тупеньких клиентах это тоже стабильность. =)

Тут надо понимать когда можно и нужно применять ту или иную схему. Поройте форум, за несколько месяцев уже не раз объяснял этот момент.

Цитата: edo1 от 24/10/2019, 07:19

перенёс айфон, из соседней комнаты, он зарегался сначала в 2.4, потом в 5

Oct 24 05:08:15 kernel: ASSOC - Assign AID=1 to 2.4GHz AP e4:e4:ab:90:b9:ee, FT mode
Oct 24 05:08:15 kernel: ASSOC - HT support STA. Update AP OperaionMode=2, fAnyStationIsLegacy=0, fAnyStation20Only=1, fAnyStationNonGF=1
Oct 24 05:13:02 kernel: ASSOC - Assign AID=2 to 5GHz AP e4:e4:ab:90:b9:ee, FT mode
Oct 24 05:13:02 kernel: ASSOC - HT support STA. Update AP OperaionMode=3 , fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
Oct 24 05:13:02 kernel: ASSOC - VHT support STA

как понять, был ли использован FT?

больше в логе ничего не вижу

[Wive-NG-MT@/]# nvram_get 2860 IAPPDebug
4

 

Цитата: sfstudio от 24/10/2019, 10:13

Не зависимо используется тут FT или нет видно, что клиент идёт по длинной процедуре. Отсутствие записей в логе от iapp демона говорит о том что R вообще не включен. Т.к. даже для не FT клиентов в логе бы были бы move notify а их нет. При этом после миграции на стороне АП с которой мигрировал была бы запись в логе от драйвера о том что клиент мигрировал именно с неё и move notify прилетело с АП куда мигрировал.

P.S. Напоминаю, что мы осуществляем саппорт исключительно на уровне "нашёл баг в официальных сборках с sf.net." Что-то с выше по ТП взял на себя ваш вендор. Пожалуйста обратитесь к нему. Ещё в марте была дана информация о переводе поддержки SNR-CPE на уровень критичных багфиксов и простых ответов в пределах типовых конфигураций. Разбор полётов выше сильно выходит за эти рамки.