Padavan
-
Постов
487 -
Зарегистрирован
-
Посещение
-
Победитель дней
27
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Сообщения, опубликованные Padavan
-
-
Расклад простой, 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, затем сам получит отказ аллокатора и будет пристрелен.
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 - нет решения - ждать нельзя в атомарном контексте, а размер буфера уменьшить нельзя, иначе гигантские пакеты не будут влезать
-
4
-
-
У вас в селфтесте клиент висит в 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МГц, со стороны клиента требуется дополнительный элемент в пакете и это требование на текущий момент не соблюдается у части клиентов (и попавших в этот топик).
-
1
-
-
Проверил 2.10 на Giga3 чтение с USB3 накопителя по 5ГГц:
SMB: 31МБ/с
FTP: 46МБ/сСтранно откуда у вас 23 на более мощном девайсе.
Тем не менее, похоже на регрессию в cifsnq, в ближайшее время выясним. К Wireless у меня нет вопросов.
-
Лучше сделать отдельную тему, чтобы не мешать все в кучу. В логе обычно видно, кто был инициатор отключения, так что нужны куски лога во время таких отключений.
-
Цитата
На ноуте с BCM4352 один раз дико выбесило, когда видимо на грани приема (по мнению роутера) коннект прервался и несколько секунд тупил, прежде чем переключиться на 2.4. Аналогичное было на другом смарте, но тот вместо переключения на другую сеть перешел на мобильные данные, и переподключился к точке только через несколько минут
Да, это как раз следствие активного cгона клиента с бэнда. Возможно сделаем переключатель на пассивный режим, тогда AP будет загонять клиента на нужный бэнд только во время его подключения, но никогда не будет его сгонять принудительно.
-
В последнем драфте поправлены пропуски ответов на probe/auth. Если клиент делает небольшое кол-во probe/auth до тех пор как бросает подключение к AP, это критично. Специально проверил подключение 2g-only клиентов - первое подключение как обычно с небольшой задержкой, чтобы дождаться таймаута 5g probe, дальше клиент заносится в кеш и подключение его всегда мгновенное, без единого пропуска ответа на probe/auth. -
Ну какая такая-же? Там нет Band Steering, так что связи с обсуждением никакой.
-
2
-
-
2.4-only клиенты пропускаются мимо Band Steering и более того, заносятся в кеш-таблицу, чтобы подключать их в следующий раз моментально, не дожидаясь таймаута probe 5ГГц. По крайней мере этот так уже около месяца в прошивке.
При включенном Band Steering, первое подключение 2.4-only клиента задерживается примерно на 4 секунды, после чего он заносится в кеш 2.4-only и в дальнейшем обрабатывается моментально. Кеш хранится в RAM, т.е. до перезагрузки устройства.
-
1
-
-
Да, это важное замечание.
Модуль уже достали, попробуем воспроизвести проблему.
-
Цитата
Band Steering нормально не работает с момента появления.
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.
-
1
-
1
-
-
Если не затруднит, проверьте на старых прошивках <= 2.06 и на 2.08.
В данный момент такого модуля под руками нет, только заказывать.
-
В USB3 порт что-то подключено?
-
Исправление касалось старых Ultra1/Extra.
Для Ultra2 все рабочее из коробки. Специально проверил, подключается с любых клиентов без проблем моментально, обе AP видны через WiFi Analyzer, даже при включенном Band Steering. Убедитесь что MAC адреса различаются у обоих AP.
-
1
-
-
В постоянном пользовании Ultra2 и Giga3, даже близко нет описываемых проблем. А что по скорости, на Mi6 в прямой видимости выдает до 400Mbps в 5ГГц.
Да, с Band Steering были шерховатости, сейчас в драфте он в целом допилен, но даже если не устраивает его работа (разные клиенты могут вести себя по разному, когда ими начинают манипулировать), его всегда можно отключить и сделать два разных SSID.
-
1
-
-
Не путаем карты, проблема описываемая топикстартером с Ultra 1, в точности такая-же регрессия на старой Extra. Проблема из-за некорректного назначения MAC на 5ГГц интерфейс на этих двух устройствах. Точнее так - на 5ГГц назначался MAC от 2.4ГГц. Я буквально вчера нарвался сам на эту регрессию и решение уже готово для 2.09 и выше. Для всех остальных устройств это не актуально, только для старых Ultra и Extra на 2.09 и выше.
В новом драфте уже будет решение.
-
3
-
-
В данном куске лога нет ничего о текущей проблеме. PPE отключен, видно.
У нас с одним из пользователей с данной проблемой было выяснено, что со стороны LAN был хост, который поднимал PHY линк, но не принимал пакеты. Конкретно был виноват смарт-тв Sony, который при включении питания в standby режиме поднимал линк на порту, но его MAC не был настроен. В итоге в этому порту начинал расти затор (обычно из броадкаст пакетов), до тех пор, пока свитч не забивался под завязку, а далее по цепочке оба GMAC вставали колом из-за невозможности отправить ни единого пакета. Отключение такого хоста из порта восстанавливало работу. После настройки сетевого интерфейса смарт-тв, он перестал поднимать линк в standby режиме и проблему как рукой сняло.
-
1
-
-
Shadow87
Есть подозрение на проблему нового алгоритма flush в PPE (появился с 2.10, затянут из SDK 5.0.3.0), для проверки просто временно отключите hw_nat (no ppe hardware), если за неделю-две проблема не проявится, значит оно.
-
1
-
-
Когда клиент хочет отключиться от точки доступа, он должен прислать ей фрейм DEAUTH или DISASSOC, где в качестве MAC адреса получателя указывается BSSID точки доступа. Точка доступа, получив такой фрейм, первым делом проверяет, ей ли он адресован, если нет, то такой фрейм отбрасывается. Если в вашем случае клиент остается висеть "мертвой душой" на одной из двух AP, то значит:
- либо он не прислал фрейм DEAUTH или DISASSOC
- либо прислал такой фрейм с чужим BSSID в качестве MAC адреса получателяНа роутере обе AP имеют разный BSSID (MAC), так и должно быть.
P.S.
Зависшая ассоциация будет удалена с AP по истечению 300 секунд неактивности, либо по превышению порога ретрансмитов к данной "мертвой душе".-
2
-
-
Нажав 1 раз кнопку WPS, вы инициируете WPS подключение для бэнда 2.4ГГц.
"Предпочитать 2.4 ГГц" - не означает, что клиент будет подключаться сразу к 2.4. Подключаться все равно будет по возможности к 5ГГц, а вот по условиям уровней будет раньше переходить на 2.4 при ухудшении сигнала 5 и переходить обратно на 5 при других условиях (и только при отсутствии трафика). При включении Band Steering, у вас всегда 1 из диапазонов закрыт от клиента. AP не отвечает на probe request и на auth в закрытом диапазоне.
Если клиент однобэндовый 2.4, то разовое нажатие на WPS должно подключить его, независимо от Band Steering.
-
1
-
-
Нужно больше вводных данных.
- Версия прошивки NDM
- Примерное расстояние от WISP клиента до Root-AP
- Примерное расстояние от клиентов до AP KeeneticЯ так понимаю что на WISP клиенте у вас WEP шифрование. А вот на AP Keenetic тоже выставлен WEP? Или WPA2-PSK?
-
Да, все верно. Мы в курсе. Чип MT7628 на текущем драйвере имеет проблемы работы в 2SS с Q835 (rate_ctl трейнит линк до 1Mbps по кругу), поэтому только для MT7628 мы откатили фикс, который открывал 2SS. В 1SS работает стабильно и в итоге скорость выше, чем на 2SS с постоянным трейном линка.
Как проблему решим через вендора, обязательно откроем 2SS.
-
1
-
-
Это нормальное поведение, когда очередь подзабита. Она сама продувается, когда CPU разгребают очереди интерфейсов и когда есть место, куда отправлять пакеты.
В случае топикстартера, входит в кому фатально, блокируется один из RGMII.
-
1
-
-
Прошивки 2.10 и 2.11 по кодовой базе ядра Linux и Ethernet драйвера (+ свитча) сейчас идентичны. Поэтому чудес не будет.
Можно попробовать установить прошивку 2.09 (а потом даже 2.08, если на 2.09 воспроизведется), чтобы понять была ли проблема ранее (т.е. произошла ли регрессия). Это может сузить круг поиска регрессии (если она была) и помочь в расследовании.
-
1
-
-
Если коммутатор между провайдером и роутером не помог (а также сброс линка WAN порта не вернул eth к жизни), проблема вероятно кроется в другом месте. Вполне возможно со стороны LAN (внешнего свитча Ultra2).
Получили еще подобное сообщение от пользователя, что характерно также с Ultra2.
Ставлю Ultra2 в стенд, буду ловить проблему, чтобы отловить, разобраться в причине и починить. На это может уйти много времени (в основном на воспроизведение проблемы). Как получу результаты, отпишусь.
-
Цитата
Вся беда в том, что на Keenetic 2 этот же телефон, работает без каких-либо нареканий
На Keenetic 2 и Giga2 установлен один и тот же Wireless чип Ralink RT5392, если брать один и тот же срез прошивки, Wireless драйвер там будет идентичный для обоих устройств.
Я тестировал 2 недели назад Ultra1 (RT5392 и RT3593) в обоих диапазонах с Xiaomi Mi6, все работало идеально (в 2SS).
-
1
-
1
-
Wi-fi 5GHz и ширина канала на устройствах с Windows 2.10.C.0.0-0
в 2.10
Опубликовано
Нет, FCU не ставил, но можно поставить хотя бы на стенде, не вопрос.
Под Linux это работает со многими адаптерами, в Wireshark доступен Monitor. Под Win с Intel адаптерами точно не работает. С какими-то работает, но я не в курсе, использую Wireshark под линухом. Монитор запускается на любом хосту, на нужном канале. Дальше производится подключение нужного клиента к AP и этот трафик задампится с 802.11 заголовками. После чего можно сохранить в файл для последующего анализа.