Jump to content

Padavan

Global Moderators
  • Content Count

    300
  • Joined

  • Last visited

  • Days Won

    14

Padavan last won the day on January 21

Padavan had the most liked content!

Community Reputation

324 Excellent

7 Followers

About Padavan

  • Rank
    Content Generator

Converted

  • Location
    Keenetic Giga II

Equipment

  • Keenetic
    Giga3

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Padavan

    Потому что один чип радио не может одновременно работать в одном диапазоне, но на двух разных каналах.Это физически невозможно.
  2. Padavan

    Это не баг. По дизайну, при 3-адресном заголовке 802.11, не могут в одном эфире (т.е. на одном канале) работать два клиента с одинаковым MAC. Когда вы включаете функцию MAC-репитера, то она проксирует на каждого своего клиента отдельное вышестоящее соединение к корневой точке доступа. Если клиент беспроводной и садится из под того же бэнда, на котором работает MAC-repeater, то сейчас прокси-MAC смешивается из OUI AP-Client и 3 октета от реального клиента. Иначе в одном эфире окажутся два клиента с одинаковым MAC, и все 4 пира будут слышат друг друга, в итоге сильно просаживается скорость из-за хаоса с ACK (очень сильная пила). Потому как неизвестно от кого прилетает ACK, так как MAC-и одинаковые. Поэтому, если MAC-репитер вывешивает прокси соединение к вышестоящей корневой AP на клиента: - проводного - беспроводного, но с противоположного бэнда (например MAC-repeater настроен на 2.4, а клиент пришел с 5ГГц или наоборот) то в этом случае проксируется оригинальный MAC клиента. Иначе, формируется составной MAC для прокси соединения, чтобы избежать двух одинаковых MAC в одном эфире. Все другие прозрачные мосты основаны на базе WDS и используют 4-x адресный заголовок 802.11. По своей сути MAC-repeater - это костыль, чтобы заткнуть брешь MAC Address Translation (MAT), без которой нельзя работать при 3-адресном заголовке 802.11. У нас точно появится решение на базе WDS (4-адресного заголовка), после чего решим что делать с MAC-repeater-ом.
  3. Да, спасибо за фидбэк, сломано в 2.15 и только на свитче MT7628. К следующей сборке исправим.
  4. Padavan

    При включении в настройках 11r (FT), в список IE у маяков и пакетов probe/assoc response добавляется еще один тип Auth, который не знает ваш клиент и отказывается подключаться, несмотря на то что в списке есть WPA2-PSK. Точно такая же проблема с Intel 4965 и его старыми драйверами. Проблема чисто софтовая (в драйвере) на стороне клиента. Как можно вылечить баг на клиенте со стороны AP? Лечить нужно клиента. Есть некоторые мысли, как подпереть костылем таких древних клиентов (так как у большинства не будет обновлений драйверов), надо пробовать, но это может сломать распознавание поддержки FT у нормальных клиентов.
  5. T@rkus Спасибо за логи, попробуем разобраться.
  6. Речь о другом, наличие такой ошибки допустимо, факторы я перечислил. Если у вас после 2.14.C.0.0-3 все равно весь лог засыпан этой ошибкой, то что-то идет не так, нужно разбираться в конкретном случае.
  7. Ошибка означает, что хост-кейхолдер не может найти в базе PMK-R0 или R1 запись при попытке клиента пройти на нем FT auth. Такое сейчас возможно, после того как - вы смените любые настройки Wireless и база PMK будет очищена при перезапуске драйвера - роутер/AP будут перезагружены - изменится IP на AP, при этом управляющий демон будет перезапущен На текущий момент, в 2.14.C.0.0-3 это все факторы, приводящие к очистке базы данных PMK-R1 кейхолдера. До 2.14.C.0.0-3 существовали еще критерии, когда база кейхолдера обнулялась. После того как клиент не смог перейти по FT auth, он обычно коннектится стандартным способом, используя 4-way хендшейк и база кейхолдера обновляется автоматически. У нас есть идеи, как побороть первые 2 пункта, не прибегая к сохранению PMK-R1 (так как он секретный). - На данной ошибке не стоит заострять внимание, так как результат FT auth выводили специально для внутренней отладки.
  8. Ethernet драйвер потребляет меньше ресурсов CPU на входящем локальном трафике, чем Wireless драйвер. Wireless драйвер занимаеется преобразованием 802.11 заголовков в 802.3, де-аггрегацией MPDU. Локальный трафик также обычно имеет огромные TCP пакеты, которые также склеиваются программно уже в сетевом стеке. На транзитном трафике (Wifi <-> WAN) все будет хорошо (там пакеты обычно не больше MTU), но для локального трафика, Wireless всегда будет проигрывать Ethernet по ресурсам CPU. Обратите внимание на загрузку CPU при копировании на накопитель. Она будет под 100%.
  9. Это фича, а не баг. Если клиент подключается в VHT режиме (с QAM256), то CLI так и пишет о 11ac, потому что это единственный статус, позволяющий понять что клиент в VHT режиме. Для того чтобы понимать как формируется mcs и rate, они формируются именно по 11ac таблице. WebUI автоматически конвертит строку в 11n, чтобы не смущать людей. Вывод информации в CLI разбирает техподдержка в ваших селфтестах, им важно понимать текущий режим.
  10. В сборке 2.11.D.0.0-1 драйвер rt539x для Giga2 отстает от 2.14.B.0.0-1 только на 1 изменение - с 2.14.A.5.0-0 увеличено максимальное число клиентов с 32 до 64 (увеличен массив статической таблицы клиентов). Это никак не должно сказываться на качестве работы. По поводу проблемы подключения, посмотрим что еще можно сделать, проблема обычно связана с тем что иногда клиент не прощается со старой AP.
  11. Padavan

    Leksey118 MCU микрокод для чипа MT7615 не менялся с 2.12 прошивки. Начиная с 2.13, в драйвере добавился функционал MAC-repeater и FT + RRM (11r + 11k). При отключенном в настройках 11r, драйвер должен себя вести так же как и 2.12. MAC repeater включается только в режимах Адаптер и Усилитель, причем из CLI (пока). На первых сборках 2.13 не работало управление TxPower из Web интерфейса, в релизе 2.13 и свежей 2.14 это исправлено. Также в релизе 2.13 при выборе 11gn (любого без 11b) не вещается поддержка 11b в маяках и probe/assoc response. У вас в настройках стоит compatibility BGN, значит для вас ничего не изменилось. У вас с этим клиентом (00:0c:43:95:55:e4) одна проблема Sep 26 05:55:38 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(00:0c:43:95:55:e4) pairwise key handshaking timeout. Sep 26 05:55:38 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(00:0c:43:95:55:e4) had deauthenticated (reason: PTK 4-way handshake timeout). Попробуйте в настройках точки 2.4 - выбрать режим 11g/n - временно отключить eBF и MU-MIMO - временно отключить TxBurst и QAM256 Без дампа эфира сложно понять что происходит и кто виноват в обрыве 4way хендшейка, чтобы понять, нужно на внешнем хосте включать режим монитора на 11 канале и захватывать 802.11 заголовки во время проблемного подключения клиента.
  12. AndreyUA Несколько наводящих вопросов: - замеченные проблемы с этими двумя клиентами стали проявляться с 2.13? Работали ли ранее по другому? - на других кинетиках, кроме 1010 проблема также есть? - включен ли RRM и FT в настройках на 2.13?
  13. Padavan

    При включении FT и RRM в маяки и probe/assoc response добавляются дополнительные элементы, на которые может реагировать Apple. Просьба проверить тот же самый кейз на 2.13, только временно отключить k и r.
  14. У каждого вендора свой механизм дистрибуции PMK R1, это не оговорено стандартом. Поэтому точки доступа разных вендоров не смогут работать в одном мобильном домене 11r.
×