очередная домашняя сеть на паре ME1

Цитата: edo1 от 20/10/2019, 07:21есть пара ME1, компьютер-роутер, два провайдера.
хочется завести обоих провайдеров на компьютер (сделано), настроить бесшовный роуминг между точками (тут вот сложности).
https://drive.google.com/file/d/1GnHv4XMEON6HayhHfac7Ny0lizSrmuzD/view?usp=sharing
что было сделано:
0. подготовка
залита последняя версия прошивки (8.2.10.RU.04092019), роутеры сброшены кнопкой.
1. из вебинтерфейса
- переведено в AP-Bridge;
- выбраны руками каналы (1 и 36 на одной точке, 13 и 60 на другой);
- зажата мощность на 2.4ГГц до 10%;
- включены k/r
2. из командной строки
заведено 3 vlan:
- 10 - внутренняя сеть (wifi);
- 11 - первый провайдер;
- 12 - второй провайдер.
switch vlan dump с первого ME1 (к которому подключен роутер):
vid portmap eg-tag eg-con stag ivl fid 1 11111-1 uuuuu-u 0 0 1 - 10 ---111- ---ttu- 0 0 1 - 11 ---11-- ---tt-- 0 0 1 - 12 ---11-- ---tt-- 0 0 1 - PVID: port pvid prio matrix 0 10 0 1111111 1 10 0 1111111 2 1 0 1111111 3 1 0 1111111 4 1 0 1111111 5 10 0 1111111 6 1 0 1111111
- порт 4 (wan) - линк до второго ME1
- порт 3 (lan4) - линк до компьютера
- порт 5 (eth3) - внутренняя сеть
на втором ME1:
vid portmap eg-tag eg-con stag ivl fid 1 --111-1 --uuu-u 0 0 1 - 10 ----11- ----tu- 0 0 1 - 11 1---1-- u---t-- 0 0 1 - 12 -1--1-- -u--t-- 0 0 1 - PVID: port pvid prio matrix 0 11 0 1111111 1 12 0 1111111 2 1 0 1111111 3 1 0 1111111 4 1 0 1111111 5 10 0 1111111 6 1 0 1111111
- порт 0 (lan1) - первый провайдер
- порт 1 (lan2) - второй провайдер
- порт 4 (wan) - линк до другого ME1
- порт 5 (eth3) - внутренняя сеть
настройки бриджа на обоих роутерах одинаковые
bridge name bridge id STP enabled interfaces br3 8000.f8f082571768 no eth3 ra0 rai0 br0 8000.f8f0823d6dce no eth2
что имею
- интернет раздаётся, локальная сеть работает;
- wifi в целом работает, телефоны почти всегда цепляются к 5ГГц, выбирают правильную точку (мигрируют при перемещении по квартире);
- мой телефон (mi max 3) переключается между точками через 4G (то есть wifi гаснет, появляется 4g, потом заново появляется wifi); при этом рвутся соединения (в shellguard, например), что раздражает;
- пинги с моего телефона до компьютера больше 10мс, и скачут; с айфона до компьютера 10мс; с ноутбука через wifi до компьютера 3мс и более-менее стабильные;
- жена иногда жалуется на пропадание интернета на её телефоне; с компьютера (через провод) всё хорошо.
вопросы
- как проверить, что k/r работают?
- где должны бегать служебные пакеты для k/r? в br3/eth3 (где радио) или в br0/eth2 (где default gateway)? что-то сходу я их tcpdump'ом не увидел;
- такие задержки с телефонов - это нормально или нужно что-то тюнить? мне кажется, что ненормально. да и 3мс с ноутбука мне кажется многовато.
есть пара ME1, компьютер-роутер, два провайдера.
хочется завести обоих провайдеров на компьютер (сделано), настроить бесшовный роуминг между точками (тут вот сложности).
https://drive.google.com/file/d/1GnHv4XMEON6HayhHfac7Ny0lizSrmuzD/view?usp=sharing
что было сделано:
0. подготовка
залита последняя версия прошивки (8.2.10.RU.04092019), роутеры сброшены кнопкой.
1. из вебинтерфейса
- переведено в AP-Bridge;
- выбраны руками каналы (1 и 36 на одной точке, 13 и 60 на другой);
- зажата мощность на 2.4ГГц до 10%;
- включены k/r
2. из командной строки
заведено 3 vlan:
- 10 - внутренняя сеть (wifi);
- 11 - первый провайдер;
- 12 - второй провайдер.
switch vlan dump с первого ME1 (к которому подключен роутер):
vid portmap eg-tag eg-con stag ivl fid 1 11111-1 uuuuu-u 0 0 1 - 10 ---111- ---ttu- 0 0 1 - 11 ---11-- ---tt-- 0 0 1 - 12 ---11-- ---tt-- 0 0 1 - PVID: port pvid prio matrix 0 10 0 1111111 1 10 0 1111111 2 1 0 1111111 3 1 0 1111111 4 1 0 1111111 5 10 0 1111111 6 1 0 1111111
- порт 4 (wan) - линк до второго ME1
- порт 3 (lan4) - линк до компьютера
- порт 5 (eth3) - внутренняя сеть
на втором ME1:
vid portmap eg-tag eg-con stag ivl fid 1 --111-1 --uuu-u 0 0 1 - 10 ----11- ----tu- 0 0 1 - 11 1---1-- u---t-- 0 0 1 - 12 -1--1-- -u--t-- 0 0 1 - PVID: port pvid prio matrix 0 11 0 1111111 1 12 0 1111111 2 1 0 1111111 3 1 0 1111111 4 1 0 1111111 5 10 0 1111111 6 1 0 1111111
- порт 0 (lan1) - первый провайдер
- порт 1 (lan2) - второй провайдер
- порт 4 (wan) - линк до другого ME1
- порт 5 (eth3) - внутренняя сеть
настройки бриджа на обоих роутерах одинаковые
bridge name bridge id STP enabled interfaces br3 8000.f8f082571768 no eth3 ra0 rai0 br0 8000.f8f0823d6dce no eth2
что имею
- интернет раздаётся, локальная сеть работает;
- wifi в целом работает, телефоны почти всегда цепляются к 5ГГц, выбирают правильную точку (мигрируют при перемещении по квартире);
- мой телефон (mi max 3) переключается между точками через 4G (то есть wifi гаснет, появляется 4g, потом заново появляется wifi); при этом рвутся соединения (в shellguard, например), что раздражает;
- пинги с моего телефона до компьютера больше 10мс, и скачут; с айфона до компьютера 10мс; с ноутбука через wifi до компьютера 3мс и более-менее стабильные;
- жена иногда жалуется на пропадание интернета на её телефоне; с компьютера (через провод) всё хорошо.
вопросы
- как проверить, что k/r работают?
- где должны бегать служебные пакеты для k/r? в br3/eth3 (где радио) или в br0/eth2 (где default gateway)? что-то сходу я их tcpdump'ом не увидел;
- такие задержки с телефонов - это нормально или нужно что-то тюнить? мне кажется, что ненормально. да и 3мс с ноутбука мне кажется многовато.

