Padavan
-
Постов
495 -
Зарегистрирован
-
Посещение
-
Победитель дней
27
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Сообщения, опубликованные Padavan
-
-
ydzhus
Для начала проверьте канал, в 2.09 разрешен выбор каналов 149..161 в режиме автовыбора. Если канал у вас задан не фиксированный, то результат автовыбора будет разный на 2.08 и 2.09.
Я вот не вижу никаких значимых ухудшений по работе 2.08 и 2.09 на 7612 радио, тем более там по радиотракту разница только в ограничении RX гаина на ~2dB. Это может сказаться на расстояниях больше 8 метров. Но 336 vs 27 выглядит каким-то ужастиком.
-
1
-
-
Спасибо.
Нужно было выяснить что нет регрессии, поскольку тестировать OTT из глобальной сети в других условиях просто нереально, трасса будет совсем иной, как и результаты. Да и у провайдеров приоритеты на разный тип трафика (а также параметры DPI) разные.
-
IgaX
На текущих прошивках DFS отключен при сборке драйвера, поэтому параметр IEEE80211H не имеет силу (специально закрыт дефайном). CSA аннонсится только в 5ГГц и только при включенном IEEE80211H, для того чтобы предупреждать клиента, что происходит уход на другой канал при обнаружении сигнала радара. DFS используется не только в USA, но и в ряде европейских стран.
У нас планируется активация DFS/TPC + 802.11h (а также ED-CCA) по коду региона, который прошит во флеше при производстве, при этом смена региона в настройках не будет влиять на эти два параметра, так как они обязательно сертифицируемые для конкретных стран.
Тем не менее, в тех странах где DFS/TPC и соответственно 802.11h не используется (RU в частности), CSA работать не будет. И это не должно вызывать никаких проблем на клиентах, если AP меняет канал (на любом бэнде).
Соответственно, если AP сменила канал без CSA, клиент обязан потерять AP по прошествию 3..4 секунд из-за неполучения от AP сигнала маяков на данном канале и сделав рескан, принять решение о переподключении. Застрять он может только если его нагнали с бэнда по событию Band Steering (через Deauth), но клиент недополучил Deauth (например по причине Power Save Mode).
-
Я так понимаю что при возврате на 2.09.A.5.0-2 ситуация не изменилась? Соответственно как таковой регрессии в А.6 нет.
-
enpa
Multicast у нас на стенде прошел проверку целостности пайлоада после передачи с сервера на клиента (если говорить о А.6), поэтому сначала не разглядели что речь идет о OTT источнике (unicast).
Все текущие изменения по ядру приняты в ветку stable для 3.2 (маинтайнер Ben Hutchings) и вошли в LongTerm Debian. Это не 100% гарантия, иногда бывают осечки.
Чтобы исключить смену условий и окружения, не могли бы вы прошить предыдущую сборку и не меняя настроек, попробовать воспроизвести эту проблему на месте? Спасибо.
-
1
-
-
enpa
Band Steering на самом деле не такой уж злой и вероломный.
Он блокирует доступ определенному клиенту только в 5 или только в 2.4. При этом блокируется не только само подключение, но и AP не отвечает клиенту на probe request. Если клиент использует активный режим сканирования (probe request - response), он также в активном режиме не увидит SSID (в пассивном всегда будет виден).
Однако, Band Steering сталкивая принудительно клиента с одного band на другой, также отправляет ему Deauth. Если клиент не поймает Deauth, он залипнет, считая что еще подключен.
Фича Band Steering отключается также автоматически, если SSID на 2.4 и 5 отличается, т.е. необязательно через CLI отключать.
-
1
-
-
AJ_
Уровни TxPower прошиты в EEPROM на фабрике, в драйверах не было изменений (и не будет), прямо или косвенно влияющих на уровень исходящего сигнала от AP.
Sergey Zozulya
На Android 6.0 и выше, с некоторыми клиентами наблюдается проблема, когда они не ловят сигнал Deauth, который рассылает AP перед началом автоскана (по всей вероятности что клиент находится в режиме Power Save Mode), поэтому клиент не получает сигнал отключения от AP и продолжает висеть на AP, считая что еще подключен. Обычно, если канал меняется (что в 5ГГц явление редкое из-за чистоты эфира), то клиент потеряв маяки от AP, ресканит каналы и пытается переподключиться заново. Если канал не поменялся, то он может застрять в состоянии, когда считает что подключен, чего на самом деле нет.
В таком случае на 5ГГц можно увеличить интервал автовыбора канала на максимум или отключить его совсем, так как в чистом эфире с более сильной изоляцией от соседей, нет большого смысла постоянно менять канал.-
1
-
-
В готовящемся draft 2.09, периодические ARP броадкасты (в рамках фичи hotspot discovery) были отключены на Wireless path.
-
Со скрытыми ничего измениться не должно. Скрытые перебираются из списка BSS по совпадению AuthType и EncrypType.
Основное отличие PartialScan - он перебирает каналы не все друг за другом, а после каждого возвращается назад, чтобы продолжить на короткое время beaconing на текущем канале. Это позволяет сохранить своих клиентов.-
1
-
-
2.09 draft выйдет скорее всего завтра (в субботу).
-
1
-
-
Также применили функцию PartialScan, которая после переключения на следующий канал каждый раз возвращается на текущий. Это позволяет дополнительно отправлять несколько маяков и наши клиенты не теряют связь с AP. В итоге сканирование каналов работает дольше, но клиенты не рвутся.
Сейчас логика будет такова - если чистый AP-Client, то работает по старому - каждые 5 секунд в лоб сканирует эфир. Если AP + AP-Client, то с каждой попыткой наращивается интервал (лимит до 40с) и сканирование выполняется по методу PartialScan. В итоге получили удовлетворительный результат.-
2
-
-
vincome
Если вы указали канал явно, то перебора каналов быть не должно. Только Probe, которые не повляют на ваших подключенных клиентов.
-
1
-
-
Проблему на 100% решить невозможно, потому что клиент должен сканировать эфир, чтобы он смог подключится к удаленной AP (она может появиться на любом канале). Сканирование эфира занимает 4..5 секунд, в это время клиент перебирает все каналы. Во время сканирования, все клиенты, подключенные к этой нашей точке доступа теряют ее, так как канал меняется. Дальше уже зависит от самих клиентов, если он за это время не отключится, значит будет жить дальше. Другое дело что это происходит каждые 5 секунд и работать с такой AP становится просто невозможно.
На этой неделе я как раз занимался этим вопросом и сделал динамический интервал сканирования от числа неудачных попыток. В итоге интервал сканирования при нескольких неудачах доходит до 40секунд, что позволяет хоть как-то работать с AP. Растягивать до бесконечности или вообще отключать сканирование тоже плохо, так как после того как удаленная AP появится в эфире, клиент просто не сможет к ней подключиться.
-
1
-
-
Да, в логе отображаются только успешный автоскан, когда прошли проверки. Если пропущено, то ничего не пишет.
-
Solonix
Уточните пожалуйста релиз 2.07, на котором проблема не наблюдается в ваших условиях.
-
ИваN
KorDen
IgaXКартина следующая. Небольшая регрессия есть - в 2.09 первая инициализация драйвера не подставляет SSID, при этом драйвер сам подставляет HT_APx. В 2.08 и ранее, в SSID подставляется фабричное значение, а далее уже при загрузке startup-config подставляется значения из сохраненных настроек.
Угрозе безопасности нет никакой, во первых, маяки эти светятся около половины секунды, во вторых, даже если успеть подключиться, то AP отстрелит клиентов, потому что интерфейс будет закрыт. В-третьих, эти несколько сот миллисекунд интерфейс не включен в бридж и пакеты никуда не пройдут.Конечно, этот недочет имеет смысл исправить, есть изящное решение.
-
6
-
-
Общий трафик ничего не даст. Когда приходит запланированное время для автоскана, проверяется трафик за последние 10 секунд. Если он превысил лимит, то автоскан пропускается.
Тут можно сделать небольшую доработку - если лимит превышен, сделать еще хотя бы 3 попытки с небольшим интервалом. И если они провалятся, то уже откладывать до следующего события планировщика
-
2
-
-
KorDen
Как поймаете пропадание AP из эфира, попробуйте сделать следующее - зажмите кнопку WPS дольше 5 секунд - это вызовет отключение радиотракта. И повторная процедура снова запустит радиотракт.
Нужно понять, появится ли AP после этой процедуры.
-
Проверил версию Wireless драйвера mt76x2 в сборке v2.07(ABGH.3)C2, с тех пор изменений было не так много, ни одно из них не касающееся радиотракта, в основном по логике коннекта AP-Client. Так что очень странно.
Вчера вышла 2.07.С.4, там Wireless драйвер по срезу идентичный с 2.08.
-
Трафик виден в закладке Wi-Fi клиентов. Но его придется просуммировать по клиентам, чтобы оценить.
В 2 раза поднять лимиты можно, тут главное чтобы не возник дискомфорт от того что AP сменит канал, когда вам не нужно. Так как смена канала вызовет переподключение клиента, что даст затык на 3..5 секунд. -
KorDen
Для информации - на Giga3/Ultra2/Air/Extra2 используется один и тот же Wireless драйвер 5ГГц mt76x2 3.0.5.0 (т.е. собирается из общего котла). Разница лишь в eLNA (Giga3/Ultra2) и iLNA (Air/Extra2).
Если AP исчезает из эфира, значит есть какая-то мощная помеха в 5ГГц. Некоторые бытовые приборы (в том числе HD телевизоры) могут генерить подобную помеху в 5ГГц спектре. Драйвер постоянно подстраивает усиление входного сигнала, опираясь на клиентов. При максимальном усилении чип уязвим для помех, которые могут вызвать флуд на входе, это вызывает пропадание AP в эфире (отсутствие маяков). Как только помеха исчезает, маяки появляются автоматически.
Если роутер находится в непосредственной близости с ТВ, попробуйте отнести его на несколько метров.
-
Можно немного подрезать верхний уровень усиления AGC 5ГГц в драйвере, это позволит избежать подобной проблемы, но немного ухудшится слышимость удаленных клиентов.-
1
-
-
Лимиты можно увеличить, предлагайте варианты. Однако здесь есть тонкая грань, которая определяет уровень комфорта. Главное не загрубить.
-
1
-
-
Значит есть небольшой паразитный трафик.
В финальном варианте лимиты такие:
RX: 9Kbps
TX: 3Kbps
Если в течении 10 секунд трафик не превышал этих лимитов, то при приходе планирования автоскана, он разрешается. Иначе пропускается. Когда нет подключенных клиентов - разрешается автоматически. Напоминаю, что в этот момент также проверяется активность WPS кнопки и включенного Wireless клиента (например WISP). При подключенном клиенте любой автоскан блокируется, так как клиент является ведущим, AP - ведомой.-
1
-
-
Тут вряд-ли пахнет неисправностью. У 802.11 очень сложная архитектура, и огромное кол-во потенциальных проблем совместимости с разными клиентами.
Для примера, недавно выяснили проблему с Honor8, который при подключении сообщает о поддержке 11ac 80МГц, но реально работает на 40МГц. В итоге половину данных что ему шлет AP он теряет и скорость RX очень низкая. Если выставить AP принудительно на 40МГц, работает отлично. Баг в драйвере клиента.-
3
-
Wi-Fi 5 ГГц на 2.09.A.7.0-3
в 2.09
Опубликовано
Специально сейчас замерил на U2, клиент в 4 метрах, пилы нет, скорость > 400 Mbps.
Никакого криминала не вижу. Единственное что могло хоть как-то повлиять - это небольшое занижение гаина, о котором писал выше, но эту разницу можно увидеть только в плохих условиях.
Какое расстояние у вас до клиента, есть ли препятствия?
ЗЫ. На графике WAN -> WiFi 5, т.е. плюс операция NAT. LAN -> WiFi легче для роутера.