Padavan

19 октября, 2017

Когда клиент хочет отключиться от точки доступа, он должен прислать ей фрейм DEAUTH или DISASSOC, где в качестве MAC адреса получателя указывается BSSID точки доступа. Точка доступа, получив такой фрейм, первым делом проверяет, ей ли он адресован, если нет, то такой фрейм отбрасывается. Если в вашем случае клиент остается висеть "мертвой душой" на одной из двух AP, то значит:
- либо он не прислал фрейм DEAUTH или DISASSOC
- либо прислал такой фрейм с чужим BSSID в качестве MAC адреса получателя

На роутере обе AP имеют разный BSSID (MAC), так и должно быть.

P.S.
Зависшая ассоциация будет удалена с AP по истечению 300 секунд неактивности, либо по превышению порога ретрансмитов к данной "мертвой душе".

18 октября, 2017

Нажав 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.

8 октября, 2017

Нужно больше вводных данных.

- Версия прошивки NDM
- Примерное расстояние от WISP клиента до Root-AP
- Примерное расстояние от клиентов до AP Keenetic

Я так понимаю что на WISP клиенте у вас WEP шифрование. А вот на AP Keenetic тоже выставлен WEP? Или WPA2-PSK?

5 октября, 2017

Да, все верно. Мы в курсе. Чип MT7628 на текущем драйвере имеет проблемы работы в 2SS с Q835 (rate_ctl трейнит линк до 1Mbps по кругу), поэтому только для MT7628 мы откатили фикс, который открывал 2SS. В 1SS работает стабильно и в итоге скорость выше, чем на 2SS с постоянным трейном линка.

Как проблему решим через вендора, обязательно откроем 2SS.

23 сентября, 2017

AndreBA

Это нормальное поведение, когда очередь подзабита. Она сама продувается, когда CPU разгребают очереди интерфейсов и когда есть место, куда отправлять пакеты.

В случае топикстартера, входит в кому фатально, блокируется один из RGMII.

20 сентября, 2017

Прошивки 2.10 и 2.11 по кодовой базе ядра Linux и Ethernet драйвера (+ свитча) сейчас идентичны. Поэтому чудес не будет.

Можно попробовать установить прошивку 2.09 (а потом даже 2.08, если на 2.09 воспроизведется), чтобы понять была ли проблема ранее (т.е. произошла ли регрессия). Это может сузить круг поиска регрессии (если она была) и помочь в расследовании.

20 сентября, 2017

Если коммутатор между провайдером и роутером не помог (а также сброс линка WAN порта не вернул eth к жизни), проблема вероятно кроется в другом месте. Вполне возможно со стороны LAN (внешнего свитча Ultra2).

Получили еще подобное сообщение от пользователя, что характерно также с Ultra2.

Ставлю Ultra2 в стенд, буду ловить проблему, чтобы отловить, разобраться в причине и починить. На это может уйти много времени (в основном на воспроизведение проблемы). Как получу результаты, отпишусь.

18 сентября, 2017

Цитата

Вся беда в том, что на Keenetic 2 этот же телефон, работает без каких-либо нареканий

На Keenetic 2 и Giga2 установлен один и тот же Wireless чип Ralink RT5392, если брать один и тот же срез прошивки, Wireless драйвер там будет идентичный для обоих устройств.

Я тестировал 2 недели назад Ultra1 (RT5392 и RT3593) в обоих диапазонах с Xiaomi Mi6, все работало идеально (в 2SS).

15 сентября, 2017

Wireless чипы MT7620 и RT5592 (применяемые в данном устройстве) не поддерживают аппаратное шифрование/дешифрование PMF (ни один тип 802.11 пакетов). Поэтому нет и не планируется.

Для домашнего применения PMF малоактуален, это прерогатива для хотспотов и интернет кафе.

14 сентября, 2017

Да, проблема локализована и решена, баг был косвенный (никак не касался Wireless кухни). Исправление войдет в ближайшем драфте.

12 сентября, 2017