Цитата: sfstudio от 20/10/2019, 13:27
- глянуть в лог на тему буковок FT при коннекте клиентов, глянуть iw scan на тему анонсов.
- всегда бегают по верх дефолтового бриджа, nvram_set 2860 IAPPDebug 4 && reboot
- эт радио, буферизация, неравномерность обслуживания и т.д. и т.п. Запросто может быть и 10мс в зависимости от клиентов, конфига, состояния эфира и т.д.. Нет ну можно кастрировать всё включая агрегацию powersave и т.д., пинг будет короткий и как вкопанный. Только по скорости вернёмся на уовень 802.11g по сути. А тут ещё и MBSSID....
Да обновиться бы до 11го там с конфигом MBSSID косяк в UI пофикшен кроме прочего, хоть вы видимо на него и не наступили.
Далее, не видел ни одного сяоми (и прочего китайского хлама) что бы поддерживало K/R. От слова совсем. Т.е. переключаться он будет совсем топорно теряя сеть с вероятность 50/50 и часто когда уже PER зашкалил и пакеты во всю теряются. Так что только костылями на стороне телефона можно попробовать обойти, см раздел по роумингу там они есть.
Чем меньше городушек - тем шелковистее волосы.
- глянуть в лог на тему буковок FT при коннекте клиентов, глянуть iw scan на тему анонсов.
- всегда бегают по верх дефолтового бриджа, nvram_set 2860 IAPPDebug 4 && reboot
- эт радио, буферизация, неравномерность обслуживания и т.д. и т.п. Запросто может быть и 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сек.
Ну и да, поддержка 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) не работает. =) Муркетинг да, он такой беспощадный.
С точки зрения миграции самая беспробленая сеть это где все 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+ прошло.
ББрр только дошло. Городушки с вланами эт только ради того что бы провода до компа от провов не тянуть??
Дык может эт. По нормальному сделать таки? Дотянуть 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 но этот вариант абсолютно точно работающий корректно и обкатанный за исключением транзита хвостов от провов.
Можно попробовать сделать так. Ну раз сервер есть. Отказаться от 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-соединения - было бы совсем хорошо.
ся бы до 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/роумингом разобраться )
Цитата: 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?
хм, достал старый разбитый телефон (тоже сяоми, 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 у меня нет, если это играет какую-то роль.
эт радио, буферизация, неравномерность обслуживания и т.д. и т.п. Запросто может быть и 10мс в зависимости от клиентов, конфига, состояния эфира и т.д.. Нет ну можно кастрировать всё включая агрегацию powersave и т.д., пинг будет короткий и как вкопанный. Только по скорости вернёмся на уовень 802.11g по сути. А тут ещё и MBSSID....
имелось в виду, что быть может где-то стоит подкрутить в сторону меньшей оптимистичности и соединение будет формально на более низкой скорости, но и задержки упадут?
я сейчас вижу скорости соединения с телефонами на 5ГГц 300+мбит/с, это красиво, конечно, но необходимость таких скоростей в реальной жизни под сомнением.
BTW, MBSSID у меня нет, если это играет какую-то роль.

Цитата: zrain от 21/10/2019, 10:40Цитата: sfstudio от 20/10/2019, 13:48С точки зрения миграции самая беспробленая сеть это где все AP на одном канале.
А это не повлияет на общую стабильность и скорость сети?
Цитата: 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
перенёс айфон, из соседней комнаты, он зарегался сначала в 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 на уровень критичных багфиксов и простых ответов в пределах типовых конфигураций. Разбор полётов выше сильно выходит за эти рамки.
Не зависимо используется тут FT или нет видно, что клиент идёт по длинной процедуре. Отсутствие записей в логе от iapp демона говорит о том что R вообще не включен. Т.к. даже для не FT клиентов в логе бы были бы move notify а их нет. При этом после миграции на стороне АП с которой мигрировал была бы запись в логе от драйвера о том что клиент мигрировал именно с неё и move notify прилетело с АП куда мигрировал.
P.S. Напоминаю, что мы осуществляем саппорт исключительно на уровне "нашёл баг в официальных сборках с sf.net." Что-то с выше по ТП взял на себя ваш вендор. Пожалуйста обратитесь к нему. Ещё в марте была дана информация о переводе поддержки SNR-CPE на уровень критичных багфиксов и простых ответов в пределах типовых конфигураций. Разбор полётов выше сильно выходит за эти рамки.