AUN D7 and AMPAK AP6255 (bcm43455c0) disconnects fix

aun d7 mini dlp projectorНекоторое время назад решил я себе прикупить какой-нить автономный мини проектор для реализации развлекаловок в поездках, и демонстрации всяких интересностей на встречах вне дома.

Потратив несколько вечеров гуглежа и определившись с пределом ценника и хотелками, остановил свой выбор на AUN D7. Рассказывать сколько ждал и т.д. не вижу смысла. Как и о качестве самого по себе воспроизведения (о красных рожах, откровенно никакущей батарейки и т.д., это всё ожидаемо).

Но вот чего я не ожидал от устройства, которое должно быть мобильным – так это того, что единственное, что связывает его с миром в виде wifi будет безбожно глючить.

Как это выглядит для пользователя. Запускаем speedtest, радуемся скорости, не соврали. Тест завершается, и спустя пару секунд wifi решает переподключиться. Зачем? А фиг его знает. Ладно, ну глюк, ну бывает. Запускаем видео с DLNA в VLC. Играет минут 5 – 30 (как повезёт) – опять реконнект.

Лезем на AP и смотрим лог. И видим там такую картину.

5GHz AP ASSOC - receive DIS-ASSOC(seq-352) request from cc:4b:73:2e:4d:5e, reason=8
ASSOC - Assign AID=2 to 5GHz AP cc:4b:73:2e:4d:5e
ASSOC - HT support STA. Update AP OperaionMode=3 , fAnyStationIsLegacy=0, fAnyStation20Only=0, fAnyStationNonGF=1
ASSOC - VHT support STA

Т.е. проектор подумал-подумал да и решил, что нечего тут делать и отключился. Мдяяяя. Чешем репу и лезем в логи самого проектора. Что такое логи ядра в китайских поделках, где валится весь дебаг, причём сам дебаг обычно такой, что толку с него 0, при этом прёт оно тупо нескончаемым потоком, я говорить не буду. =) Покажу лишь важную часть.

[ 164.696490@0] CFG80211-ERROR) wl_escan_handler : unexpected Escan Event 11 : abort 
[ 181.162645@0] CFG80211-ERROR) wl_escan_handler : unexpected Escan Event 11 : abort 
[ 186.057573@2] CFG80211-ERROR) wl_cfg80211_disconnect : Reason 3 
[ 187.013622@0] CFG80211-ERROR) wl_is_linkdown : Link down Reason : WLC_E_LINK 
[ 187.019685@0] link down if wlan0 may call cfg80211_disconnected. event : 16, reason=2 from f8:f0:82:01:00:04

На первые 2 строки не обращаем внимания – это просто неработающий background scan, ибо дров криво собран, опять-таки не удивительно.
А вот дальше видим сообщение от 802.11 подсистемы ядра, что, мол, что-то пошло не так (2 – leave – я устал, я ухожу =).   Затем сразу видим опускание линка с генерацией линк биат и посылом в сторону AP DEAUTH фрэйма с reason=2 (reason 2 – предыдущая сессия аутентификации не верна), и что самое интересное – AP получает этот DEAUTH фрэйм с reason=8 (т.е. как DISSASSOC LEAVING, чудесато)…

Стало понятнее? Ну не особо, мы и до этого знали, что оно само дисконнектится, причину оно нам так и не сказало, но это уже гарантирует, что дальше со стороны AP трогать ничего не стоит и надо колупать клиента, ибо чудеса явно на его стороне.

Нагугливаем даташит на AMPAK. Несколько раз ужасаемся, какое это гамно, легче от этого не становится. Однако в нём есть прекрасная картинка – блок схема, из которой понятно, что в обвязке BCM только свитч BT/WLAN.

После ряда тестов выясняем, что с момента, когда пропал трафик, и до момента того, когда клиент решает отключиться, проходит несколько секунд. Правдами и неправдами пытаемся поймать зависимость, а её нет. И тут после пары литров кофе и мешка сигарет в голову приходит, что единственное, что может вот так лихо останавливать передачу на корню, – это срабатывание механизма CCA и RRM QUIET. Второго эта железка не умеет. А вот ED-CCA ещё как.

Лезем в конфиг, живущий по адресу /etc/wifi/6255/nvram.txt и в самом конце видим:

ed_thresh2g=-54
ed_thresh5g=-54

ООООО.. -54 порг для ED-CCA ??? Он же почти никогда не будет срабатывать…. Гуглим, находим ошмётки непокорёженных дров от BCM и там видим порог -77. Ок. Пробуем – фиг, вообще RX почти всегда вырублен и даже аутентификация не проходит. Прелесть какая.

Ок. Действуем от обратного, напрочь вырубаем ED логику в CCA, задрав порог в -30. Вуаля.. Всё забегало, скорость в норме, смотрим фильмец и под самый конец ловим опять то же самое. Пытаемся повторить – повторяется, но интервал уже около получаса, не меньше. Пробуем выкрутить ещё выше порог, но нет.

Ладно, начинаем собирать ошмётки дров и конфигов (вендор же нам как обычно нифига не предоставил), разбираемся с параметрами калибровок, выясняем, что оно вообще работать не должно, ибо конфиг представляет из себя помесь конфига для режимов работы буквально всех, тут тебе и внешний RX/TX switch, и тут же флаги, задающие работу с внутренним и т.д. И калибровки машинные (производимые для каждой серии модулей на заводе) в обратную сторону, и прочие прелести.

Выправляем (т.к. нет оборудования – на глазок по примеру от какой-то железки, где оно похоже на правду).

Проверяем. И вот один фильм просмотрен, и решаем скачать пару фильмов с сервера с собой. И под самый конец копирования получаем повтор. Схватившись было за молоток, решаем-таки посмотреть фирмварь, загружаемую в этот самый BCM и поставляемую в блобах. Обгугливаем инет, находим 10ток разных бинарей, разной степени давности. И идём ва-банк.

Тупо подменяем бинари и тестим. И вот оно. Самый последний бинарь от июля с какого-то проекта на рокчипе не устраивает диких плясок ни при копировании, ни при просмотре. УРРРА.

Ради интереса меняем конфиг на оригинальный и получаем ту же Ж, что была раньше. Вывод ED-CCA по-прежнему глючит у BCM, и его вырубать надо, калибровки тоже нужно править (PER на стороне AP с новыми 0, со старыми 12-15% постоянно).

Ниже прикладываю файлик (в теме статьи на форуме) со всеми своими правками по радио и добавленными коментариями. Структура директорий внутри архива сохранена, и достаточно будет просто заменить на своём устройстве файлики из архивных с соблюдением путей.

Вот такой вот хэппиэнд. Вероятно, это решение можно использовать и для других устройств с этим радиомодулем. AUN жирный минус за подобное. Хоть бы сайтик полечили и номинально устройство сопровождали. В общем фу и ещё раз фу.

P.S. По собственной оценке, за такие устройства вендор ещё и приплачивать должен. Ибо куда ни плюнь, всё работает через Ж. Это ещё одна причина, почему не стоит покупать железки без нормальной софтовой поддержки вендором. Ну если вы только не готовы сами тратить время на решение проблем, что не всегда реально, даже имей вы должную квалификацию. В том смысле, что время потратите, но решить проблему может и не удаться т.к. вендор так или иначе не поставляет исходники. Описанное выше решение – это банальное везение, что удалось обойтись без ковыряния самого драйвера, иначе бы этим проектором только орехи колоть.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.