Giga3 поддерживает в 5ГГц и 11N и 11AC, однако если у вас клиент не поддерживает 11AC, либо 11AC заблокирован в прошивке смартфона, будет подключаться как 11N. 150 - это линк 11N, в 11AC совсем другие цифры (1SS до 433 при 80МГц).

12 сентября, 2017

Если у вас клиент 1SS, то в 11N линк 150 на полосе 40МГц - это предел стандарта. Я чуть выше приводил расклад по линкам.

12 сентября, 2017

Цитата

При установке 20 для 2.4 сети сеть 5 становится тоже 20

Первый раз слышу подобное. Обе AP абсолютно независимые, настройки также.

Переключение 270/300, 135/150, 65/72 - это нормально, когда AP не передает активно трафик, линк переключается на ступень ниже (c GI400 на GI_800).

ЗЫ:
Роутер передает по проводу > 930Mbps, я не знаю почему вы пытаетесь найти черную кошку в темной комнате, выискивая под лупой отличия от вашего "эталонного" девайса.

12 сентября, 2017

Исправление было только в логике управления, rai1 теперь стал добавляться в гостевой бридж (это вошло в 2.10 и в 2.11). Со стороны Wireless ничего не поменялось. В общем пока выглядит странно.

Спасибо за замечание, будем разбираться.

12 сентября, 2017

Очень странно на все это смотреть. Giga3 с тем же Xiaomi Mi6 на линке 866 в 5ГГц выдает на спидтесте 420..450 Mbps в обе стороны (ISP Ростелеком, GPON), в прямой видимости. Близкие скорости на iPad Air2 и на ноутбуке с Intel AC7265 адаптером.

Пытаться выжать на клиенте с 1SS, задушенном до 20МГц в 2.4ГГц в условиях занятого эфира жалкие 10..15Mbps и сравнивать по этому показателю устройства из разных категорий - выглядит как погоня за идеалом.

13 канал не выбирается на автовыборе в 2.4ГГц с давних времен, причина - массовое кол-во клиентов (в основном гаджеты), имеющих лейбл РСТ, но не работающих с 12 и 13 каналом из-за ограничений FCC в прошивке. Это приводит к тому что такие клиенты перестают "видеть" точку доступа, когда она встает на канал выше 11.

Цитата

Но все равно все устройства отображаются в роутере со скоростью подключения 135.

Если клиентское устройство имеет 11N/AC адаптер с 1SS (читайте 1 антенну), то максимальная скорость линка будет ограничена по стандарту:
65/72 при 20МГц
135/150 при 40МГц
390/433 при 80МГц (11AC)

Поэтому нужно понимать, что на линке 65 в плохих условиях, скорости 30..40Mbps являются отличными. На линке 135 можно рассчитывать на скорости в районе 90..100Mbps, но в хороших условиях. Например мой Zenfone2 551 выдавал стабильно 110 Mbps (с GPON провайдером). Если нет прямой видимости, в 5ГГц скорости сильно плавают из-за отражений, 5ГГц также отражается от тела человека.

10 сентября, 2017

Да, это можно организовать, Too short и Too long полетят в "stat64->rx_length_errors".

9 сентября, 2017

На Ultra2/Giga3, в синему порту, в поле rxerrors заносятся ошибки:

Overflow
FCS error
Too short
Too long
L4 checksum

Ваши ошибки могли быть запросто из-за слишком коротких (< 64) или слишком больших (> 1536). В этом плане не очень удобно сделано, по идее Too short и Too long нужно заносить только в дропы, а не в ошибки.

9 сентября, 2017

На Ultra2/Giga3 синий порт смотрит в eth3 интерфейс, с которого читаются стандартные 64 бит счетчики ядра Linux, в которых нет полей
rx-broadcast
tx-multicast
tx-broadcast

по дизайну (см. cat /proc/net/dev).

Желтые порты читаются с MIB счетчиков свитча, там наличие счетчиков зависит от аппаратной реализации свитча, на всех 3 ваших устройствах разный набор MIB.

9 сентября, 2017

