Jump to content

Padavan

Global Moderators
  • Content count

    233
  • Joined

  • Last visited

  • Days Won

    12

Padavan last won the day on November 27 2017

Padavan had the most liked content!

Community Reputation

254 Excellent

4 Followers

About Padavan

  • Rank
    Content Generator

Converted

  • Location
    Keenetic Giga II

Equipment

  • Keenetic
    Giga3
  1. Как уже сказали, M2U работает автоматически по подписке, более того, работает на уровне Wireless драйвера без копирования skb (используется быстрое клонирование), что положительно сказывается на загрузке CPU. В противном случае вы бы не смогли смотреть IPTV мультикаст с WiFi клиента.
  2. Shadow87 Примерно с 1.5 недели назад был добавлен фикс, связанный с FlowControl CPU порта,,он коснулся и Ultra2 (его GigabitEthernet1), очень надеюсь это окончательно решит проблему.
  3. В последних модификациях (и это перенесено до 2.09 (еще не опубликованной)), MAC читается драйвером напрямую с EEPROM, схема назначения закреплена и меняться больше не будет. Могу 100% заверить. Тем не менее, на ra0..ra4 ничего меняться не должно было. Если это вас беспокоит, пришлите в личку MAC, который на этикетке и что было/стало.
  4. 1) MAC адрес(а) прошит(ы) в EEPROM, раздельно для 2.4 и 5ГГц 2) На основании этого базового MAC назначается MAC на виртуальные интерфейсы ra0..ra4, apcli0 и rai0..rai4, apclii0 (2 возможных варианта, привязаны к модели чипа). MAC в EEPROM никто не меняет, он(и) прошит(ы) на фабрике и уникальные для вашего экземпляра. Назначение MAC на виртуальные интерфейсы точно менялось для старых устройств, там 2 варианта назначения. Для новых устройств всегда используется ENHANCED NEW_MBSSID_MODE и меняться не может. На Extra менялся только 5ГГц MAC из-за бага после 2.08.
  5. Версия 2.11.A.8.0-5: > Wi-Fi: исправлено некорректное назначение MAC-адреса на 5 ГГц, что приводило к проблемам видимости SSID и подключения Касалось старой Ultra и Extra.
  6. Нет, FCU не ставил, но можно поставить хотя бы на стенде, не вопрос. Под Linux это работает со многими адаптерами, в Wireshark доступен Monitor. Под Win с Intel адаптерами точно не работает. С какими-то работает, но я не в курсе, использую Wireshark под линухом. Монитор запускается на любом хосту, на нужном канале. Дальше производится подключение нужного клиента к AP и этот трафик задампится с 802.11 заголовками. После чего можно сохранить в файл для последующего анализа.
  7. Расклад простой, minidlna съедает всю доступную RAM в процессе парсинга файлов. Очень прожорливые библиотеки ffmpeg и libjpeg. Плюс часть RAM перетекает в IO кеши в процессе чтения файлов. NDM постоянно считывает состояние Wireless клиентов через IOCTL вызов в драйвер (RTMPIoctlGetMacTable). Поправить конкретно эту ошибку с Wireless можно, сейчас драйвер под каждый IOCTL запрос в RTMPIoctlGetMacTable аллокирует блок памяти 16КБ с использованием GFP_ATOMIC флага (но на деле там не атомарный контекст), как видно в SLAB-ах нет доступного блока, а GFP_ATOMIC не разрешает ожидания для освобождения RAM из IO кешей. В итоге отказ аллокатора и NDM получает ошибку IOCTL + дамп стека при Page Allocation Failure. В неатомарном контексте можно засыпать и дождаться пока аллокатор получит свободный SLAB после pagecache reclaim. Починить можно и нужно, конкретно эта проблема уйдет, однако никакой гарантии нет, что minidlna рано или поздно съест всю RAM, затем сам получит отказ аллокатора и будет пристрелен. vasek00 usbnet драйвер ax88179_178a аллокирует гигантские RX пакеты размером 20480 байт. Потому что чип склеивает до 12 пакетов в один URB. Соответственно требуется SLAB 32K, чтобы аллокировать такой RX skb. Аллокируются RX в атомарном контексте, где не положено засыпать (GFP_ATOMIC). Соответственно если сейчас в SLAB-ах нет такого блока, аллокатор немедленно возвращает Page Allocatio Failure и usbnet драйвер не получает свежий RX буфер для принятия мега-пакета. В лого хорошо видно, что хоть и есть свободная рама, но 32K SLAB-ов нет в наличии: kernel: Normal: 203*4kB 230*8kB 4*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2716kB Для понимания - Ethernet драйвер SoC использует под RX skb не больше 2048 байт, Wireless - 4096 байт. Их всегда достаточно в SLAB-ах. usbnet драйверы часто под RX используют большие skb (до 32КБ), так как USB чип склеивает пакеты в большие блоки до 10..15 штук. Здесь проблема нехватки доступной RAM в атомарном контексте будет стоять более остро. Кроме как подрезать аппетиты ffmpeg и libjpeg - нет решения - ждать нельзя в атомарном контексте, а размер буфера уменьшить нельзя, иначе гигантские пакеты не будут влезать
  8. flash У вас в селфтесте клиент висит в 802.11a на 54Mbps. Это Legacy OFDM. Вопрос на засыпку - случаем не включали на Windows клиентах галочку совместимости с FIPS? Это форсирует клиента в Legacy. Чтобы выяснить кто виноват - клиент или AP в свале в Legacy, нужно снимать wireshark дамп 802.11 заголовков во время подключения к AP. Могу с уверенностью сказать что дело не в AP, у меня 4 разных 11ac клиента из под Win10 коннектятся на 11ac 80МГц. Что-то поменялось у вас на клиентах. > Хотелось бы в ручном режиме выбирать приоритетную ширину канала для каждого девайся в отдельности Возможно сделать только ограничение конкретного клиента на 20 или на 20/40. Форсировать в 40 или в 80 не получится, это невозможно по стандарту. На самом деле, только в 11ac есть проблема автосогласования на 40МГц, в 11n все однозначно задается 1 флагом и никаких дополнительных элементов в пакете не требуется. В 11ac для ограничения 40МГц, со стороны клиента требуется дополнительный элемент в пакете и это требование на текущий момент не соблюдается у части клиентов (и попавших в этот топик).
  9. Проверил 2.10 на Giga3 чтение с USB3 накопителя по 5ГГц: SMB: 31МБ/с FTP: 46МБ/с Странно откуда у вас 23 на более мощном девайсе. Тем не менее, похоже на регрессию в cifsnq, в ближайшее время выясним. К Wireless у меня нет вопросов.
  10. sokol2007 Лучше сделать отдельную тему, чтобы не мешать все в кучу. В логе обычно видно, кто был инициатор отключения, так что нужны куски лога во время таких отключений.
  11. Да, это как раз следствие активного cгона клиента с бэнда. Возможно сделаем переключатель на пассивный режим, тогда AP будет загонять клиента на нужный бэнд только во время его подключения, но никогда не будет его сгонять принудительно. - В последнем драфте поправлены пропуски ответов на probe/auth. Если клиент делает небольшое кол-во probe/auth до тех пор как бросает подключение к AP, это критично. Специально проверил подключение 2g-only клиентов - первое подключение как обычно с небольшой задержкой, чтобы дождаться таймаута 5g probe, дальше клиент заносится в кеш и подключение его всегда мгновенное, без единого пропуска ответа на probe/auth.
  12. ИваN Ну какая такая-же? Там нет Band Steering, так что связи с обсуждением никакой.
  13. 2.4-only клиенты пропускаются мимо Band Steering и более того, заносятся в кеш-таблицу, чтобы подключать их в следующий раз моментально, не дожидаясь таймаута probe 5ГГц. По крайней мере этот так уже около месяца в прошивке. При включенном Band Steering, первое подключение 2.4-only клиента задерживается примерно на 4 секунды, после чего он заносится в кеш 2.4-only и в дальнейшем обрабатывается моментально. Кеш хранится в RAM, т.е. до перезагрузки устройства.
  14. Да, это важное замечание. Модуль уже достали, попробуем воспроизвести проблему.
  15. Band Steering определяет поведение AP, а не клиента. У нас изначально используется активный вариант Band Steering, когда AP принудительно сталкивает клиента с текущего бэнда (при критическом изменении уровня RSSI, полученного от клиента), для того чтобы он переключился на другой бэнд. Никогда нельзя дать гарантию, что клиент, которого нагло нагнали, вернется к смежному бэнду. Он может уйти как на другую AP (если она есть в списке реквизитов и доступна), так и на LTE, если тот включен. Для примера - iOS. Если iOS клиента 3 раза согнать принудительно от AP и, в случае, если между предыдущим DEASSOC прошло менее 3 минут, iOS добавляет эту AP во временный бан и вообще перестает к ней подключаться, пока принудительно не тапнуть снова по данной AP в списке. Поэтому был сделан woarkaround, который не отключает клиента принудительно с 2.4 (чтобы перейти на 5), пока не истекло 3 минуты с предыдущего DEASSOC. Единственный вариант, который сглаживает данные углы - это пассивный режим Band-Steering, когда бэнд предоставляется клиенту в момент подключения (и в момент probe request) по текущему уровню и клиент в дальнейшем никогда принудительно не выгоняется с этого бэнда, вся логика отключения дается на откуп клиенту. Но в этом случае нет гарантии, что клиент сам переключится на другой бэнд при ухудшении сигнала, он может это сделать когда данные совсем перестанут ходить. Пассивный режим лишь назначает бэнд конкретному клиенту во время подключения. Точки доступа CISCO используют именно пассивный Band-Steering.
×