Здесь обычный soft lockup на SMP ядре Linux (дедлок), явление очень сложное для поимки и отладки. Происходит крайне редко (и в разных ситуациях), мы знаем об этом и постоянно работаем над качеством кода (как прикладного, так и ядра Linux). soft lockup приводит к тому что система становится неработоспособной, при этом она не перезапускается сама по аппаратному watchdog таймеру, так как один из CPU успевает его обновлять. В итоге девайс частично отзывается, но остается в коме (до перезагрузки).

NDM обрастает фичами, они могут увеличивать вероятность появления дедлока.

Shadow87
В данном случае никакой связи с вашей проблемой нет.

9 сентября, 2017

У чипа два интерфейса (LAN и WAN), но общая DMA очередь на оба. Если любой из интерфейсов заблокируется, то очередь вскоре заполнится и возникнет общий затор. Это не позволит отправлять пакеты в оба интерфейса, так как не будет места в очереди, чтобы положить новый пакет.

Причиной блокировки может быть как WAN порт, так и один из LAN. Сброс линка "продует" очередь, так как MAC выбрасывает все пакеты, если у PHY нет линка.

Заблокированный порт обычно характерно моргает LED-ом во время коллизии (пытается отправить пакет снова и снова).

8 сентября, 2017

По логу очень похоже на блокирование ответного Eth порта, который смотрит в синий WAN порт.

Цитата

Обратно аппарат оживает только после перезагрузки.

Если возникнет похожая ситуация, для проверки предположения удалите Eth кабель из синего порта на 5..10 секунд и подключите на место. Если проблема решится именно таким образом (без перезагрузки), значит ответный порт встал на паузу и больше не смог принимать пакеты, что вызвало затор и остановку очередей в роутере. В данной ситуации возможно поможет отключение FlowControl на GigabitEthernet1 интерфейсе.

31 августа, 2017

У меня сейчас на руках Mi6 (на старой стоковой прошивке), перепроверил текущую прошивку Giga3, с Mi6 всегда коннектится на 2SS, линк 130..144 в 2.4 (867 на 5). Переподключился несколько раз, в том числе к гостевой. При этом до применения workaround там то же самое было, коннектился в 1SS всегда, на любом бэнде.

Непонятно пока почему OnePlus 5 первый раз коннектится на 2SS, а при последующих подключениях (с ваших слов) со стороны AP опять уходит в 1SS. В ваших настройках никаких проблем не вижу, однако selftest не покажет причину, нужно снимать 802.11 Radiotap заголовки во время подключения (например через Wireshark).

Я думаю вам есть смысл подождать обновление прошивки для OnePlus, так как на Mi6 уже вышла прошивка, которая может работать в 2SS без workaround-а. Тем более что 5ГГц теперь коннектится в 866. Надеюсь это будет быстрее, чем мы найдем OnePlus 5.

31 августа, 2017

Цитата

К 2,4 ГГц стало подключаться, к 5 ГГц так и не подключается.

Подтверждаю, только здесь баг в логике NDM, интерфейс rai1 выпал из бриджа br1. Соответственно проблема с любыми клиентами, а не с сабжем.

Спасибо за замечание.

31 августа, 2017

Пока не могу подтвердить, за 2 суток тестирования ни разу не было. Да и маловероятно, так как MT7628 и MT7602 очень разные чипы, драйверы к ним сильно различаются. Поэтому враз оба не могли умереть. Workaround никак не влияет на работоспособность самого драйвера, он лишь затрагивает ответ probe response (при подключении) чтобы клиент не отключал 2SS.

-
Я протестировал все чипы, начиная от RT5392, все работают с Q835 в 2SS адекватно, за исключением MT7628, с ним есть какая-то нестыковка, MT7628 в паре с Q835 в 2SS постоянно ретрейнит линк со 144 до 1, и так по кругу. При этом в 1SS все ровно.

31 августа, 2017

Web отображает текущее состояние из драйвера, проверьте, при передаче данных оно должно крутиться. После коннекта у вас там должно загореться 144, затем возможно начнет меняться, но это уже работа rate_ctl, который в реальном времени подстраивает линк на основании BER/SNR/RSSI.

Профили

Форумы

Галерея

Загрузки

Блоги

События

Сообщения, опубликованные Padavan

Важная информация