EDIMAX EW-7811UN .... Используется набор микросхем rtl8188cus, IIRC.

Если у вас его еще нет, создайте /etc/modprobe.d/8192cu.conf с содержимым ....

Отключить управление питанием

параметры 8192cu rtw_power_mgnt = 0 rtw_enusbss = 0

На самом деле rpi3 использует драйвер brcmfmac для встроенного Wi-Fi.
существует проблема, требующая отключения энергосбережения / управления

Я думаю, что новые ядра raspian уже исправили это, чтобы отключить энергосбережение по умолчанию, но я еще не думаю, что это в этой ветке 4.5

Что я делаю в данный момент (установка gentoo), при загрузке я делаю следующее, чтобы отключить энергосбережение на карте Wi-Fi.

iw wlan0 выключить power_save

На самом деле rpi3 использует драйвер brcmfmac для встроенного Wi-Fi.

Да, я знаю. О, я вижу. Он больше не использует электронный ключ EDIMAX EW-7811UN. Раньше он использовал его с RPi2.

да, я больше не использую usb wifi, как мне настроить строку cmd, чтобы отключить управление питанием?
crontab
@reboot iw wlan0 выключить power_save

Не уверен для raspian, так как я использую gentoo, будет по-другому

Попробуйте это: https://gist.github.com/mkb/40bf48bc401ffa0cc4d3

Кажется, работает, так как я отключил управление питанием, у меня не было еще одного сбоя wlan.

Чтобы упомянуть об этом, чтобы автоматически перезапустить wlan после сбоя, это помогает:
sudo cp /etc/wpa_supplicant/ifupdown.sh /etc/ifplugd/action.d/ifupdown

Кстати, последнее обновление ядра apt-get по умолчанию отключено.
@ dh-connect сработает ли это для вас, если вы удалите текущий обходной путь?

он все еще вылетает после последнего обновления, теперь я получаю эту ошибку в системном журнале:
brcmfmac: brcmf_sdio_bus_txdata: вне шины-> txq !!!

Когда вы говорите, что происходит сбой, есть ли другие симптомы, кроме сообщения об ошибке?

нет, только тот, который я разместил здесь, но он много раз в журнале

wlan перестает работать, я все еще могу с ним работать, но чтобы вернуть wlan, мне нужно его перезагрузить

Спасибо - я думаю, что "wlan перестает работать" считается симптомом.

Я пробовал несколько вещей, но wlan все еще не работает

чтобы ответить на вопрос выше, когда я заберу конфигурацию
отключение беспроводной связи в / etc / network / interfaces
и перезагрузить
и проверьте настройки с помощью iwconfig
управление питанием снова включено, поэтому по умолчанию я бы не сказал, что это отключено, поэтому я оставлю конфигурацию

Я пробовал это с ядром 4.1.19, а теперь и с ядром 4.1.20 ... без изменений

когда произошел сбой wlan, и я пытаюсь снова включить его с помощью ifdown и ifup wlan0, я получаю следующее:
Ошибка для беспроводного запроса «Установить управление питанием» (8B2C): сбой SET на устройстве wlan0; Неверный обмен.

У меня также есть еще несколько ошибок в системном журнале:

dhcpcd [532]: wlan0: xxx: срок действия опции 25 истек

21 марта 17:29:35 Ядро raspberrypi: [6627.337503] brcmfmac: _brcmf_set_multicast_list: Ошибка установки mcast_list, -52
21 марта, 17:29:36 raspberrypi wpa_supplicant [6318]: успешно инициализирован wpa_supplicant
21 марта 17:29:36 raspberrypi dhcpcd [532]: wlan0: оператор связи потерян

21 марта 17:29:43 Ядро raspberrypi: [6635.337616] brcmfmac: _brcmf_set_multicast_list: Ошибка установки mcast_list, -52

21 марта 17:29:45 ядро ​​raspberrypi: [6637.337588] brcmfmac: brcmf_do_escan: error (-52)
21 марта 17:29:45 ядро ​​raspberrypi: [6637.337602] brcmfmac: brcmf_cfg80211_scan: ошибка сканирования (-52)

21 марта 17:29:47 Ядро raspberrypi: [6639.337596] brcmfmac: _brcmf_set_multicast_list: Ошибка установки allmulti, -52
21 марта 17:29:49 Ядро raspberrypi: [6641.337632] brcmfmac: _brcmf_set_multicast_list: Ошибка установки BRCMF_C_SET_PROMISC, -52

есть еще что-нибудь, что я могу попробовать?

также эти:

21 марта 21:26:55 raspberrypi dhcpcd [526]: wlan0: xxx: срок действия опции 25
21 марта 21:28:54 ядро ​​raspberrypi: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
21 марта 21:30:16 raspberrypi dhcpcd [526]: wlan0: xxx недоступен, срок его действия истекает

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

Есть ли у вас приблизительные цифры времени безотказной работы и примерный объем данных, которые могли быть переданы (из ifconfig)?

да, когда у меня работает только веб-сервер с небольшим трафиком (менее 100 МБ), он длится день или два, когда я передаю большие файлы данных, такие как сбой 1 ГБ wlan, в течение 1 часа

что я могу предоставить, чтобы помочь найти ошибку?

вот некоторая ошибка из системного журнала:

29 марта 14:20:56 raspberrypi dhcpcd [535]: wlan0: xxx: срок действия опции 25
29 марта 14:30:15 raspberrypi dhcpcd [535]: wlan0: xxx недоступен, срок его действия истекает
29 марта 17:18:42 ядро ​​raspberrypi: [186148.102420] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 марта, 17:18:43 Ядро raspberrypi: [186149.101045] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 марта 17:18:43 ядро ​​raspberrypi: [186149.101145] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 марта 17:18:44 Ядро raspberrypi: [186150.101209] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 марта 17:18:50 raspberrypi wpa_supplicant [478]: wlan0: CTRL-EVENT-DISCONNECTED bssid = xxx reason = 3 locally_generated = 1
29 марта 17:18:50 ядро ​​raspberrypi: [186156.181033] brcmfmac: brcmf_cfg80211_disconnect: error (-52)
29 марта 17:18:52 ядро ​​raspberrypi: [186158.181028] brcmfmac: send_key_to_dongle: ошибка wsec_key (-52)
29 марта 17:18:54 ядро ​​raspberrypi: [186160.181046] brcmfmac: send_key_to_dongle: ошибка wsec_key (-52)
29 марта 17:18:56 ядро ​​raspberrypi: [186162.181048] brcmfmac: send_key_to_dongle: ошибка wsec_key (-52)
29 марта 17:18:58 ядро ​​raspberrypi: [186164.181049] brcmfmac: send_key_to_dongle: ошибка wsec_key (-52)
29 марта 17:18:58 Ядро raspberrypi: [186164.185477] cfg80211: Вызов CRDA для обновления всемирного регулирующего домена
29 марта 17:18:58 raspberrypi dhcpcd [535]: wlan0: оператор связи потерян
29 марта 17:18:58 raspberrypi wpa_supplicant [7354]: успешно инициализирован wpa_supplicant
29 марта 17:18:58 ядро ​​raspberrypi: [186164.314511] brcmfmac: brcmf_cfg80211_reg_notifier: это не код ISO3166
29 марта 17:18:58 ядро ​​raspberrypi: [186164.314541] cfg80211: Мировой регулирующий домен обновлен:
29 марта 17:18:58 ядро ​​raspberrypi: [186164.314548] cfg80211: Главный регион DFS: не задано
29 марта 17:18:58 ядро ​​raspberrypi: [186164.314555] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
29 марта 17:18:58 ядро ​​raspberrypi: [186164.314565] cfg80211: (2402000 кГц - 2472000 кГц при 40000 кГц), (нет данных, 2000 мБм), (нет данных)
29 марта 17:18:58 Ядро raspberrypi: [186164.314573] cfg80211: (2457000 кГц - 2482000 кГц при 40000 кГц), (нет данных, 2000 мБм), (нет данных)
29 марта 17:18:58 raspberrypi kernel: [186164.314581] cfg80211: (2474000 кГц - 2494000 кГц при 20000 кГц), (нет данных, 2000 мБм), (нет данных)
29 марта 17:18:58 raspberrypi kernel: [186164.314592] cfg80211: (5170000 кГц - 5250000 кГц при 80000 кГц, 160000 кГц автоматически), (нет данных, 2000 мБм), (нет данных)
29 марта 17:18:58 Ядро raspberrypi: [186164.314602] cfg80211: (5250000 кГц - 5330000 кГц при 80000 кГц, 160000 кГц АВТО), (Н / Д, 2000 мБм), (0 с)
29 марта 17:18:58 Ядро raspberrypi: [186164.314611] cfg80211: (5490000 кГц - 5730000 кГц при 160000 кГц), (н / д, 2000 мБм), (0 с)
29 марта 17:18:58 Ядро raspberrypi: [186164.314645] cfg80211: (5735000 кГц - 5835000 кГц при 80000 кГц), (нет данных, 2000 мБм), (нет данных)
29 марта 17:18:58 Ядро raspberrypi: [186164.314654] cfg80211: (57240000 кГц - 63720000 кГц при 2160000 кГц), (нет данных, 0 мБм), (нет данных)

Спасибо за предложение, но теперь оно в руках Broadcom.

Любое обновление от Broadcom, если это ошибка, которая будет исправлена? Теперь у меня есть настройка задания cron, чтобы отключать и запускать wlan0, когда он не выполняет ping.

быстрое обновление с моей стороны, я мог исправить проблему, похоже, связанную с драйвером, я установил Ubuntu MATE 16.04 с ядром 4.4.8 и не имел проблем с Wi-Fi с тех пор

Я имею в виду, что они рекламируют: «Ubuntu MATE 16.04 также имеет полностью работающие Bluetooth и Wi-Fi на Raspberry Pi 3», что кажется правдой.

возможно, он также работает с новым выпуском Debian, о котором я не могу сказать

@ juched78 У вас ядро ​​4.4? Если нет, запустите sudo rpi-update чтобы получить последнюю сборку 4.4.8, и посмотрите, возникает ли та же проблема.

Драйверы Broadcom значительно изменились по сравнению с версией 4.1, и наше дерево 4.4 включает в себя обратные порты некоторых исправлений, которые вошли в 4.5. Мне не известно о каких-либо нерешенных ошибках, кроме невозможности выхода из спящего режима (управление питанием все еще отключено) - каналы 12 и 13 можно использовать там, где это разрешено, и режим Ad Hoc не дает сбоев - но могут все еще быть скрытые проблемы .

О, в 4.4.8 есть еще одна сообщенная ошибка - очевидно, интенсивное использование hostapd может привести к предупреждению ядра (см. Https://github.com/raspberrypi/linux/issues/1375).

Я бегаю:
Linux XXX 4.4.8-v7 + # 880 SMP Пт 22 апреля 21:55:04 BST 2016 armv7l GNU / Linux

27 апреля 2016 11:06:18
Авторские права (c) 2012 Broadcom
версия 9b52ab7b475f4a056658fd2d95d2440b32167390 (чистая) (релиз)

С моим Netgear R7000, работающим под управлением Shibby Tomato, около 2 дней в сети Wi-Fi падает, и в системных журналах я вижу:

CTRL-EVENT-DISCONNECTED
brcmfmac: brcmf_link_down: WLC_DISASSOC failed (-52)
brcmfmac: send_key_to_dongle: wsec_key error (-52)
...
brcmfmac: brcmf_do_escan: error (-52)
...
wpa_supplicant[506]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
...
brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code

(then I see it scan and re-pick my country code CA)

brcmfmac: _brcmf_set_multicast_list: Setting allmulti failed, -52
brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -52
brcmfmac: _brcmf_set_multicast_list: Setting mcast_list failed, -52

Потом вроде никогда не переподключится ...

Использование sudo ifdown wlan0 с последующим sudo ifup wlan0 возвращает мое соединение.

Только что обновили до:
Linux JuchePi 4.4.8-v7 + # 881 SMP Сб, 30 апреля 12:16:50 BST 2016 armv7l GNU / Linux

Не уверен, чем все отличается от 22-го по 30-е. Буду следить за подключением.

Мой RPi 3 тоже столкнулся с этой проблемой. Я получил несколько разных сообщений ядра. В основном один из тех, что ниже.
После этого я могу заставить Wi-Fi работать, отключение и включение wlan0 не помогает.

May 09 21:24:25 osmc kernel: brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
May 09 22:00:15 osmc kernel: brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
May 09 22:00:18 osmc kernel: brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!

May 10 00:51:10 osmc kernel: brcmfmac: brcmf_cfg80211_get_tx_power: error (-52)
May 10 00:51:12 osmc kernel: brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110

May 10 00:53:16 osmc kernel: brcmfmac: brcmf_do_escan: error (-52)
May 10 00:53:16 osmc kernel: brcmfmac: brcmf_cfg80211_scan: scan error (-52)

Raspberry питается от оригинального адаптера питания версии 3. Я использую последнюю версию OSMC:
$ uname -a
Linux osmc 4.4.8-3-osmc # 1 SMP PREEMPT Вс, 1 мая 18:57:43 UTC 2016 armv7l GNU / Linux

Еще мониторинг. У меня openhab отключился после трех дней работы, но по какой-то причине я все еще мог подключиться к Pi через ssh, чего обычно не мог. Вершина часа и скрипт Wi-Fi побежал, чтобы отключить и установить соединение, а затем он снова подключился к моей организации openhab. Странный. Будем смотреть дальше.

У меня тоже возникла та же проблема - трассировка dmesg следующим образом:

send_key_to_dongle: wsec_key error (-52)
brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -52
brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
brcmf_cfg80211_get_tx_power: error (-52)

Применение:

rp3 используется как маршрутизатор / точка доступа

Продолжительность подключения кажется случайной - у меня было целых две недели, а всего несколько минут. В последнее время он выходит каждые 20 минут или около того. Выключение и резервное копирование wlan0 не решает проблему - требуется полная перезагрузка.

Проблема, кажется, усугубляется при потоковой передаче Netflix с моего AppleTV. Хотя это было не так, когда у меня было две недели безотказной работы.

Я на 4.4.10-v7 +

Я переключил канал с 13 на 6, чтобы проверить, может ли это быть проблемой (были некоторые дефекты в отношении высоких каналов), и с тех пор у меня не было зависаний WiFi. Но это могло быть совпадением ...

Смена каналов точки доступа не помогла. WiFi все равно ломается. Последние несколько раз мне приходилось перезапускать несколько раз подряд, чтобы он заработал.

У меня возникает эта проблема, когда я пытаюсь выполнить передачу SFTP между rpi3 и моим телефоном Galaxy S5. Когда я пытаюсь выполнить ту же передачу со своего ноутбука, все работает без сбоев.

Запуск последней версии ядра из rpi-update:

Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux

Сообщение об ошибке из системного журнала:

May 29 18:10:46 raspberrypi kernel: [  178.605907] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Вроде единственное решение после этой ошибки - перезагрузка.

За последнюю неделю я дважды отключался от сети. В первый раз я был в спешке, поэтому просто отключил и перезагрузил. Через несколько дней это произошло снова, снова перезагрузился, а затем запустил полные обновления системы (включая прошивку) и будет контролировать. Установите его так, чтобы поблизости не было монитора, поэтому для получения подробной информации об ошибке потребуется больше усилий :)

Здесь та же проблема. Он всегда зависает при передаче больших файлов по sftp. Просто перезагрузитесь, чтобы решить

Эта проблема может быть связана с https://github.com/raspberrypi/linux/issues/1313.

Broadcom заявляет, что # 1313 не представляет проблемы, и последнее ядро ​​больше не показывает эти сообщения.

Мне не удалось воспроизвести эту проблему. Кто-нибудь смог захватить трассировку пакета во время сбоя?

Если у кого-то есть время еще раз протестировать модуль драйвера с поддержкой отладки, мы будем очень признательны:

1) Запускаем sudo rpi-update и перезагружаемся. Это необходимо для того, чтобы ваше ядро ​​достигло того же уровня, что и мое, чтобы модуль был совместим.

2) Загрузите и установите обновленный модуль драйверов:

BRCM80211=/lib/modules/`uname -r`/kernel/drivers/net/wireless/brcm80211
BRCMFMAC=$BRCM80211/brcmfmac
wget -O brcmfmac.ko "https://docs.google.com/uc?authuser=0&id=0B8VsfKAD4-NOR1ZxWS00ZmFrR1k&export=download"
wget -O brcmutil.ko "https://docs.google.com/uc?authuser=0&id=0B8VsfKAD4-NOM0ZDd3FvYUNwZXc&export=download"
sudo mv $BRCMFMAC/brcmfmac.ko{,.orig}
sudo cp brcmfmac.ko $BRCMFMAC
sudo sh -c "echo options brcmfmac debug=0x100000 > /etc/modprobe.d/brcmfmac.conf"
BRCMUTIL=$BRCM80211/brcmutil
sudo mv $BRCMUTIL/brcmutil.ko{,.orig}
sudo cp brcmutil.ko $BRCMUTIL/brcmutil.ko

Перезагрузитесь, чтобы активировать новые модули.

3) Используйте свой Pi как обычно, а затем, если ваш WiFi завис, запустите:

dmesg > wifi_freeze.txt

и загрузите его на свой любимый сайт для вставки (или создайте Gist). Одного-двух журналов должно хватить.

Чтобы восстановить исходную версию модуля:

BRCM80211=/lib/modules/`uname -r`/kernel/drivers/net/wireless/brcm80211
sudo mv $BRCM80211/brcmfmac/brcmfmac.ko{.orig,}
sudo mv $BRCM80211/brcmutil/brcmutil.ko{.orig,}

Заранее спасибо.

Подождите, пока мы убедимся, что вывод отладки действительно включен.

Вам также необходимо включить функцию отладки в драйвере:

sudo sh -c "echo options brcmfmac debug=0x100000 > /etc/modprobe.d/brcmfmac.conf"

Я изменил инструкции выше.

После перезагрузки ваш вывод dmesg должен содержать что-то вроде этого:

[   10.848903] brcmfmac: CONSOLE: hndarm_armr addr: 0x18003000, cr4_idx: 0
[   10.860475] brcmfmac: CONSOLE: 000000.001
[   10.869471] brcmfmac: CONSOLE: RTE (SDIO-CDC) 7.45.41.26 (r640327) on BCM43430 r1 @ 37.4/81.6/81.6MHz
[   10.883644] brcmfmac: CONSOLE: 000000.001 sdpcmdcdc0: Broadcom SDPCMD CDC driver
[   10.896090] brcmfmac: CONSOLE: 000000.005 reclaim section 0: Returned 47716 bytes to the heap
[   10.909734] brcmfmac: CONSOLE: 000000.007 wlc_bmac_info_init: host_enab 1
[   10.921417] brcmfmac: CONSOLE: 000000.026 wl0: Broadcom BCM43430 802.11 Wireless Controller 7.45.41.26 (r640327)
[   10.936777] brcmfmac: CONSOLE: 000000.027 TCAM: 256 used: 179 exceed:0
[   10.936794] brcmfmac: CONSOLE: 000000.028 reclaim section 1: Returned 81268 bytes to the heap
[   10.936803] brcmfmac: CONSOLE: 000000.029 sdpcmd_dpc: Enable
[   10.938242] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: May 27 2016 00:13:38 version 7.45.41.26 (r640327) FWID 01-df77e4a7
[   10.949404] brcmfmac: CONSOLE: 000000.125 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
[   10.963663] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[   10.969865] brcmfmac: CONSOLE: 000000.150 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
[   10.969876] brcmfmac: CONSOLE: 000000.151 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
[   11.189639] brcmfmac: CONSOLE: 000000.368 wl0: wl_open

@pelwell после выполнения ваших инструкций у меня больше нет Wi-Fi ...

корень @ pi3b : / home / pi # dmesg | grep brcmf
[15.582665] brcmfmac: Неизвестный символ brcmu_dbg_hex_dump (err 0)
[15.613709] brcmfmac: Неизвестный символ brcmu_dbg_hex_dump (err 0)

Попробуй это:

BRCMUTIL=/lib/modules/`uname -r`/kernel/drivers/net/wireless/brcm80211/brcmutil
wget -O brcmutil.ko "https://docs.google.com/uc?authuser=0&id=0B8VsfKAD4-NOM0ZDd3FvYUNwZXc&export=download"
sudo mv $BRCMUTIL/brcmutil.ko{,.orig}
sudo cp brcmutil.ko $BRCMUTIL

И перезагружаемся.

wlan0 не связывает.
wireless.txt
(при одной из многих перезагрузок я видел ассоциацию на несколько минут, но не уловил (пока) в dmesg)

Похоже, проблема могла быть решена для меня путем обновления с 4.4.11-v7 + до 4.4.15-v7 +

Я попытался воссоздать проблемы, которые у меня были с передачей SFTP с телефона Android, но на данный момент я не вижу никаких проблем.

@pelwell после долгого ожидания wlan0 удалось связать; добавил dmesg к предыдущему журналу:
wireless.txt
жду сейчас замораживания или потери ассоциации
надеюсь, что это полезно

@pelwell снова быстро потерял связь; добавлен dmesg к:
wireless.txt

Спасибо. В первый раз для меня это было медленно. Я был занят получением чистого Raspbian и установкой исправлений, чтобы попытаться воспроизвести проблему - я все равно продолжу.

@pelwell
wireless.txt
и снова ассоциирован: снова добавлен dmesg
ты хочешь, чтобы я продолжил?

@pelwell : снова потерял ассоциацию
wireless_associationloss.txt

@pelwell
он включается / выключается нерегулярно
wireless_associationloss.txt

Думаю, тебе лучше переключиться обратно, пока мой почтовый ящик не переполнился.

ОК; Я вернусь к своему электронному ключу MT7601U за 3 евро. ;)

Спасибо за вашу помощь,

Я только что обнаружил эту проблему, могу ли я подтвердить, что она похожа на то, что я вижу? Я установил RPi 3 в качестве точки доступа, и время от времени мне не удается подключиться к ней. Я могу подключиться по ssh через проводное соединение, и я вижу, что wlan0 все еще работает с правильным IP-адресом, но единственный способ заставить точку доступа снова заработать - это перезагрузить. Я вижу такие следы стека в /var/log/messages

Jul 16 06:57:18 raspberrypi kernel: [117621.171957] ------------[ cut here ]------------
Jul 16 06:57:18 raspberrypi kernel: [117621.172042] WARNING: CPU: 2 PID: 879 at drivers/net/wireless/brcm80211/brcmfmac/core.c:1191 brcmf_netdev_wait_pend8021x+0xe4/0xf0 [brcmfmac]()
Jul 16 06:57:18 raspberrypi kernel: [117621.172052] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables bnep hci_uart btbcm bluetooth brcmfmac brcmutil cfg80211 rfkill snd_bcm2835 snd_pcm snd_timer snd bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio ipv6
Jul 16 06:57:18 raspberrypi kernel: [117621.172168] CPU: 2 PID: 879 Comm: hostapd Tainted: G        W       4.4.11-v7+ #888
Jul 16 06:57:18 raspberrypi kernel: [117621.172177] Hardware name: BCM2709
Jul 16 06:57:18 raspberrypi kernel: [117621.172212] [<80018724>] (unwind_backtrace) from [<80014058>] (show_stack+0x20/0x24)
Jul 16 06:57:18 raspberrypi kernel: [117621.172235] [<80014058>] (show_stack) from [<803205a4>] (dump_stack+0xd4/0x118)
Jul 16 06:57:18 raspberrypi kernel: [117621.172259] [<803205a4>] (dump_stack) from [<80025300>] (warn_slowpath_common+0x98/0xc8)
Jul 16 06:57:18 raspberrypi kernel: [117621.172282] [<80025300>] (warn_slowpath_common) from [<800253ec>] (warn_slowpath_null+0x2c/0x34)
Jul 16 06:57:18 raspberrypi kernel: [117621.172350] [<800253ec>] (warn_slowpath_null) from [<7f23a1d4>] (brcmf_netdev_wait_pend8021x+0xe4/0xf0 [brcmfmac])
Jul 16 06:57:18 raspberrypi kernel: [117621.172466] [<7f23a1d4>] (brcmf_netdev_wait_pend8021x [brcmfmac]) from [<7f228fbc>] (send_key_to_dongle+0xa4/0xf8 [brcmfmac])
Jul 16 06:57:18 raspberrypi kernel: [117621.172579] [<7f228fbc>] (send_key_to_dongle [brcmfmac]) from [<7f229208>] (brcmf_cfg80211_del_key+0x68/0x78 [brcmfmac])
Jul 16 06:57:18 raspberrypi kernel: [117621.172723] [<7f229208>] (brcmf_cfg80211_del_key [brcmfmac]) from [<7f1742f0>] (nl80211_del_key+0xfc/0x28c [cfg80211])
Jul 16 06:57:18 raspberrypi kernel: [117621.172817] [<7f1742f0>] (nl80211_del_key [cfg80211]) from [<80505e00>] (genl_rcv_msg+0x26c/0x3f0)
Jul 16 06:57:18 raspberrypi kernel: [117621.172841] [<80505e00>] (genl_rcv_msg) from [<80504fd8>] (netlink_rcv_skb+0xb0/0xcc)
Jul 16 06:57:18 raspberrypi kernel: [117621.172862] [<80504fd8>] (netlink_rcv_skb) from [<80505b84>] (genl_rcv+0x34/0x44)
Jul 16 06:57:18 raspberrypi kernel: [117621.172883] [<80505b84>] (genl_rcv) from [<80504914>] (netlink_unicast+0x190/0x254)
Jul 16 06:57:18 raspberrypi kernel: [117621.172904] [<80504914>] (netlink_unicast) from [<80504de0>] (netlink_sendmsg+0x340/0x354)
Jul 16 06:57:18 raspberrypi kernel: [117621.172926] [<80504de0>] (netlink_sendmsg) from [<804b7c14>] (sock_sendmsg+0x24/0x34)
Jul 16 06:57:18 raspberrypi kernel: [117621.172947] [<804b7c14>] (sock_sendmsg) from [<804b82fc>] (___sys_sendmsg+0x1e0/0x1e8)
Jul 16 06:57:18 raspberrypi kernel: [117621.172968] [<804b82fc>] (___sys_sendmsg) from [<804b9054>] (__sys_sendmsg+0x4c/0x7c)
Jul 16 06:57:18 raspberrypi kernel: [117621.172988] [<804b9054>] (__sys_sendmsg) from [<804b909c>] (SyS_sendmsg+0x18/0x1c)
Jul 16 06:57:18 raspberrypi kernel: [117621.173008] [<804b909c>] (SyS_sendmsg) from [<8000fb40>] (ret_fast_syscall+0x0/0x1c)
Jul 16 06:57:18 raspberrypi kernel: [117621.173019] ---[ end trace 2d66bc66d6534ca4 ]---

У меня ядро ​​4.4.13-v7 +, и я только что впервые запустил rpi-update, поэтому пока не знаю, поможет ли это.

Интересно, может ли это быть связано или, возможно, отдельная проблема
https://www.youtube.com/watch?v=_D_fi_ck9Vo

Мой RPI3 работал без проблем через Wi-Fi, пока я не обновил его до последней версии udev ...

Теперь он больше не подключается ...

Я также установил исправленные модули от Pelwell, но безуспешно: просто не подключается ...

Дай мне знать, если я могу помочь,

Мой лучший,
Mimmo

@ dh-connect ваша проблема решена? Если да, закройте этот вопрос. Благодарю.

Я работаю с LAN с тех пор, не пробовал wlan

Здравствуй,

У меня, похоже, та же проблема с моим rpi 3. Я вернулся к использованию официального USB-ключа RPI wifi, который надежен, но встроенный Wi-Fi умирает через ~ 20 часов подключения с такими сообщениями в системном журнале

brcmfmac: brcmf_cfg80211_reg_notifier: не код ISO3166
cfg80211: Мировой регулирующий домен обновлен:
cfg80211: Главный регион DFS: не задано

это последний распбиан, последняя прошивка

Можно ли повторно открыть этот вопрос?
Почему его закрыли?

Я работаю с LAN с тех пор, не пробовал wlan
dh-connect закрыт 13 дней назад

Это решение не стоит закрывать вопрос ...

У меня все еще есть проблема, и я могу воспроизвести ошибку.

Моя соответствующая часть dmesg:

[174174.396705] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
[174215.037175] brcmfmac: _brcmf_set_multicast_list: Setting mcast_list failed, -52
[174217.037166] brcmfmac: _brcmf_set_multicast_list: Setting allmulti failed, -52
[174219.037171] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -52

Я столкнулся с той же проблемой, что и

$ dpkg-query -s firmware-brcm80211
Package: firmware-brcm80211
Status: install ok installed
Priority: optional
Section: non-free/kernel
Installed-Size: 4296
Maintainer: Debian Kernel Team <[email protected]>
Architecture: all
Multi-Arch: foreign
Source: firmware-nonfree
Version: 0.43+rpi5
Suggests: initramfs-tools
Description: Binary firmware for Broadcom 802.11 wireless cards
 This package contains the binary firmware for wireless network cards with
 the Broadcom BCM4313, BCM43224, BCM43225, BCM43241, BCM43143, BCM4329,
 BCM4330, BCM4334, BCM4335 or BCM43430 chips, supported by the brcmsmac or
 brcmfmac driver.
 .
 Contents:
  * Broadcom 802.11 firmware, version 610.812 (brcm/bcm43xx-0.fw)
  * Broadcom 802.11 firmware header, version 610.812
    (brcm/bcm43xx_hdr-0.fw)
  * Broadcom BCM43143 firmware (brcm/brcmfmac43143-sdio.bin)
  * Broadcom BCM43241 rev 0-3 firmware (brcm/brcmfmac43241b0-sdio.bin)
  * Broadcom BCM43241 rev 4+ firmware (brcm/brcmfmac43241b4-sdio.bin)
  * Broadcom BCM4329 firmware (brcm/brcmfmac4329-sdio.bin)
  * Broadcom BCM4330 firmware (brcm/brcmfmac4330-sdio.bin)
  * Broadcom BCM4334 firmware (brcm/brcmfmac4334-sdio.bin)
  * Broadcom BCM4335 firmware (brcm/brcmfmac4335-sdio.bin)
  * Broadcom BCM43362 firmware (brcm/brcmfmac43362-sdio.bin)
  * Broadcom BCM4354 firmware (brcm/brcmfmac4354-sdio.bin)
  * Broadcom BCM43143 firmware (brcm/brcmfmac43143.bin)
  * Broadcom BCM43430 firmware (brcm/brcmfmac43430-sdio.bin)
  * NVRAM file for BCM943430 (brcm/brcmfmac43430-sdio.txt)
Homepage: http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git

Установите hostapd с мостом.

/etc/hostapd/hostapd.conf

ctrl_interface=/var/run/hostapd
###############################
# Basic Config
###############################
macaddr_acl=0 auth_algs=1
# Most modern wireless drivers in the kernel need driver=nl80211
driver=nl80211

#####
# Logging
#####
logger_syslog_level=0

##########################
# Local configuration...
##########################
interface=wlan0
bridge=br0
hw_mode=g
ieee80211n=1
channel=1
ssid=WillCrashOnYou
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=3
wpa_passphrase=JustYouWait:)
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

/ и т.д. / сеть / интерфейсы

# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

#auto eth0
iface eth0 inet manual
#iface eth0 inet dhcp

#allow-hotplug wlan0
iface wlan0 inet manual
#    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#
#allow-hotplug wlan1
#iface wlan1 inet manual
#    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

auto br0
iface br0 inet dhcp
        post-up /etc/init.d/hostapd restart
        post-down /etc/init.d/hostapd stop
        bridge-ports eth0 wlan0

Для людей с проблемами Wi-Fi Cypress (был Broadcom) предоставил нам модули отладки, чтобы помочь диагностировать проблемы. Поскольку модули зависят от версии ядра, вам сначала необходимо обновить (или, возможно, вернуться) до конкретной версии прошивки:

sudo rpi-update b0ef6e25679d3612a980708cf4c3907ce6e13e84
sudo shutdown -r now

Теперь вы можете скачать и установить модули отладки:

wget -O brcmdbg.tgz "https://drive.google.com/uc?export=download&id=0B_P-i4u-SLBXb1o0UjVLY1NRbk0"
tar zxvf brcmdbg.tgz
sudo ./brcmdbg

Последняя команда запустит сценарий установки, который копирует исходные модули в одну сторону перед заменой их отладочными версиями. Повторный запуск команды вернет исходные версии.

После установки перезагрузите Pi 3 - теперь dmesg | grep brcmfmac покажет такое диагностическое сообщение:

[    9.952095] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[    9.978064] usbcore: registered new interface driver brcmfmac
[   10.277931] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: May 27 2016 00:13:38 version 7.45.41.26 (r640327) FWID 01-df77e4a7
[   10.299380] brcmfmac: CONSOLE: hndarm_armr addr: 0x18003000, cr4_idx: 0
[   10.314284] brcmfmac: CONSOLE: 000000.001
[   10.326859] brcmfmac: CONSOLE: RTE (SDIO-CDC) 7.45.41.26 (r640327) on BCM43430 r1 @ 37.4/81.6/81.6MHz
[   10.326867] brcmfmac: CONSOLE: 000000.001 sdpcmdcdc0: Broadcom SDPCMD CDC driver
[   10.326876] brcmfmac: CONSOLE: 000000.005 reclaim section 0: Returned 47716 bytes to the heap
[   10.326882] brcmfmac: CONSOLE: 000000.007 wlc_bmac_info_init: host_enab 1
[   10.326890] brcmfmac: CONSOLE: 000000.026 wl0: Broadcom BCM43430 802.11 Wireless Controller 7.45.41.26 (r640327)
[   10.326895] brcmfmac: CONSOLE: 000000.027 TCAM: 256 used: 179 exceed:0
[   10.326902] brcmfmac: CONSOLE: 000000.028 reclaim section 1: Returned 81268 bytes to the heap
[   10.326911] brcmfmac: CONSOLE: 000000.029 sdpcmd_dpc: Enable
[   10.371343] brcmfmac: CONSOLE: 000000.121 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
[   10.422886] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[   10.432919] brcmfmac: CONSOLE: 000000.185 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
[   10.432929] brcmfmac: CONSOLE: 000000.186 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
[   10.500547] brcmfmac: CONSOLE: 000000.254 wl0: wl_open
[   10.531447] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[   10.531457] brcmfmac: brcmf_add_if: ignore IF event
[   10.536516] brcmfmac: power management disabled
[   10.540645] brcmfmac: CONSOLE: 000000.284 wl0: wlc_enable_probe_req: state down, deferring setting of host flags
[   13.950422] brcmfmac: CONSOLE: 000003.703 wl_nd_ra_filter_clear_cache: Enter..

Когда вы столкнетесь с проблемой, используйте dmesg > wifidbg.txt чтобы записать трассировку в файл вместе с любыми другими сообщениями ядра, затем загрузите файл куда-нибудь (gist, pastebin, dropbox и т. Д.) И опубликуйте ссылку на него вместе с описание того, что вы делали, когда произошла ошибка.

пожалуйста, освежите мою память: какую команду использовать, чтобы вернуться к стабильной прошивке
если я решу прекратить отладку?

sudo apt-get update
sudo apt-get upgrade

должен сделать свое дело. И sudo ./brcmdbg чтобы просто вернуться к драйверам без отладки.

https://gist.github.com/BenoitSvB/368983f2c09eed2d85a24e6920dc3a50#file -201609081547_wifidbg-txt

Началась отладка; нужно около 5 или 6 попыток связать; не знаю, почему все попытки, кроме последней, не удались; позволит ему работать до тех пор, пока я не увижу потерю ассоциации, а затем сбросит новый dmesg. Непоследовательное поведение ассоциации было моей проблемой до того, как я перестал использовать бортовой Wi-Fi, так что это могло быть на месте. Пожалуйста, дайте мне знать, если какие-либо дополнительные действия могут быть вам полезны.

https://gist.github.com/BenoitSvB/bf8acdbb7b664df90e885603bb4774ce#file -201609081628_wifidbg-txt
Ничего не делать, кроме ожидания; мы видим здесь несколько потерь / возмещений ассоциаций?

Спасибо за это. Хм - эти журналы не очень информативны, но давайте посмотрим, что принесет Cypress.

https://gist.github.com/BenoitSvB/98db53ff884e7b1a57bf1475d6106c56
Необъяснимая потеря и восстановление ассоциации; достаточно долго, чтобы увидеть значок на панели задач.
Точка доступа - Linksys wrt160n с прошивкой: DD-WRT v24-sp2 (08.07.10) std.
Думаю, я могу пока прекратить отладку и вернуться к своему ключу MT7601U за 3 евро, но дайте мне знать, могу ли я помочь.

@pelwell Я не видел восстановления прошивки после sudo apt-get update && sudo apt-get upgrade и sudo rpi-update дает
*** Ваша прошивка уже обновлена; Думаю, мне нужно запустить rpi-update с определенным хешем git, чтобы вернуться к стабильной прошивке. Вы знаете, какой хеш?

История фиксации в репозитории RPI-Distro показывает, что вы хотите зафиксировать 390f53ed0fd79df274bdcc81d99e09fa262f03ab из репозитория микропрограмм, поэтому запустите:

sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab

@pelwell :
корень @ pi3b : / home / pi # sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab
** Программа обновления прошивки Raspberry Pi от Hexxeh, улучшенная AndrewS и Dom* * Самостоятельное обновление
** Перезапуск после обновления* * Программа обновления прошивки Raspberry Pi от Hexxeh, усовершенствованная AndrewS и Dom
Указан недопустимый хеш git

Ах, у rpi-прошивки Hexxeh разные идентификаторы фиксации - попробуйте 569e6611ac20c735647eb0e550484a73935a672d.

Интересно, может ли https://github.com/raspberrypi/linux/issues/1552 / # 1444 быть связан с этой проблемой.

Я недавно развернул установку 40xRPI3, которая выполняет некоторые функции bluetooth, мы должны были получить интерфейсы usb wifi, иначе wlan постоянно зависал бы ... Теперь мы используем внутреннее устройство bl, а внутренний модуль Wi-Fi занесен в черный список в modprobe.d.

Может быть, было бы полезно сделать hcitool name 11:11:11:11:11:11 и посмотреть, генерирует ли это какие-нибудь интересные записи в журнале .. Я только что следил за этой проблемой, у меня не было времени настроить свою лабораторную среду, чтобы проверить что-либо самостоятельно. У нас было несколько зависаний Wi-Fi без включенного BT, но комбинация Wi-Fi + BT может более или менее всегда убивать Wi-Fi за очень короткий промежуток времени .. Это всегда воспроизводилось на любом количестве наших rpi.

@pelwell
ОК; uname -a дает Linux pi3b.thuis 4.4.13-v7 + # 894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU / Linux
Просто для информации: где можно найти хеш git для актуальной стабильной версии прошивки?

@thomasf
хотя у меня есть Bluetooth, в данный момент он мне не нужен. hcitool name 11: 11: 11: 11: 11: 11 ничего не возвращает; что, я полагаю, вполне ожидаемо, поскольку я не подключен ни к какому устройству. Может мне стоит купить мне аудиоустройство BT, чтобы поиграть.

Определите стабильный.

Хэш, который я (наконец) дал вам, относится к выпуску прошивки от 20 июня, который вы получите, если запустите:

sudo apt-get update raspberrypi-kernel
sudo apt-get update raspberrypi-bootloader

Я не знаю ни одного места, которое содержит хеши самого последнего «стабильного» выпуска, но, пройдя через RPI-Distro, как я, а затем перекрестные ссылки с репозиторием Hexxeh, вы можете получить хэши rpi-update для любого выпуска тебе нравится. Если вы считаете выпуск 2016-05-23 стабильным, потому что он был частью последнего полного выпуска Raspbian, тогда вам нужен хэш 3b98f7433649e13cf08f54f509d11491c99c4c0b, который переводится в хэш rpi-update 2b9c0bfacfc11ee8bb9b30dc9698adb36

@BenoitSvB Просто запуск этой команды hcitool из новой загрузки, не касаясь hci0 с любым другим программным обеспечением, приводит к тому, что Wi-Fi начинает плохо себя вести в наших тестах, я не знаю, имеет ли значение, есть ли какие-либо другие устройства Bluetooth, но это наименьший воспроизводимый пример Я могу думать о том, чтобы вызвать проблемы с зависанием Wi-Fi.

Я также тестировал внешний bt dongle + внутренний Wi-Fi, но внутренний Wi-Fi иногда зависает, даже если внутренний драйвер bcm bt не загружен. «Решением» (как и в случае с быстрым исправлением) для нас было использование USB-адаптеров Wi-Fi, которые доказали свою стабильность в наших тестах и ​​использовании в производстве.

Я все еще подозреваю, что № 1313 связан с этим.

Оп 8-9-2016 в 18:07 schreef Томас Фрёссман:

Я также тестировал внешний bt dongle + внутренний Wi-Fi, но внутренний
Wi-Fi иногда зависает, даже если внутренний драйвер bcm bt не работает
загружен. «Решением» (как и в случае с быстрым исправлением) для нас было использование usb wifi.
адаптеры, которые доказали свою стабильность в наших тестах и ​​эксплуатации.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245649229,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFyzObJxRjzQ-uMUlfe8hjRasrfq3nkwks5qoDLXgaJpZM4HupC5.

@pelwell
стабильной в этом случае будет прошивка, выпущенная Фондом с ее последним опубликованным образом и обновленная только с помощью «sudo apt-get update && sudo apt-get upgrade», так что без вызова rpi-update (с определенным git или без него хэш, который, как я понял, предназначен для обновления до более свежей прошивки только для определенных целей).
Это подводит меня к вопросу: могу ли я прочитать хэш моей рабочей прошивки перед загрузкой новой прошивки для тестирования, чтобы упростить восстановление после тестирования, поскольку я бы не стал доверять себе, выполняя перекрестную ссылку, о которой вы упомянули ...

Возможно - cat /boot/.firmware_revision пишет rpi-update, но
не попробовав, я не мог сказать вам, пишут ли также выпуски Raspbian
Это.

boot / .firmware-revision - это вещь rpi-update (
https://www.raspberrypi.org/forums/viewtopic.php?t=106073&p=732449#p731830)

Но я нашел с:

zcat /usr/share/doc/raspberrypi-bootloader/changelog.Debian.gz

что я действительно хочу:

• прошивка от 390f53ed0fd79df274bdcc81d99e09fa262f03ab

Я понимаю перекрестную ссылку из
https://github.com/RPi-Distro/firmware/commit/debian?author=popcornmix в
https://github.com/Hexxeh/rpi-firmware/commit/master сделано тщательно
сравнение дат и описаний коммитов.

Кое-что узнал; спасибо :)

Оп 8 сен. 2016 20:28 schreef "Фил Элвелл" [email protected] :

Возможно - cat /boot/.firmware_revision пишет rpi-update, но
не попробовав, я не мог сказать вам, пишут ли также выпуски Raspbian
Это.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245693018,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFyzOQ_pfODaEmuBGR6pQVXs2W6LggW8ks5qoFO2gaJpZM4HupC5
.

@BenoitSvB : Ваши следы, похоже, указывают на проблему другого рода - прошивка не дает никаких подсказок о том, почему вас отключают. Вы можете получить больше подсказок из анализатора пакетов, такого как WaveShark.

@mathieugouin @ dh-connect @ juched78 @maciex @duncanmcdowell : У меня есть инженер Cypress, который хочет узнать больше о ваших проблемах; Если вы напишете мне письмо - Фил из raspberrypi dot org - я могу связать вас с ним. Если вы хотите ускорить процесс, установите модули отладки, как описано выше, и сохраните вывод dmesg, когда что-то пойдет не так.

@pelwell Google не
Wireshark может помочь, но мне понадобится помощь в настройке / проведении серьезной отладки оборудования.

Да, я имел ввиду wirehark.

Вы можете использовать утилиту dumpcap (часть пакета tshark для текстового режима), чтобы записывать всю активность в файл, а затем уничтожать ее, когда журнал dmesg содержит подозрительное сообщение. Что-то вроде этого:

sudo apt-get install -y tshark
# You can say no when it asks if non-superusers can capture packets
dumpcap -D
# if your wlan isn't interface 2, change the next command to match
# Leave dumpcap recording in the background
sudo dumpcap -i 2 -q -w packets.pcap &
# Search for the error message, then kill the capture
dmesg -w | grep --max-count 1 "wlc_enable_probe_req: state down, deferring setting of host flags" && sudo killall dumpcap

Обратите внимание, что хотя команда «grep --max-count 1» должна останавливаться после одного совпадения, кажется, что для ее остановки требуется еще одна строка ввода, но на практике это не должно быть проблемой.

Если ваш файл захвата становится слишком большим, вы можете настроить dumpcap для использования записи фиксированной продолжительности с помощью опции «-b duration: 60 » (для одной минуты). Существует вероятность того, что такой перезапуск захвата может произойти в неподходящее время и потерять интересующие пакеты, но это маловероятно. Вы всегда можете уменьшить вероятность этого, увеличив продолжительность.

@BenoitSvB Существует поток здесь , что предлагает Отключение роуминга в драйвере PI3 WiFi как способ избежать проблем с подключением. Роуминг позволяет устройству автоматически перемещаться между точками доступа с одним и тем же SSID, но это, вероятно, будет менее полезно на статическом устройстве, таком как Pi3, и есть предположение, что в конечном итоге это может привести к полной потере подключения.

Не могли бы вы попробовать включить параметр roamoff module? Вам необходимо создать /etc/modprobe.d/brcmfmac.conf, содержащий следующее:

options brcmfmac roamoff=1

@pelwell : Отключение роуминга - не решение; но это заставляет меня играть с разными каналами и второй точкой доступа. Я обнаружил, что встроенный адаптер Wi-Fi имеет проблемы только с некоторыми каналами (например, 1, 5) и только на Linksys WRT160N с прошивкой DD-WRT. Любопытно, что ни один из моих других клиентов Wi-Fi не разделял этой проблемы: они без проблем подключатся по всем предложенным каналам на обеих точках доступа. Хорошо для меня, у меня есть стабильный обходной путь (проблемы с неиспользованием каналов бортового Wi-Fi), но нет ясности в этом вопросе.
Вы хотите, чтобы я провел конкретное тестирование?
Кстати, нам нужно установить параметр
options brcmfmac debug = 1
в /etc/modprobe.d/brcmfmac.conf при использовании специальных тестовых драйверов?
И знаете ли вы, как измерить время безотказной работы ассоциации Wi-Fi: тогда я мог бы более систематически тестировать все каналы в течение более длительных периодов времени, не создавая гигантских файлов захвата.

Меня заверили, что запрошенная отладка включена в драйверах отладки по умолчанию (она имеет тот же эффект, что и options bcrmfmac debug=0x100000 ), но не стесняйтесь экспериментировать с другими значениями.

Я не знаю ни одного способа измерить время безотказной работы ассоциации, кроме частого опроса и надежды обнаружить изменения.

Сотрудник Cypress знает об этой теме, но напишите мне письмо (phil at raspberrypi dot org), если с вами свяжутся напрямую.

Здравствуйте,

Есть ли прогресс по этому вопросу? Я могу подключиться к своей открытой сети Wi-Fi, и через случайное время у меня в журналах появляется следующее:

Sep 26 22:42:36 dhcpcd: wlan0: carrier lost
Sep 26 22:42:36 kernel: brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
Sep 26 22:42:36 kernel: cfg80211: World regulatory domain updated:
Sep 26 22:42:36 kernel: cfg80211: DFS Master region: unset
Sep 26 22:42:36 kernel: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Sep 26 22:42:36 kernel: cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Sep 26 22:42:36 kernel: cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Sep 26 22:42:36 kernel: cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
Sep 26 22:42:36 kernel: cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
Sep 26 22:42:36 kernel: cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
Sep 26 22:42:36 kernel: cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
Sep 26 22:42:36 kernel: cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
Sep 26 22:42:36 kernel: cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
Sep 26 22:42:36 kernel: cfg80211: Regulatory domain changed to country: CH
Sep 26 22:42:36 kernel: cfg80211:  DFS Master region: ETSI
Sep 26 22:42:36 kernel: cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Sep 26 22:42:36 kernel: cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Sep 26 22:42:36 kernel: cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
Sep 26 22:42:36 kernel: cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
Sep 26 22:42:36 kernel: cfg80211:   (5490000 KHz - 5710000 KHz @ 160000 KHz), (N/A, 2700 mBm), (0 s)
Sep 26 22:42:36 kernel: cfg80211:   (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
Sep 26 22:42:36 dhcpcd: wlan0: deleting address 2a02::xxxx/64
Sep 26 22:42:36 dhcpcd: wlan0: deleting default route via fe80::xxxx
Sep 26 22:42:36 dhcpcd: wlan0: deleting route to 2a02:xxxx::/64
Sep 26 22:42:36 dhcpcd: wlan0: deleting address fe80::xxxx
Sep 26 22:42:36 dhcpcd: wlan0: deleting route to 10.206.0.0/16
Sep 26 22:42:36 dhcpcd: wlan0: deleting default route via 10.206.0.1

И тогда я не могу пинговать роутер.

После ifdown wlan0 && ifup wlan0 он снова работает до следующего wlan0: carrier lost .

Управление питанием отключено, bluetooth отключен, роуминг отключен (как вы предложили), и моя версия - Linux pi3 4.4.17-v7+ .

это всегда происходило при соединении eth0 с wlan0 у меня та же проблема, что и https://github.com/raspberrypi/linux/issues/1375

У меня точно такая же проблема с пропаданием бортового WiFi Pi3 через случайный промежуток времени. ifup запускает его снова без проблем.

После долгих исследований я обнаружил, что это связано с наличием трех точек доступа (BSSID) с одним SSID (по 1 на каналах 1, 6 и 11). Эта установка поддерживает плавный роуминг и отлично работает со всеми другими клиентами WLAN.

Включение отладки / ведения журнала с помощью стандартного драйвера, похоже, показывает, что на каком-то этапе Pi решает деаутентифицировать и даже помещает в черный список один из BSSID. Причина неясна, но, похоже, решение было принято на стороне Pi.

Когда у меня точно такая же конфигурация на Pi, но только с одним BSSID для SSID, Pi может без проблем работать несколько дней.

К сожалению, отключить роуминг по ссылке Пелвелла (http://projectable.me/optimize-my-pi-wi-fi/) на самом деле невозможно, наличие только одного BSSID на SSID не вариант, и я бы скорее не нужно полагаться на скрипт, который пингует какой-то хост, а затем запускает ifdown / ifup.

Проводятся ли какие-либо дальнейшие исследования для поддержки нескольких BSSID для каждого SSID, или я могу сделать что-то специально для поддержки расследования?

Спасибо!

У меня эта проблема, и моя сеть похожа на сеть @TheOriginalMrWolf .
У меня есть базовая станция Apple и экспресс до аэропорта в ячеистой конфигурации с использованием WDS.

У меня тоже есть эта проблема. Если я копирую файлы на общий ресурс samba, соединение Wi-Fi теряется (raspberry 3, новый установленный raspbian).
Системный журнал:
brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012

У меня точно такая же проблема при воспроизведении музыки с помощью upnp (gmediarender).

У меня такая же проблема при запуске голосовых вызовов в WeChat с rpi в качестве AP с помощью hostapd. Я получаю такой спам:

[19841.278019] net_ratelimit: 940 callbacks suppressed
[19841.304748] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
[19841.331372] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
[19841.361587] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
[19841.399362] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
[19841.434506] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
[19841.466598] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
[19841.496736] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
[19841.525425] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
[19841.552678] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!

Со следами вроде этого:

[19837.728722] ------------[ cut here ]------------
[19837.730033] WARNING: CPU: 3 PID: 503 at drivers/net/wireless/brcm80211/brcmfmac/core.c:1191 brcmf_netdev_wait_pend8021x+0xdc/0xe8 [brcmfmac]()
[19837.732645] Modules linked in: xt_REDIRECT nf_nat_redirect xt_tcpudp nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre iptable_filter ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack cdc_ether sr_mod cdrom brcmfmac brcmutil cfg80211 bcm2835_rng rng_core bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio sch_fq_codel snd_bcm2835 snd_pcm snd_timer snd ip_tables x_tables ipv6
[19837.743040] CPU: 3 PID: 503 Comm: hostapd Not tainted 4.4.38-1-ARCH #1
[19837.745188] Hardware name: BCM2709
[19837.747428] [<80015e54>] (unwind_backtrace) from [<80012ccc>] (show_stack+0x10/0x14)
[19837.752350] [<80012ccc>] (show_stack) from [<804f7dcc>] (dump_stack+0x94/0xb4)
[19837.755134] [<804f7dcc>] (dump_stack) from [<8002e958>] (warn_slowpath_common+0x84/0xb4)
[19837.760698] [<8002e958>] (warn_slowpath_common) from [<8002ea24>] (warn_slowpath_null+0x1c/0x24)
[19837.767009] [<8002ea24>] (warn_slowpath_null) from [<7f2a50b4>] (brcmf_netdev_wait_pend8021x+0xdc/0xe8 [brcmfmac])
[19837.774038] [<7f2a50b4>] (brcmf_netdev_wait_pend8021x [brcmfmac]) from [<7f2950b4>] (send_key_to_dongle+0x94/0xe8 [brcmfmac])
[19837.781637] [<7f2950b4>] (send_key_to_dongle [brcmfmac]) from [<7f2972a8>] (brcmf_cfg80211_add_key+0x16c/0x324 [brcmfmac])
[19837.789919] [<7f2972a8>] (brcmf_cfg80211_add_key [brcmfmac]) from [<7f125ae8>] (nl80211_new_key+0x11c/0x28c [cfg80211])
[19837.798477] [<7f125ae8>] (nl80211_new_key [cfg80211]) from [<807441ec>] (genl_rcv_msg+0x254/0x3c8)
[19837.807003] [<807441ec>] (genl_rcv_msg) from [<80743564>] (netlink_rcv_skb+0xb4/0xd8)
[19837.815674] [<80743564>] (netlink_rcv_skb) from [<80743f88>] (genl_rcv+0x24/0x34)
[19837.824371] [<80743f88>] (genl_rcv) from [<80742efc>] (netlink_unicast+0x188/0x218)
[19837.833161] [<80742efc>] (netlink_unicast) from [<807432cc>] (netlink_sendmsg+0x278/0x330)
[19837.842135] [<807432cc>] (netlink_sendmsg) from [<806fa454>] (sock_sendmsg+0x14/0x24)
[19837.851174] [<806fa454>] (sock_sendmsg) from [<806faadc>] (___sys_sendmsg+0x1d0/0x1d8)
[19837.860301] [<806faadc>] (___sys_sendmsg) from [<806fb780>] (__sys_sendmsg+0x3c/0x68)
[19837.869517] [<806fb780>] (__sys_sendmsg) from [<8000f240>] (ret_fast_syscall+0x0/0x34)
[19837.878793] ---[ end trace e4988f6034c7c2ec ]---

Трассировка выглядит подозрительно похожей на @jrmhaig .

Я просто повторил это снова и немного отладил. На этот раз я получил несколько разных сообщений, которые кажутся интересными (похоже, это те же сообщения, что и @maciex когда-то):

[25353.256286] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[25355.254920] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[25355.257952] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -52

1. Похоже, когда это происходит, вся система зависает. Выполнение while sleep 1; do date; done в цикле приводит к разрыву при замораживании. Интересно, означает ли это, что brcmf_proto_bcdc_msg, возвращающий -110 (тайм-аут), является всего лишь симптомом реальной проблемы - он просто регистрируется везде, где мы зависаем.
2. Я измерил (с помощью vcgencmd ) температуру и напряжения во время замерзания. Насколько я могу судить, там не о чем сообщать.
3. Моя система представляет собой точку доступа с пересылкой на модем ZTE 4G через USB (т.е. client -> wlan0 -> rpi -> usb0 -> 4g . Кажется, что usb0 все еще может получить доступ к Интернету, когда происходит зависание Wi-Fi.

Re: комментарии выше, это происходит в режиме совместного использования NAT для меня с roamoff=1 . Ни один из них не устранил и не смягчил проблему для меня.

После отключения WPA (в моем случае с использованием create_ap -w 2 для включения только WPA2) проблема кажется исправленной. Хотя непонятно почему.

Я также сталкиваюсь с проблемами, описанными здесь. В моем случае это происходит всякий раз, когда я обращаюсь к файлам (обычно mp3) через Samba из файлового менеджера и плеера Samsung + ES.

Моя raspberry pi3 подключена к моей точке доступа по Wi-Fi. Поэтому вся связь с ним осуществляется через сеть Wi-Fi. У него нет ни монитора, ни клавиатуры, ни мыши.

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

Ниже моих записей системного журнала.

27 декабря 16:11:50 raspberrypi kernel: [560.902063] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
27 декабря, 16:11:52 ядро ​​raspberrypi: [562.928930] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg сбой со статусом -110
27 декабря 16:11:54 ядро ​​raspberrypi: [564.926659] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg сбой со статусом -110
27 декабря, 16:11:54 ядро ​​raspberrypi: [564.926820] brcmfmac: brcmf_cfg80211_get_station: Ошибка GET STA INFO, -52
27 декабря 16:11:56 ядро ​​raspberrypi: [566.924560] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg сбой со статусом -110
27 декабря, 16:11:58 ядро ​​raspberrypi: [568.922555] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg сбой со статусом -110
27 декабря 16:11:58 ядро ​​raspberrypi: [568.928073] brcmfmac: brcmf_cfg80211_get_station: Ошибка GET STA INFO, -52
27 декабря, 16:12:00 ядро ​​raspberrypi: [570.920675] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg сбой со статусом -110
27 декабря, 16:12:02 ядро ​​raspberrypi: [572.918980] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg сбой со статусом -110
27 декабря, 16:12:02 ядро ​​raspberrypi: [572.924580] brcmfmac: brcmf_cfg80211_get_station: Ошибка GET STA INFO, -52
27 декабря, 16:12:04 ядро ​​raspberrypi: [574.917259] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg сбой со статусом -110
27 декабря, 16:12:06 ядро ​​raspberrypi: [576.915703] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg сбой со статусом -110
27 декабря, 16:12:06 ядро ​​raspberrypi: [576.921498] brcmfmac: brcmf_cfg80211_get_station: Ошибка GET STA INFO, -52
27 декабря, 16:12:06 raspberrypi ifplugd (wlan0) [1149]: Использование режима обнаружения: IFF_RUNNING

@rcassaniga
У меня тоже была такая же проблема с идентичной настройкой.

Решение после нескольких часов отладки:
Отключите IPv6 на малине в /etc/modprobe.d/ipv6.conf:
псевдоним net-pf-10 выкл.
псевдоним ipv6 выключен
параметры ipv6 disable_ipv6 = 1

Это обходной путь, только если вы не используете ipv6 в своей сети.

Спасибо @ varl0g ты мой герой! :)
Похоже, это обходное решение работает для меня, больше не могу воспроизвести проблему.

@ varl0g : Похоже, обходной путь сработал, потому что я не могу воспроизвести ошибку.

Спасибо и счастливого 2017 года.

Пытался отключить ipv6. Это не имело значения. Я пробовал выключить режим энергосбережения. По-прежнему никакой разницы. Однако, когда я установил канал своей точки доступа на 6 (вместо 11), мой Raspberry Pi работал в течение 2 дней без проблем!

Я хочу подтвердить, что обходной путь с отключением IPv6 не работает.
К сожалению, у меня такая же проблема с роутером RPi3 и Apple Airport Extreme.

@rajid , @ dh-connect
Удивительно, но это тоже решило мою проблему, когда я изменил канал Wi-Fi моей точки доступа на 6 вместо автоматического, спасибо @rajid

У меня тоже есть эта ошибка - brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
Где исправить ????
Я пробую ядро ​​4.9, ядро ​​4.4.41 - у всех есть эта ошибка. Электропитание 2.4а.

Я должен отозвать свой предыдущий комментарий по поводу канала 6. Видимо, это совпадение, что мой RPI3 имел стабильный Wi-Fi в течение 6 дней.

Просто интересно, повезло ли кому-нибудь с этой проблемой. Я пробовал отключить управление питанием, блютуз и переключение каналов. Пока ничего не помогло. Я использую Octoprint с подключенной веб-камерой. Кажется, это происходит довольно часто, и я замечаю, что это происходит намного чаще, когда у меня установлено более одного HTTP-соединения.
ошибка системного журнала перед переходом в режим энергосбережения:
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
Ошибка системного журнала после режима энергосбережения:
octopi kernel: [10317.342360] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!! octopi kernel: [10317.342593] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!! octopi kernel: [10327.358384] brcmfmac: brcmf_sdio_bus_txdata: out of bus->txq !!!
Сейчас у меня Linux octopi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

Я наконец-то добился того, чтобы мой RaspPi 3 работал стабильно на моем Wi-Fi, изменив канал 2,4 ГГц моего Wi-Fi на «6». Я забыл, что было раньше, 11 думаю, но не уверен. Это не сработало, и я нашел веб-страницу, на которой говорилось, что это проблема, но 6 работает нормально. Стало намного лучше с тех пор, как я переключил домашний Wi-Fi на канал 6.

/ raj

3 марта 2017 г. в 20:39 Даниэль < [email protected] [email protected] > написал:

Просто интересно, повезло ли кому-нибудь с этой проблемой. Я пробовал отключить управление питанием, блютуз и переключение каналов. Пока ничего не помогло. Я использую Octoprint с подключенной веб-камерой. Кажется, это происходит довольно часто, и я замечаю, что это происходит намного чаще, когда у меня установлено более одного HTTP-соединения.
ошибка системного журнала перед переходом в режим энергосбережения:
brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
Ошибка системного журнала после режима энергосбережения:
ядро осьминога: [10317.342360] brcmfmac: brcmf_sdio_bus_txdata: вне шины-> txq !!! ядро осьминога: [10317.342593] brcmfmac: brcmf_sdio_bus_txdata: вне шины-> txq !!! ядро осьминога: [10327.358384] brcmfmac: brcmf_sdio_bus_txdata: вне шины-> txq !!!
В настоящее время я использую Linux octopi 4.1.19-v7 + # 858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU / Linux

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-284126948 или отключите поток https://github.com/notifications/unsubscribe-auth/AFAlZVD- 39p6wrK1h7WmH2Hc13mwu55Zks5riOr_gaJpZM4HupC5 .

https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed -b52498112777.png https://github.com/raspberrypi/linux https://github.com/raspberrypi/linux/issues/1342#issuecomment-284126948

канал 6, ширина канала 20 МГц, уже несколько недель выглядит стабильно.

Я наблюдал ту же проблему, о которой Отключение ipv6, предложенное @ varl0g, решило мои проблемы. Wi-Fi теперь стабилен в течение многих дней, тогда как раньше он ломался через несколько минут после загрузки.

Мне не повезло на канале 6 или 7. Больше никто на этих каналах не подтвердил.
Я попытался прошить свой sd новым образом, и теперь мои контроллеры Wi-Fi не получают надлежащую аренду DHCP. Они загружаются с локальными IP-адресами 169.254.xx.xx, а не с подсетью с моего DHCP-сервера.

Решил просто стереть его и пойти установить новейший raspbian и установить octoprint из исходников. пока без проблем.

Насколько я могу судить, это проблема самого программного драйвера brcm80211 sdio.c.
Строка 0x40012 на самом деле является 0x00040012, которая при интерпретации с использованием масок и кодов отсюда ~ строка 55 может рассматриваться как строка почтового ящика, указывающая на изменение управления потоком на DEVREADY. Странно то, что строка никогда не интерпретируется как таковая и, таким образом, попадает в обратно совместимый раздел драйвера ~ строка 1127 файла sdio.c в исходном коде brcm80211 / brcmfmac здесь ..

У меня нет большого опыта работы с самим драйвером, а также у меня нет возможности перекомпилировать и тестировать (у меня только один rpi3, и я бы не хотел испортить среду, в которой он живет, в настоящее время. m не разбирается в перекомпиляции / обновлении драйверов linux ..) так что я не совсем уверен, но кажется, что два сообщения HMB отправляются друг за другом так быстро, что у драйвера не хватает времени, чтобы интерпретировать их оба .

Для тех, кто задается вопросом, в настоящее время я использую octoprint (созданный вручную) на моем rpi3 по беспроводной сети (да…) с емкостным сенсорным экраном adafruit pitft2,8 "и настраиваемым ядром adafruit (версии 4.4.27-v7 +) и дублирую проблему, когда пытаюсь получить доступ к видеопотоку (Logitech C270) на моем Samsung Galaxy S7 через PrintDroid pro или через Chrome. Блокировка происходит без сбоев каждый раз, когда это выполняется, и происходит только по беспроводной сети. Я обновил источник питания, отключил ipv6 и управление питанием, безрезультатно.

@TGYK Можете ли вы проверить упомянутую проблему - вам она кажется такой же? Какие сообщения вы получаете в dmesg? кевент упал?

@TGYK. Вы сделали ссылку на исходную страницу Broadcom на github - можете ли вы указать, где возникают проблемы в дереве ядра Raspberry Pi здесь? Немного сложно отследить, какие строки кода вы имеете в виду.

sdio.c находится здесь, в дереве 4.9 https://github.com/raspberrypi/linux/tree/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac.

@ JamesH65 На странице github, которую вы связали, строка, о которой я говорю, находится примерно в 1140–1147 годах. Что касается ошибки dmesg, сообщение такое же, как показано выше:
«Неизвестное содержимое данных почтового ящика: 0x40012», за которым следует ошибка escan (-52).

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

Спасибо за информацию. Возможно, связанная проблема, я считаю, похожа в том, что это проблема с драйвером Wi-Fi, который, возможно, получает странное сообщение, вызывающее еще больше странностей в стеке, но я все еще копаю.

У меня такая же проблема с Raspberry Pi Zero W с симптомом, аналогичным @TGYK. В моем случае я запускаю mpd на нуле и управляю им через клиент Android на Samsung Galaxy S5. В обязательном порядке, если я переведу телефон в режим ожидания во время работы приложения контроллера (т. Е. Без возврата сначала на главный экран), нулевой Wi-Fi прервется с сообщением «Неизвестное содержимое данных почтового ящика». Если я просто оставляю устройство на холостом ходу или стараюсь всегда закрывать приложение, прежде чем позволить телефону перейти в спящий режим, оно будет работать бесконечно.

У меня была эта проблема с Raspian, а теперь и с OSMC.

В основном периодически, но что интересно, доступ к веб-интерфейсу Kodi с моего S7 всегда вызывает эту проблему. То же самое с iPhone моей жены работает безупречно и никогда не вызывает проблем.

@daedalia : У меня очень похожая проблема с Samsung Galaxy Tab S. Однако у меня нет доступа к устройству iPhone / iPad для подтверждения ...

На моем устройстве Samsung происходит сбой Wi-Fi при попытке доступа к веб-интерфейсу tvheadend.

Этого не происходит при доступе из браузера Firefox с ПК с Windows.

Рад, что нашел эту ветку, подумал, что я единственный. У меня те же проблемы, что и на плакатах выше, Wi-Fi пропадает на моем pi3 / osmc при доступе с Samsung Galaxy Tab A. Работает нормально при доступе с планшета Nexus 7, телефона OnePlus или ноутбука Acer, только Samsung дает проблемы. Легко повторяемый. Кажется, драйверу samsung wifi не нравится встроенный Wi-Fi pi3? Добавление ключа Wi-Fi tp-link к Pi3 - это обходной путь для меня.

@philborman Мне любопытно, используете ли вы один и тот же мобильный браузер на Samsung и Nexus?

Оба работают под управлением Chrome, но это проблема не только браузера. Если я использую Яце для
control kodi он отлично работает с нексуса / мобильного телефона / ноутбука, но pi3 WiFi падает
если я попробую то же самое от самсунга. То же самое, если я ssh в, вылетает с Samsung
а не другие. С ssh я могу немного, но любые передачи файлов или
даже редактирование текстового файла приведет к отключению Wi-Fi.

В среду, 12 апреля 2017 г., 19:03 Матье Гуен, [email protected] написал:

@philborman https://github.com/philborman Мне любопытно, вы используете
тот же мобильный браузер на Samsung или Nexus?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-293643847 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ALmHOdtJ9AQtpfU7tmeVouI-a4STg2WMks5rvQPJgaJpZM4HupC5
.

Кто-нибудь, комментирующий здесь, имеет возможность собрать ядро ​​с имеющимся у меня патчем, который может с этим помочь? Они основаны на 4.9, но могут работать и на 4.4. Обратите внимание, это только тесты ...

diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index df60c98..82f618c 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -2076,6 +2076,13 @@ static struct sk_buff *smsc95xx_tx_fixup(struct usbnet *dev,
                        return NULL;
        }

+       if (skb_cloned(skb))
+       {
+               printk(KERN_ERR "Found a cloned skb");
+               if (pskb_expand_head(skb, 8, 0, GFP_ATOMIC))
+                              return NULL;
+       }
+
        if (csum) {
                if (skb->len <= 45) {
                        /* workaround - hardware tx checksum does not work
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index a190f53..402beb1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -2100,6 +2100,14 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
        int rc = 0;

        brcmf_dbg(DATA, "tx proto=0x%X\n", ntohs(eh->h_proto));
+
+       /* Possible we might receive a cloned skb, if this happens
+        * we must unclone it as we are going to be alter the data by
+        * adding headers.
+        * unclone will only do anything if it is cloned so no check required
+        */
+       skb_unclone(skb, GFP_ATOMIC);
+
        /* determine the priority */
        if ((skb->priority == 0) || (skb->priority > 7))
                skb->priority = cfg80211_classify8021d(skb, NULL);

Здравствуйте,

У меня та же проблема, что описана здесь, с одним из моих 2 Pi3. Wi-Fi теряет соединение через некоторое время, может быть от 30 минут до нескольких часов. Я пробовал абсолютно все, что здесь предлагалось, включая изменение каналов Wi-Fi на AP и т. Д., Но безуспешно. Что чрезвычайно странно, так это то, что на моем втором Pi3 (версия 1.2 тоже точно такая же) и с той же SD-картой / установкой (Raspbian), которую я переключаю между обоими, Wi-Fi надежен в течение многих

Это действительно странно. Оба Pi3 обновлены с помощью rpi-update, ядра 4.9 и прошивки №991, но это уже было то же самое с предыдущими выпусками ядра / прошивки.

Если вы выполните rpi-update, вы получите вышеуказанные исправления, одобренные разработчиками ядра - это для драйвера smsc9x и драйвера brcmfmac на прошлую ночь. Не могли бы вы попробовать это? Если это все еще не удается, можете ли вы выполнить dmesg и посмотреть, есть ли что-нибудь странное в системном журнале? Хотя я подозреваю, что, возможно, неисправность аппаратного обеспечения очевидна, поскольку беспроводной чип нагревается, учитывая, что другой Pi отлично работает с той же картой.

Благодарю. Я сделал это на подозрительной плате, Wi-Fi отключился через несколько минут.
dmesg дает следующее:
``
[266.654964] brcmfmac: brcmf_sdio_bus_sleep: ошибка при изменении состояния сна шины -110
[266.655033] brcmfmac: brcmf_sdio_txfail: ошибка SDIO, команда прерывания и завершение кадра
[266.659215] brcmfmac: brcmf_sdiod_regrw_helper: не удалось записать данные F1 @ 0x1000d ,
[266.663346] brcmfmac: brcmf_sdiod_regrw_helper: не удалось прочитать данные F1 @ 0x1001a ,
[266.667472] brcmfmac: brcmf_sdiod_regrw_helper: не удалось прочитать данные F1 @ 0x10019 ,
[266.671608] brcmfmac: brcmf_sdiod_regrw_helper: не удалось прочитать данные F1 @ 0x1001a ,
[266.675736] brcmfmac: brcmf_sdiod_regrw_helper: не удалось прочитать данные F1 @ 0x10019 ,
[266.679866] brcmfmac: brcmf_sdiod_regrw_helper: не удалось прочитать данные F1 @ 0x1001a ,
[266.683992] brcmfmac: brcmf_sdiod_regrw_helper: не удалось прочитать данные F1 @ 0x10019 ,
[269.655049] brcmfmac: brcmf_sdio_bus_sleep: ошибка при изменении состояния сна шины -110
[272.069378] net_ratelimit: 35 обратных вызовов подавлены

......... затем этот "цикл" продолжает заполнять журнал dmesg несколько раз в минуту.

Изменить: я прикоснулся ко всем компонентам на плате, они все, но не горячие, я бы сказал, около 30 °, просто немного теплее, чем кожа моих пальцев.

Хм, SDIO - это интерфейс между Pi и беспроводным чипом - время ожидания истекает (-110). Это действительно похоже на проблему с аппаратным обеспечением - поскольку чип нагревается, возможно, где-то на интерфейсных линиях sdio есть плохой паяный стык, что означает отключение связи.

Ping @ Roger-Thornton - Роджер, мы можем что-нибудь сделать, чтобы это проверить?

@Crrispy Можете ли вы проверить, что у вашего Pi нет недостатка мощности - что сообщает vcgencmd get_throttled ?

@pelwell : после потери Wi-Fi я проверил и задушил = 0x0

Не думаю, что это аппаратный сбой, простая перезагрузка всегда мгновенно решает проблему.

@ JamesH65 Я не думаю, что это похоже на проблему с производством оборудования, поскольку все линии работают так, как должны. Если есть другие указания на проблемы с оборудованием, я могу взглянуть на плату.

Похоже, это не такая же проблема, как у меня. У меня только один пи3 и это
Wi-Fi надежен, пока я не подключусь с планшета Samsung. Соединить с
что-нибудь еще, и это нормально. Не похоже на питание или перегрев
связанных, так как это нормально в течение нескольких дней, пока я не подключусь к неправильному
планшет и он падает.

Я предполагаю, что это связано с драйвером или прошивкой, что-то, что самсунг
драйвер сообщает, что pi3 не нравится.

В чт, 27 апреля 2017 г., 22:01 Crrispy, [email protected] написал:

@pelwell https://github.com/pelwell : после потери Wi-Fi я проверил, и
дросселируется = 0x0

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297823068 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5
.

В последней версии raspbian было сделано несколько исправлений для работы в сети -
когда вы в последний раз

sudo apt-get update
sudo apt-get dist-upgrade

?
Возможно, стоит попробовать посмотреть, исправит ли это что-то.

28 апреля 2017 года в 14:38 philborman [email protected] написал:

Похоже, это не такая же проблема, как у меня. У меня только один пи3 и это
Wi-Fi надежен, пока я не подключусь с планшета Samsung. Соединить с
что-нибудь еще, и это нормально. Не похоже на питание или перегрев
связанных, так как это нормально в течение нескольких дней, пока я не подключусь к неправильному
планшет и он падает.

Я предполагаю, что это связано с драйвером или прошивкой, что-то, что самсунг
драйвер сообщает, что pi3 не нравится.

В чт, 27 апреля 2017 г., 22:01 Crrispy, [email protected] написал:

@pelwell https://github.com/pelwell : после потери Wi-Fi проверил,
и
дросселируется = 0x0

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
или отключить поток
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHag08r5c96nB39R3F-mFW772qBbGks5r0evJgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

У меня такая же проблема с raspbery pi zero W. Через некоторое время я не могу подключиться к нему по ssh. Все перепробовала. Один забавный факт ... когда я подключил rpi к своему телевизору, чтобы устранить неполадки после того, как я не смогу подключиться к нему по ssh ... он работал на 18 часов безупречно. Затем я переключил hdmi на другое устройство, и через некоторое время, когда я захотел использовать ssh на pi, я получил красивую информацию «нет маршрута к хосту». Когда я снова подключил кабель hdmi, я смог пропинговать шлюз. В журналах ошибок нет, iwconfig вроде нормально. systemctl перезапуск сети помог.

Как указано выше, попробуйте последнюю версию Raspbian и сообщите, если вы все еще видите
эта проблема.

28 апреля 2017 года в 19:30 frankja2 [email protected] написал:

У меня такая же проблема с raspbery pi zero W. Через некоторое время я не
может подключиться к нему по ssh. Все перепробовала. Один забавный факт ... когда я подключился
rpi на телевизор, чтобы устранить неполадки после того, как я не смогу подключиться к
это ... он работал на 18 часов как скала. Затем я переключил hdmi на другой
устройство и через некоторое время, когда я хотел ssh to pi, я получил красивое "нет"
маршрут к хосту "информация. Когда я снова подключил кабель hdmi, я смог пропинговать
шлюз. systemctl перезапуск сети помог.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D298073149&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=RRDqSoxb3C7hDEBxNO3XBNmSEOtX2e-ViBXtXxAJvMY&s=fnPJANeV-xMcDLPhx_cDGAdzEL2Lkk9HBD9Re7R8i2E&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHUqtTFP0QfIH-5FX9tlk9JtsUYZnsYks5r0jA2gaJpZM4HupC5&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=RRDqSoxb3C7hDEBxNO3XBNmSEOtX2e-ViBXtXxAJvMY&s=wkn8zDGV-kUL1yxzQL15ZaghSmFFncriyxZU91j_SSs&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Возможно, я единственный, кто достаточно упрям, чтобы это стало проблемой, но я обнаружил, что в моем wpa_supplicant.conf неправильно указан код страны (пропущено, что это отдельный элемент конфигурации от других вариантов локализации). Я не скажу, что проблема исчезла полностью, но как только я это исправил, она перестала терять сетевое соединение, как «каждый раз, когда я подключаюсь с моего samsung», как это было раньше.

Просто обновился до последней версии (apt-get dist-upgrade), и это обнадеживает.
Мое предыдущее обновление было около 2 недель назад, как раз перед тем, как я сообщил о
начальные проблемы. Последние пару часов работает нормально, Wi-Fi нет
отсев вообще. Большое спасибо!

28.04.17 15:53 ​​Джеймс Хьюз написал:

В последней версии raspbian было сделано несколько исправлений для работы в сети -
когда вы в последний раз

sudo apt-get update
sudo apt-get dist-upgrade

?
Возможно, стоит попробовать посмотреть, исправит ли это что-то.

28 апреля 2017 года в 14:38 philborman [email protected] написал:

Похоже, это не такая же проблема, как у меня. У меня только один пи3 и
его
Wi-Fi надежен, пока я не подключусь с планшета Samsung. Соединить с
что-нибудь еще, и это нормально. Не похоже на питание или перегрев
связанных, так как это нормально в течение нескольких дней, пока я не подключусь к неправильному
планшет и он падает.

Я предполагаю, что это связано с драйвером или прошивкой, что-то, что самсунг
драйвер сообщает, что pi3 не нравится.

В чт, 27 апреля 2017 г., 22:01 Crrispy, [email protected] написал:

@pelwell https://github.com/pelwell : после потери Wi-Fi проверил,
и
дросселируется = 0x0

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub

< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
или отключить поток
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub

https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
или отключить поток

https://github.com/notifications/unsubscribe-auth/ADqrHag08r5c96nB39R3F-mFW772qBbGks5r0evJgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298003537 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ALmHORKJxKdws0fMKU5tpfoJHJSah0Ffks5r0e9FgaJpZM4HupC5 .

Это исправлено для меня в последней версии.

Большинство других «исправлений», похоже, упускают из виду то, что моя система работала.
отлично со всем, кроме одного планшета (Samsung), так что кажется
проблема заключалась в том, что самсунг отправил что-то драйвер / прошивку Wi-Fi pi3
не мог справиться.

Если код моей страны был установлен неправильно, почему только Samsung
проблемы. Остальные планшеты / телефоны / ноутбуки все подключаются нормально.

Во всяком случае, сейчас это исправлено - по крайней мере, не упало в последние несколько
часов. Еще время покажет ...

28.04.17, 21:09 rraszews писал:
>

Я могу быть единственным, кто достаточно упрям, чтобы это стало проблемой, но
Я обнаружил, что в моем wpa_supplicant.conf установлен код страны
неверно (пропущено, что это был отдельный элемент конфигурации от другого
варианты локализации). Не скажу, что проблема ушла
полностью, но как только я это исправил, он перестал терять свою сеть
соединение в режиме "каждый раз, когда я подключаюсь с моего samsung"
было раньше.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298082370 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ALmHOWtM-_MXCz5RoQd8XShI4Mk-4LAyks5r0jlUgaJpZM4HupC5 .

В моем случае это длилось около 19 часов. После этого я больше не мог ssh ...

В чем разница между rpi-update и dist-upgrade?

Потому что после rpi-update у меня было 4.9.25+ # 995, а затем я сделал dist-upgrade, и ядро ​​вернулось к 4.9.24+ # 993. В любом случае для меня проблема до сих пор не решена. На этот раз я использовал другой rpi0w и другой блок питания :) Последний шаг - использовать другую SD-карту.

Хорошо, спасибо за информацию.

Потребуется дополнительная информация, чтобы попытаться воспроизвести. Ваша установка, что
вы подключились и какой сетевой трафик идет, любые журналы dmesg
или другие сообщения об ошибках, когда sh перестает работать.

Благодарю.

29 апреля 2017 года в 16:16 franko [email protected] написал:

В моем случае это длилось около 19 часов. После этого я больше мог использовать ssh ...

В чем разница между rpi-update и dist-upgrade?

Потому что после rpi-update у меня было 4.9.25+ # 995
https://github.com/raspberrypi/linux/pull/995, а затем я сделал
dist-upgrade и ядро ​​вернулись к 4.9.24+ # 993
https://github.com/raspberrypi/linux/pull/993 . В любом случае для меня проблема
все еще не исправлено.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298175041 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHQR8cadrEhb55YJj5PV6PP_odmJmks5r01RJgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Здравствуйте,

Я поместил Pi3 в футляр с довольно мощным вентилятором, и температура в комнате в настоящее время составляет 19 ° C, так что это не может быть проблемой тепла. Поменял блок питания на другой (тоже 5В 3А). Использовал другую SD-карту, dist-upgrade, затем rpi-update.
Вчера он работал несколько часов, я надеялся, что это будет исправлено, но через 3-4 часа он отключился (ping -t работает с моей машины windoze).
Попробовал еще раз сегодня утром, Wi-Fi отключился менее чем через 20 минут :-(
По-прежнему ошибка -110 от драйвера Wi-Fi на sdio (см. Выше), которая повторяется в цикле до перезагрузки.
А другой мой Pi3 подключился на 3-4 дня, без проблем.
Так что это может выглядеть как аппаратный сбой. Но .. почему он никогда не выходит из строя при загрузке и всегда работает после перезагрузки? Действительно озадачивает.
Почему он пытается изменить "состояние сна шины", если для wlan0 отключено управление питанием? (извините, если вопрос тупой).

только что сделал apt-get update; apt-get dist-upgrade . К сожалению, для меня никаких изменений. По моим наблюдениям, проблема связана с преодолением wlan0 вопроса о том, может ли это быть связано с беспорядочными половыми связями. Устали еще rpi-update проверить 4.9.25

на самом деле это даже хуже, чем раньше, так как соединение сейчас обрывается обычно всего за несколько минут, и я могу видеть обычные журналы

[  410.095280] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
[  523.447618] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[  526.007648] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[  526.007659] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110

«Потому что после rpi-update у меня было 4.9.25+ # 995, а затем я сделал dist-upgrade, и ядро ​​вернулось к 4.9.24+ # 993».

Странно. Я сделал dist-upgrade, перешел на 4.9.24+ # 993, и когда я делаю rpi-update прямо сейчас, он говорит, что у меня уже есть последняя прошивка, и ей нечего делать ... почему она не обновляется до 4.9.25 / # 995?

На самом деле нужно сказать, что использование brcmfmac/wlan0 bridged кажется более стабильным, чем с чистым wlan0 (все с hostapd)

Итак, можете ли вы дать полное и точное описание вашей установки вместе с
типы подключенных устройств и любые сообщения об ошибках dmesg, которые вы можете получить
при сбое беспроводной связи.

Мне действительно нужен способ воспроизвести проблему, которая не займет часы, поэтому
Любая предоставленная информация, которая может помочь в этом, с благодарностью принимается.

1 мая 2017 года в 17:27 Szymon Stasik [email protected] написал:

На самом деле должен сказать, что использование brcmfmac / wlan0 bridged, похоже, работает больше
стабильнее, чем с чистым wlan0 (все с hostapd)

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D298367138&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=EjlHynB9dJ8jSAEyJJ1GhRYyOmqDmnvnudeSn-6_IGA&s=u8cZPP8YoQwzh97BQP6tqY2_2yZ30j_UKtU-Lrb3WCc&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHb-5FiQT-5FkgQciloIK9Zw7fsj2ju2kks5r1gfYgaJpZM4HupC5&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=EjlHynB9dJ8jSAEyJJ1GhRYyOmqDmnvnudeSn-6_IGA&s=1_t1KVf3cAXu26O3AikloysPJ6Pi44P6C7y8pebOFww&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Я не знаю, связано ли это конкретно с этим аспектом проблемы, но IIRC мне удалось полностью воспроизвести один способ сброса Wi-Fi с помощью команды hcitool .. Может быть, это больше невозможно, это было примерно год назад и мы пошли с usb wifi, чтобы решить проблему, которая сработала для кучи rpis ...

https://github.com/raspberrypi/linux/issues/1342#issuecomment -245637144

@thomasf Какова была настройка вашей системы (автономное устройство, точка доступа, точка доступа с мостовым подключением и т. д.) и на каком компьютере вы выполняете команду hcitool? Быстрый тест на устройстве, подключенном к другому Pi по беспроводной сети, не выявил проблем.

@ JamesH65 Мы рассмотрели множество сценариев, и проблема была воспроизведена в любой конфигурации ..

Когда команда hcitool была запущена на rpi, она обычно теряла сетевое соединение (Wi-Fi) в течение нескольких секунд. IIRC было легче воспроизвести, если на устройстве был сетевой трафик (например, передача файлов).

Бегло взглянув на нашу окончательную систему подготовки, следующая wpa_supplicant.conf была последней, которую мы использовали ... Я думаю, что она не сильно отличается от той, которая вызвала проблемы с внутренним интерфейсом Wi-Fi, я уверен, что мы начали использовать только одну точку доступа, но у нас все еще были проблемы ..

(SSID и ключи отредактированы):

country=ID
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
    priority=10
    ssid="..."
    psk="..."
}

network={
    priority=10
    ssid="..."
    psk="..."
}

network={
    priority=10
    ssid="..."
    psk="..."
}

network={
    priority=10
    ssid="..."
    psk="..."
}

# Thomasf home AP
network={
    priority=1
    ssid="MKONION"
    psk=...
}

Я только что нашел скрипт под названием troublemaker.sh в репозитории подготовки сейчас ..

Это очень взломано, я думаю, что я подготовил его для запуска при запуске ~ примерно раз в несколько минут или около того ~~ (редактировать: вероятно, только один раз, поскольку он сам выполняет некоторый цикл) на кучу rpi, чтобы спровоцировать проблемы и получить несколько журналов сохранено ..

Это в основном использовалось до того, как я понял больше о проблемах .. Я думаю, что время пинга и потери пакетов увеличивались в течение периода, прежде чем Wi-Fi полностью отключился ..

#!/bin/bash

set -e

sudo killall ping hcitool bash || true
nohup sudo bash -c 'while true; do date; iwconfig ; sleep 60; done' >>${HOME}/troublemaker_iwconfig.log &
nohup sudo bash -c 'while true; do date; ifconfig ; sleep 60; done' >>${HOME}/troublemaker_ifconfig.log &
nohup sudo hcitool lescan --duplicates >>${HOME}/troublemaker_lescan.log &
nohup ping -s 50000 192.168.1.1 >> ${HOME}/troublemaker_ping.log &
nohup sudo bash -c 'while true; do sleep 60; date; sudo hcitool name 11:11:11:11:11:11 ; done' >>${HOME}/troublemaker_hcitoolname.log &

Запуск сценария устранения неполадок на последней стабильной версии Raspbian (ядро 4.9) не показывает ошибок, что хорошо, но плохо для попытки воспроизвести ошибки!

@ciekawy Оглядываясь назад, вы, кажется, можете легко воспроизвести проблему, которую мы не можем здесь сделать. Не могли бы вы дать мне некоторое представление о ваших точных настройках, чтобы я мог заняться расследованиями. Также стоит взять самое последнее rpi-update, так как там были некоторые исправления для USB, которые могут иметь или не иметь отношения (если вы используете Ethernet). Мне нужно знать топологию вашей сети, как настроен Pi, что, похоже, вызывает проблему. Ничего действительно!

@ JamesH65 , Моя текущая настройка:

auto lo
iface lo inet loopback

iface eth0 inet manual

allow-hotplug wlan2 # internet access - wlan2 is Atheros AR9271 using ath9k_htc
iface wlan2 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1 # internal AP 1 - D-Link using rt2800usb
iface wlan1 inet static
    post-up iwconfig wlan1 power off
    hostapd /etc/hostapd/hostapd1.conf
    address 10.114.0.11
    netmask 255.255.255.0
    network 10.114.0.0
    broadcast 10.114.0.255

allow-hotplug wlan0 # internal AP 2 - integrated using brcmfmac
iface wlan0 inet static
    hostapd /etc/hostapd/hostapd.conf
    address 10.114.0.10
    netmask 255.255.255.0
    network 10.114.0.0
    broadcast 10.114.0.255

auto br0 # helper bridge to be independent on the wlan interface being used
iface br0 inet static
bridge_ports wlan0 wlan1
    address 10.114.0.1
    netmask 255.255.255.0
    network 10.114.0.0
    broadcast 10.114.0.255

также как для brcmfmac

[    4.485558] brcmfmac: Firmware version = wl0: May 27 2016 00:13:38 version 7.45.41.26 (r640327) FWID 01-df77e4a7
[    9.306550] brcmfmac: power management disabled

Стоит отметить, что этот RPI работал стабильно в течение нескольких дней (хотя более продолжительные передачи 10 Мбит / с также могли вызвать некоторые проблемы), когда роли были переключены и wlan0 brcmfmac использовался для подключения к Интернету, а локальная точка доступа работала на wlan2 ath9k. Я изменил конфигурацию, так как мне нужно использовать лучшую антенну, подключенную к wlan2 для доступа в Интернет.

Мои последние rpi-updated были 1 мая

У меня такая же проблема в rpi3 с использованием Archlinux-ARM.

После нескольких часов работы create_ap он перестает работать с сообщениями dmesg, о которых уже сообщили другие:
[11418.347554] brcmfmac: send_key_to_dongle: ошибка wsec_key (-110)

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

Linux alarm 4.9.25-2-ARCH # 1 SMP Пт 5 мая 00:46:52 UTC 2017 armv7l GNU / Linux

Та же проблема с Pi Zero W, текущим Raspbian Lite. Через некоторое время (от минут до часов) dmesg показывает
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
С этого момента соединение Wi-Fi пропало, и его можно перезапустить только с помощью команд rmmod'ing и modprob'ing brcmfmac.

Я отключил управление питанием: без изменений.
Я обновил все через apt-get upgrade / dist-upgrade: без изменений
Я обновил материал через rpi-update: без изменений

brcmfmac наверняка прослушивается. У меня была такая же проблема с dmesg msg "brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012", а иногда и с разными сообщениями, как описано в моем сообщении выше.

Я использую адаптер USB Wi-Fi tp-link, и теперь мое приложение работает нормально.

Я надеюсь, что Broadcom сможет исправить ошибки в brcmfmac.

Есть обходной путь?

Как я уже упоминал в начале этого разговора, я изменил свой маршрутизатор Wi-Fi на использование канала 6 вместо 11 (который он использовал раньше), и мой rPi с тех пор (с января по настоящее время) работает без проблем. все.

Возможно, это связано с этим примечанием к модулю ядра:

Это поколение микросхем содержит дополнительную нормативную поддержку, не зависящую от драйвера. Устройства используют единый всемирный регулирующий домен, с каналами 12–14 (диапазон 2,4 ГГц) и каналами 52-64 и 100–140 (диапазон 5 ГГц), ограниченными для пассивной работы. Передача по этим каналам подавляется до тех пор, пока на этих каналах не будет наблюдаться соответствующий другой трафик. В драйвере мы используем вымышленный код страны «X2» для обозначения этой всемирной нормативной области. В настоящее время нет интерфейса для настройки другого домена. Драйвер считывает код страны SROM с чипа и передает его mac80211 в качестве нормативной подсказки, однако в остальном эта информация не используется драйвером.
(отсюда: https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211)

Я полагаю, это означает, что даже код страны "DE" (который должен разрешать более высокие каналы Wi-Fi) не имеет никакого эффекта? Но я не уверен, что это могло иметь эффект, аналогичный проблеме Unknown mailbox data content: 0x40012 ...

По крайней мере, для меня это не обходной путь - переключился с канала 11 на канал 6 сегодня, через 2 часа: Unknown mailbox data content: 0x40012

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

Возможно, это вызвано дополнительной мощностью, необходимой для работы при слабом сигнале.

Та же проблема, что и Crrispy.

Для тех, кто работает над этим с USB-адаптером WiFi (смена канала и т. Д., У меня тоже не работает), Edimax EW-7811Un сработал сразу, когда я подключил его к USB-кабелю OTG на RPI Zero W. Я этого не сделал. Не нужно делать никаких настроек или ifconfig - он сразу был в сети! Вчера я несколько часов возился с TP-Link Archer T1U AC450.

@ b3nj1 - извините, что

Я выбрал такое же решение - купил USB-адаптер с внешней антенной и чипсетом mt7601 (около 5 евро) для своего Zero W, работает безотказно. Прежде всего, следовало бы купить не-W ... эта проблема существует уже больше года, и ее не видно.

@blacktigersoftware - странно, правда !? Zero W WiFi отлично работает. Zero W Bluetooth отлично работает. Но если я использую оба одновременно, система становится невыносимо медленной и в конечном итоге недоступной через Wi-Fi.

Быстро изучил описанную выше проблему с мейбоксом. Google показывает, что это, похоже, происходит изрядно (и по крайней мере одна ссылка на платформу, отличную от Pi). Код драйвера обнаруживает, что в сообщении, возвращающемся из почтового ящика (я предполагаю, что это соединение с прошивкой HW), установлены некоторые биты, которых не должно быть. Однако он только печатает сообщения - не выполняет никаких операций восстановления или возврата ошибок. Поскольку кажется, что это значение, возвращаемое прошивкой, у меня нет доступа к нему, чтобы на самом деле увидеть, что происходит, а таблица данных на чипе совершенно бесполезна. Так что я думаю, что это нужно отправить в Broadcom / Cypress / linux-wireless для исследования.

Также стоит отметить, что у нас действительно установлена ​​последняя версия прошивки HW, согласно https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm. Файлы имеют разницу в длине на один или два байта, но это все.

Проблема в том, что за ошибкой почтового ящика следуют другие ошибки (-52, -110 и т. Д.), И только перезагрузка системы Wi-Fi снова работает.

-110 - ошибка тайм-аута, указывающая на то, что что-то еще умирает и не отвечает. -52 - недопустимый обмен, аналогичный тому же. Я подозреваю, что к тому времени, когда произошла ошибка почтового ящика, прошивка на микросхеме не исправна, поэтому эти другие ошибки продолжаются.

Может ли любой, кто может воспроизвести проблему, собрать последнее ядро ​​разработчика Pi (4.11, доступно на нашем github) и посмотреть, возникает ли по-прежнему ошибка почтового ящика. Прежде чем я начну продвигать вверх по течению, я хотел бы знать, что это все еще происходит на последней версии ядра, и я не смог воспроизвести это.

Я могу подтвердить, что проблема возникает в: Linux alarm 4.9.25-2-ARCH # 1 SMP Fri May 5 00:46:52 UTC 2017 armv7l GNU / Linux

Я не тестировал в ядре 4.11

Драйвер, использованный в моих тестах: brcmfmac: Firmware version = wl0: Dec 15 2015 18:10:45 version 7.45.41.23 (r606571) FWID 01-cc4eda9c

@ b3nj1 - ух ты, спасибо за хедз-ап

Всем - это происходит только при включенном гпу?

Графический процессор всегда включен (в некоторой степени) во всех моделях Pi.

Вы имеете в виду, когда включен Bluetooth?

@ JamesH65 - Я попробую 4.11. Могу ли я просто клонировать / строить в соответствии со следующим? При клонировании в соответствии с этими инструкциями я использую ветку rpi-4.9.y. Стоит мне проверить rpi-4.11.y или что-то еще?

https://www.raspberrypi.org/documentation/linux/kernel/building.md

заранее спасибо

Проверьте ветку rpi-4.11.y, затем перестройте ее, следуя инструкциям, которые вы
связаны с.

25 мая 2017 года в 05:02 b3nj1 [email protected] написал:

@ JamesH65
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jamesh65&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=MvrZEWZr46JRqX_2LLKdchnCVZJLmKJ9gMYoScOCXTc&s=kiIB6faklaD63EgzIvXgaWaSep5vCF5K06oTlqQQKb8&e=

• Дам 4.11 попробовать. Могу ли я просто клонировать / строить в соответствии со следующим?
  При клонировании соответственно я нахожусь на ветке rpi-4.9.y. Я должен оформить заказ
  вместо rpi-4.11.y или что-то другое?

https://www.raspberrypi.org/documentation/linux/kernel/building.md

заранее спасибо

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D303916506&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=MvrZEWZr46JRqX_2LLKdchnCVZJLmKJ9gMYoScOCXTc&s=AGANXJT8mm2dDDBNh9M40Me6Y0E0V8bfRyuFuxauBlQ&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHcEFH69JTeMvuM4RIT3hJafMoVyiks5r9P1RgaJpZM4HupC5&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=MvrZEWZr46JRqX_2LLKdchnCVZJLmKJ9gMYoScOCXTc&s=BQHNOl8syT4Dp5uU3x6CKOUD2Eli4Z4xoPanb8_hnFI&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Чтобы повторить некоторую информацию, которую я предоставил в другом месте, я тестировал беспроводное соединение в условиях низкого энергопотребления. Я довел его до того, что USB-устройства отключились, но не заметил никаких проблем с беспроводным подключением. Хотя это доказывает, что это не проблема питания, это стоит отметить.

Мне случилось найти, как воспроизвести это, запустив sudo memtester 256M 1 через SSH с моего телефона; Wi-Fi умирает, как только memtester начинает заполняться этими "загружающими" символами:

Loop 1/1:
  Stuck Address       : ok
  Random Value        : \
                        ^-- Here

Странная вещь, Wi-Fi зависает только при этом на моем телефоне. Я безуспешно пробовал свой компьютер, другой пи и маршрутизатор.

@ JamesH65 - Обновление 2: я смог загрузиться с 4.11 (я неправильно настроил ядро ​​в первый раз).
Linux rpiz 4.11.2+ #2 Thu May 25 21:19:11 PDT 2017 armv6l GNU/Linux

К сожалению, система все еще ячмень реагирует, когда я забиваю BT.

Когда я снова подключаю внешний USB WiFi и подключаю адрес этого адаптера, все снова в порядке.

• Бенджамин

Новое ядро ​​собрано и установлено из ветки rpi-4.11.y, следуя инструкциям здесь: https://www.raspberrypi.org/documentation/linux/kernel/building.md.
Linux raspberrypi 4.11.2-v7+ #1 SMP Fri May 26 03:55:54 CEST 2017 armv7l GNU/Linux

К сожалению, wifi по-прежнему зависает с той же ошибкой:
brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Если вы подключаетесь, когда Wi-Fi отключается, вы можете перезапустить его. Я сейчас тестирую сценарий bash, чтобы узнать, помогает ли это. Я собираюсь запустить его в cron. Вот он, если кому интересно.

#!/bin/bash

ping -q -c 3 192.168.254.1 > /dev/null

if [ $? -ne 0 ]
then
    systemctl restart [email protected]
    sleep 3
    ping -q -c 3 192.168.254.1 > /dev/null
    if [ $? -ne 0 ]
    then
        dhcpd wlan0
    fi
fi

exit

Я запускаю это в течение дня и пока не заметил падения моего Wi-Fi.

@ JR1994
Это все еще работает?
Как часто вы его запускаете?
Каждую минуту ?

Я попробую его на некоторых из моих малин, у меня есть несколько, которые я перезагружаю каждый раз, когда он не может пинговать маршрутизатор

заранее спасибо

Все идет нормально. Проверяю каждые 2 мин.

Обратите внимание, что последняя версия прошивки для brcmfmac слишком старая:

brcmfmac: версия микропрограммы = wl0: 15 декабря 2015 г. 18:10:45 версия 7.45.41.23 (r606571) FWID 01-cc4eda9c

@semeion Не уверен, какую прошивку вы используете - текущая должна быть «Version: 7.45.41.26 CRC: 5932ca06 Date: Fri 2016-05-27 00:15:32 PDT Ucode Ver: 1043.2060 FWID: 01-df77e4a7». По сути, это то же самое, что и в репозитории linux-firmware, хотя мы получаем наш напрямую от Brcm.

@ JamesH65 Это сообщение было возвращено в dmesg.

$ dmesg | grep brcmfmac
[    7.242110] usbcore: registered new interface driver brcmfmac
[    7.337467] brcmfmac: Firmware version = wl0: Dec 15 2015 18:10:45 version 7.45.41.23 (r606571) FWID 01-cc4eda9c
[   15.072509] brcmfmac: power management disabled

Но используя vcgencmd version он показывает:

$ /opt/vc/bin/vcgencmd version

# Firmware Version #
May 30 2017 15:23:29 
Copyright (c) 2012 Broadcom
version b8cdd5ae76f39d9f353dfa8fb48bf7e33b74903c (clean) (release)

Это не прошивка чипа Wifi, это прошивка SoC, которая получает
обновляется довольно часто.

Тем не менее, все еще не уверен, почему ваша система считает, что в ней установлена ​​эта старая прошивка. Ты
у вас очень последняя прошивка SoC, поэтому, вероятно, вы сделали обновление apt-get
недавно?

5 июня 2017 года в 17:55 Александр Болелли [email protected] написал:

@ JamesH65
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jamesh65&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=W4TAJLAOB4LK3uzOCSYuvCg12E0PPs2YnLK7F3dSY6o&s=M_TSF6XbiHCAZO2_1FYozegsNPyrTwcm6HGX8iccJsg&e=
Это сообщение было возвращено в dmesg. Но с использованием версии vcgencmd он показывает:
`$ / opt / vc / bin / vcgencmd версия
Версия прошивки

30 мая 2017 15:23:29
Авторские права (c) 2012 Broadcom
версия b8cdd5ae76f39d9f353dfa8fb48bf7e33b74903c (чистая) (выпуск) `

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D306242176&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=W4TAJLAOB4LK3uzOCSYuvCg12E0PPs2YnLK7F3dSY6o&s=w68PzYzJ8vnRpMlooVMqrykuimfbvRpWuispieW9KgU&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHTn-5FXFlZe4iParOh8BaB5IxFTATXks5sBDMUgaJpZM4HupC5&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=W4TAJLAOB4LK3uzOCSYuvCg12E0PPs2YnLK7F3dSY6o&s=8571drfpHyjrCl9XD_lHk65aTZxzWBxIm0grbwi225U&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

@ JamesH65 Как я уже сказал выше, я использую Archlinux-ARM, это дистрибутив с скользящим выпуском, и да, моя система обновлена ​​с помощью pacman -Syu (pacman -Syu является эквивалентом apt-get upgrade / update).

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

В любом случае, ошибка происходит с raspbian, верно? Об ошибке сообщили в марте 2016 года? Это старое.

PS. Английский не мой родной язык, извините за ошибку / опечатку.

Хорошо, не понял, что вы используете ARCH. Похоже, они не поставляют
последняя прошивка для чипа Wifi. Вы можете обновить его вручную,
может решить вашу проблему, а может и нет - я думаю, что, вероятно, есть несколько
беспроводные ошибки, и нет никакой гарантии, что вы видите
один человек видит на Распбиане.

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

Обратите внимание, что обычно мы не поддерживаем другие дистрибутивы, наш собственный дистрибутив
Raspbian, поэтому для исследования проблемы нам необходимо воспроизвести ее на
это.

5 июня 2017 года в 23:13 Александр Болелли [email protected] написал:

@ JamesH65 https://github.com/jamesh65 Как я уже сказал выше, я использую
Archlinux-ARM, это постоянно обновляемый дистрибутив, и да, моя система обновлена
с помощью pacman -Syu (pacman -Syu является эквивалентом apt-get upgrade / update).

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

В любом случае, ошибка происходит с raspbian, верно? Об ошибке сообщили в
Март 2016? Это старое.

PS. Английский не мой родной язык, извините за ошибку / опечатку.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306325452 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHaL4XsN5drPggS8eJDZWme4LyKXWks5sBH2CgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

@ jamesH65 Да, конечно. Я попробую спросить в # archlinux-arm, почему эта прошивка устарела. В любом случае я буду следить за этой проблемой и искать решение. Я сообщу здесь любую обнаруженную информацию.

Заранее спасибо.

@ JamesH65 Я могу постоянно воспроизводить его на моем Raspbian (RPi 3). Если я могу чем-то помочь, дайте мне знать!

Какая у вас установка? Как воспроизвести проблему?

6 июня 2017 года в 14:17 Дэн [email protected] написал:

@ JamesH65 https://github.com/jamesh65 Я могу его воспроизвести
постоянно на моем Raspbian (RPi 3). Если я могу чем-то помочь
с этим, дайте мне знать!

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306483030 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHWyW5cQuS47k3xTmi3UX-QW7ffEYks5sBVF5gaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Посмотрите предыдущие комментарии, я недавно объяснил, как это воспроизвести.
Pi работает под управлением полного Raspbian с 3,5-дюймовым экраном сверху с использованием официального источника питания. Ничего особенного, все обновляется с помощью rpi-update и apt upgrade.

Через несколько дней внутренний Wi-Fi перестает работать со следующим сообщением в dmesg:

[643660.135429] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
[643710.076781] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[643712.636821] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[643712.636834] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[643800.318024] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[643802.878064] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[643802.878076] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[643861.598874] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
[643862.558872] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
[643865.118918] brcmfmac: send_key_to_dongle: wsec_key error (-110)
[643867.679113] brcmfmac: brcmf_cfg80211_change_station: Setting SCB (de-)authorize failed, -110
[643868.638966] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
[643871.199007] brcmfmac: send_key_to_dongle: wsec_key error (-110)
[643873.759040] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
[643876.319079] brcmfmac: brcmf_cfg80211_change_station: Setting SCB (de-)authorize failed, -110
[643878.879108] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
[643881.439147] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
[643883.999183] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
[643886.559225] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
[652339.956933] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110

Я запускаю hostapd на этом интерфейсе, и к Pi подключен еще один USB-интерфейс Wi-Fi. Моя системная информация:

pi<strong i="9">@raspberrypi</strong>:~ $ uname -a
Linux raspberrypi 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux
pi<strong i="10">@raspberrypi</strong>:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 8.0 (jessie)
Release:        8.0
Codename:       jessie

Да, и когда вы увидите, что (-110) вам нужно перезагрузить систему, чтобы она снова заработала ...

Приятно знать, что это происходит и в Raspbian, ошибка не зависит от дистрибутива. То же самое происходит в Archlinux.

Однако, поскольку я переместил свой Wi-Fi с канала 11 на канал 6, с тех пор я не видел проблемы. Из моих предыдущих ответов в этой теме я понял, что это было с 7 января, когда я изменил канал 6. В настоящее время я использую два RaspPI Zero W и один RaspPi 3, все без проблем. Два RaspPi W работают под управлением DietPi.

У меня также есть эта проблема на моем Raspberry Pi 3. Уже пробовал разные каналы Wi-Fi.
Я заметил, что если я также подключу порт LAN, Wi-Fi будет чертовски стабильным. Как только я отсоединяю порт LAN, Wi-Fi постоянно отключается.

Это действительно странно ...!

15 июня 2017 года в 23:02 macmeck [email protected] написал:

У меня также есть эта проблема на моем Raspberry Pi 3. Пробовал разные каналы Wi-Fi.
уже.
Я заметил, что если я также подключу порт LAN, Wi-Fi будет чертовски стабильным.
Как только я отсоединяю порт LAN, Wi-Fi постоянно отключается.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-308878043 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHbUKBO9mG3xpKHFK977h4hrFUhrGks5sEantgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

у меня есть
"brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012"
проблема также в моем rpi3. мой самый надежный обходной путь для предотвращения этой ошибки был
"Wondershaper 9000 9000"
Надеюсь, первопричина определена.

У меня точно такая же проблема. Мой pi3 имеет следующие симптомы при подключении ТОЛЬКО к WIFI:

1. ИСХОДЯЩИЙ Wi-Fi работает ОТЛИЧНО. Я могу без проблем подключаться к Интернету и скачивать файлы на свой pi3.
2. ВСЕ ВХОДЯЩИЕ соединения Wi-Fi не работают. Тайм-аут эхо-запросов, время ожидания доступа http к порту 80, сбой ssh, сбой всего ТОЛЬКО ВХОДЯЩИЕ.
   НОТА:
3. Как только Ethernet подключен к pi3, Wi-Fi работает ЛУЧШЕ, но все равно отбрасывает пакеты.
4. Как только Ethernet удаляется снова, Wi-Fi полностью отключает все входящие соединения.
5. Как только Ethernet снова подключен к pi3, Wi-Fi работает ЛУЧШЕ и пропускает некоторые входящие пакеты. но многие из них все еще отбрасываются.

Пожалуйста, исправьте это!

В ifconfig я заметил следующее:

Пакеты RX: 1613 ошибок: 0 отброшено: 1074 переполнения: 0 кадр: 0
Пакеты TX ошибок: 0 сброшено: 0 переполнено: 0 несущая: 0
столкновения: 0 t xqueuelen: 1000

Так что в основном сторона RX Wi-Fi pi3 сбрасывает пакеты как сумасшедшие. Неудивительно, почему он не отвечает на входящие соединения. ТХ отлично работает!

С тех пор, как я настроил этот скрипт, у меня не было проблем с Wi-Fi на обоих моих
RPI3s.

В среду, 21 июня 2017 г., в 4:26, Эдвард Канг [email protected]
написал:

В ifconfig я заметил следующее:

Пакеты RX: 1613 ошибок: 0 отброшено: 1074 переполнения: 0 кадр: 0
Пакеты TX ошибок: 0 сброшено: 0 переполнено: 0 несущая: 0
столкновения: 0 t xqueuelen: 1000

Так что в основном сторона RX Wi-Fi pi3 сбрасывает пакеты как сумасшедшие.
Неудивительно, почему он не отвечает на входящие соединения.

ПОЖАЛУЙСТА, ИСПРАВИТЬ ЭТО !!

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310049620 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AFHmIH6kkxraxahE22_PpstdDkqW8Pgqks5sGP3ggaJpZM4HupC5
.

Все очень хорошо говорят: «Пожалуйста, исправьте это», но такие проблемы - абсолютная сволочь. На поиск ошибки в драйверах smsc / brcmfmac при мостовом соединении ушел месяц, и мне посчастливилось ее найти, и я подозреваю, что эта встречается реже и ее труднее найти. Если кто-нибудь сможет найти воспроизводимый тестовый пример, который быстро показывает ошибку, это будет большим подспорьем. Некоторые люди, кажется, часто получают ошибку kevent, а я получаю ее очень редко.

Что касается проблемы с отброшенными пакетами, то это рассматривается, когда у меня есть пробелы в расписании. В приведенном выше случае кажется, что вы отбрасываете почти все пакеты, что очень странно и обычно не видно большинству людей. Это происходит со всеми устройствами, подключенными к Pi? Или только один в частности.

прости, Джеймс!

Я не уверен, что вы имеете в виду под всеми устройствами, подключенными к Pi. Отброшенные пакеты вызваны выполнением ifconfig непосредственно на пи. Pi подключен через Wi-Fi к роутеру. Когда пи подключен только к сети Wi-Fi, он постоянно принимает и отбрасывает пакеты.

@ JamesH65 Ну, я согласен с вами, это сложно решить ... Но используя Arch Linux-ARM, установив пакет "create_ap" и включив его (pacman -S create_ap; systemctl start / enable create_ap), вы можете получить - 110 и сообщение «Неизвестное содержание данных почтового ящика: 0x40012» через несколько минут работы ... Просто иногда подключайте к нему свой смартфон и / или смарт-телевизор, и ошибка появится.

Мы не поддерживаем Arch, Raspbian - наша поддерживаемая ОС, и это та, которую я
нужно иметь возможность исправить проблему в. Я не знаю, какая версия
ядро или драйверы, которые использует ARCH, они могут сильно отличаться от
те на Распбиане.

Люди все еще видят проблему, используя Pi в качестве точки доступа?
Используете мост? IPv4 или IPv6? Это своего рода информация (а не
не считая конечно, требуется как можно больше информации) требуется
для воспроизведения проблем.

Обратите внимание, что Broadcom были проинформированы об ошибке почтового ящика (это их чип
и водитель конечно), но с ними дела идут медленно.

21 июня 2017 года в 18:27 Александр Болелли [email protected]
написал:

@ JamesH65
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jamesh65&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w&s=o90aBGb27vZvog3BdioLSa2_MEySix0ymtnTgiNb87c&e=
Что ж, согласен, решить сложно ... Но используя Arch Linux-ARM,
установка пакета "create_ap" и его включение (pacman -S create_ap;
systemctl / startenable create_ap), вы можете получить ошибку -110 и
"Неизвестное содержимое данных почтового ящика: 0x40012" за несколько минут работы ... Просто
иногда подключайте к нему свой смартфон и / или смарт-телевизор, и ошибка
придет.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D310149166&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w&s=bv5qC2cUEdCUx-HsDkQYbYJ1fuscyuPU_iPIGs7ViHA&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHfDuqt5fcQ3ODkJUFKxuUaWgUpIhks5sGVKfgaJpZM4HupC5&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w&s=Ojyj5WoAXeLeCsvarhv2rrmQUVoQGkjZmsfPB2lrOUw&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Я использую статический ipv4 на некоторых устройствах и имею ту же проблему, что и
другие используют dhcp

2017-06-22 4:06 GMT-03: 00 Джеймс Хьюз [email protected] :

Мы не поддерживаем Arch, Raspbian - наша поддерживаемая ОС, и это та, которую я
нужно иметь возможность исправить проблему в. Я не знаю, какая версия
ядро или драйверы, которые использует ARCH, они могут сильно отличаться от
те на Распбиане.

Люди все еще видят проблему, используя Pi в качестве точки доступа?
Используете мост? IPv4 или IPv6? Это своего рода информация (а не
не считая конечно, требуется как можно больше информации) требуется
для воспроизведения проблем.

Обратите внимание, что Broadcom были проинформированы об ошибке почтового ящика (это их чип
и водитель конечно), но с ними дела идут медленно.

21 июня 2017 года в 18:27 Александр Болелли [email protected]
написал:

@ JamesH65
3A__github.com_jamesh65 & d = DwMFaQ & c = DpyQ_ftY536pf7wCBQXXU58xADDRY77THQz
Ju1OmzOo & r = w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m =
BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w & s = o90aBGb27vZvog3BdioLSa2_
MEySix0ymtnTgiNb87c & e =>
Что ж, согласен, решить сложно ... Но используя Arch Linux-ARM,
установка пакета "create_ap" и его включение (pacman -S create_ap;
systemctl / startenable create_ap), вы можете получить ошибку -110 и
"Неизвестное содержимое данных почтового ящика: 0x40012" через несколько минут работы ...
Только
иногда подключайте к нему свой смартфон и / или смарт-телевизор, и ошибка
придет.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D310149166 & d =
DwMFaQ & c = DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo & r = w09_
2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m = BDIwUx7SC6sTRvRQKgA0QZB_
ZlIJDs3bd_wzKoIw_7w & s = bv5qC2cUEdCUx-HsDkQYbYJ1fuscyuPU_iPIGs7ViHA & e =>,
или отключить поток
3A__github.com_notifications_unsubscribe-2Dauth_
ADqrHfDuqt5fcQ3ODkJUFKxuUaWgUpIhks5sGVKfgaJpZM4HupC5 & d = DwMFaQ & c = DpyQ_
ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo & r = w09_
2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m = BDIwUx7SC6sTRvRQKgA0QZB_
ZlIJDs3bd_wzKoIw_7w & s = Ojyj5WoAXeLeCsvarhv2rrmQUVoQGkjZmsfPB2lrOUw & e =>
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310294786 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ACeQBFj8ICNkDl7xYwYJcD6TK-k6_4K5ks5sGhJ1gaJpZM4HupC5
.

Следует отметить, что Wi-Fi отлично работал у меня с того момента, как я получил свой pi3 в прошлом году, до примерно 3 месяцев назад, когда Wi-Fi перестал работать.

Очевидно, что примерно в то время в программном обеспечении должно было произойти какое-то изменение, которое привело к тому, что Wi-Fi перестал работать.

Если ваш Wi-Fi полностью перестал работать, это указывает на проблему на вашей стороне (которая, конечно, может быть усугублена проблемой программного обеспечения), потому что для всех остальных Wi-Fi обычно работает (хотя я вижу отброшенные пакеты).

Кстати, мой rpi3 - совершенно новый производитель в Великобритании.

Я борюсь и с этим несколько месяцев. Иногда это длится минуты. Иногда недели. Общим знаменателем, когда я теряю соединение, является то, что я вижу призывы сбросить мировой регулирующий домен CRDA непосредственно перед тем, как он потеряет соединение. Каждый раз. Точка доступа Ubiquiti AC, канал 11, ширина канала HT40 (единственное, что может быть особенным).

28 июня, 14:19:31 ядро ​​raspberrypi: [980.387378] cfg80211: Мировой регулирующий домен обновлен:
28 июня, 14:19:31 ядро ​​raspberrypi: [980.387387] cfg80211: Главный регион DFS: не задано
28 июня, 14:19:31 ядро ​​raspberrypi: [980.387396] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 июня, 14:19:31 Ядро raspberrypi: [980.387411] cfg80211: (2402000 кГц - 2472000 кГц при 40000 кГц), (н / д, 2000 мБм), (н / д)
28 июня, 14:19:31 Ядро raspberrypi: [980.387426] cfg80211: (2457000 кГц - 2482000 кГц при 20000 кГц, 92000 кГц автоматически), (нет данных, 2000 мБм), (нет данных)
28 июня, 14:19:31 ядро ​​raspberrypi: [980.387439] cfg80211: (2474000 кГц - 2494000 кГц при 20000 кГц), (н / д, 2000 мБм), (н / д)
28 июня, 14:19:31 Ядро raspberrypi: [980.387453] cfg80211: (5170000 кГц - 5250000 кГц при 80000 кГц, 160000 кГц автоматически), (нет данных, 2000 мБм), (нет данных)
28 июня, 14:19:31 ядро ​​raspberrypi: [980.387468] cfg80211: (5250000 кГц - 5330000 кГц при 80000 кГц, 160000 кГц автоматически), (нет данных, 2000 мБм), (0 с)
28 июня 14:19:31 ядро ​​raspberrypi: [980.387481] cfg80211: (5490000 кГц - 5730000 кГц при 160000 кГц), (нет данных, 2000 мБм), (0 с)
28 июня, 14:19:31 ядро ​​raspberrypi: [980.387493] cfg80211: (5735000 кГц - 5835000 кГц при 80000 кГц), (н / д, 2000 мБм), (н / д)
28 июня, 14:19:31 Ядро raspberrypi: [980.387505] cfg80211: (57240000 кГц - 63720000 кГц при 2160000 кГц), (нет данных, 0 мБм), (нет данных)
28 июня, 14:19:32 Ядро raspberrypi: [981.262521] cfg80211: Нормативный домен изменен на страну: США
28 июня, 14:19:32 Ядро raspberrypi: [981.262536] cfg80211: Главный регион DFS: FCC
28 июня, 14:19:32 Ядро raspberrypi: [981.262540] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 июня, 14:19:32 ядро ​​raspberrypi: [981.262549] cfg80211: (2402000 кГц - 2472000 кГц при 40000 кГц), (нет данных, 3000 мБм), (нет данных)
28 июня, 14:19:32 Ядро raspberrypi: [981.262557] cfg80211: (5170000 кГц - 5250000 кГц при 80000 кГц, 160000 кГц автоматически), (нет данных, 2300 мБм), (нет данных)
28 июня, 14:19:32 Ядро raspberrypi: [981.262565] cfg80211: (5250000 кГц - 5330000 кГц при 80000 кГц, 160000 кГц автоматически), (нет данных, 2300 мБм), (0 с)
28 июня, 14:19:32 Ядро raspberrypi: [981.262571] cfg80211: (5490000 кГц - 5730000 кГц при 160000 кГц), (нет данных, 2300 мБм), (0 с)
28 июня, 14:19:32 Ядро raspberrypi: [981.262578] cfg80211: (5735000 кГц - 5835000 кГц при 80000 кГц), (нет данных, 3000 мБм), (нет данных)
28 июня, 14:19:32 Ядро raspberrypi: [981.262584] cfg80211: (57240000 кГц - 63720000 кГц при 2160000 кГц), (нет данных, 4000 мБм), (нет данных)

Извините, что подлил топливо в огонь, но я думаю, что у Pi Zero W такая же проблема.

При переключении wlan0 между режимом точки доступа (при использовании hostapd) и обычным режимом подключения (то есть подключением к маршрутизатору) wlan0 иногда теряет способность связываться с точкой доступа.

Он застрянет в этом состоянии:

~iwconfig wlan0 
wlan0     IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=31 dBm

и ничего, кроме перезагрузки, не исправит. Когда это происходит, я замечаю в dmesg следующие ошибки:

[Wed Jul  5 16:08:27 2017] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[Wed Jul  5 16:09:07 2017] brcmfmac: brcmf_cfg80211_stop_ap: setting INFRA mode failed -7
[Wed Jul  5 16:10:16 2017] brcmfmac: brcmf_cfg80211_stop_ap: setting INFRA mode failed -7
[Wed Jul  5 16:10:18 2017] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error : -30
[Wed Jul  5 16:10:18 2017] brcmfmac: brcmf_cfg80211_scan: scan error (-30)
[Wed Jul  5 16:10:37 2017] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set error : -30
[Wed Jul  5 16:10:37 2017] brcmfmac: brcmf_cfg80211_scan: scan error (-30)

Меня беспокоит то, что это совершенно произвольно и случайно. Иногда я могу переключаться между двумя режимами на некоторое время, прежде чем возникнет проблема. Но в конце концов это так.

FWIW Я думаю, что перезагрузка модуля ядра Wi-Fi (выполнив "modprobe -r -v brcmfmac && modprobe brcmfmac") исправила его, поэтому мне просто нужно создать сценарий, который делает это всякий раз, когда у моего Pi проблемы с Wi-Fi.

Это пока что странно. У меня были проблемы такого типа на Raspberry pi zero & zero W, но они полностью исчезли, когда я переключил каналы (как обсуждалось ранее в этой теме).

Кроме того, в последнее время я использую ОС DietPi и вообще не испытывал никаких проблем. Вы можете попробовать это.

Мне очень хотелось разобраться в проблеме, поскольку я уже видел ее раньше, но сейчас я просто не могу этого добиться! :(

/ raj
(отправлено с iPhone)

5 июля 2017 г. в 9:01 timdonovanuk [email protected] написал:

FWIW Я думаю, что перезагрузка модуля ядра Wi-Fi (выполнив "modprobe -r -v brcmfmac && modprobe brcmfmac") исправила его, поэтому мне просто нужно создать сценарий, который делает это всякий раз, когда у моего Pi проблемы с Wi-Fi.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Чем больше людей сможет это рассмотреть, тем лучше, я ограничен во времени
Я могу потратить на это сейчас деньги из-за других проектов. Одна серьезная проблема
надежный механизм для его воспроизведения.

5 июля 2017 года в 17:10 rajid [email protected] написал:

Это пока что странно. У меня были такие проблемы на Raspberry pi
ноль и ноль W, но они полностью исчезли, когда я переключил каналы (как
обсуждалось ранее в этой ветке).

Кроме того, в последнее время я использую ОС DietPi и не испытывал проблем с
все. Вы можете попробовать это.

Мне очень хотелось разобраться в проблеме, я видел ее раньше, но я
просто не может этого случиться в наши дни! :(

/ raj
(отправлено с iPhone)

5 июля 2017 г., в 9:01, timdonovanuk [email protected]
написал:

FWIW Я думаю перезагрузить модуль ядра Wi-Fi (выполнив "modprobe -r -v
brcmfmac && modprobe brcmfmac ") исправлено, поэтому мне просто нужно создать
скрипт, который делает это всякий раз, когда у моего Pi проблемы с Wi-Fi.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D313150296&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=UAE2wwxV4_BdJX0zfG2qnu3kAD_j1y0Js_FZxpJl4b4&s=haaEuyne9neeuPZzAlNI2PG7DctVLxxfwV3oezxYcwI&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHU6ugUl6QkcLNobslh5Th7hcXeecks5sK7VggaJpZM4HupC5&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=UAE2wwxV4_BdJX0zfG2qnu3kAD_j1y0Js_FZxpJl4b4&s=8TZEHLn2evTT1wzFzZo2CHYC2Zb0ydjsR39j-vskecM&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

@timdonovanuk было бы неплохо, поделитесь с нами своим скриптом, я ищу обходной путь. Может, какой-нибудь скрипт мониторинга работает как systemd service ... Как вы думаете?

Есть ли способ запустить обновление нормативного домена вручную? Как я уже сказал, для меня это выглядит довольно стабильно, когда это происходит, соединение разрывается. Мне было бы интересно запустить его вручную несколько раз, чтобы посмотреть, смогу ли я надежно воспроизвести для вас.

@rajid , случайно у тебя ширина канала 40? А вы помните, видели ли вы аналогичные обновления мировых нормативных требований до того, как выпали? Любопытно, может быть, есть комбинация вокруг канала 11 и очень широкой ширины канала ... и какой маршрутизатор / AP вы используете? Просто ищу какую-то общность, так как я вижу это на канале 11, как и другие ... Моя точка доступа - это Ubiquiti.

Обходной путь переключения с автоматического канала на Apple Extreme на канал 6 у меня не работал. Я буду использовать локальную сеть во время отпуска.

Изменить: теперь я теряю соединение даже с локальной сетью, здесь есть что-то еще, это проблема с нагревом при использовании официального корпуса (без вентилятора)?

Здравствуйте,
Я столкнулся с очень похожей проблемой на Raspberry Pi Zero W.

Я разработал API, работающий с Node.JS на Pi и интегрированный с GPIO.
Pi подключен к моей локальной сети через Wi-Fi. Все отлично работает, когда клиенты ПК вызывают API. Однако, как только я запрашиваю свой API с помощью устройства Android, Pi дает сбой. Сбои происходят случайно: иногда устройства Android могут вызывать API несколько раз, и внезапно происходит сбой.
Под сбоем я подразумеваю потерю пинга, но Pi все еще работает.

Вызов одного и того же API через ПК никогда не вызывает сбоев.

Я попытался изменить канал Wi-Fi, но не добился лучших результатов.

Если я могу запустить что-нибудь, чтобы помочь для диагностики / решения, не стесняйтесь спрашивать!

Что-нибудь в этом сообщении на форуме помогает?

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=188043#p1185246

11 июля 2017 года в 16:22 matthiasbou [email protected] написал:

Здравствуйте,
Я столкнулся с очень похожей проблемой на Raspberry Pi Zero W.

Я разработал API, работающий с Node.JS на Pi, и интегрировал
с GPIO.
Pi подключен к моей локальной сети через Wi-Fi. Все отлично работает, когда ПК
клиенты вызывают API. Однако, как только я запрашиваю свой API с Android
устройство, Pi вылетает. Сбои происходят случайно: иногда API может
вызываться устройствами Android несколько раз, и внезапно происходит сбой.
Вызов одного и того же API через ПК никогда не вызывает сбоев.

Я попытался изменить канал Wi-Fi, но не добился лучших результатов.

Если я могу запустить что-нибудь, чтобы помочь для диагностики / решения, не стесняйтесь спрашивать!

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314479400 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHYDohQoNRBDcX4oG49rK9e6kwpjjks5sM5MpgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

@matthiasbou

Интересно то, что вы сказали, мой драйвер Broadcom возвращает ошибку -110 (иногда другая ошибка) и вылетает именно в тот момент, когда я подключаю свой смартфон Motorola X2 (Android). Но такая же ошибка возникает при подключении моего SmartTV. В любом случае, я могу подтвердить, что сбой происходит во время установления соединения.

Моя страна настроена правильно, ipv6 disable и roamoff = 1, я использую канал 6, проблема все еще возникает. В моем дистрибутиве по умолчанию отключены режим энергосбережения Wi-Fi и Bluetooth.

@ JamesH65 : Я попробовал интересное решение: установить правильную страну (это было не так), отключить IPV6 и роуминг, но проблема все равно осталась :(

Wi-Fi подключается, но как только я начинаю «играть» с устройством Android, делая несколько вызовов API на Pi Zero W, через некоторое время он вылетает.

Почему отключение IPv6 должно устранять проблему Wi-Fi? Есть ли разумное объяснение, почему задействован IPv6, который можно воспроизвести? Единственное, о чем я могу думать, что IPv6 может иметь небольшую дополнительную многоадресную нагрузку из-за RA.

Как бы то ни было, я использую два Pi Zero W в качестве мостов IPv6 между интегрированным wlan0 и внешним eth0 с заблокированным IPv4. wlan0 находится в режиме AP и имеет запущенный сервер ISC dHCPv4. Подключаю к нему разные Android планшеты и смартфоны. Пока не заметил никаких проблем, но, возможно, мне нужно дать им поработать более длительные периоды времени. Я использую канал 6.

Извините, я использую коробку Apple Airport, и здесь нет настройки или упоминания о «ширине канала». Я просто установил канал 6 для сети 2,3 ГГц. Теперь я использую DietPi на своих маленьких системах RaspPi Zero W. Другие RaspPi, которые у меня есть, были настроены давно с Edimax USB, и у меня никогда не было никаких проблем. Я полагаю, что единственный раз, когда я видел проблемы, был Raspbian в системе Zero W. Придется снова загрузить это и посмотреть, смогу ли я воспроизвести это.

/ raj

5 июля 2017 г. в 15:19 Майкл Хэллок < [email protected] [email protected] > написал:

Есть ли способ запустить обновление нормативного домена вручную? Как я уже сказал, для меня это выглядит довольно стабильно, когда это происходит, соединение разрывается. Мне было бы интересно запустить его вручную несколько раз, чтобы посмотреть, смогу ли я надежно воспроизвести для вас.

@rajid https://github.com/rajid , случайно у вас ширина канала 40? А вы помните, видели ли вы аналогичные обновления мировых нормативных требований до того, как выпали? Любопытно, может быть, есть комбинация вокруг канала 11 и очень широкой ширины канала ... и какой маршрутизатор / AP вы используете? Просто ищу какую-то общность, так как я вижу это на канале 11, как и другие ... Моя точка доступа - это Ubiquiti.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это электронное письмо напрямую, просмотрите его на GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-313242611 или отключите поток https://github.com/notifications/unsubscribe-auth/AFAlZVdfvh5QzIlsZYtt9sjpXolJpZAcm .

https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed -b52498112777.png https://github.com/raspberrypi/linux https://github.com/raspberrypi/linux/issues/1342#issuecomment-313242611

Я просто провел больше тестов и сменил роутер, к которому подключается Pi.
До сих пор все работает, когда Pi находится на другом маршрутизаторе Wi-Fi (без изменений на стороне устройства Android):
Конфигурация рабочего маршрутизатора :
Канал 6
WPA-PSK
Полоса пропускания 20 МГц

Нерабочая конфигурация роутера (потеря Wi-Fi после некоторого доступа из Android Wifi):
Netgear WNR1000v2
Канал 6
WPA2-PSK [AES]
Длина фрагмента 2346
CTS / RTS Порог 2347

Я переключу рабочий маршрутизатор на WPA2-PSK, чтобы проверить, можно ли воспроизвести проблему.

@TheDiveO Что касается IPv6, драйвер имеет разные пути кода для ipv6, как и ядро. Может быть ошибка в любом из этих путей, которых нет в ipv6, или, как ISTR из ошибки некоторое время назад, что-то запускает кодовый путь ipv6, когда он должен запускать кодовый путь ipv4 или наоборот. Весь стек довольно запутан.

новое поведение. Изменение языкового стандарта и выполнение apt-get upgrade и update теперь ведет себя следующим образом, когда мой pi3 подключен через WIFI:

теперь устройства вне локальной сети могут подключаться к PI через TCP / IP.

PI по-прежнему отклоняет все подключения (TCP / IP) только в локальной сети.

PI все еще может получить доступ к внешнему Интернету через WIFI.

неважно. Ничего не изменилось. Это точно такое же поведение, как и раньше. Pi3 Wi-Fi отбрасывает все пакеты в локальной сети.

Просто чтобы немного проследить ... Я запустил новую точку доступа (Linksys E4200 V2), которая у меня валялась. Я настроил его на 11 канале для 2,4 ГГц, настроил WPA2 Personal, BSSID и пароль. Затем настроил это на моем raspberry pi zero w. Подключился просто отлично. Затем я переместил эту AP в ту же комнату, где находится моя обычная домашняя AP (которая находится на канале 6). Затем мой RaspPi получил ASSOC-REJECT status_code = 16. Перемещение AP обратно в мой офис снова сделало помощника RaspPi прекрасным.

Итак, похоже, что в моем случае, по крайней мере, канал 11 является проблемой, если точка доступа находится в другой комнате. Я предполагаю, что это, вероятно, указывает на проблему с помехами.

Я также опубликую здесь веб-страницу, которую я нашел, которая сообщает, что такое все коды status_codes и ошибки:

https://supportforums.cisco.com/document/141136/80211-association-status-80211-deauth-reason-codes

Это показывает, что мой "status_code = 16" вызван тайм-аутом, поэтому одна из систем просто не принимает пакеты вовремя.

Я просто подумал, что брошу эту информацию там, если она кому-то поможет.

Когда я включаю свет на кухне, мой Wi-Fi прерывается.
гостиная ... я не знаю почему, но когда вы говорили о помехах, я думаю
я не сумасшедший

2017-07-12 16:27 GMT-03: 00 rajid [email protected] :

Просто вкратце ... Я запустил новую точку доступа (Linksys E4200 V2),
который у меня завалялся. Я настроил его на канал 11 на 2,4 ГГц, настроил
WPA2 Personal, BSSID и пароль. Затем настроил это на моей малине
пи ноль ш. Подключился просто отлично. Затем я переместил эту точку доступа в ту же комнату
где находится моя обычная домашняя точка доступа (которая находится на канале 6). Тогда мой RaspPi
получил ASSOC-REJECT status_code = 16. Один раз перемещаю точку доступа в мой офис
снова сделал сотрудника RaspPi в порядке.

Итак, похоже, что в моем случае, по крайней мере, канал 11 является проблемой, если AP
в другой комнате. Я предполагаю, что это, вероятно, указывает на вмешательство
проблема.

Я также размещу здесь найденную мной веб-страницу, в которой рассказывается, что все
status_codes и коды ошибок:

https://supportforums.cisco.com/document/141136/80211-
ассоциация-статус-80211-деаутентификация-коды-причины

Это показывает, что мой "status_code = 16" вызван тайм-аутом, поэтому один из
системы просто не получают пакеты своевременно.

Я просто подумал, что брошу эту информацию там, если она поможет
кто угодно.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314872003 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ACeQBJdfk2zp1sReVVs1wvrilKHXNm53ks5sNR42gaJpZM4HupC5
.

Есть действительно хорошая программа WiFi Analyzer для Android, которая показывает, какие точки доступа находятся вокруг вас, вместе с их подробной информацией. (Я бы хотел, чтобы что-то подобное существовало для iPhone / iPad, но Apple ...)

@ JamesH65, вы действительно меня смущаете, говоря, что драйвер уровня сетевому уровню 3. «Беспорядок», вероятно, тоже не подходящее слово для этой ситуации ...

На самом деле я этого не говорю. Я не специалист по сетям Linux
стек, но я точно помню, что видел некоторые специфические для IPv6 вещи в
водитель где-нибудь.

Все это находится в дереве ядра, вы можете посмотреть
себя, чтобы успокоить свой ум.

13 июля 2017 года в 08:58 TheDiveO [email protected] написал:

@ JamesH65 https://github.com/jamesh65 ты действительно меня беспокоишь
говоря, что драйвер уровня
сетевой уровень 3. "Беспорядок", вероятно, не подходящее слово для этого
ситуация либо ...

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315002002 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHUSoqqxnhaw4k2ECkzGC9CDkIlhYks5sNc4ngaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

@TheDiveO Джеймс имеет в
SMSC95xx, например, может поддерживать только разгрузку контрольной суммы IPv4 из-за того, что IPv6 требует, чтобы контрольная сумма 0x0000 была заменена 0xFFFF. См. Https://github.com/torvalds/linux/commit/fe0cd8ca1b82983db24b173bb8518ea646c02d25. Следовательно, IPv6 и IPv4 будут следовать разными путями кода. В этом нет ничего сомнительного, но присуще сетевому стеку, где оборудование не может охватить все ситуации.

Я почти уверен, что эта ошибка в драйвере Broadcom, а не в ядре.

Почти наверняка. Драйвер Brcm - это большой кусок кода, и ошибки
такие не легко отлаживать, особенно когда вы не можете их воспроизвести ...

13 июля 2017 г. в 13:04, Александр Болелли [email protected]
написал:

Я почти уверен, что эта ошибка в драйвере Broadcom, а не в ядре.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315058283 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHbr5SiWPKvQZOY7rN8IbyIIscNfVks5sNgexgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Чем больше я борюсь с этим, тем больше я начинаю задаваться вопросом, связано ли это с неспособностью Ubuntu / Debians подключить wlan0 и eth0 к одной и той же подсети без какой-либо обширной настройки. Я собираюсь изучить это подробнее и посмотреть, проблема ли в этом.

@ JamesH65. Было бы

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

13 июля 2017 г. в 13:57 Туомас Айраксинен [email protected]
написал:

@ JamesH65 https://github.com/jamesh65 поможет ли мне (или кто-то
else) установил бы для вас ноль w или rpi 3 в среде, где это
легко воспроизводимые и дать вам доступ по ssh для отладки? (Я
для этого нужно будет купить дополнительный ноль w).

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315069935 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHeQ1RECH-uIIHWPX6ItvRdVbZG_Xks5sNhRWgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Джеймс,
Если я сделаю этот простой цикл опроса, я быстро увижу, что бортовая сеть Wi-Fi переходит в непригодное для использования состояние. Когда я выключаю встроенный Wi-Fi и использую USB-Wi-Fi, он работает найти. Я не помню, чувствителен ли он к присутствию или отсутствию устройства BT, и не могу легко проверить это в течение нескольких дней. Я ограничился 10 минутами, чтобы после эксперимента вернуться к значению пи-ноль w.

bash# ((t= date +% s +600)); while [ date +% s -lt $t ] ; do hcitool name <BTMAC>; done
Надеюсь, это поможет,
Бенджамин

Этот фрагмент кода лишил меня клещей на спине. Спасаясь от них ...

((t = `дата +% s` + 600)); while [`дата +% s` -lt $ t]; do hcitool name "вставить BT MAC"; сделанный

О, МОЙ БОГ. Думаю, поправили. Wi-Fi работает, когда Ethernet отключен. Невероятно.

Я удалил все упоминания об eth0 из своего файла / etc / network / interfaces, заменил allow-hotplug на auto, а затем принудительно отключил беспроводное питание как на wlan0, так и на wlan1.

мой файл / etc / network / interfaces:

авто лоу
iface lo inet loopback

отключение беспроводной сети
авто wlan0
iface wlan0 inet руководство
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

отключение беспроводной сети
авто wlan1
iface wlan1 inet руководство
wpa-conf / etc / wpa_supplicant / wpa_supplicant.conf`

Затем я сбросил arp:

ip -s -s neigh flush all

Потом перезагрузился:

sudo reboot now

И теперь мой вайфай работает. Невероятно. Спасибо всем, кто прокомментировал эту ветку.

Ваша конкретная проблема конфигурации может быть решена, ошибка в драйвере Broadcom все еще присутствует.

Хорошо, мы это рассматривали. Моя первая проблема заключалась в том, что при подключении SSH к моему испытательному устройству сеанс блокировался, ЕСЛИ не был подключен кабель Ethernet. Оказывается, что ARP обрабатывается любым интерфейсом, поэтому, когда Ethernet был подключен, он использовал это. Отсутствие подключения означало, что он обрабатывался Wi-Fi и возникла проблема. Эту проблему можно решить, отключив QoS / ToS в SSH (см. Здесь https://expresshosting.net/ssh-hanging-authentication/), что, в свою очередь, означает, что драйвер Broadcom Wifi очень недоволен TOS (тип service) / поле DSCP. Это уже было замечено ранее в NTP (Issue # 1519). Я подозреваю, что это может быть причиной проблем с Wi-Fi, связанных с этой проблемой, и сегодня я собираюсь покопаться в драйвере Brcm, чтобы узнать, смогу ли я что-нибудь найти.

Промежуточный доклад. Мы определенно наблюдаем проблемы с определенными значениями пакетов TOS, из-за которых пакеты отбрасываются без уведомления, вызывая блокировки SSH. Пока нет ничего очевидного в непонятном коде драйвера, который в любом случае не должен касаться этой части пакета, но явно что-то происходит. Имеет ли это какое-либо отношение к общему зависанию беспроводной сети, о котором здесь сообщается? Пока не знаю.

У меня похожие проблемы на Pi Zero W с raspbian jessie и ядром 4.9.35+
У меня та же проблема, о которой упоминал JamesH65, с SSH и ntpd (TOS). Исправление от https://expresshosting.net/ssh-hanging-authentication/ работало для sshd. У меня также есть проблемы с отключением wlan0, но с несколько менее подробными сообщениями журнала. На первый взгляд это выглядит так, как будто оператор связи потерян, а wpa_supplicant иногда не может пересмотреть условия. Единственный выход из этого - выполнить ifdown wlan0, подождите, ifup wlan0 для меня, тогда wlan0 снова начнет работать. С радостью предоставлю журналы, если они кому-то понадобятся. Просто скажи мне какой.

Промежуточный доклад. Хотел записать несколько заметок, пока они не забылись. Мы определили, что это ответ от подключенного по беспроводной сети pi, который отсутствует при доступе через SSH с другого устройства. Если в этом ответе задано поле TOS, пакет автоматически отбрасывается и никогда не возвращается к запрашивающей стороне. Мы можем воспроизвести это с помощью netcat. Простая команда net cat от беспроводного Pi с установленными флагами TOS, похоже, не выходит из устройства.
Итак, на беспроводном PI попробуйте отправить UDP-пакет на другое устройство ...
nc -T 0x10 -u7
Устройство не получает пакет (как показано при запуске tcpdump в месте назначения)
nc -T 0x00 -u7
попадет в удаленную систему.
Мы пробовали это только по беспроводной сети здесь, в офисе. Мне нужно настроить другую сеть Wi-Fi, чтобы узнать, связана ли она с маршрутизатором или проблемой в драйвере.

Незначительное исправление указанной выше команды netcat
nc -T 0x10 -u <dest_ip> 7
UDP-порт 7 был выбран, так как это эхо-сервис. Не имеет значения, что это не работает на удаленном компьютере, хотя это приводит к соответствующему отклику ICMP о недоступности, который является полезным сигналом того, что удаленный конец получил сообщение.

Начинаю думать, что проблема SSH / ToS на самом деле не связана. Я проследил пакеты до уровня HW, и не имеет значения, установлены ли флаги TOS или нет, пакеты, похоже, сводятся к прошивке (или, по крайней мере, к функции brcmf_sdiod_send_pkt, которая не имеет приоритетной обработки в драйвер linux). Это указывает на то, что проблемы связаны либо с прошивкой в ​​микросхеме (закрытый исходный код), либо с маршрутизатором, то есть беспроводной маршрутизатор, который я использую, не пропускает флаги TOS, которые не равны нулю (или, возможно,> 0x04). Завтра я попробую другой беспроводной маршрутизатор, чтобы проверить это.

Есть ли шанс найти отдел, ответственный за разработку модуля brcmfmac, чтобы кто-нибудь мог следить за этим потоком или, по крайней мере, отвечать, если будет выпущено какое-либо исправление для этих ошибок?

Мы уже поддерживаем связь через список рассылки linux-wireless.

19 июля 2017 г., 19:06, «Александр Болелли» [email protected] написал:

Есть ли шанс найти отдел, отвечающий за разработку
модуль brcmfmac, чтобы кто-то мог следить за этой цепочкой или хотя бы
ответить, будет ли выпущено какое-либо исправление для этих ошибок?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316469790 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHYtYvpxdKd3SBBynOnlDN-ZXiWs_ks5sPkW9gaJpZM4HupC5
.

Мы уже поддерживаем связь через список рассылки linux-wireless.

... и другие прямые маршруты. Проблема всегда заключалась в воспроизводимости - как только у нас есть способ четко продемонстрировать проблему, мы можем представить ее Broadcom / Cypress и исправить. Я никогда не мог увидеть проблему с использованием NTP, но у Джеймса был успешный сбой с SSH, поэтому я оптимистично настроен, что мы доберемся до основной причины.

@pelwell +1 за термин "_успешная неудача" _ :)

У меня есть хакерское исправление проблемы с блокировкой SSH. Похоже, это проблема в прошивке. Вот некоторые подробности.

`
Мы изучаем проблему с Raspberry Pi, где SSH и
Сеансы NTP завершаются ошибкой, если в заголовке IPv4 установлен флаг TOS.

Вот выдержка из того, что такое TOS:

TOS - 0x08 или 0x10. Одновременно может быть установлен только один из 4 битов.
0x10 - минимизировать задержку
0x08 - увеличить пропускную способность
0x04 - максимальная надежность
0x02 - минимизировать денежную стоимость.
Технически TOS был заменен DSCP, но все еще поддерживается.

Мы могли бы попытаться воссоздать эту проблему с помощью DSCP, если это действительно необходимо, но это не так.
кажутся актуальными.

Подробную информацию о проблеме с SSH и обходной путь можно найти здесь https://expresshosting.net/ssh-hanging-authentication/

Однако это явно проблема где-то в сообщениях.
стек, так что это то, что мы исследуем.

Мы смогли воспроизвести простой пример с помощью netcat. В первую очередь,
подключить Pi к точке доступа (PiA) по беспроводной сети с другим подключенным устройством
либо по беспроводной сети, либо через Ethernet в одну и ту же сеть (PiB).

На PiB запустить

sudo tcpdump -n 'udp port 7' -v -i wlan0 <<<< или eth0 в зависимости от соединения

На PiA,

nc -T 0x10 -u7

Это отправляет пакет UDP на порт 7 с флагом TOS, установленным на 0x10.

Это НЕ придет (или когда-нибудь будет очень сильно задержано - 10 секунд)

Отправка TOS как 0

nc -T 0x0 -u7

Прибудет. 0x02 и 0x04 также поступят, 0x8 и 0x10 - нет.

Инструментирование драйвера brcmfmac показывает, что пакет с TOS
flag = 0x10 правильно отправляется вниз по стеку в HW, но затем
пакет пропадает.

Мы смогли пройти пакет, взломав код BCDC,
в функции bcdc.c! brcmf_proto_bcdc_hdrpush приоритет
пакет также помещается в заголовок bcdc. Установив это на
постоянное значение (которое может быть любым от 0 до 7), пакет
передан. Кажется, что постоянное значение для приоритета bcdc
работает, но с установленным приоритетом, определяемым входящим
skb приоритетные вещи не работают, ЕСЛИ TOS равен 0x08 или 0x10. Итак, кажется
быть комбинацией пакетов с разными приоритетами, которая вызывает
значения более высокого приоритета не срабатывают, а не само значение.

Поскольку приоритет заголовка BCDC предназначен для прошивки, это
казалось бы, проблема в самой прошивке, а не в Linux
Водитель.

Вот разница в изменении, которое, кажется, помогает предотвратить возникновение проблемы.

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c index 9f2d0b0cf6e5..2e6132a513be 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcdc.c @@ -274,7 +274,7 @@ brcmf_proto_bcdc_hdrpush(struct brcmf_pub *drvr, int ifidx, u8 offset, if (pktbuf->ip_summed == CHECKSUM_PARTIAL) h->flags |= BCDC_FLAG_SUM_NEEDED; - h->priority = (pktbuf->priority & BCDC_PRIORITY_MASK); + h->priority = 0; h->flags2 = 0; h->data_offset = offset; BCDC_SET_IF_IDX(h, ifidx);

@ JamesH65 Отлично. Поскольку я не жду скорого исправления прошивки, не могли бы вы скопировать это в linux-wireless?

Я собираюсь дождаться информации от Broadcom / Cypress, так как я
не уверен, что этот взлом безопасен при любых обстоятельствах. Я отправил им по электронной почте. однажды
Получу отзыв. Я пришлю патч для linux-wireless.

20 июля 2017 года в 12:41 Стефан Варен [email protected] написал:

@ JamesH65 https://github.com/jamesh65 Отлично. Поскольку я не ожидаю
Скоро исправление прошивки, не могли бы вы скопировать это в linux-wireless?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316678154 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHY3DlxTr9mehRDlxBK3NWbjowxxyks5sPzzqgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Некоторые результаты тестов, похоже, указывают на отсутствие вредных последствий этого взлома. Просто передавал данные туда и обратно, 500 МБ на Wireless Pi, отправлено 3,4 ГБ. Пакеты RX 56 сброшены с 794730, пакеты TX не сброшены с 2813930. Производительность кажется оптимальной для соединения со скоростью 11 Мбит / с. Так выглядит приемлемо, но этот хак фактически отключает то, что, вероятно, должно быть включено, так что это не долгосрочное решение.

@lategoodbye Задумывался над тем, чтобы

@moonman
Как вы думаете, это можно было перенести на ARCH linux-raspberrypi?

@ JamesH65 Конечно, ваш хак подходит не для всех моделей чипов. Но не ваша работа - находить решение для всех из них. Я думаю, что простой копии вашего длинного комментария выше (включая взлом) будет достаточно. Я стремился проинформировать об этой проблеме других разработчиков ядра, не связанных с Broadcom. Я не ожидал, что вы отправите правильный патч для этой проблемы, только отчет об ошибке.

Я предлагаю добавить его в наш репозиторий, чтобы провести серьезное тестирование - начните с rpi-4.12.y, который используется ночными передовыми сборками LibreElec.

Одна мысль - не могли бы вы сделать патч более избирательным в отношении приоритетной фильтрации и при этом решить проблему?

Я просто готовлю PR для репо Pi.

Что касается выборочной проверки, я попытался просто определить приоритет
6 (тот, что передается по стеку - он переведен из TOS
значение чего-то более специфичного для стека Linux) и установив для него значение 0
это действительно сработало, но я подозреваю, что это комбинация
другие приоритеты, а не конкретно 6, что вызывает проблему. Мы
также знайте, что TOS 0x08 также имеет проблемы, и то есть IIRC,
преобразуется в 2 к тому времени, когда он достигает этой точки. Мы могли бы просто сказать, если бы
его 6 или 2, затем установите его на ноль, но я все еще не уверен, что это поймает
все, что может вызвать проблемы. Поскольку в любом случае значение 0-7, я считаю,
для этого взлома лучше просто установить в 0 во всех случаях. Мы знаем это
работает, может быть, конечно, не оптимально, но я думаю, что все пакеты будут
пройти через. Обратите внимание, что этот параметр НЕ влияет на значение TOS в
Пакет IPv4 - он остается прежним, это просто система отправки
приоритет чипа и то, как он затем обрабатывает его, что кажется нестабильным.

21 июля 2017 года в 09:35 Фил Элвелл [email protected] написал:

Одна мысль - не могли бы вы сделать патч более избирательным по приоритетности
фильтрация и все еще есть решение проблемы?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D316940828&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=bmJYpA4c2HSXiPbO68JUYdepjN1tnBs_lkuzpPvnoh4&s=lTkmZTnZKvmqZQgONBOnkdo5C-y1dP_Z61sUY17WvV0&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHYglVaRlIj07b13KHHEPd43W9kiLks5sQGLWgaJpZM4HupC5&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=bmJYpA4c2HSXiPbO68JUYdepjN1tnBs_lkuzpPvnoh4&s=QrCSx1NLJWIkcH1C1mIZRxSCuySlqHXvu_Mpn37WdPw&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

У меня был контакт с Сайпрессом, который собирается попытаться получить это
посмотрел как можно скорее.

21 июля 2017 года в 10:11 Джеймс Хьюз [email protected] написал:

Я просто готовлю PR для репо Pi.

Что касается выборочной проверки, я попытался просто обнаружить
приоритет 6 (тот, который передается в стек - он переводится с
значение TOS для чего-то более специфичного для стека Linux) и установив для него
0, и это, похоже, сработало, но я подозреваю, что это комбинация
различных приоритетов, а не конкретно 6, что вызывает проблему.
Мы также знаем, что TOS 0x08 также имеет проблемы, то есть IIRC,
преобразуется в 2 к тому времени, когда он достигает этой точки. Мы могли бы просто сказать, если бы
его 6 или 2, затем установите его на ноль, но я все еще не уверен, что это поймает
все, что может вызвать проблемы. Поскольку в любом случае значение 0-7, я считаю,
для этого взлома лучше просто установить в 0 во всех случаях. Мы знаем это
работает, может быть, конечно, не оптимально, но я думаю, что все пакеты будут
пройти через. Обратите внимание, что этот параметр НЕ влияет на значение TOS в
Пакет IPv4 - он остается прежним, это просто система отправки
приоритетом чипа, который кажется нестабильным, и тем, как он с этим справляется.
кажется шелушащимся.

21 июля 2017 года в 09:35 Фил Элвелл [email protected] написал:

Одна мысль - не могли бы вы сделать патч более избирательным по приоритетности
фильтрация и все еще есть решение проблемы?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D316940828&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=bmJYpA4c2HSXiPbO68JUYdepjN1tnBs_lkuzpPvnoh4&s=lTkmZTnZKvmqZQgONBOnkdo5C-y1dP_Z61sUY17WvV0&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHYglVaRlIj07b13KHHEPd43W9kiLks5sQGLWgaJpZM4HupC5&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=bmJYpA4c2HSXiPbO68JUYdepjN1tnBs_lkuzpPvnoh4&s=QrCSx1NLJWIkcH1C1mIZRxSCuySlqHXvu_Mpn37WdPw&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Мы также знаем, что TOS 0x08 также имеет проблемы, и это означает, что IIRC конвертируется в 2 к тому времени, когда он достигает этой точки.

Правильный. TOS 0x08 (максимальная пропускная способность) сопоставлен с 2. Это значения TC_PRIO_xxx из http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/pkt_sched.h#L19. 6 = ИНТЕРАКТИВНЫЙ, 2 = МАССОВЫЙ.

Предыдущее тестирование с установкой IPQoS на 8 в sshd_config или с netcat с использованием TOS 8 приводило к отброшенным пакетам.
Ни 0x02, ни 0x04 не вызвали никаких проблем, но драйвер Wi-Fi мало что может сделать из-за разницы в стоимости (ее нет) или надежности, поэтому, вероятно, игнорирует их.
edit На самом деле таблица сопоставления на http://elixir.free-electrons.com/linux/latest/source/net/ipv4/route.c#L177, принимая tos>>1 , устанавливает TOS 0x02 и 0x04 на TC_PRIO_BESTEFFORT = 0 в любом случае, что объясняет, почему у них нет никаких проблем.

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

21 июля 2017 года в 11:07 6by9 [email protected] написал:

Мы также знаем, что TOS 0x08 также имеет проблемы, то есть IIRC,
преобразуется в 2 к тому времени, когда он достигает этой точки.

Правильный. TOS 0x08 (максимальная пропускная способность) сопоставлен с 2. Это TC_PRIO_xxx
значения из http://elixir.free-electrons.com/linux/latest/source/
включить / uapi / linux / pkt_sched.h # L19. 6 = ИНТЕРАКТИВНЫЙ, 2 = МАССОВЫЙ.

Предыдущее тестирование с установкой IPQoS на 8 в sshd_config или с
netcat с использованием TOS 8 приводил к отбрасыванию пакетов.
Ни 0x02, ни 0x04 не вызвали никаких проблем, но драйвера Wi-Fi мало
может быть выше разницы в стоимости (ее нет) или надежности, поэтому, вероятно
игнорируя их (я не проверял).

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316962443 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHXTmjzqVW0o4T9IIoYFPprKvEvS7ks5sQHhXgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Более простой способ воспроизведения - используйте пинг! (Я забыл, что ping / ICMP был выше IP - глупый я)

ping -Q 0x10 <dest ip addr> на Pi3
и запустите tcpdump -n -v -i wlan0 'icmp' в пункте назначения.
Приводит к потере пакетов> 90% на -Q 0x10 или -Q 0x08. Часто это нормально начинается с прохождения 4 последовательных пакетов, но затем идет очень прерывисто.
Он немного более полезен, чем netcat, поскольку (а) он продолжает повторяться, и (б) он сообщает вам, когда получает ответ.

Здесь есть обходной путь: https://github.com/raspberrypi/linux/pull/2126
Если вы хотите протестировать его с ядром 4.9, используйте rpi-update.
Затем замените:
modules / 4.9.39 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko с этим
modules / 4.9.39-v7 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko с этим

РЕДАКТИРОВАТЬ: последнее ядро ​​rpi-update теперь включает патч, поэтому загрузка модулей больше не требуется.

Не уверен, связано ли это. Подключение к бортовому Broadcom на моем Pi Zero W обрывается каждые 2 часа, когда второй интерфейс wlan1 подключен с помощью ключа rt8192eu / 8192eu. Это не похоже на проблему с питанием, потому что это очень циклично, у меня есть pastebin отключений на https://pastebin.com/5hMQHWeW

Когда это продолжается, wpa_supplicant иногда отказывается от попыток без очевидной причины, кроме отказа аутентификации, и единственный способ восстановить соединение на wlan0 - это выполнить ifdown / ifup, который затем работает на 100%.

Теперь я не знаю, вызывает ли это проблемы связанные с модулем ядра Broadcom проблемы, или это ошибка 8192eu, или и то, и другое. Я рад предоставить больше строк журналов, если необходимо, или опубликовать в другом потоке, но кто-то из #raspbian предложил мне добавить это здесь.

Если вы можете подтвердить, что vcgencmd get_throttled возвращает 0x0 после отключения, это исключит проблему с питанием.

Обычно это происходит, когда я сплю / не с Pi, и я оглядываюсь назад, когда я больше не могу подключиться к нему (тогда я подключался через вторую точку доступа и сбрасывал wlan0). Однако, поскольку ключ 8192eu сейчас отключен, не было никаких событий. Я могу подключить второй ключ с неисправным модулем, но как скоро после отключения мне нужно проверить vcgencmd get_throttled?

Пока вы не перезагружаете, верхние биты сообщают вам, было ли когда-либо событие пониженного напряжения.

Просто запустил. Определенно не перезагружался с момента последнего отключения. Можно подтвердить, что vcgencmd get_throttled возвращает:
дросселируется = 0x0

К сожалению, get_throttled не будет работать на Pi0 / Pi0w (не имеет схемы обнаружения пониженного напряжения).

По какой-то причине копирование и вставка разницы из JamesH65 у меня не сработало. Создал файл патча, который должен применяться сразу, решил, что люди могут найти это полезным: https://github.com/bortek/EZ-WifiBroadcast/blob/master/kernel/linux-4.9.28-brcmfmac-tos.patch

В имени файла указано 4.9.28, но должно применяться как минимум до 4.9.35 (и, возможно, более поздних версий).

Скопируйте этот файл в корневой каталог дерева ядра и примените с помощью patch -p1 < linux-4.9.28-brcmfmac-tos.patch

Дополнительная (но нечетная) информация:

Если Pi Zero W подключен к wlan0, но в остальном ничего не делает (скрипт cron проверяет sntp максимум каждые 15 минут), происходят очень частые отключения, что-то порядка 1-10 / час, продолжительностью не более секунды каждое.

Если бы у меня было что-то, использующее соединение, например, простоя в IRC (несколько больших каналов), соединение не разрывается ни разу за все время, это так.

Оказалось, что загрузка модулей ядра 4.9.39 на 4.9.35 была не очень хорошей идеей.

Еще один отчет об ошибке с форума, ошибка почтового ящика кажется обычным явлением.

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=189046

Последнее ядро ​​rpi-update теперь включает патч приоритета BCDC.

Cypress (называвшаяся Broadcom) предоставила нам для тестирования новые версии прошивок для WiFi и Bluetooth. Вы можете скачать предварительную версию здесь . После загрузки на свой Pi запустите:

tar zxvf brcmfw_170808.tgz
cd brcmfw_170808
./brcmfw -i

Будет извлечена, а затем установлена ​​новая прошивка (сначала будут созданы резервные копии старых версий).

Чтобы вернуться к исходной прошивке (что я рекомендую вам сделать перед установкой надлежащей версии):

./brcmfw -u

Что изменилось:

1. CVE-2017-9417: исправление проблемы «Broadpwn»
2. Добавьте строку «CY» в строку версии.
3. Исправление взаимоблокировки порядкового номера AMPDU (потенциальное решение этой проблемы)
4. Обновление версии CLM
5. CVE-2017-0572: исправление повреждения памяти

Небольшое примечание - я отключил внутренний Wi-Fi на своем первом Pi Zero W и переключился на USB-ключ Wi-Fi, все проблемы исчезли. Несколько дней назад я установил еще один Pi Zero W для управления своим 3D-принтером (с помощью OctoPi). Я был немного удивлен, увидев, что внутренний Wi-Fi, кажется, работает безупречно, но после некоторых тестов я могу подтвердить, что Wi-Fi прерывается, как только я подключаюсь со своего телефона LG G4 Android (браузер Chrome). Когда я думаю об этом, я думаю, что поведение первого Pi было очень похоже ...
Подключение с моего ПК к таким эффектам не приводит.

Пожалуйста, попробуйте новую прошивку и сообщите о своих результатах.

Я установил предварительную прошивку. Я все еще получаю сообщение об ошибке «raspberrypi kernel: brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content:», за которой следует сбой Wi-Fi.

Какой у вас вариант использования?

такой же как:
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=189046

пробуя опубликованный там рабочий конфиг. Буду обновлять.

Укажите версию вашего ядра, сводку подключенных устройств и время, необходимое для появления ошибки.

Ошибка почтового ящика все еще расследуется, я не ожидаю этого
прошивка для исправления. В этой прошивке есть дополнительная отладка, чтобы помочь отследить
это хотя. Если включить отладку драйвера (извините, на мобильных и
нет подробностей о том, как это сделать) и увидеть ошибку, а затем сбросить
подробности отладки и публикации здесь, когда вы получите ошибку почтового ящика, будут
полезно.

13 августа 2017 г. в 21:40 "Стефан Варен" [email protected] написал:

Укажите версию вашего ядра, краткое описание подключенных устройств и
требуется много времени, пока не появится ошибка.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322062745 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHRwsQyHa-QqOP7ntTqgCfWlgXpEqks5sX1DlgaJpZM4HupC5
.

Отладка по умолчанию отключена, и для ее включения требуется перестройка модуля (возможно, нам следует изменить это во время этих исследований). Требуемые изменения: добавление BRCMDBG=y в .config с последующим перестроением, затем добавление brcmfmac.debug=0x???????? в /boot/cmdline.txt , где ???????? - шестнадцатеричное число, содержащее битовые значения, задокументированные здесь: https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h#L22

Пробовал тестовую прошивку, опубликованную pelwell, проблема все еще сохраняется. Связь зависает каждые 1-2 часа. Когда соединение разорвалось, и я попытался выполнить ping ( ping 8.8.8.8 ), он снова работал _ кратковременно_ до 8-го ping. При зависании поведение пинга одинаково. Работает-> замораживает-> пинг 8.8.8.8-> работает -> 8-й пинг -> зависает. После этого мне нужно перезагрузить Raspberry Pi. Не знаю, поможет ли это ...

Ядро:
Linux raspberrypi 4.9.41-v7 + # 1023 SMP Вт, 8 августа 16:00:15 BST 2017 armv7l GNU / Linux

Прошивка:
BT: test_170808
Корзина Wi-Fi: test_170808
WiFi txt: test_170808

Что-нибудь актуальное в dmesg, когда это происходит?

14 августа 2017 г., 13:16, "GIlang Charismadiptya" [email protected]
написал:

Пробовал тестовую прошивку, опубликованную pelwell, проблема все еще сохраняется.
Связь зависает каждые 1-2 часа. Когда соединение разорвалось и я
пробовал пинговать (пинг 8.8.8.8), опять работает ненадолго до 8 числа
пинг. После этого мне нужно перезагрузить Raspberry Pi.

Ядро:
Linux raspberrypi 4.9.41-v7 + # 1023
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1023&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=AKaU_LFRmDMObaVb2VxPhT3pS6_Sd6Qnrtg_9TSH5pc&s=OFVHPpEIYXIdyZoaKEmVcXWxHk2O53Mv7nB_Kp-jNnI&e=
SMP Вт, 8 августа 16:00:15 BST 2017 armv7l GNU / Linux

Прошивка:
BT: test_170808
Корзина Wi-Fi: test_170808
WiFi txt: test_170808

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D322164546&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=AKaU_LFRmDMObaVb2VxPhT3pS6_Sd6Qnrtg_9TSH5pc&s=lhUPrFZ2Xcg2O_gDeznrblSKqMffIk4hXHFaUrCfNIc&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHej12v-2DqQEMPe4n2TBq-5F5VyQgq2Iks5sYCyMgaJpZM4HupC5&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=AKaU_LFRmDMObaVb2VxPhT3pS6_Sd6Qnrtg_9TSH5pc&s=-6r_-x8_9PHhc0q5uJZcGsxdyCROGK7EhGQyp3scT8U&e=
.

Нет, ничего интересного. Может потому, что я не пересобирал модуль с поддержкой отладки. Как это сделать? или скомпилированный модуль предоставите? Благодарю.

Ниже прилагаются логи dmesg:

`pi<strong i="7">@raspberrypi</strong>:~ $ sudo dmesg

[    4.654722] brcmfmac: Firmware version = wl0: Aug  7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[    5.752968] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[    5.753285] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    6.206530] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    6.206577] brcmfmac: power management disabled
[    7.088933] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[    7.340040] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    7.340841] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[    7.431235] Adding 102396k swap on /var/swap.  Priority:-1 extents:4 across:217088k SSFS
[   10.182342] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   10.182357] brcmfmac: power management disabled
[   10.872838] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   10.872903] brcmfmac: power management disabled
[   11.594201] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   14.128592] ip_tables: (C) 2000-2006 Netfilter Core Team
[   14.172268] nf_conntrack version 0.5.0 (15360 buckets, 61440 max)
[   54.604680] random: crng init done

pi<strong i="8">@raspberrypi</strong>:~ $ sudo dmesg -l err
[    4.501055] raspberrypi-touchscreen 3f700000.dsi.0: Unknown Atmel firmware revision: 0xfa
`

Подробную информацию о модуле отладки см. В сообщении Фила выше. Мы особенно
интересуется трассировкой отладки при возникновении ошибки почтового ящика.

14 августа 2017 г., 17:52, "GIlang Charismadiptya" [email protected]
написал:

Нет, ничего интересного. Может быть, потому что я не пересобирал модуль с
поддержка отладки. Как это сделать? или скомпилированный модуль предоставите?
Благодарю.

Прилагается ниже журнал dmesg:

` pi @ raspberrypi : ~ $ sudo dmesg

[4.654722] brcmfmac: версия микропрограммы = wl0: 7 августа 2017 г. 00:46:29 версия
7.45.41.46 (r666254 CY) FWID 01-f8a78378
[5.752968] smsc95xx 1-1.1: 1.0 eth0: оборудование не поддерживает удаленное управление
Проснись
[5.753285] IPv6: ADDRCONF (NETDEV_UP): eth0: ссылка не готова
[6.206530] IPv6: ADDRCONF (NETDEV_UP): wlan0: ссылка не готова
[6.206577] brcmfmac: управление питанием отключено
[7.088933] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: ссылка становится готовой
[7.340040] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: ссылка становится готовой
[7.340841] smsc95xx 1-1.1: 1.0 eth0: соединение вверх, 100 Мбит / с, полнодуплексный режим, lpa
0xCDE1
[7.431235] Добавление 102396 КБ подкачки в / var / swap. Приоритет: -1 степени: 4
через: 217088k SSFS
[10.182342] IPv6: ADDRCONF (NETDEV_UP): wlan0: ссылка не готова
[10.182357] brcmfmac: управление питанием отключено
[10.872838] IPv6: ADDRCONF (NETDEV_UP): wlan0: ссылка не готова
[10.872903] brcmfmac: управление питанием отключено
[11.594201] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: ссылка становится готовой
[14.128592] ip_tables: (C) 2000-2006 Основная группа разработчиков Netfilter
[14.172268] nf_conntrack версии 0.5.0 (15360 сегментов, максимум 61440)
[54.604680] random: crng init done

pi @ raspberrypi : ~ $ sudo dmesg -l err
[4.501055] raspberrypi-touchscreen 3f700000.dsi.0: Неизвестная прошивка Atmel
редакция: 0xfa
`

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322228992 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHXuy3Eo5PqPAP8FfSFiYWMUQL7fAks5sYG1HgaJpZM4HupC5
.

Последнее ядро ​​rpi-update включает BRCMDBG, который должен разрешать параметр командной строки brcmfmac.debug=0x???????? предложенный ранее @pelwell .

Errrr ..... мой Pi3, который был как скала с Wi-Fi, теперь также теряет его, так как я обновился до последней версии raspbian несколько дней назад :-(

Какие симптомы? Не ожидал регресса в прошивке, или
собственно сам драйвер.

24 августа 2017 года в 20:07 Crrispy [email protected] написал:

Errrr ..... мой Pi3, который был как скала с Wi-Fi, теперь также теряет его, поскольку я
обновился до последней версии raspbian несколько дней назад :-(

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-324728431 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHUxvLV3OzKGpcmEMGEoSad_piujBks5sbcoHgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

@Crrispy
Попробуй это:
Я удалил все упоминания об eth0 из своего файла / etc / network / interfaces, заменил allow-hotplug на auto, а затем принудительно отключил беспроводное питание как на wlan0, так и на wlan1.

мой файл / etc / network / interfaces:

auto lo
iface lo inet loopback

wireless-power off
auto wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

wireless-power off
auto wlan1
iface wlan1 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf`

Затем я сбросил arp:

ip -s -s neigh очистить все

Потом перезагрузился:

sudo перезагрузить сейчас

Я почти уверен, что сталкиваюсь с этой ошибкой регулярно. Запуск hostapd, использование внутреннего Wi-Fi Broadcom для размещения точки доступа и маршрутизация клиентов, которые подключаются к нему через USB-ключ Wi-Fi, который служит беспроводным клиентом. Подключено несколько устройств, но как только я вынесу Pi за пределы диапазона подключенных устройств, кажется, что произойдет сбой wlan. Как и в случае с другими, выходит из строя только внутреннее устройство WLAN Broadcom: Ethernet и другие беспроводные сети остаются без изменений. Еще у меня в системном журнале появляется ошибка "почтового ящика":

Aug 27 08:34:38 raspberrypi kernel: [40063.859420] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

(подробности журнала на https://pastebin.com/NPB00ZEq)

Я заметил, что вывод iwconfig больше не показывает значение Tx_Power, когда устройство wlan находится в состоянии сбоя, поэтому я использовал это для создания сценария автоматической перезагрузки в качестве временного решения.

Я только что обновился до последнего rpi-update, установил тестовые драйверы Wi-Fi, упомянутые выше, и добавил флаг отладки в свой cmdline.txt, используя шестнадцатеричное значение для BRCMF_TRACE_VAL: bcrmfmac.debug=0x00000002

Если вы можете регулярно получать ошибку почтового ящика, мы будем благодарны за результаты работы отладочного драйвера. Когда вы получаете сообщение об ошибке почтового ящика, сделайте что-то вроде этого, чтобы получить криминалистику и опубликовать результаты здесь, я могу передать их Cypress, который исследует проблему.

cat /sys/kernel/debug/brcmfmac/mmc1\:0001\:1/forensics

Что ж, то, что было легко воспроизводимой проблемой, я больше не могу дублировать, так как запустил rpi-update. Я мог бы сделать это, вернувшись к новой установке сборки Raspbian с 21 июня 2017 года, если это будет полезно.

@ JamesH65
Удалось зафиксировать запрошенную вами криминалистику (после ошибки почтового ящика), но, чтобы пояснить, это произошло после перехода на версию ядра, включенного в сборку Raspbian от 21 июня. Возможно, проблема уже решена, потому что я еще не продублировал проблему после установки тестовой прошивки, опубликованной @pelwell около двух недель назад, и запуска rpi-update.

Вот ссылка на криминалистику:
https://pastebin.com/VVqVQ8FW

Надеюсь, это поможет ...

Так что со старой прошивкой подозреваю. Мы надеемся провести экспертизу для
новая прошивка с дополнительными сообщениями (очевидно), направленными на отслеживание
вниз вопрос почтового ящика. Это заставляет меня думать, что Сайпресс все еще думает
проблема с почтовым ящиком будет там, даже после других исправлений. В любом случае передаст данные, если это поможет.

Приятно знать, что ошибки воспроизвести гораздо сложнее!

29 августа 2017 года в 15:51 randyoo [email protected] написал:

@ JamesH65
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jamesh65&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=owdl09j03eJ21jjmS-pXzxuHC0FQIGtHaCHVAUCN42I&s=3RXFuPnppW2lu6j302oN0bZFkwDQhfTLIZ4fb-qzMds&e=
Удалось получить результаты судебно-медицинской экспертизы, которые вы запрашивали, но, чтобы внести ясность,
это после перехода на ядро, включенное в Raspbian от 21 июня.
построить. Возможно, это уже было решено, потому что я не могу
продублируйте проблему после установки тестовой прошивки, опубликованной @pelwell
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pelwell&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=owdl09j03eJ21jjmS-pXzxuHC0FQIGtHaCHVAUCN42I&s=OEna5EdFdm9tLu51AyYXqp_FN2kYCjSiEmIG7OTV8yI&e=
около двух недель назад.

Вот ссылка на криминалистику:
https://pastebin.com/VVqVQ8FW
https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_VVqVQ8FW&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=owdl09j03eJ21jjmS-pXzxuHC0FQIGtHaCHVAUCN42I&s=05AD-plLg4D-_tU_7DpsL3d-tOtWDjbQs62eqP9W9gg&e=

Надеюсь, это поможет ...

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D325689126&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=owdl09j03eJ21jjmS-pXzxuHC0FQIGtHaCHVAUCN42I&s=0aM55qLQhMgI2neXi8qVWOJ4FNsV4VlNCOyxI3AW_2c&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHZObdWpcetcTECfa0dqKXJPMWiS1ks5sdCVxgaJpZM4HupC5&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=owdl09j03eJ21jjmS-pXzxuHC0FQIGtHaCHVAUCN42I&s=nNj0tSkc_hIjXqC-9GAp1TcD06OXO70Ivwzo_EdWB1E&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Это заставляет меня думать, что Сайпресс все еще думает
проблема с почтовым ящиком будет там, даже после других исправлений.

Да, я тоже так понимаю.

@randyoo Спасибо за положительный отзыв.

@ JamesH65
Хорошо, это случилось снова, на этот раз с последней прошивкой rpi-update и с использованием тестовой прошивки, опубликованной @pelwell . К сожалению, результаты экспертизы выглядят идентично тому, что было в предыдущем посте. (Не уверен, почему я не получаю другую / более подробную информацию в дампе криминалистической экспертизы, поскольку в моем cmdline.txt включена отладка, как в моем предыдущем сообщении)

Я пошел дальше и сбросил содержимое других файлов / sys / kernel / debug. Вот он: https://pastebin.com/pdFUPBxN

При последнем зависании wlan трассировка журнала ядра выглядит более подробной. См. Ссылку:
https://pastebin.com/KTxbgpYV

Надеюсь, это поможет.

Были ли подробности в криминалистике прошивки? Я думаю, что это
bit Cypress действительно интересует, когда возникает ошибка почтового ящика.

31 августа 2017 года в 21:56 randyoo [email protected] написал:

При последнем зависании wlan трассировка журнала ядра выглядит более подробной.
См. Ссылку:
https://pastebin.com/KTxbgpYV
https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_KTxbgpYV&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=Q-jbAaSSLWAuC7E9Mh2NDxUucRiJHVodu4QDmS5Tcoo&s=9SV25GVatAz8aDQRiSTEUEGmojqbPPSY5MnyCHwA3X0&e=

Надеюсь, это поможет.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D326418448&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=Q-jbAaSSLWAuC7E9Mh2NDxUucRiJHVodu4QDmS5Tcoo&s=IZRQxkqqxvIzHVKqJB-6M_URsEqng8tIkcmxDIzkkiw&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHdZjkkbqkyNpJMIj22zqwwR9Evq5ks5sdx4OgaJpZM4HupC5&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=Q-jbAaSSLWAuC7E9Mh2NDxUucRiJHVodu4QDmS5Tcoo&s=JGjVJt7B0gGL7s7rhdudrn9OPNciRuJmCSYSUHuezJ8&e=
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Правильно, извините. Удалось получить данные судебно-медицинской экспертизы, и да, похоже, там гораздо больше деталей:
https://pastebin.com/qypfAfAp

Так как иногда помогают новые случаи, я также время от времени получаю это:

pi @ jempi : ~ $ grep "brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012" / var / log / syslog
14 августа 22:16:23 jempi kernel: [501.247242] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
17 августа 20:26:20 Ядро jempi: [509.684277] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
24 августа 23:57:37 jempi kernel: [573.652189] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
29 августа 23:50:16 Ядро jempi: [5052.517999] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
30 августа 00:02:18 Ядро jempi: [170.978988] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
30 августа 23:58:03 Ядро jempi: [8254.502431] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
2 сентября 00:33:28 jempi kernel: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012

Я использую внутренний Wi-Fi (wlan0) в качестве точки доступа и подключил ключ (wlan1) для подключения к моему маршрутизатору:
pi @ jempi : ~ $ ifconfig wlan0
wlan0 Link encap: Ethernet HWaddr b8: 27: eb: cf: db: b8
inet адрес: 10.3.141.1 Bcast: 10.3.141.255 Маска: 255.255.255.0
inet6 адрес: fe80 :: 6b56: 4657: 75cd: a501 / 64 Объем: Ссылка
ВВЕРХ ТРАНСЛЯЦИИ МУЛЬТИКАЛТА MTU: 1500 Метрика: 1
Пакеты RX ошибок: 0 отброшено: 0 переполнений: 0 кадров: 0
Пакеты TX ошибок: 0 сброшено: 0 переполнений: 0 несущая: 0
столкновения: 0 t xqueuelen: 1000
Байты приема передачи: 5492 (5,3 КБ)

pi @ jempi : ~ $ ifconfig wlan1
wlan1 Link encap: Ethernet HWaddr 00: 60: b3: db: 8a: 4a
инет адр: 192.168.1.74 Bcast: 192.168.1.255 Маска: 255.255.255.0
inet6 addr: fe80 :: 260: b3ff: fedb: 8a4a / 64 Объем: Ссылка
ВВЕРХ ТРАНСЛЯЦИИ МУЛЬТИКАЛТА MTU: 1500 Метрическая система: 1
Пакеты RX ошибок: 0 отброшено: 2 переполнения: 0 кадр: 0
Пакеты TX ошибок: 0 сброшено: 0 переполнений: 0 несущая: 0
столкновения: 0 t xqueuelen: 1000
Байт RX 250,6 КиБ) Байт TX

У меня было ядро ​​4.9.35-v7 +, вчера я обновил его до 4.9.46-v7 + (с rpi-update), но это не помогает. Вход из системного журнала при сбое:

2 сентября 00:33:28 jempi kernel: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
2 сентября, 00:34:00 Ядро jempi: [6011.624839] brcmfmac: brcmf_netdev_wait_pend8021x: Истекло время ожидания ожидающих пакетов 802.1x
2 сен 00:34:02 Ядро jempi: [6014.184823] brcmfmac: send_key_to_dongle: ошибка wsec_key (-110)
2 сентября 00:34:05 Ядро jempi: [6016.744833] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON не удалось -110
2 сентября 00:34:06 Ядро jempi: [6017.704831] brcmfmac: brcmf_netdev_wait_pend8021x: Истекло время ожидания ожидающих пакетов 802.1x
2 сентября 00:34:08 Ядро jempi: [6020.264850] brcmfmac: send_key_to_dongle: ошибка wsec_key (-110)
2 сентября 00:34:11 Ядро jempi: [6022.824903] brcmfmac: brcmf_cfg80211_change_station: Ошибка авторизации SCB (де-), -110

Перезапустить интерфейс wlan0 с помощью sudo ifconfig wlan0 down, а затем up не помогло.

@bulrog Пожалуйста, предоставьте также результаты судебно-медицинской экспертизы, как объяснил Джеймс выше.
Какой драйвер использует wlan1? Эта проблема по-прежнему возникает с отключенным ключом?

Еще несколько криминалистических исследований:
https://pastebin.com/vqh3UcF3

В случае, если это помогает Cypress искать в нужной области: я сталкивался с этой проблемой много-много раз, и, похоже, она проявляется всякий раз, когда устройство пытается подключиться. Это происходило много раз после попадания в зону действия точки доступа или когда спящее устройство просыпалось.

Я хранил эту конфигурацию достаточно долго, чтобы собирать данные судебной экспертизы, и если есть какие-то подробности, которые я могу предоставить, я был бы счастлив сделать это, но сбои wlan теперь происходят так часто, что это делает мое устройство бесполезным. Я собираюсь использовать другой USB-ключ Wi-Fi для замены внутреннего радио, чтобы добиться надежности.

Я передал вашу последнюю экспертизу Сайпресс - спасибо, что нашли время.

Просто хотел вмешаться. У меня точно такая же проблема с тремя RPI3, на которых установлена ​​последняя прошивка. Я использую Octopi на всех трех и получаю к ним доступ через Printoid.

bcrmfmac.debug должно быть brcmfmac.debug (спасибо, что заметили @MilhouseVH)
Я отредактирую предыдущие сообщения.

bcrmfmac.debug должен быть brcmfmac.debug (спасибо, что заметили @MilhouseVH)
Я отредактирую предыдущие сообщения.

Исходя из этого, я предположил, что проведенная мною криминалистика была неполной.

Я повторил криминалистический захват, его можно просмотреть по следующему URL-адресу:
https://pastebin.com/ha5rd7SW

Вдобавок мой файл /var/log/kern.log имеет размер около 200 МБ, большая часть которого состоит из очень похожих записей. Я обнаружил ошибку почтового ящика в 00:53:19 и отсек за пару секунд до и после ошибки. Надеюсь, это поможет, посмотрите здесь:
https://pastebin.com/JcE0zstS

поэтому я думаю, что нашел ту же проблему, см. https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=192735

я могу воспроизвести это за 5 минут. Вам нужен большой объем трафика через Wi-Fi (веб-интерфейс камеры) и очень низкий уровень сигнала Wi-Fi. У меня есть пи ноль, и его достаточно, чтобы положить палец / руки на бортовую антенну, чтобы получить сигнал почти до нуля (мой маршрутизатор показывает сигнал 15-20%). Примерно через 1 минуту в этом состоянии происходит сбой Wi-Fi

@lategoodbye через неделю я включил свой пи и никаких проблем, пока ничто не использовало точку доступа, и через некоторое время возникла проблема при подключении моего телефона к wlan0. Я запускаю команду, и результат можно найти здесь: https://pastebin.com/77tGfRcU

для wlan1 я использовал довольно старый донгл. Не могу вспомнить, какой драйвер мне пришлось установить, чтобы он заработал, но вот что дает lsusb для HW, которое я использую:

Шина 001 Устройство 005: ID 0 cde: 0008 Беспроводной адаптер Z-Com XG-703A 802.11g [Intersil ISL3887]

Не знаю, помогает ли это, но вот мой опыт:

Я купил Pi3 и протестировал его в течение нескольких дней с внутренним Wi-Fi (недалеко от точки доступа), и, похоже, он работал очень хорошо (я не ожидал высоких битрейтов, это просто было полезно для удаленной оболочки через ssh ).

После помещения его в алюминиевый корпус он все еще казался нормальным, но затем Wi-Fi стал беспорядочно приходить в негодность. До минут отсутствия пинга. Были случаи, когда он работал очень хорошо в течение нескольких секунд, но он снова переключался на «одно нажатие клавиши в секунду» или вообще переставал работать.

Кажется, что нет «медленного, но полезного» соединения, возможно только «очень хорошее» или «непригодное». Это могло быть связано с ошибкой в ​​прошивке. Я понятия не имею, и, честно говоря, я потерял терпение и вместо этого использовал очень крошечный USB-ключ, который работает на 100% стабильно.

Кто-нибудь нашел обходной путь для обнаружения проблемы (в режиме AP) и программного сброса устройства wlan?

Не то чтобы я видел, перезапуск интерфейса не помог. Для меня сдерживание заключалось в том, чтобы купить внешнее устройство Wi-Fi USB, и оно работает как шарм, но это жалко, так как теперь я отключил Wi-Fi пи (вздох!)

Вы имеете в виду проблему с почтовым ящиком? Это все еще расследуется в Cypress.

21 сентября 2017 г. в 08:38 "morel jerome" [email protected] написал:

Не то чтобы я видел, перезапуск интерфейса не помог. Для меня сдерживание
было купить внешнее устройство wifi usb, и оно работает как шарм, но это
Жалко как сейчас отключил вайфай пи (вздох!)

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D331077428&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=yJzPdDsdAiNsKtR1oEpYjjGEpQ0eJYC9ewXwEfkuqPc&s=6bBJAhWAGVPWclnkLVfXnnxkjzhpirqKWLaw_h7N5vE&e= ,
или отключить поток
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHSRUXSjMwOd-5Fd-5F2VgM3QanccSv4Kks5skhJ-2DgaJpZM4HupC5&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=yJzPdDsdAiNsKtR1oEpYjjGEpQ0eJYC9ewXwEfkuqPc&s=YJocP4q5OKwHSRNQcwjY5pPFGv4VuM-5oNsMo0MDIZU&e=
.

Да, проблема с почтовым ящиком. Я надеюсь, что это будет исправлено, но в качестве сдерживания мне пришлось переключиться на внешнее устройство.

ОК. Мы находимся во власти Cypress в этом вопросе - это проблема прошивки, и они единственные, у кого есть доступ. Я буду напоминать им ... нам может понадобиться еще несколько криминалистических исследований, но если это так, мы опубликуем здесь сообщение.

мой wlan отключается и снова подключается через несколько секунд бездействия (я предполагаю, что это экономия энергии, хотя я отключил его с помощью iw или, возможно, помехи). Не уверен, что это та же проблема, о которой говорилось здесь (поскольку она немедленно подключается).

Если я подключаюсь к ssh -o ServerAliveInterval 5 ... он больше не отключается.

$ uname -a
Linux pi3 4.4.50-hypriotos-v7+ #1 SMP PREEMPT Sun Mar 19 14:11:54 UTC 2017 armv7l GNU/Linux

@asssaf ,
Не проблема, если бы он повторно подключился, это, как правило, было бы только проблемой задержки, но при работе без подключения к сети Wi-Fi (одна из основных потенциальных функций PiZero-W), когда Wi-Fi отключается и не подключается автоматически, происходит сбой системы. для всех практических целей.

Даже если у меня есть HDMI, мышь и клавиатура при сильной сетевой нагрузке, как в случае с Motioneye, иногда единственный способ восстановить систему - это выключить и снова включить питание.

Я повторил установку и настройку Motioneye на Pi2 с WiPi USB WiFi ключом, и до сих пор он отлично работал с нагрузками, которые надежно убивали PiZero-W за несколько часов. Мне кажется, это подтверждает проблему с чипом / драйвером WiFi, а не с Raspbian-stretch.

@ PeterTheMaster1 @randyoo @joshfria

Хорошо, сообщение для всех, кто регулярно сталкивается с проблемой почтового ящика, и сможет что-то проверить для меня.

У нас есть диагностическая прошивка от Cypress, которая может помочь определить проблему. Если кто-то, у кого возникла проблема с почтовым ящиком, захочет запустить эту прошивку, и когда возникнет проблема с почтовым ящиком, сбросьте криминалистику и опубликуйте результаты здесь, это будет большим подспорьем. Обратите внимание, эту прошивку не следует использовать ни для чего другого, кроме этого теста, так как она будет «неоптимальной»! Пожалуйста, прокомментируйте здесь, если вы можете провести тест, и я свяжусь с прошивкой и инструкциями.

@iurly : Я написал скрипт, который обнаруживал проблему, а затем перезагружался, так как включение и выключение интерфейса не помогло ... Но потом он перезагружался так часто, что я мог получить полезное устройство, только взяв его вне режима AP (и назначение функций AP моему USB-ключу)

@ JamesH65 : Я был бы рад помочь, как и раньше. Это новая версия диагностической прошивки? Я опубликовал криминалистический снимок 3 недели назад (на странице с этой проблемой) с использованием диагностической / отладочной прошивки, размещенной ранее на этой странице.

Да, новая прошивка от Cypress от понедельника 25 сентября.
диагностика в нем. Предыдущая предоставленная вами криминалистическая экспертиза сузила круг
проблема, им нужно немного больше деталей. Я управляю машиной
в течение 24 часов до сих пор без ошибок почтового ящика, поэтому в настоящее время невозможно воспроизвести его
себя.

Можете ли вы написать мне на Джеймс. [email protected] и я могу отправить вам прошивку. Я не хочу публиковать его более глобально, потому что это действительно только для целей тестирования.

27 сентября 2017 года в 14:48 randyoo [email protected] написал:

@iurly https://github.com/iurly : я написал скрипт, который обнаруживает
проблема, а затем перезагрузите, так как выводит интерфейс вниз и вверх
не помогло ... Но тогда так часто перезагружалась, что мне оставалось только
полезное устройство, выведя его из режима AP (и назначив функции AP моему
USB-ключ)

@ JamesH65 https://github.com/jamesh65 : Я был бы рад помочь, поскольку
перед. Это новая версия диагностической прошивки? Я опубликовал
криминалистический снимок 3 недели назад (на странице этой проблемы) с помощью
диагностическая / отладочная прошивка, размещенная ранее на этой странице.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332526471 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHW_vEVuxFD-9RuxE003QZc_2NoFaks5smlIjgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

@ JamesH65 Не могли бы вы дать ссылку на новую прошивку, я могу установить ее и снова попытаться провести криминалистическую экспертизу, как вы просили.

К сожалению, ссылка здесь означает, что она общедоступна, и
так как это очень тестовая прошивка, я бы предпочел, чтобы она не сбегала в
дикая. Отсюда просьба сделать по электронной почте. Если это проблема, я загружу
это где-нибудь и можно разместить ссылку.

27 сентября 2017 года в 15:56 randyoo [email protected] написал:

@ JamesH65 https://github.com/jamesh65 Не могли бы вы
предоставьте ссылку на новую прошивку, могу установить и попробовать захватить
Опять криминалистика, как вы и просили.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332548884 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHbVhHD2rk_hp3kG51WBY0R0IQzL3ks5smmIbgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

@ JamesH65 Я знаю, что у меня регулярно

Я использую прошивку, поставляемую с ядром 4.4.50 (и я действительно не могу обновиться до последней версии 4.9 из-за регресса, см. # 2197), будет ли эта версия отображать это сообщение или оно было добавлено на более позднем этапе?

Спасибо!

@iurly вы

Что меня действительно беспокоит, так это отсутствие обходного пути, кроме перезагрузки всей системы.
Я имею в виду, что нет даже способа сбросить периферию и перезапустить hostapd?!?

@iurly вы

К вашему сведению, у меня тоже проблемы в режиме клиент / станция. Запуск мастера LEDE, ядро ​​4.9 и прошивка 7.45.41.46.

@ JamesH65
Понять желание не допустить публикации тестовой прошивки. Электронная почта подойдет, но я тоже не хочу публиковать здесь свой адрес, и я не вижу способа отправлять сообщения на github.

Используйте мой пи-адрес выше, чтобы написать мне по электронной почте, и я пришлю вам прошивку.

Re. Режим AP
Начиная с 4.4 было внесено несколько исправлений, поэтому стоит попробовать последнюю версию.
чтобы узнать, возникает ли эта проблема.

Ах, когда вы редактируете комментарий, обновления по электронной почте не отправляются, и я отредактировал в своем письме Pi запись выше, поэтому вы, возможно, не были обновлены. Используйте веб-сайт github, чтобы узнать, куда вам нужно написать мне письмо.

@ JamesH65 Отправил вам электронное письмо. Рад слышать, что предыдущая криминалистическая экспертиза помогла сузить круг вопросов, по крайней мере ... Похоже, многие люди будут довольны, когда эта проблема будет решена.

@ JamesH65
Вот криминалистический снимок прошивки, которую вы отправили по электронной почте: https://pastebin.com/zdB36ttj
Надеюсь, это поможет.

Потрясающе, перейдем к Cypress. Спасибо за это.

У меня есть пи в установке прямо сейчас, и, кажется, я могу воспроизвести это по своему желанию. Дайте мне знать, если вам будет полезно собрать дополнительную информацию. Ошибка почтового ящика - это все, что я вижу в журналах.

После того, как я заменил microSD в моем Zero W, он был подключен в течение 7 дней без проблем. Я не думаю, что он выжил так долго. Звучит странно, что SD-карта может влиять на WiFi, но поскольку они обе подключены к шине SDIO, возможно, что одна влияет на другую.

Раньше я использовал (вероятно, дешевую) карту Transcend class 4 на 8 ГБ, которая шла с моей платой UDOO Quad. Сейчас это Samsung EVO 32GB. Люди, сталкивающиеся с проблемами, могут захотеть попробовать, если поможет использование другой карты.

@stintel Интересно, но, возможно, это была какая-то проблема с установкой программного обеспечения на другой microSD или даже поврежденный microSD.

Может быть, это связано с властью? Может быть, дешевая карта на мгновение потребила слишком много энергии от автобуса?

Я загрузил прошивку Пелвелла и увидел ОГРОМНОЕ улучшение. Раньше SSH для моего Pi 0W был похож на набор номера в терминал с модемом на 2400 бод и дрянной телефонной линией. Теперь я могу запустить удаленный X, и он отлично работает.

Спасибо!

У меня такая же проблема. Перенося огромное количество имен файлов (синхронизация по ftp) с raspberryPi3-internal-wifi на Galaxy S5, Wi-Fi перестает работать. но иногда работает ...

У меня была такая же проблема с сообщением почтового ящика с моей точкой доступа RPi3 WiFi, но я нашел решение на этом форуме , и оно сработало для меня. Решением было изменить следующие параметры в /etc/hostapd/hostapd.conf

wpa = 3 изменено на wpa = 2auth_algs = 3 изменен на auth_algs = 1

Я тестировал его в течение 1 недели, и он больше не показывает проблем с почтовым ящиком.

Я не уверен, что это сработает для всех вас, но вы можете попробовать и опубликовать здесь, если это сработает.

Это рабочий hostapd, conf:

interface=wlan0
driver=nl80211
country_code=CO
ctrl_interface=wlan0
ctrl_interface_group=0
ssid=Mailbox Issue Test
hw_mode=g
channel=5
wpa=2
wpa_passphrase=mailbox
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
beacon_int=100
auth_algs=1
macaddr_acl=0
wmm_enabled=1
eap_reauth_period=360000000

Есть новости по этой проблеме? Или есть какое-нибудь известное обходное решение?

Все еще испытываю это на недавно купленном Pi Zero W с последними stretch-lite и rpi-update на вчерашний день.

Используя RPi для потоковой передачи видео с камеры через RTSP (udp), я вижу, что соединение резко ухудшается непосредственно перед тем, как соединение WiFi прерывается, после этого соединение WiFi никогда не восстанавливается, и мне нужно выключить и снова включить Pi0W.

dmesg > dmesg.log показывает только:

brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Если я поднесу Pi0W ближе к точке доступа, проблема не возникнет.

Я не использую Pi0W как точку доступа, это просто клиент. Я пробовал разные источники питания.

В настоящее время мы ждем Cypress, поставщиков беспроводного чипа,
чтобы продвинуть проблему. Я пингую их еще раз.

25 октября 2017 г., в 14:02, Маттиас Урхан [email protected]
написал:

Есть новости по этой проблеме? Или есть какое-нибудь известное обходное решение?

Все еще испытываю это на недавно купленном Pi Zero W с последним
stretch-lite и rpi-update по состоянию на вчерашний день.

Используя RPi для потоковой передачи видео с камеры через RTSP (udp), я вижу
соединение резко ухудшается как раз перед отключением Wi-Fi,
после этого соединение Wi-Fi никогда не восстанавливается, и мне нужно выключить и снова включить
Pi0W.

Dmesg> dmesg.log показывает только:

brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012

Если я поднесу Pi0W ближе к точке доступа, проблема не возникнет.

Я не использую Pi0W как точку доступа, это просто клиент. я пытался
разные источники питания.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-339322153 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHRlPhJBGXc3JFWbpw_Tf4_EKmgAeks5svzFQgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Что ж ... Я обновился до последней версии ядра / прошивки (apt-get upgrade, затем rpi-update), и теперь даже мой Pi3 с надежным Wi-Fi также теряет его через несколько часов !! Я знаю, что если он не сломан, не чините его ... не следовало обновлять, но поскольку я время от времени провожу тесты на своем втором Pi3 с той же SD-картой ...

FWIW, я тоже могу воспроизвести эту проблему по желанию. Я создал сообщение на форуме Raspberry Pi, в котором объясняется проблема:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=196018&p=1226143#p1226143

ПРИМЕЧАНИЕ. Я не использую Pi в качестве точки доступа. Я могу помочь с экспертизой или тестированием экспериментальной прошивки и т. Д., Если это поможет.

Здесь та же проблема. Я установил ownCloud и могу без проблем передавать файлы со своего ноутбука.
Но как только я передаю файлы своим Samsung Galaxy S7, Wi-Fi ломается и
raspberrypi kernel: [ 962.273390] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012 :
появляется.

Мой роутер FRITZ! Box 7490.

Спасибо @srinathava за сообщение, в котором хорошо описана моя проблема!

Люди, которые тестировали тестовую прошивку, могут попробовать следующее - Cypress требует дополнительной отладочной информации.

1. при выполнении insmod добавьте «debug = 0x100000»
2. как только проблема возникнет, сохраните вывод "dmesg"

Благодарю.

Еще одна просьба о помощи по этому поводу.

Люди, которые тестировали тестовую прошивку (см. Выше), могут попробовать следующее - Cypress требует больше отладочной информации.

при выполнении insmod добавьте «debug = 0x100000»
как только проблема возникнет, сохраните вывод "dmesg" - это тот бит, который нас интересует.

Благодарю.

@ JamesH65 Просто чтобы вы знали, сейчас я пытаюсь собрать информацию, но проблема еще не проявилась. Я внес лишь несколько небольших изменений в файл /etc/hostapd/hostapd.conf, но эти изменения могли случайно решить эту проблему. Если проблема не возникнет в течение нескольких дней, я отменю эти изменения, чтобы попытаться воспроизвести проблему и собрать данные отладки.

Спасибо за помощь в этом.

Было бы интересно увидеть те изменения, которые вы внесли в hostapd, если это действительно решит проблему.

После 4 дней стабильности я вернул свои изменения в файл /etc/hostapd/hostapd.conf, и всего через несколько часов проблема повторилась. Вот результат работы dmesg:

[86340.811305] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
[86374.278317] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86376.838299] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86376.838314] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[86379.398310] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86381.958740] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86381.958754] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[86384.518337] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86384.518353] brcmfmac: brcmf_cfg80211_get_tx_power: error (-110)
[86387.078328] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86389.638353] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86389.638366] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110

Я использую программный пакет под названием RaspAP , и я почти уверен, что он настроил файл hostapd.conf от моего имени, хотя я не уверен на 100%.

В любом случае, закомментировав эту строку в /etc/hostapd.conf: и заменив его на это: У меня была стабильная работа в течение 4 дней подряд, тогда как раньше он падал в течение нескольких часов, а иногда и минут!

Надеюсь, все это поможет.

Приносим извинения, если я отправляю сообщения в неправильном месте, я испытываю странное поведение с внутренним (Broadcom) wlan RPi3 при отправке пакетов UDP Unicast под raspbian.
Я отправляю небольшой пакет данных 2kb один раз в секунду, на стороне получателя он блокируется каждые 120 секунд примерно на 3-4 секунды. Этот тест работает как часы, и я могу воспроизвести его с помощью iperf, выполнив следующие действия.

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

ПК с Ubuntu подключен как WiFi-клиент к RPi3 (IP 192.168.1.22, как указано выше)

iperf -u -s -i 1

Гарантированная блокировка каждые 120 секунд. Интересно, что при использовании TCP этого не происходит.
Наконец, скачав и посмотрев код драйвера (и ничего не поняв) заметил подозрительное упоминание о

определить BRCMF_SCAN_PASSIVE_TIME 120

Что затем используется в коде драйвера

может ли это быть связано, я нахожусь в конце концов, пытаясь решить?
Спасибо

Я поместил следующее в /etc/rc.local, и мой, похоже, работает намного лучше:

Iwconfig wlan0 выключение питания

PI ноль w

Шон

19 декабря 2017 года в 3:42 утра LeeMooreImperas [email protected] написал:

Приносим извинения, если я отправляю сообщения в неправильном месте, я испытываю странное поведение с внутренним (Broadcom) wlan RPi3 при отправке пакетов UDP Unicast под raspbian.
Я отправляю небольшой пакет данных 2kb один раз в секунду, на стороне получателя он блокируется каждые 120 секунд примерно на 3-4 секунды. Этот тест работает как часы, и я могу воспроизвести его с помощью iperf, выполнив следующие действия.

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

ПК с Ubuntu подключен как WiFi-клиент к RPi3 (IP 192.168.1.22, как указано выше)

iperf -u -s -i 1

Гарантированная блокировка каждые 120 секунд. Интересно, что при использовании TCP этого не происходит.
Наконец, скачав и посмотрев код драйвера (и ничего не поняв) заметил подозрительное упоминание о

определить BRCMF_SCAN_PASSIVE_TIME 120

Что затем используется в коде драйвера

может ли это быть связано, я нахожусь в конце концов, пытаясь решить?
Спасибо

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

Привет Шон
Спасибо за внимание, к сожалению, устройство Broadcom не принимает это, я получаю

Error for wireless request "Set Power Management" (8B2C) 
    Set failed on device wlan0; Invalid argument

Однако я ДЕЙСТВИТЕЛЬНО использую следующую команду в своей настройке для достижения той же цели.
$ iw dev wlan0 set power_save off
это принято, и если я запрошу настройки
$ iwconfig wlan0
Понимаю
Power Management:off

Так что почти наверняка энергосбережение отключено, но не решает эту проблему.
Спасибо

@LeeMooreImperas Я предлагаю открыть для этого отдельный выпуск и указать хотя бы версию ядра и версию прошивки Wi-Fi.

Я давным-давно прокомментировал эту ветку, но потом мне пришлось перестать смотреть на нее, потому что я больше не мог ее воспроизвести. Что ж, у меня есть новые данные, и это мне очень интересно.

У меня есть два Raspberry Pi; один B + V1.2 и один оригинальный Raspberry PI (C) 2011.

Если я запустил «4.1.19+ # 858 Tue Mar 15 15:52:03 GMT 2016» на RaspPi B +, чип Edimax WiFi покажет проблему, которую видели другие.

Если я запускаю «4.9.27+ # 1 Thu May 11 17:40:53 UTC 2017» на том же RaspPi B +, тот же чип Edimax WiFi не покажет проблему.

Теперь мне интересно, не связана ли это скорее с несовместимостью с оборудованием, и мне также напоминают, что с гораздо более старыми платами RaspPi для USB WiFi требовался специальный кабель для увеличения мощности +5 В, потому что питание, поступающее с платы, не было т достаточно, чтобы проехать на нем. Я собираюсь переключить SD-карты обратно, чтобы они показывали проблему, а затем посмотрю, поможет ли этот тип кабеля.

Хорошо, я думаю, что я ошибся.

При запуске 4.9.27+ на более ранней версии RaspPi возникнет проблема. Проверяю сейчас.

Хорошо, это окончательно и очень интересно.

Используя оригинальную плату Raspberry Pi (около 2011 г.) и работающую под управлением Linux 4.9.27+ (из «uname -a»), я могу воспроизвести проблему, когда чип Edimax USB WiFi теряет соединение WiFi и, следовательно, IP-адрес, каждый раз. , в течение нескольких минут.

Используя ту же оригинальную плату Raspberry Pi и ту же версию Linux, но ЕДИНСТВЕННОЕ изменение - простое использование USB-кабеля, которое позволяет мне увеличить + 5V к USB WiFi из вторичного источника, система стабильна.

Итак, определенно существует проблема с USB-картой Edimax, которая не получает достаточно энергии в этой настройке. Это, очевидно, не помогает тем, кто использует Raspberry Pi со встроенным Wi-Fi, но в этих случаях мне интересно, может быть, возникает аналогичная проблема и, возможно, переход на USB-адаптер, который производит больше усилителей, может показать разница?

Возможно, что адаптер питания от сети к USB, который питает Pi, в некоторых случаях может не давать чистых 5 В.
Поскольку переменный ток необходимо регулировать, а затем сглаживать, прежде чем он станет 5 В, но вы все равно получите небольшую пульсацию на выходе постоянного тока.
5 В от ноутбука или ПК, скорее, без пульсаций, чем дешевое зарядное устройство от сети к USB.

Было бы интересно поставить осциллограф на блок питания к микросхеме Wi-Fi в разных условиях, чтобы посмотреть, на что похожа пульсация при отказе / исправности

Пожалуйста, оставьте эту проблему для проблем с беспроводным чипом ONBOARD Brcm на Pi3 - если у вас есть проблемы с другими устройствами, обратитесь за советом на форум. Это просто для того, чтобы информация, которую мы должны передать Cypress, не запуталась.

@ JamesH65
@lategoodbye

Привет, Джеймс, Стефан,
Итак, здесь противоречивые сообщения, проблема, которую я зарегистрировал, была напрямую связана с RPi3 BRCM WiFi.
Так должно ли это идти в другом потоке (как предлагает lategoodbye)?
Я бы подумал, что эта ветка конкретно посвящена моей проблеме?

Я рад переместить вопрос

Спасибо

@LeeMooreImperas Хотя ваша проблема связью , у вас пауза каждые 2 минуты, эта проблема описывает полный сбой беспроводной блокировки, который происходит через случайные промежутки времени, поэтому кажется, что это не связано. Так что, возможно, стоит создать еще одну проблему. К сожалению, в предыдущем сообщении я был немного расплывчатым.

Добавление еще одного «я тоже» по этому поводу.
Оборудование: Raspberyy Pi 3, модель B.
Ядро: Linux raspberrypi 4.9.70-v7 +
ОС: Raspbian GNU / Linux 9 (stretch)
Загруженный образ: 2017-11-29-raspbian-stretch.img
Образ MD5:
SDCard: не знаю производителя, она идет в комплекте
Файл интерфейсов :
hostapd.conf: hostapd.txt
вывод dmesg (при работе): dmesg_20171230.txt

Устройство настроено как точка доступа для моей беспроводной сети. Мой основной маршрутизатор - это Linksys EA6400 с прошивкой версии 1.1.40 (сборка 184085). И Linksys, и Pi предлагают одинаковый SSID на разных каналах. Pi подключен к маршрутизатору через проводное соединение с неуправляемым коммутатором между ними.
Загрузка ОС на устройстве достаточно свежая. У меня было изображение RetroPie в системе, и я столкнулся с теми же проблемами. Я перезагрузился в Raspbian, чтобы посмотреть, работает ли он лучше.
Я наблюдаю спорадические обрывы моста. Основным признаком является то, что беспроводная сеть, предоставляемая Pi, кажется изолированной от проводной сети. Проводной интерфейс продолжает нормально работать, и я могу подключиться к Pi через SSH. Если я запускаю tcpdump на беспроводном интерфейсе (wlan0), находясь в этом состоянии, я все равно могу видеть трафик к подключенным устройствам и от них.
Повторное включение беспроводного соединения (если не работает; если работает), похоже, не решает проблему. Я еще не пробовал зацикливать интерфейс моста (br0). Обычно я перезагружаю устройство, что решает проблему.
Я не уверен, что это связано; однако проблема, похоже, возникает, когда я пытаюсь управлять своим ChromeCast 2 после того, как он некоторое время работал. Например, если я проигрываю шоу через Netflix на ChromeCast, а затем пытаюсь приостановить шоу, кажется, что в это время мост отключается. Я еще не смог поймать это через tcpdump; но это следующий шаг для меня.
Я подумал, что это может быть проблема тепла; однако у меня был /opt/vc/bin/vcgencmd measure_temp работающий в 30-секундном цикле во время одного из выпадений, и температура моего процессора была в диапазоне 50C. Не знаю, как получить показания температуры на микросхеме LAN, так как здесь может возникнуть проблема с нагревом.

Я буду рад записывать журналы / pcaps по мере необходимости, чтобы помочь в дальнейшем устранении проблемы. Тем не менее, пожалуйста, будьте ясны в инструкциях, поскольку у меня довольно много пробелов в моих знаниях о Linux.

РЕДАКТИРОВАТЬ: только что выпал и сделал sudo ifdown br0 && sudo ifup br0 и, похоже, он снова начал работать. Я буду тестировать снова при следующем выпадении.

EDIT2: вот дамп dmesg с ошибкой соединения. На этот раз sudo ifdown br0 && sudo ifup br0 , похоже, не восстановил соединение.
dmesg_20171220_failed.txt
Особо следует отметить ошибку:
brcmfmac: brcmf_cfg80211_stop_ap: не удалось установить режим INFRA -7

EDIT3: пробежался по этой теме по аналогичной проблеме, которая ссылалась на эту тему. Выполните запрошенное изменение модуля brcmfmac, чтобы включить отладку. Имел триггер отказа и захватил вывод dmesg:
dmesg_debug_failed.txt
Также я заметил упоминание о телефоне Samsung в другой ветке. Мы заметили, что проблемы с мостом с моим Pi, похоже, вращаются вокруг моего Samsung Galaxy S7. Устройства Apple моей жены (iPhone и iPad), похоже, не вызывают проблемы.

EDIT4: снова запустить sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000 за которым следует dmesg. Результат ниже:
dmesg_debug_failed_reset_driver.txt

Хм, это не ожидаемая ошибка почтового ящика. В новом году передам разработчикам Cypress.

Не уверен, что это та же проблема, но мой симптом - прерывистая беспроводная связь на борту RPi3; 10 секунд хороших запросов, затем 20-30 секунд отсутствия запросов и повторение бесконечно. Если эхо-запросы отсутствуют, удаленный хост получает эхо-запросы ICMP и отправляет эхо-ответы ICMP. Точка доступа возвращает узел ICMP, который недоступен удаленному узлу.

Обязательным условием является подключение к сети Ethernet и беспроводной связи. Вероятность того, что это произойдет, значительно улучшится из-за ненужного перезапуска dhcpcd .

Обходной путь - установить сетевой интерфейс в неразборчивый режим; sudo ifconfig wlan0 promisc . Симптом возвращается в течение десяти секунд до минуты sudo ifconfig wlan0 -promisc .

Дополнительная информация доступна при необходимости, просто спросите.

@ Sylver-Dragon, для меня tcpdump предотвратило появление симптома, и, возможно, вы обнаружили то же самое; попробуйте -p флаг, который отключает неразборчивый режим; это позволяет симптому продолжаться.

https://github.com/iiab/iiab/issues/638

@quozl Я пробовал запустить tcpdump как на беспроводном интерфейсе, так и на интерфейсе моста, и во время его работы были зависания. Я попробую беспорядочный режим и посмотрю, имеет ли это значение. Хотя, основываясь на отладочных выводах драйвера беспроводного интерфейса, в частности:
wl0: _wlc_bss_update_beacon: out of mem, 0 байт сброшено
Я предполагаю, что это какая-то утечка ресурсов (памяти?) Со стороны драйвера. Когда у меня есть немного больше времени, я хочу сделать захват пакета и вникнуть в момент его блокировки. Я подозреваю, что мой телефон отправляет какой-то странный или искаженный пакет или серию пакетов на устройство, которое запускает блокировку. Если я смогу зафиксировать и изолировать это, это должно помочь в исправлении.

Похоже, проблема с почтовым ящиком, которую мы сейчас отслеживаем, связана с другой ошибкой. Что раздражает. Ваш телефон Samsung BTW? Кажется, что проблема с почтовым ящиком чаще вызывается устройствами SS. Если вы можете отследить, что когда-либо вызывает проблемы, это будет очень полезно.

Я ищу то же самое (?) Уже несколько недель. Я чувствую, что, должно быть, прочитал все отчеты об этой и подобных проблемах. Итак, вот еще немного информации от меня:

Я использую внутренний Wi-Fi raspberry pi 3 в качестве точки доступа. Я использую стандартное ядро ​​и модули raspbian (Linux версия 4.9.35-v7 + (dc4 @ dc4-XPS13-9333) (gcc версия 4.9.3 (crossstool-NG crossstool-ng-1.22.0-88-g8460611)) # 1014 SMP, пятница, 30 июня, 14:47:43 BST 2017 г.).

Прошивка для Wi-Fi: brcmfmac: Версия микропрограммы = wl0: 7 августа 2017 г. 00:46:29 версия 7.45.41.46 (r666254 CY) FWID 01-f8a78378

Я почти уверен, что раньше эта аппаратная установка работала, но после некоторого обновления (в том числе ядра), я считаю, все пошло наперекосяк. Создание точки доступа работает нормально, но после ее использования в течение некоторого времени (около 30 минут, не каждый раз, как я думаю), потоковой передачи с использованием Chromecast соединение перестает работать. Может быть (но здесь я не уверен), что это происходит чаще всего, когда я приостанавливаю / останавливаю трансляцию, но только изредка во время просмотра. В случае сбоя существующие подключения удаляются, а новые попытки подключения не принимаются ни одним клиентом. Перезагрузка hostapd приводит к brcmf_cfg80211_stop_ap: setting INFRA mode failed -7 (невозможно установить режим master). Это можно временно исправить, перезагрузив драйвер: rmmod brcmfmac; modprobe brcmfmac . Затем все снова работает так, как ожидалось, пока в следующий раз не произойдет сбой. В качестве альтернативы перезагрузка также «решает» проблему.

Единственное, что я получаю в состоянии сбоя (с включенной отладкой) в системном журнале:

ядро: [3615.491795] brcmfmac: brcmf_netdev_wait_pend8021x: истекло время ожидания ожидающих пакетов 802.1x
hostapd: wlan0: STA xx: xx: xx: xx: xx: xx IEEE 802.11: деаутентификация из-за локального запроса деаутентификации

Это сообщение об ошибке не имеет для меня смысла. Время ожидания "ожидающих пакетов" истекло? Тем не мение:

У меня отключен режим энергосбережения:

iw wlan0 get power_save Power save: off

roam_off установлен в 1 и отладка включена:

`systool -a -v -m brcmfmac
Модуль = "brcmfmac"

Атрибуты:
coresize = "222874"
initsize = "0"
initstate = "жить"
refcnt = "0"
srcversion = "10E8F4629D109E78E1F506C"
taint = ""
uevent =

Параметры:
альтернатива_fw_path =
debug = "1048576"
roamoff = "1"
`

У меня нет телефона Samsung, но есть несколько Android. Ни один из них не подключен к этой точке доступа. Единственными прямыми клиентами являются два Chromecast (одно видео, одно только аудио, а также планшет Android). Все остальное поступает через проводной интерфейс.

@knarrff
Пожалуйста, найдите на этой странице мой предыдущий комментарий от 3 недель назад, чтобы найти хорошее решение.

@ JamesH65
Никогда не получал от вас подтверждения. Вы копировали / ретранслировали вывод dmesg, которым я поделился из этого комментария 3 недели назад, ребятам из Cypress?

@randyoo : У меня есть как "rsn_pairwise = CCMP", так и "wpa = 2" в моем hostapd.conf. В моем случае не помогает. Несекретные записи из моего файла:
`
интерфейс = wlan0

драйвер = nl80211
ssid = XXX
hw_mode = g
канал = 1
ieee80211n = 0
wmm_enabled = 1
ht_capab = [HT40] [SHORT-GI-20] [DSSS_CCK-40]
macaddr_acl = 0
auth_algs = 1
ignore_broadcast_ssid = 0
wpa = 2
wpa_key_mgmt = WPA-PSK
wpa_passphrase = XXX
rsn_pairwise = CCMP
`

Также становится ясно, что сбой всегда, кажется, происходит для меня, когда я пытаюсь приостановить поток netflix на Chromecast (что не означает, что он всегда терпит неудачу, когда я пытаюсь это сделать, просто всякий раз, когда он терпит неудачу, это то, что я делал ). С другой стороны, это может быть отвлекающим маневром, так как это то, что я делаю почти все время с этой сетью Wi-Fi. Возможно, проблема возникает просто, когда устройство пытается аутентифицироваться в AP (например, планшет Android, который, вероятно, отключил Wi-Fi во время сна). Покажет больше испытаний. Попробую без Chromecast - просто обычный wifi на планшете, включая циклы wifi-сна.

Не похоже, что моя проблема такая же, как эта, поэтому я переключусь в режим скрытия. Мой ifconfig wlan0 promisc исправил его для

Я могу надежно воспроизвести это без Netflix или Chromecast, подключившись к сети через планшет Google, затем позволив планшету перейти в спящий режим, возобновить работу (планшет пытается повторно установить связь), и в этот момент точка доступа «мертва».

На машине Linux я получаю это в системном журнале при попытке связать (с использованием правильных учетных данных):

`

[42231.476518] wlan7: отправить аутентификацию на b8: 27: eb: 33: 98: 14 (попробуйте 1/3)
[42231.583434] wlan7: отправить аутентификацию на b8: 27: eb: 33: 98: 14 (попробуйте 2/3)
[42231.694397] wlan7: отправить аутентификацию на b8: 27: eb: 33: 98: 14 (попробуйте 3/3)
[42231.799368] wlan7: аутентификация с помощью b8: 27: eb: 33: 98: время ожидания 14 истекло
[42236.585750] wlan7: аутентифицироваться с помощью b8: 27: eb: 33: 98: 14
[42236.598833] wlan7: отправить аутентификацию на b8: 27: eb: 33: 98: 14 (попробуйте 1/3)
[42236.602344] wlan7: аутентифицирован
[42236.603480] wlan7: связать с b8: 27: eb: 33: 98: 14 (попробуйте 1/3)
[42236.619322] wlan7: RX AssocResp из b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 помощь = 1)
[42236.623181] wlan7: связанный
[42236.623325] IPv6: ADDRCONF (NETDEV_CHANGE): wlan7: ссылка становится готовой
[42236.625464] wlan7: ограничение мощности передачи до 30 (30 - 0) дБм, как объявлено b8: 27: eb: 33: 98: 14
[42239.730365] wlan7: деаутентификация с b8: 27: eb: 33: 98: 14 (Причина: 2 = PREV_AUTH_NOT_VALID)
[42241.243434] wlan7: аутентифицироваться с помощью b8: 27: eb: 33: 98: 14
[42241.256326] wlan7: отправить аутентификацию на b8: 27: eb: 33: 98: 14 (попробуйте 1/3)
[42241.260724] wlan7: аутентифицирован
[42241.263403] wlan7: связать с b8: 27: eb: 33: 98: 14 (попробуйте 1/3)
[42241.279537] wlan7: RX AssocResp из b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 help = 1)
[42241.282500] wlan7: связанный
[42241.336166] wlan7: ограничение мощности передачи до 30 (30 - 0) дБм, как заявлено в b8: 27: eb: 33: 98: 14
[42244.392213] wlan7: деаутентификация с b8: 27: eb: 33: 98: 14 (Причина: 2 = PREV_AUTH_NOT_VALID)
[42253.916626] wlan7: аутентифицироваться с помощью b8: 27: eb: 33: 98: 14
[42253.928966] wlan7: отправить аутентификацию на b8: 27: eb: 33: 98: 14 (попробуйте 1/3)
[42253.936020] wlan7: аутентифицирован
[42253.939533] wlan7: связать с b8: 27: eb: 33: 98: 14 (попробуйте 1/3)
[42253.943361] wlan7: RX AssocResp из b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 aid = 2)
[42253.945415] wlan7: связанный
[42254.035149] wlan7: ограничение мощности передачи до 30 (30 - 0) дБм, как заявлено в b8: 27: eb: 33: 98: 14
[42257.053762] wlan7: деаутентификация с b8: 27: eb: 33: 98: 14 (Причина: 2 = PREV_AUTH_NOT_VALID)
`

b8: 27: eb: 33: 98: 14 - рассматриваемый RPI3, на котором я снова получаю dmesg-entries:
brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets

Я не совсем понимаю, почему AP отправляет PREV_AUTH_NOT_VALID, когда я, по-видимому, связан. У меня сложилось впечатление, что аутентификация предшествует ассоциации. Не должно быть случая, когда я связан, но не аутентифицирован.

Здравствуй

Я использую Pi3 в качестве медиасервера, связь через встроенный WiFi

Обновление Rasbian Stretch Lite 4.9 (сейчас)
Plex Media Server

Я получаю...

ядро: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012

в dmesg и syslog при подключении к Pi с использованием клиента BubbleUPnp на Samsung S5 SM_G900F Android 7.1.2 это в значительной степени гарантировано и требует перезагрузки, чтобы PiWiFi снова стал пригодным для использования.

На моем старом Sony Xperia XP Android 6.0.1 снова работает BubbleUPnp, пока он работает нормально. Это мое решение. Однако, если я могу оказать какую-либо помощь, чтобы разобраться в этом, я буду рад внести свой вклад.

Джон

Он также работает на iPad с mConnectLite.

@johnthesoftwareathome Напишите электронное письмо Джеймсу Хьюзу из Raspberry Pi, чтобы он отправил вам отладочную прошивку по Wi-Fi.

Адрес электронной почты, опубликованный на странице контактов Raspberry Pi fao James Hughes

Хорошо, у нас есть новая отладочная прошивка от Cypress, которую я хотел бы использовать для тестирования - в ней больше отладки, но нет исправлений, поэтому только для тех, кто счастлив тестировать. Если вы уже отправили мне свой адрес электронной почты, укажите здесь, что вы хотели бы провести некоторое тестирование, и я пришлю вам прошивку, или свяжитесь со мной через личку на форумах Pi.

Чтобы люди не копались в том, как установить / запустить новую прошивку.

Скопируйте файл отладочной прошивки в:

/lib/firmware/brcm/

(Сначала вы захотите создать резервную копию оригинала)

Думаю, на этом этапе нужно перезагрузиться.

Теперь перезапустите драйвер Linux в режиме отладки.

sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000

Сделайте это неправильно .. !!

Выгрузите dmesg в файл и разместите здесь.

Чтобы добавить к тому, что говорит Джеймс, вы можете предпочесть избегать последовательности rmmod / modprobe, добавив brcmfmac.debug=0x100000 к /boot/cmdline.txt .

@ JamesH65 Я буду рад помочь в тестировании. Хотя я только что зарегистрировался на форуме Pi, я не могу отправлять сообщения. Используя то же имя пользователя, если это поможет.

Вчера я попробовал новую отладочную прошивку, а также добавил brcmfmac.debug = 0x100000 в /boot/cmdline.txt.

Однако, как ни странно, я не видел никаких отладочных данных в dmesg. Что еще более странно, там, где я мог достоверно воспроизвести проблему раньше, она работала весь вечер, независимо от того, что я делал. У меня не было ни одной проблемы, и все, что я делал иначе, это использование нового файла прошивки (md5 sum ba679a85c1dc76e9775603af45440bc0) вместо старого и добавление записи в /boot/cmdline.txt вместо добавления параметра с помощью modprobe. Вчера у меня не было времени вернуться к старой прошивке и посмотреть, вернется ли она к старым проблемам. Я сообщу, как только сделаю это. А пока: действительно ли все, что изменилось в этой прошивке, "больше отлажено"?

Я думал, что это просто отладка, но вернусь к Cypress так же ясно
что-то еще изменилось, надеюсь, в хорошем смысле!

11 января 2018 года в 06:48 Фрэнк Лёффлер [email protected] написал:

Вчера попробовал новую отладочную прошивку и тоже добавил
brcmfmac.debug = 0x100000 в /boot/cmdline.txt.

Однако, как ни странно, я не видел никаких отладочных данных в dmesg. Даже больше
как ни странно, там, где раньше я мог достоверно воспроизвести проблему, она работала
весь вечер независимо от того, что я делал. У меня не было ни одной проблемы, и
все, что я сделал, это использовал новый файл прошивки (сумма md5
ba679a85c1dc76e9775603af45440bc0). Вчера у меня не было времени пойти
вернитесь к старой прошивке, чтобы увидеть, вернется ли она к старым проблемам. Больной
доложить, как только я это сделал. А пока: все ли изменилось в этом
прошивка реально "еще отладочная"?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-356842102 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHam4jUgDCkSFxMXS-KW4axCLoPZhks5tJa6fgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Мой опыт был похож на опыт @knarrf , за исключением того, что я видел отладочные сообщения в dmesg.

Раньше мой Samsung S5 был непригоден для использования в качестве клиента plexserver, но когда я загрузил отладочную прошивку, он работал (с, как я уже сказал, отладочными сообщениями в dmesg), поэтому я вернулся к исходному двоичному файлу (резервное копирование и проверенный размер), и он все еще работает. Итак, я снова работаю с отладочной прошивкой (я не пробовал мод cmdline.txt, только rmmod / modprobe) и прослушал несколько часов музыки без ошибок. Я пробовал активировать большинство из множества разбросанных по всему миру WiFi-устройств, но безрезультатно.

Я буду пробовать это в течение нескольких дней, чтобы посмотреть, не произойдет ли что-нибудь, затем перезагрузите оригинал и повторите попытку. Возможно, я не отключал Pi между перезагрузками. Я обязательно сделаю это, когда вернусь, чтобы посмотреть, может ли это быть какое-то сохранение реестра.

Сегодня вечером я загрузил старую прошивку (взятую из установочного образа raspian; более подробная информация о версиях, которые я использую ниже) и перезагрузил модуль с этим (и включенной отладкой), я даже перезагрузился между ними. Короткий вывод в dmesg подтверждает, что теперь загружена старая версия. И, как и в случае с @johnthesoftwareathome , он продолжал работать весь вечер, несмотря на то, что делал вещи, которые в прошлом несколько раз

Итак, на данный момент моя задача, похоже, состоит в том, чтобы вернуть его «не работает», чтобы иметь возможность узнать, что происходит. Моя следующая попытка, хотя и не сегодня, будет делать полный сброс (отключение питания на некоторое время вместо простого использования команды «перезагрузка») и использование совершенно новой установки из свежего образа.

Кроме того, я, к сожалению, не могу исключить возможность того, что образ, с которым у меня возникли ошибки, был еще одной версией, так как я забыл сделать резервную копию, прежде чем перезаписывать ее отладочным образом. Может быть, @johnthesoftwareathome может опубликовать, какое именно изображение он использует и с которым / имеет проблемы? С другой стороны, тогда я обновлял прошивку только с помощью стандартных пакетов, и у меня действительно была установлена ​​версия пакета firmware-brcm80211 (1: 0.43 + rpi6). Хотя последняя запись в журнале изменений не указывает версию прошивки, предпоследняя указывает: 7.45.41.26, которая старше версии из образа. Если предположить, что журнал изменений был написан правильно, это будет убедительным признаком того, что прошивка не была заменена с момента создания образа, и что тот, который я называю «образом», - это тот, который я использовал раньше.

Информация о двух моих файлах прошивки (изображение: тот из установочного образа raspbian, отладка: тот, который я получил непосредственно от @ JamesH65 :

отлаживать:
Версия прошивки = wl0: 23.10.2017 03:55:53 версия 7.45.98.38 (r674442 CY) FWID 01-e58d219f
md5sum: ba679a85c1dc76e9775603af45440bc0
образ:
Версия прошивки = wl0: 7 августа 2017 г., 00:46:29 версия 7.45.41.46 (r666254 CY) FWID 01-f8a78378
md5sum: 5f520a38ab4e943bfa1ba102f80fb2a0

@johnthesoftwareathome : как выглядит новый вывод «отладки»? Я до сих пор не получаю ничего, что даже удаленно выглядело бы как обширная отладка, независимо от того, как я загружаю модуль. Во время работы я получаю ноль записей, и даже после загрузки все выглядит несколько уместно:

как root: dmesg | grep brcm
[0.000000] Командная строка ядра: 8250.nr_uarts = 0 bcm2708_fb.fbwidth = 640 bcm2708_fb.fbheight = 480 bcm2708_fb.fbdepth = 16 bcm2708_fb.fbswap = 1 vc_mem.mem_basec = 0c_mem_base = 0c_mem_base = 0c_mem_basec = 0c_mem_base = 0c_mem_base = 0c_mem_base = 0c_mem_base = 0c_mem_base = 0c_mem_ea00 , 115200 console = tty1 root = PARTUUID = f8e4f7c2-02 rootfstype = ext4 elevator = deadline fsck.repair = yes rootwait brcmfmac.debug = 0x100000
[3.500135] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[3.662113] brcmfmac: версия микропрограммы = wl0: 7 августа 2017 г. 00:46:29 версия 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[3.774278] brcmfmac: управление питанием отключено
[4.711443] brcmfmac: управление питанием отключено

Небольшое обновление: оглядываясь на один из моих старых комментариев в этой теме, я действительно могу подтвердить, что старая прошивка, которую я использовал сегодня («образ»), - это та, с которой у меня были проблемы до тех пор, пока я не попробовал новый образ отладки.

Пустой дом, вот и наконец добрался до последнего альбома Боуи. Все заработало отлично (альбом не очень). Вдали от дома до завтра, тогда я заберу это.

Удалось заставить оригинальную прошивку отказывать, как и раньше, но не надежно между ее использованием и отладочной прошивкой. В настоящее время просто перезагружаюсь с отладкой без сбоев.

Я неправильно понял, что @knarrf имел в виду в отношении вывода отладки, и предположил, что он не мог видеть, что новая прошивка установлена, а не имел ввиду, что он ожидал какого-то потока отладки (которого я тоже не вижу). Он прав. В случае неудачи мы что-нибудь увидим или шестнадцатеричный код отладки неправильный?

Также не сразу выпала одна из неисправностей. Это позволило мне снова подключиться к ssh до перезагрузки. Системный журнал содержит следующее ..

13 января 08:34:48 Ядро plexServer: [46.648630] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
13 января 08:35:14 Ядро plexServer: [72.161473] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg не удалось со статусом -110
13 января 08:35:14 Ядро plexServer: [72.161484] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-110)

Это очень знакомый набор сообщений об ошибках, но все же полезно знать, что вы столкнулись с той же проблемой, которая теперь, похоже, может быть исправлена.

Cypress готовит для нас новую версию прошивки - мы опубликуем здесь, когда что-то будет доступно для тестирования. Спасибо всем за проявленный интерес, время и терпение.

ОК. Спасибо за рабочий драйвер.

С этого момента все могло измениться.

https://tech4research.wordpress.com/2014/07/23/brcmfmac-debugging-and-appgotiation-debug-values/

и я понимаю, что переключатель отладки для новой прошивки может быть специальным дополнением, но эти переключатели, похоже, работают как для исходной, так и для «отладочной» прошивки, и ожидаемый поток отладки извергается вперед.

Наверное, уже видели; но TPLink утверждает, что устройства Android подвергают свои устройства DoS-атакам с помощью пакетов MDNS, когда они выходят из спящего режима и пытаются повторно подключиться к Chromecast или аналогичным устройствам.
Копаясь в pcap, я получил отключение одного моего собственного устройства, я вижу, что ~ 3500 пакетов MDNS приходят за ~ 2,25 секунды прямо перед тем, как мое соединение прерывается. Кажется, это соответствует этому шаблону и может быть связано.

Просто чтобы добавить / подтвердить некоторую информацию в этом выпуске:

• Настройка интерфейса Wi-Fi на неразборчивый ( ifconfig wlan0 promisc ), похоже, смягчает проблему
• Проблема, похоже, вызвана только моим телефоном Android 7.1.2 Galaxy S7 (который я получил неделю назад, и именно тогда начались проблемы)

Я запускаю Debian Buster с aarch64 на моем Pi3 и запускаю на нем сервер Nextcloud. scp'ing больших файлов с ноутбука Linux не вызывает никаких проблем, и Nextcloud не синхронизируется с этим ноутбуком, но как только я загружу пакет файлов из Galaxy, появится ошибка Unknown mailbox data content: 0x40012 и подключение к Wi-Fi будет потерял.

Я использую прошивку brcmfmac 7.45.41.26 (r640327) FWID 01-4527cfab

К сожалению, у меня нет более старой версии Android для тестирования.

Я tcpdump загрузил загрузку с Samsung на Pi3, но затем Wi-Fi был в беспорядочном режиме, и все работало нормально. Если у меня будет время, я посмотрю на pcap и сообщу, если найду что-нибудь полезное / интересное.

PS: Cast (основной нарушитель, описанный в статье TPLink) не активен (по крайней мере, я не вижу его в настройках подключения).

Привет всем,

Я просто хочу подтвердить, что отключение энергобезопасного режима и включение неразборчивого режима устранили проблему для меня: впервые ему удалось оставаться на связи в течение 24 часов.

sudo iw wlan0 отключил power_save
sudo ifconfig wlan0 promisc

Спасибо,
Люк

Пожалуйста, прочтите это сообщение на форуме для получения подробной информации о новой версии прошивки. Любой, кто видит проблему с почтовым ящиком или даже какие-либо проблемы с беспроводной связью, должен попробовать это, чтобы увидеть, поможет ли это.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508

@ JamesH65
Привет, Джеймс,
Не могли бы вы предоставить инструкции по установке, является ли файл .bin в архиве самоустанавливающимся исполняемым файлом?
Спасибо
Ли

Инструкции теперь на связанной странице форума.

Повторная проверка после запуска новой прошивки чуть больше недели. Пока что все было хорошо. Я неоднократно будил свое устройство Samsung после долгих периодов времени, а беспроводной интерфейс на моем Pi продолжал работать. Я считаю, что у меня был один случай, когда он временно упал, а затем восстановился; хотя я не смог воспроизвести это. В целом выглядит солидно. Спасибо Джеймсу за то, что он придерживается этого, и команде Cypress за то, что исправили это.

Спасибо за отчет.

Может ли кто-нибудь сказать мне, было ли исправление прошивки уже включено в официальный дистрибутив Raspbian, чтобы его можно было установить через apt update или, если еще нет, сообщить мне, когда это произойдет?

Может ли кто-нибудь сказать мне, было ли исправление прошивки уже включено в официальный дистрибутив Raspbian, чтобы его можно было установить с помощью apt update, или, если еще нет, сообщить мне, когда это произойдет?

Да. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508&start=25#p1270212
О некоторых проблемах сообщается на Pi0W после общего обновления, но не совсем ясно, просто ли это изменение прошивки или что-то еще - https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=204882

Я обновил прошивку

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.bin
ba679a85c1dc76e9775603af45440bc0  /lib/firmware/brcm/brcmfmac43430-sdio.bin

но все еще та же проблема

$ dmesg | grep brcmfmac
[    3.917447] usbcore: registered new interface driver brcmfmac
[    4.079889] brcmfmac: Firmware version = wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[    5.079252] brcmfmac: power management disabled
[   27.125197] brcmfmac: power management disabled
[   92.278751] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
[  338.327158] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[  340.887163] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[  340.887181] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[  360.407241] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[  362.967295] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[  362.967308] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110

Следующее также не позволяет избежать этой проблемы

sudo iw wlan0 set power_save off
sudo ifconfig wlan0 promisc

Я использую RPi3 в качестве точки доступа с hostapd и dnsmasq .
Я всегда могу воспроизвести проблему при запуске загрузки в приложении Spotify на моем телефоне Android.

Нужно ли мне обновить и следующий файл?

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.txt
9a88b55134d9f8f3ad2331b93f4b7b79  /lib/firmware/brcm/brcmfmac43430-sdio.txt

Будет ли он использоваться драйвером или его можно игнорировать?

Редактировать:
Да. Также требуется файл brcmfmac43430-sdio.txt.
Но я использую самые последние версии с https://github.com/RPi-Distro/firmware-nonfree/tree/927fa8ebdf5bcfb90944465b40ec4981e01d6015/brcm

Я также обновил ядро ​​4.9.35-v7 + до 4.14.18-v7 +.
Но проблема все еще существует.

Возникла та же проблема на моем RPi3: Wi-Fi пропадает после некоторого времени безотказной работы (например, ночью) при почти полном отсутствии трафика.
Вывод dmesg показывает только:

[ +3,519999] brcmfmac: brcmf_do_escan: error (-110)
[ +0,000011] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[  +3,519987] brcmfmac: brcmf_do_escan: error (-110)
[  +0,000012] brcmfmac: brcmf_cfg80211_scan: scan error (-110)

Я попытался перезагрузить драйвер (rmmod & modprobe brcmfmac):

[  +0,100025] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -5
[  +0,000014] brcmfmac: brcmf_cfg80211_get_tx_power: error (-5)
[  +0,519934] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[  +0,000050] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[  +0,000672] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[  +0,000012] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-5)
[  +0,221254] usbcore: deregistering interface driver brcmfmac
[Mär12 21:18] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[  +0,010071] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001
[  +0,000285] usbcore: registered new interface driver brcmfmac
[  +2,649115] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[  +0,005807] brcmfmac: brcmf_c_get_clm_name: retrieving revision info failed (-110)
[  +0,000010] brcmfmac: brcmf_c_process_clm_blob: get CLM blob file name failed (-110)
[  +0,000008] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file failed, -110
[  +0,000007] brcmfmac: brcmf_bus_started: failed: -110
[  +0,000021] brcmfmac: brcmf_sdio_firmware_callback: dongle is not responding

Это как-то не сработало - драйвер загружен, но у меня нет интерфейса
Попробовал еще раз:

[Mär12 21:26] usbcore: deregistering interface driver brcmfmac
[ +32,681743] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[  +0,007275] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001
[  +0,000257] usbcore: registered new interface driver brcmfmac
[  +0,116144] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Aug  7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[  +0,000641] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.41 Inc Compiler: 1.29.4 Inc ClmImport: 1.36.3 Creation: 2017-08-07 00:37:47
[  +0,184532] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  +0,000034] brcmfmac: power management disabled
[  +1,833812] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

..и я снова встал.

Pi3 работает под управлением ядра 4.14.24-v7 + # 1097 - прошивка старше 7 августа 2017 года - та же самая прошивка, которая работает безупречно (время безотказной работы> 2 месяцев) на Pi Zero W с ядром 4.9.77+ # 1081
Оба Pis подключены к одному маршрутизатору и находятся в отдельной комнате. Оба подключены только через Wi-Fi.

Вероятно, стоит использовать последнюю версию прошивки на 4.14, поскольку в 4.14 есть все необходимые изменения для работы с этой прошивкой.

:) Обновился до последней прошивки (23.10.2017, 03:55:53, версия 7.45.98.38) вчера после публикации - вроде работает атм - посмотрим, что будет ..

Похоже, что raspbian вернулся к пакету прошивки от августа 2017 года. Есть ли какие-то новые требования к беспроводной сети rpi 3B +?

Последний пакет прошивки растянутого репозитория Foundation -brcm80211 1: 20161130-3 + rpt3 имеет версию прошивки от 23 октября 2017 года 7.45.98.38 для Pi3 / Pi0W и другой подходящий пакет для Pi3 +

У меня тоже та проблема с умирающим wifi.

Mar 17 18:25:28 hassass kernel: [10279.186321] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
Mar 17 18:25:30 hassass kernel: [10281.665090] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
Mar 17 18:25:30 hassass kernel: [10281.665622] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
Mar 17 18:25:30 hassass kernel: [10281.665638] brcmfmac: brcmf_run_escan: error (-110)
Mar 17 18:25:30 hassass kernel: [10281.665647] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
Mar 17 18:26:30 hassass kernel: [10341.665866] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout

Это с 4.14.27-v7 + и с
/ sbin / iw dev wlan0 выключить power_save
/ sbin / ifconfig wlan0 promisc
в /etc/rc.local.

те же сообщения об ошибках, что и @ flok99 - с использованием последней прошивки (rpi-update) на stretch.

Итак, ошибка, которую, как мы думали, исправил Cypress, все еще существует. Вернуться к
Кипарис идет. На получение этой версии ушел год. Не задерживая дыхание
рекомендуемые.

Однако необходимо подтвердить версию, опубликуйте содержимое

dmesg | grep brcmfmac

18 марта 2018 года в 01:44 Rebroad [email protected] написал:

те же сообщения об ошибках, что и @ flok99 https://github.com/flok99 - с использованием последней версии
Прошивка (rpi-update) на растяжке.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373966343 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHY1Cmntz_kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

[4.112717] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x15264345
[4.119827] brcmfmac: brcmf_fw_map_chip_to_name: используя
brcm / brcmfmac43455-sdio.bin для микросхемы 0x004345 (17221) rev 0x000006
[4.120314] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[4.440371] brcmfmac: brcmf_c_preinit_dcmds: Версия микропрограммы = wl0: февраль
27 2018 03:15:32 версия 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[4.440958] brcmfmac: brcmf_c_preinit_dcmds: версия CLM = API: 12.2
Данные: 9.10.105 Компилятор: 1.29.4 ClmImport: 1.36.3 Создание: 2018-03-09
18:56:28
[10.911757] brcmfmac: управление питанием отключено
[12.016088] brcmfmac: управление питанием отключено
[2074.090674] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
не удалось со статусом -5
[2074.090687] brcmfmac: brcmf_cfg80211_get_tx_power: ошибка (-5)
[2074.090745] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[2074.090753] brcmfmac: brcmf_link_down: сбой WLC_DISASSOC (-5)
[2074.610583] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[2074.611992] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[2074.613945] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[2074.613971] brcmfmac: brcmf_cfg80211_get_channel: сбой chanspec (-5)
[2074.729716] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[2074.729733] brcmfmac: brcmf_cfg80211_reg_notifier: код страны iovar
вернул err = -5
[2074.871693] usbcore: отмена регистрации драйвера интерфейса brcmfmac
[2074.929084] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x15264345
[2074.936897] brcmfmac: brcmf_fw_map_chip_to_name: используя
brcm / brcmfmac43455-sdio.bin для чипа 0x004345 (17221) rev 0x000006
[2074.937139] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[2075.118180] brcmfmac: brcmf_c_preinit_dcmds: Версия микропрограммы = wl0: февраль
27 2018 03:15:32 версия 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2075.118706] brcmfmac: brcmf_c_preinit_dcmds: версия CLM = API: 12.2
Данные: 9.10.105 Компилятор: 1.29.4 ClmImport: 1.36.3 Создание: 2018-03-09
18:56:28
[2075.215365] brcmfmac: управление питанием отключено
[2075.263751] brcmfmac: управление питанием отключено
[2085.475001] brcmfmac: управление питанием отключено
[2124.380808] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[2124.381146] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[2124.381156] brcmfmac: brcmf_cfg80211_get_channel: сбой chanspec (-5)
[2124.622345] usbcore: отмена регистрации драйвера интерфейса brcmfmac
[2124.705432] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x15264345
[2124.714194] brcmfmac: brcmf_fw_map_chip_to_name: используя
brcm / brcmfmac43455-sdio.bin для микросхемы 0x004345 (17221) rev 0x000006
[2124.716213] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[2124.929556] brcmfmac: brcmf_c_preinit_dcmds: Версия микропрограммы = wl0: февраль
27 2018 03:15:32 версия 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2124.929993] brcmfmac: brcmf_c_preinit_dcmds: версия CLM = API: 12.2
Данные: 9.10.105 Компилятор: 1.29.4 ClmImport: 1.36.3 Создание: 2018-03-09
18:56:28
[2125.105218] brcmfmac: управление питанием отключено
[2125.150290] brcmfmac: управление питанием отключено
[8237.434034] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика:
0x40012
[8239.890302] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[8239.890822] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[8239.890835] brcmfmac: brcmf_run_escan: ошибка (-110)
[8239.890845] brcmfmac: brcmf_cfg80211_scan: ошибка сканирования (-110)
[8254.280425] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
не удалось со статусом -5
[8254.280438] brcmfmac: brcmf_cfg80211_get_tx_power: ошибка (-5)
[8254.280491] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8254.280498] brcmfmac: brcmf_link_down: сбой WLC_DISASSOC (-5)
[8254.800394] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8254.803873] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8254.808353] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8254.808370] brcmfmac: brcmf_cfg80211_get_channel: сбой chanspec (-5)
[8254.881402] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8254.881420] brcmfmac: brcmf_cfg80211_reg_notifier: код страны iovar
вернул err = -5
[8255.001550] usbcore: отмена регистрации драйвера интерфейса brcmfmac
[8255.071184] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x15264345
[8255.077098] brcmfmac: brcmf_fw_map_chip_to_name: используя
brcm / brcmfmac43455-sdio.bin для чипа 0x004345 (17221) rev 0x000006
[8255.077348] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[8257.730418] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[8257.751038] brcmfmac: brcmf_c_get_clm_name: получение информации о версии
не удалось (-110)
[8257.751049] brcmfmac: brcmf_c_process_clm_blob: получить имя файла BLOB-объекта CLM
не удалось (-110)
[8257.751068] brcmfmac: brcmf_c_preinit_dcmds: загрузить файл большого двоичного объекта CLM
не удалось, -110
[8257.751076] brcmfmac: brcmf_bus_started: сбой: -110
[8257.751114] brcmfmac: brcmf_sdio_firmware_callback: ключ не является
отвечающий
[8304.417684] usbcore: отмена регистрации драйвера интерфейса brcmfmac
[8304.486099] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x15264345
[8304.493613] brcmfmac: brcmf_fw_map_chip_to_name: используя
brcm / brcmfmac43455-sdio.bin для чипа 0x004345 (17221) rev 0x000006
[8304.494078] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[8304.686761] brcmfmac: brcmf_c_preinit_dcmds: Версия микропрограммы = wl0: февраль
27 2018 03:15:32 версия 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8304.687203] brcmfmac: brcmf_c_preinit_dcmds: версия CLM = API: 12.2
Данные: 9.10.105 Компилятор: 1.29.4 ClmImport: 1.36.3 Создание: 2018-03-09
18:56:28
[8304.829994] brcmfmac: управление питанием отключено
[8304.907662] brcmfmac: управление питанием отключено
[8357.441791] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика:
0x40012
[8359.891146] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[8359.891655] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[8359.891668] brcmfmac: brcmf_run_escan: ошибка (-110)
[8359.891677] brcmfmac: brcmf_cfg80211_scan: ошибка сканирования (-110)
[8371.731226] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[8371.731731] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[8371.731746] brcmfmac: brcmf_cfg80211_get_channel: сбой chanspec (-110)
[8373.941267] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
не удалось со статусом -5
[8373.941280] brcmfmac: brcmf_cfg80211_get_tx_power: ошибка (-5)
[8373.941330] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8373.941338] brcmfmac: brcmf_link_down: сбой WLC_DISASSOC (-5)
[8374.461245] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8374.461942] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8374.463553] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8374.463573] brcmfmac: brcmf_cfg80211_get_channel: сбой chanspec (-5)
[8374.564729] brcmfmac: brcmf_fil_cmd_data: автобус не работает. у нас ничего нет
делать.
[8374.564750] brcmfmac: brcmf_cfg80211_reg_notifier: код страны iovar
вернул err = -5
[8374.702401] usbcore: отмена регистрации драйвера интерфейса brcmfmac
[8374.759839] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x15264345
[8374.767561] brcmfmac: brcmf_fw_map_chip_to_name: используя
brcm / brcmfmac43455-sdio.bin для чипа 0x004345 (17221) rev 0x000006
[8374.771137] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[8377.411255] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[8377.431924] brcmfmac: brcmf_c_get_clm_name: получение информации о версии
не удалось (-110)
[8377.431934] brcmfmac: brcmf_c_process_clm_blob: получить имя файла BLOB-объекта CLM
не удалось (-110)
[8377.431941] brcmfmac: brcmf_c_preinit_dcmds: загрузить файл BLOB-объекта CLM
не удалось, -110
[8377.431949] brcmfmac: brcmf_bus_started: сбой: -110
[8377.432003] brcmfmac: brcmf_sdio_firmware_callback: ключ не является
отвечающий
[8424.133114] usbcore: отмена регистрации драйвера интерфейса brcmfmac
[8424.229631] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x15264345
[8424.237210] brcmfmac: brcmf_fw_map_chip_to_name: используя
brcm / brcmfmac43455-sdio.bin для чипа 0x004345 (17221) rev 0x000006
[8424.239352] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[8424.460736] brcmfmac: brcmf_c_preinit_dcmds: Версия микропрограммы = wl0: февраль
27 2018 03:15:32 версия 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8424.461174] brcmfmac: brcmf_c_preinit_dcmds: версия CLM = API: 12.2
Данные: 9.10.105 Компилятор: 1.29.4 ClmImport: 1.36.3 Создание: 2018-03-09
18:56:28
[8424.646993] brcmfmac: управление питанием отключено
[8424.708633] brcmfmac: управление питанием отключено

Вск, 18 марта 2018 г., 11:30, Джеймс Хьюз [email protected]
написал:

Итак, ошибка, которую, как мы думали, исправил Cypress, все еще существует. Вернуться к
Кипарис идет. На получение этой версии ушел год. Не задерживая дыхание
рекомендуемые.

Однако необходимо подтвердить версию, опубликуйте содержимое

dmesg | grep brcmfmac

18 марта 2018 года в 01:44 Rebroad [email protected] написал:

те же сообщения об ошибках, что и @ flok99 https://github.com/flok99 - с использованием
последний
Прошивка (rpi-update) на растяжке.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -373966343
,
или отключить поток
kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5>
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373987387 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADESuI3-T3HmNWHKLTeApQsVRkxFmNUBks5tfjdhgaJpZM4HupC5
.

-
www.vanheusden.com www.slimwinnen.nl www.winnenmetbitcoin.nl

www.aliensdetected.com www.benjeeigenbank.nl www.depersoonlijkebank.nl

www.hackerspace-gouda.nl www.ismijnwebsitekapot.nl www.micro-twin.com

www.slimmetvalutahandelen.nl www.slimwinstmaken.nl www.vertrouwdbankieren.nl

www.watismijnip.info

@ flok99

brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 
Firmware version = wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04 

Похоже, вы используете более новый Pi3b +, а не оригинальный Pi3: так, может быть, другое дело?

Совершенно другой чип и прошивка, хотя драйвер на стороне Linux - это
такой же. (brcmfmac).

19 марта 2018 года в 16:26 macmpi [email protected] написал:

@ flok99 https://github.com/flok99

brcmfmac: brcmf_fw_map_chip_to_name: использование brcm / brcmfmac43455-sdio.bin для чипа
Версия прошивки = wl0: 27.02.2018 03:15:32 версия 7.45.154 (r684107 CY) FWID 01-4fbe0b04

Похоже, что вы используете более новый Pi3b +, а не оригинальный Pi3: так
может другое дело?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-374274045 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ADqrHeP6-sc-P-OSggQFPrl3O8z_B2aRks5tf9wbgaJpZM4HupC5
.

-
Джеймс Хьюз
Главный инженер-программист,
Raspberry Pi (Trading) Ltd

Я думаю, что лучше иметь еще одну ветку для проблем с Pi3B + и возвращаться к ней при необходимости, иначе ее будет очень сложно отследить. Может @ flok99 создать новые

сделанный

Кто-нибудь подписался на этот выпуск, используя 3B (не плюс), все еще видит проблемы с последней прошивкой и ядром? Хотелось бы получить какие-либо сообщения о продолжающихся неудачах - последние сообщения по теме выше, похоже, подразумевают, что теперь все работает нормально.

Мой 3B вырос за 44 дня с этим:

Linux rpi3 4.14.24-v7+ #1097 SMP Mon Mar 5 16:42:05 GMT 2018
brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f

С тех пор проблем нет ..

Хорошие новости. Если я не услышу иное, я, вероятно, закрою эту ветку через неделю или две, хотя ее можно будет открыть в любое время, если проблемы повторится.

У меня возникла эта проблема около недели назад, я не слышал о ней раньше. Я также чаще всего использую pi с телефоном samsung в качестве маршрутизатора - у меня s4. Пишу это подключено напрямую к s4 через usb, т.е. с помощью rndis. Вот мои подробности из сегодняшней загрузки:
0 обновлено, 0 установлено заново, 0 удалено и 0 не обновлено.
thenry @ pi3portable : ~ $ dmesg | grep brcmfmac
[9.965782] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x1541a9a6
[9.972059] brcmfmac: brcmf_fw_map_chip_to_name: использование brcm / brcmfmac43430-sdio.bin для микросхемы 0x00a9a6 (43430) rev 0x000001
[9.972250] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[10.147562] brcmfmac: brcmf_c_preinit_dcmds: Версия микропрограммы = wl0: 7 августа 2017 г. 00:46:29 версия 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.148507] brcmfmac: brcmf_c_preinit_dcmds: версия CLM = API: 12.2 Данные: 7.11.15 Компилятор: 1.24.2 ClmImport: 1.24.1 Создание: 2014-05-26 10:53:55 Inc Данные: 9.10.41 Inc Компилятор: 1.29 .4 Inc ClmImport: 1.36.3 Создание: 2017-08-07 00:37:47
[18.538641] brcmfmac: управление питанием отключено
[30.629545] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
[33.191450] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[33.194850] brcmfmac: brcmf_sdio_checkdied: ловушка прошивки в ключе
[35.751496] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[35.754898] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[35.754906] brcmfmac: brcmf_pno_clean: код ошибки -110
[43.271438] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[43.274800] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[43.274807] brcmfmac: brcmf_do_escan: ошибка (-110)
[43.274811] brcmfmac: brcmf_cfg80211_scan: ошибка сканирования (-110)
[7673.758073] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[7673.761437] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[7673.761454] brcmfmac: _brcmf_set_multicast_list: Ошибка установки mcast_list, -110
[7676.328075] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[7676.331449] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[7676.331466] brcmfmac: _brcmf_set_multicast_list: Ошибка установки allmulti, -110
[7678.878084] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[7678.881460] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[7681.448101] brcmfmac: _brcmf_set_multicast_list: Ошибка настройки BRCMF_C_SET_PROMISC, -110
[7689.118098] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg не удалось со статусом -110
[7689.118241] brcmfmac: управление питанием отключено
[7691.678100] brcmfmac: brcmf_cfg80211_set_power_mgmt: ошибка (-110)
[7694.238122] brcmfmac: _brcmf_set_multicast_list: Ошибка установки mcast_list, -110
[7696.798118] brcmfmac: _brcmf_set_multicast_list: Ошибка установки allmulti, -110
[7699.358158] brcmfmac: brcmf_do_escan: ошибка (-110)
[7699.358167] brcmfmac: brcmf_cfg80211_scan: ошибка сканирования (-110)
[7701.918127] brcmfmac: _brcmf_set_multicast_list: Ошибка настройки BRCMF_C_SET_PROMISC, -110
[11406.881341] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg не удалось со статусом -110
[11406.881352] brcmfmac: brcmf_cfg80211_reg_notifier: Код страны, возвращенный iovar, err = -110
[11579.921479] brcmfmac: _brcmf_set_multicast_list: Ошибка установки mcast_list, -110
[11582.491485] brcmfmac: _brcmf_set_multicast_list: Ошибка установки allmulti, -110
[11587.611478] brcmfmac: _brcmf_set_multicast_list: Ошибка настройки BRCMF_C_SET_PROMISC, -110
thenry @ pi3portable : ~ $
thenry @ pi3portable : ~ $ uname -a
Linux pi3portable 4.14.27-v7 + # 1100 SMP Пт 16 марта 13:51:48 GMT 2018 armv7l GNU / Linux
thenry @ pi3portable : ~ $
Я запускаю это ядро, потому что я переключился на следующий поток, когда тестировал загрузку с USB, и не вернулся после этого. Затем я получил уведомление о новом ядре (4.14), поэтому решил попробовать это около месяца назад. Все было хорошо, до этого никаких проблем. Единственное другое существенное изменение - я переключился с NetworkManager на systemd-networkd несколько дней назад, но это произошло после того, как эта проблема впервые проявила себя.
С Уважением,
Тревор Генри

Обновить:
Прочитав все связанные сообщения, я нашел последнюю версию прошивки в сообщении https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508
и это устранило мою проблему.

тестовая версия brcmfmas43430-sdio.bin установлена ​​250418

версия 7.45.98.38 23 октября 2017 г. заменена версия 7.45.41.46 7 августа 2017 г.

перед:

[10.368086] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x1541a9a6
[10.376702] brcmfmac: brcmf_fw_map_chip_to_name: с использованием brcm / brcmfmac43430-sdio.bin для микросхемы 0x00a9a6 (43430) rev 0x000001
[10.377026] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[10.599523] brcmfmac: brcmf_c_preinit_dcmds: Версия микропрограммы = wl0: 7 августа 2017 г. 00:46:29 версия 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.600577] brcmfmac: brcmf_c_preinit_dcmds: версия CLM = API: 12.2 Данные: 7.11.15 Компилятор: 1.24.2 ClmImport: 1.24.1 Создание: 2014-05-26 10:53:55 Inc Данные: 9.10.41 Inc Компилятор: 1.29 .4 Inc ClmImport: 1.36.3 Создание: 2017-08-07 00:37:47
[126.642710] brcmfmac: управление питанием отключено
[139.249230] brcmfmac: brcmf_sdio_hostmail: Неизвестное содержимое данных почтового ящика: 0x40012
[141.751545] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[141.754973] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[144.311482] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[144.314959] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[144.314975] brcmfmac: brcmf_pno_clean: сбойный код -110
[151.831564] brcmfmac: brcmf_sdio_bus_rxctl: возобновляется по истечении времени ожидания
[151.835066] brcmfmac: brcmf_sdio_checkdied: ловушка микропрограммы в ключе
[151.835079] brcmfmac: brcmf_do_escan: ошибка (-110)
[151.835084] brcmfmac: brcmf_cfg80211_scan: ошибка сканирования (-110)

после:

thenry @ pi3portable : ~ $ dmesg | grep brcm
[10.115833] brcmfmac: чтение подписи F1 @ 0x18000000 = 0x1541a9a6
[10.134926] brcmfmac: brcmf_fw_map_chip_to_name: использование brcm / brcmfmac43430-sdio.bin для микросхемы 0x00a9a6 (43430) rev 0x000001
[10.135115] usbcore: зарегистрирован новый драйвер интерфейса brcmfmac
[10.367703] brcmfmac: brcmf_c_preinit_dcmds: Версия микропрограммы = wl0: 23 октября 2017 г. 03:55:53 версия 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[10.368419] brcmfmac: brcmf_c_preinit_dcmds: версия CLM = API: 12.2 Данные: 7.11.15 Компилятор: 1.24.2 ClmImport: 1.24.1 Создание: 2014-05-26 10:53:55 Inc Данные: 9.10.39 Inc Компилятор: 1.29 .4 Inc ClmImport: 1.36.3 Создание: 2017-10-23 03:47:14
[18.045308] brcmfmac: управление питанием отключено
thenry @ pi3portable : ~ $

Он продолжал работать через несколько загрузок, и теперь я использую его, подключенный по Wi-Fi к телефону samsung s4.
Спасибо за вашу помощь, привет, Тревор Генри.

Я думал, что последняя прошивка уже была в последних образах, поэтому ожидал, что обновление до 4.14 принесет последнюю версию прошивки. Вы создали собственное ядро?

Да - текущие образы Raspbian имеют прошивку 7.45.98.38 от 23 октября 2017 года.

Привет, нет, я не собирал ядро, я обновился с помощью rpi-update, и, как вы можете видеть, оно все еще работало с прошивкой от августа 2017 года после обновления.

rpi-update обновляет только ядро, прошивку и небольшое количество утилит, специфичных для VideoCore. Чтобы обновить все, включая прошивку WiFi, вы должны использовать apt-get upgrade / distupgrade.

Здравствуй,
Итак, у меня есть эта проблема, и она лучше с последней версией FW, 7.45.98.38, чем была, но у меня все еще есть проблемы.
Наблюдения
Если я загружаю малину, ничего не делая, то WLAN работает как надо.
Если я попытаюсь использовать клавиатуру или мышь bluetooth до включения WLAN, проблема не исчезнет, ​​соединение не будет установлено.
Если у меня есть соединение и я отключил / включил беспроводную сеть, тогда WLAN не подключается.
Если я оставлю WLAN включенным на ночь, соединение перестанет работать.
У меня есть три одинаковые настройки, и поведение на всех одинаковое.
Не знаю, имеет ли это значение, но мы используем WPA2 Enterprise, PEAP и MSCHAPv2

Эти проблемы возникают только при подключении устройств BT?

Да! Отключенный Bluetooth и подключенные USB-клавиатуры и мышь, а также WLAN подключились быстрее, чем я когда-либо видел.

Тем не менее, некоторые проблемы с сосуществованием тогда. Полагаю, нужно будет пометить Cypress.

Просто чтобы проверить, вы используете последнюю версию Raspbian? Или что-то новенькое?

@pelwell пинг

Описание: Raspbian GNU / Linux 9.4 (stretch)
Вам нужна дополнительная информация?

Зависает после:
14 мая 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD Поставщик EAP 0, выбран метод 25 (PEAP)

см. фрагмент журнала ниже

14 мая, 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.7887] устройство (wlan0): состояние интерфейса соискателя: отключен -> связывание
14 мая 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: Связано с 44: d9: e7: f7: d5: 34
14 мая, 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-STARTED Началась аутентификация EAP
14 мая, 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.9263] устройство (wlan0): состояние интерфейса запрашивающего: ассоциация -> ассоциированный
14 мая 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 25
14 мая 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD Поставщик EAP 0, выбран метод 25 (PEAP)
14 мая, 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0716] устройство (wlan0): активация: соединение (Wi-Fi) заняло слишком много времени
14 мая, 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0718] устройство (wlan0): изменение состояния: config -> need-auth (причина «нет») [50 60 0]
14 мая 15:44:24 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-DISCONNECTED bssid = 44: d9: e7: f7: d5: 34 reason = 3 locally_generated = 1
14 мая, 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0937] устройство (wlan0): Активация: (Wi-Fi) запрашивает новые секреты
14 мая, 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0959] sup-iface [0x1c438c0, wlan0]: соединение прервано (причина -3)

У меня такая же проблема с octoPi 0.14 (каждый пакет обновлен, последняя версия прошивки rpi, каждый плагин octoprint обновлен).

brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110

с этой установкой его 100% воспроизводимость. Обращение к веб-сайту octoprint на pi (первый доступ после загрузки) с моего активного samsung s4 (android 5.0.1, с использованием Chrome) или с моего планшета samsung 10inch note, а также android 5.xi guess and chrome убивает Wi-Fi, когда страница загружена наполовину.
К моему Pi3 не подключен кабель, Wi-Fi на канале 11 с wpa2.
Я попытался отключить питание Wi-Fi и безуспешно переключиться на канал Wi-Fi 6 (подсказки сверху), однако у меня было ощущение, что с каналом 6 было немного лучше.

Но вот интересный ключ к разгадке ошибки:
У меня нет проблем, когда я открываю сайт octopi / octoprint (на pi) с моей машины с Windows 10 или ubuntu 16 (с использованием хрома, кабельное соединение с маршрутизатором). Я предполагаю, что теперь это ошибка, связанная с Android, Samsung или Wi-Fi. И я думаю, что некоторое время назад читал что-то о проблемах с android / rpi.

Надеюсь это поможет. Если вам нужен тестер для какой-то версии, я бы попробовал.

Просто подумал, что я позвоню здесь и скажу, что мы также видели то, что похоже на киоски блокировки, связанные с WiFi, вокруг этого драйвера, которые могут быть связаны с другим SBC. Это не специфично для Raspberry PI.

Это тоже происходит со мной.

Настроить

• Pi 3B 1.2 (a02082)
• Ядро:

pi<strong i="10">@raspberrypi</strong>:~ $ uname -a
Linux raspberrypi 4.14.54-v7+ #1126 SMP Wed Jul 11 20:01:03 BST 2018 armv7l GNU/Linux

Запуск Raspbian версии 9.4:

pi<strong i="14">@raspberrypi</strong>:~ $ cat /etc/debian_version
9.4

Версия прошивки:

pi<strong i="18">@raspberrypi</strong>:~ $ /opt/vc/bin/vcgencmd version
Jul  9 2018 19:35:54
Copyright (c) 2012 Broadcom
version daa7178a0900fd9a743c019f9dad7889d531e71d (clean) (release)

wlan0 Управление питанием отключено:

pi<strong i="23">@raspberrypi</strong>:~ $ iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"VIRUS_2.4"
          Mode:Managed  Frequency:2.462 GHz  Access Point: D4:7B:B0:79:AF:A6
          Bit Rate=72.2 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=47/70  Signal level=-63 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:120  Invalid misc:0   Missed beacon:0

Я использую встроенный вайфай. К порту Ethernet ничего не подключено.

Система была обновлена ​​с использованием apt-get upgrade , apt-get dist-upgrade и rpi-update .

Что я вижу

По прошествии примерно часа работы пи становится недоступным из сети. Я не могу подключиться к Pi из своей локальной сети (ping и ssh не работают).

В dmesg я вижу, что получаю:

brcmfmac: power management disabled
...
snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned

Но ошибок нет.

Что-то интересное

Я заметил, что когда это происходит, если я подключаюсь к пи напрямую и пингую свой ноутбук, все возвращается к работе. Кроме того, время пинга немного странное - кажется, нужно немного времени, чтобы все «разогрелось»:

pi<strong i="40">@raspberrypi</strong>:~ $ ping 192.168.1.22
PING 192.168.1.22 (192.168.1.22) 56(84) bytes of data.
64 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=5024 ms
64 bytes from 192.168.1.22: icmp_seq=2 ttl=64 time=4010 ms
64 bytes from 192.168.1.22: icmp_seq=3 ttl=64 time=2971 ms
64 bytes from 192.168.1.22: icmp_seq=4 ttl=64 time=1932 ms
64 bytes from 192.168.1.22: icmp_seq=5 ttl=64 time=892 ms
64 bytes from 192.168.1.22: icmp_seq=6 ttl=64 time=5.63 ms
64 bytes from 192.168.1.22: icmp_seq=7 ttl=64 time=12.4 ms
64 bytes from 192.168.1.22: icmp_seq=8 ttl=64 time=5.59 ms
64 bytes from 192.168.1.22: icmp_seq=9 ttl=64 time=55.5 ms

Если кому-то понадобится дополнительная информация, я буду рад ее предоставить.

@bugok , установка беспорядочного сетевого интерфейса решает проблему? ( ifconfig wlan0 promisc ).

@quozl : Не помогло. Через некоторое время пинг начал давать сбой:

$ ping 192.168.1.80
PING 192.168.1.80 (192.168.1.80): 56 data bytes
ping: sendto: No route to host
ping: sendto: Host is down
Request timeout for icmp_seq 0
...

Ответный отчет: моя проблема, похоже, решена и, похоже, не связана с проблемой в этой теме.

Подробности здесь , но суть в том, что я установил статический IP-адрес на самом Pi (в /etc/dhcpcd.conf ). После определения статического IP-адреса в маршрутизаторе, удаления конфигурации статического IP-адреса из /etc/dhcpcd.conf и перезагрузки - все вроде работает.

Быстрое обновление: эта проблема (ошибка «Неизвестное содержимое данных почтового ящика», сопровождающаяся полной блокировкой беспроводной сети) сохраняется в последней прошивке со всеми установленными обновлениями (dist-upgrade).

Изменение одной строки в файле hostapd.conf (согласно моему предыдущему комментарию) по- прежнему устраняет для меня проблему.

Использование Rpi3B с ядром 4.14.52-v7 (raspberrypi-kernel 1.20180703-1) и (firmware-brcm80211 1: 20161130-3 + rpt4)
Я также все еще сталкиваюсь с проблемой, когда wlan зависает (90 устройств, из которых 2 в день имеют проблему). В некоторых случаях адаптер отсутствует, а в других он не отвечает. Я не использую Pi в режиме AP, просто
Я пробовал перепрошить как в RPi-3B +, но безуспешно.

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

Я постоянно сталкивался с той же проблемой на ранее работающем Pi 3. Я понял, что единственное изменение, которое я сделал, - это подключение сенсорного ЖК-экрана, потребляющего энергию от Pi. Когда я отключил сенсорный экран, WiFi работал нормально. Так что это определенно похоже на власть. Это использовало официальный адаптер переменного тока Raspberry.

Это очень интересные данные. Это был один из наших ЖК-дисплеев?

@ JamesH65 У меня также начались сбои Wi-Fi и всплески задержки после того, как я установил https://www.waveshare.com/wiki/5inch_HDMI_LCD , у меня есть 3b + rpi cam v2 и дисплей, подключенный к 3-амперному блоку питания, я не получаю никаких предупреждений о питании ...

Привет, ребята, есть новости по этому поводу? Я пытался использовать raspivid на нулевом значении W с потоком TCP, и через несколько минут мой Wi-Fi исчез, я думаю, это та же проблема.

У меня не было этой проблемы как минимум год или около того. Я начинаю все чаще думать, что это может быть просто связано с источником питания USB, не обеспечивающим достаточного количества усилителей, но я хотел бы получить доказательство того, что это не так. В качестве теста попробуйте подключить USB-кабель к адаптеру с более мощным усилителем, особенно если вы можете легко воспроизвести проблему.

Я совершенно уверен, что это не связано напрямую с усилителем, потому что я использую только источники питания на 2 ампера. в основном старые зарядные устройства самсунг. однако это может быть пульсация или что-то в этом роде с блоком питания или оборудованием Pi.Von meinem Samsung Gerät gesendet.

-------- Ursprüngliche Nachricht --------
Фон: rajid [email protected]
Дата: 07.04.2019 02:15 (GMT + 01: 00)
An: raspberrypi / linux [email protected]
Копия: "A. Binzxxxxxx" [email protected] , комментарий [email protected]
Betreff: Re: [raspberrypi / linux] wlan зависает в raspberry pi 3 / PiZeroW (не
3B +) (# 1342)

У меня не было этой проблемы как минимум год или около того. Я начинаю все чаще думать, что это может быть просто связано с источником питания USB, не обеспечивающим достаточного количества усилителей, но я хотел бы получить доказательство того, что это не так. В качестве теста попробуйте подключить USB-кабель к адаптеру с более мощным усилителем, особенно если вы можете легко воспроизвести проблему.

- Вы получили это, потому что прокомментировали. Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите тред.
{"api_version": "1.0", "publisher": {"api_key": "05dde50f1d1a384dd78767c55493e4bb", "name": "GitHub"}, "entity": {"external_key": "github / raspberrypi / linux", "title ":" raspberrypi / linux "," subtitle ":" Репозиторий GitHub "," main_image_url ":" https://github.githubassets.com/images/email/message_cards/header.png "," avatar_image_url ":" https: //github.githubassets.com/images/email/message_cards/avatar.png "," action ": {" name ":" Открыть в GitHub "," url ":" https://github.com/raspberrypi/linux "}}," updates ": {" snippets ": [{" icon ":" PERSON "," message ":" @rajid в # 1342: у меня не было проблемы как минимум год или около того. Я Я начинаю все чаще думать, что это может быть просто связано с тем, что источник питания USB не обеспечивает достаточного количества усилителей, но я хотел бы получить доказательство того, что это не так. В качестве теста попробуйте подключить USB-кабель к адаптеру с более мощным усилителем, особенно если вы можете легко воспроизвести проблему. "}]," action ": {" name ":" View Issue "," url ":" https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753 "}}}
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"possibleAction": {
"@type": "ViewAction",
"target": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"name": "Просмотреть выпуск"
},
"description": "Посмотреть эту проблему на GitHub",
"publisher": {
"@type": "Организация",
"name": "GitHub",
"url": " https://github.com "
}
}
]

У меня все еще возникает проблема, но не так часто - может быть, через несколько недель - и я больше не могу надежно вызвать ее, подключившись с устройств Samsung Android.

На самом деле я питаю Pi zero w от источника питания USB на 3 А и кабеля USB длиной 15 см, используемого для зарядки блоков питания (без линий передачи данных, только линии электропередач)

Если я использую соединение регулярно (как обычный пользователь), оно работает нормально, но если я транслирую MJPEG со скоростью 5 Мбит / с, он вылетает через несколько минут, я вижу ошибку почтового ящика (или аналогичную) в journalct (не могу вспомнить, как я вне дома в течение недели), ssh останавливается, нет ping, Wi-Fi падает, iwconfig показывает результаты за несколько секунд, а они почти пусты.

@vascojdb Если вы используете Pi в качестве точки доступа (режим AP), этот обходной путь (см. жирный текст внизу) должен решить вашу проблему.

Дайте нам знать?

Нет, он не в режиме AP, я подключен к домашней сети Wi-Fi 2,4 ГГц

Здравствуйте,

У меня проблема с Wi-Fi для синхронизации времени при запуске с NTP-сервером с помощью LibreELEC на RPI3B +, начиная с версии 9.0.0.
После некоторых обсуждений с некоторыми членами команды LE ( см. Здесь ) проблема была исправлена ​​после этого изменения .

Но похоже, что это обходное решение было отменено, и проблема все еще существует.
Можно ли снова исправить?

Некому ответить или обострить этот вопрос?

Та же проблема. Есть новости по этому поводу?

Apr 29 22:47:04 raspberrypi kernel: [37515.093582] brcmfmac: brcmf_sdio_hostmail: mailbox indicates firmware halted

Apr 29 22:47:06 raspberrypi kernel: [37517.524316] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout

Apr 29 22:47:06 raspberrypi kernel: [37517.524776] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle

Apr 29 22:47:06 raspberrypi kernel: [37517.524792] brcmfmac: brcmf_run_escan: error (-110)

Apr 29 22:47:06 raspberrypi kernel: [37517.524807] brcmfmac: brcmf_cfg80211_scan: scan error (-110)

Пытался пока отключить управление питанием. Это старая ошибка повторно введена?

https://patchwork.kernel.org/patch/9948825/

Та же проблема. Есть новости по этому поводу?

Это сообщение говорит только о том, что прошивка чипа wifi разбилась. Ядро Linux ничего не может сделать, кроме перезагрузки. Полезный отчет об ошибке содержит следующую информацию:

Какую прошивку wifi вы используете?
Как у вас работает Wi-Fi (точка доступа, клиент, ...)?
Можете ли вы воспроизвести это в течение определенного времени?
Какие еще устройства Wi-Fi задействованы?

это в моем последнем комментарии, так как тогда он был воспроизводимым, но его плохо воспроизводить, и он изменяется вместе с изменениями программного обеспечения, когда он падает.

-------- Ursprüngliche Nachricht --------
Фон: Стефан Варен [email protected]
Дата: 01.05.2020 10:21 (GMT + 01: 00)
An: raspberrypi / linux [email protected]
Копия: "A. Binzxxxxxx" [email protected] , комментарий [email protected]
Betreff: Re: [raspberrypi / linux] wlan зависает в raspberry pi 3 / PiZeroW (не
3B +) (# 1342)

Та же проблема. Есть новости по этому поводу?

Это сообщение говорит только о том, что прошивка чипа wifi разбилась. Ядро Linux ничего не может сделать, кроме перезагрузки. Полезный отчет об ошибке содержит следующую информацию:
Какую прошивку wifi вы используете?
Как у вас работает Wi-Fi (точка доступа, клиент, ...)?
Можете ли вы воспроизвести это в течение определенного времени?
Какие еще устройства Wi-Fi задействованы?

- Вы получили это, потому что оставили комментарий. Ответьте на это письмо напрямую, просмотрите его на GitHub или откажитесь от подписки.
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"possibleAction": {
"@type": "ViewAction",
"target": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"name": "Просмотреть выпуск"
},
"description": "Посмотреть эту проблему на GitHub",
"publisher": {
"@type": "Организация",
"name": "GitHub",
"url": " https://github.com "
}
}
]

Та же проблема. Есть новости по этому поводу?

Apr 29 22:47:04 raspberrypi kernel: [37515.093582] brcmfmac: brcmf_sdio_hostmail: mailbox indicates firmware halted

Apr 29 22:47:06 raspberrypi kernel: [37517.524316] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout

Apr 29 22:47:06 raspberrypi kernel: [37517.524776] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle

Apr 29 22:47:06 raspberrypi kernel: [37517.524792] brcmfmac: brcmf_run_escan: error (-110)

Apr 29 22:47:06 raspberrypi kernel: [37517.524807] brcmfmac: brcmf_cfg80211_scan: scan error (-110)

Пытался пока отключить управление питанием. Это старая ошибка повторно введена?

https://patchwork.kernel.org/patch/9948825/

Нет никакого решения, но у меня точно такая же проблема на Rpi4 с последней установленной прошивкой. Я откатил его до образа SD-карты, который сделал несколько месяцев назад, и проблема исчезла. Поскольку я использую hostapd, я считаю, что одно из этих обновлений или их комбинация сломали меня:

Список $ apt - обновляемый
Объявление ... Готово
...
hostapd / stable 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u2 armhf [возможность обновления с: 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u1]
firmware-brcm80211 / testing 1: 20190114-1 + rpt6 все [возможность обновления с: 1: 20190114-1 + rpt4]
raspberrypi-kernel / testing 1.20200212-1 armhf [возможность обновления с: 1.20200114-1]
...

Я также попытался отключить управление питанием (и подтвердил, что оно отключено с помощью iwconfig), но это не повлияло на запуск hostapd. Мне придется отказаться от обновлений прошивки, пока они не будут исправлены, поскольку мы рассылаем многие из них и нуждаемся в стабильных точках доступа для наших клиентов.

Любой, кто сталкивается с ошибками прошивки, тайм-аутом (-110) и т. Д. - включите отладку прошивки, чтобы мы могли собрать некоторые данные.

Добавьте brcmfmac.debug=0x100000 в /boot/cmdline.txt, поместив его в одну длинную строку, затем перезагрузитесь. Запуск dmesg | grep brcmfmac должен привести к следующему выводу:

[    7.650239] brcmfmac: CONSOLE: d 0
[    7.650256] brcmfmac: CONSOLE: 000000.063 wl0: Broadcom BCM4345 802.11 Wireless Controller 7.45.202 (r724630 CY)
[    7.650270] brcmfmac: CONSOLE: 000000.064 TCAM: 256 used: 252 exceed:0
[    7.650284] brcmfmac: CONSOLE: 000000.065 reclaim section 1: Returned 122844 bytes to the heap
[    7.650297] brcmfmac: CONSOLE: 000000.065 reclaim section 4: Returned 44 bytes to the heap
[    7.650310] brcmfmac: CONSOLE: 000000.065 sdpcmd_dpc: Enable
...

Тогда продолжайте как обычно. Когда прошивка brcmfmac умирает, запишите вывод dmesg в файл и прикрепите его (или ссылку на pastebin и т. Д.) Сюда.

Так как сбой вызывает другие сообщения ядра, существует опасность того, что полезный вывод будет потерян до того, как у вас появится возможность его захватить. Способ избежать этого - оставить оболочку постоянно сохранять сообщения ядра в файл:

$ dmesg -w > kernel_log.txt &

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

Запуск hostapd в режиме AP, wireguard и frr. Также используется сотовая шляпа Sixfab.

[46972.803286] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[46975.363309] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[46975.363322] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[47292.885392] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47295.445423] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47295.445436] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[47602.007429] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47604.567452] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47604.567465] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[47830.248947] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47838.328989] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47887.049300] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
[47892.649358] brcmfmac: brcmf_cfg80211_stop_ap: SET SSID error (-110)
[47895.209353] brcmfmac: brcmf_cfg80211_stop_ap: BRCMF_C_DOWN error -110
[47897.769374] brcmfmac: brcmf_cfg80211_stop_ap: setting AP mode failed -110
[47902.889420] brcmfmac: brcmf_cfg80211_stop_ap: BRCMF_C_UP error -110
[47905.449430] brcmfmac: brcmf_set_mpc: fail to set mpc

Linux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux

Я также могу воссоздать это в ветке 5.4. FWIW, я всегда могу вручную вызвать эту ошибку, скопировав большой файл (> 400 МБ) на мой Pi Zero W.

Если это помогает, моя версия ядра соответствует этой фиксации - https://github.com/raspberrypi/linux/commit/3c860a6fd128e7cf1c39b3f51258a2a078d1a1a4

# uname -a
Linux pichime-1-c93bb27a 5.4.50 #1 Sun Jul 12 20:53:57 CDT 2020 armv6l GNU/Linux

# dmesg | grep brcmfmac | grep Firmware
[    5.319134] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: May  2 2019 02:39:18 version 7.45.98.83 (r714225 CY) FWID 01-e539531f

Журнал сбоев с отладкой:

[  340.321646] ieee80211 phy1: _brcmf_set_multicast_list: Setting mcast_list failed, -110
[  342.881642] ieee80211 phy1: _brcmf_set_multicast_list: Setting allmulti failed, -110
[  345.441616] ieee80211 phy1: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[  348.001649] ieee80211 phy1: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -110
[  358.241623] ieee80211 phy1: brcmf_cfg80211_disconnect: error (-110)
[  363.361640] ieee80211 phy1: _brcmf_set_multicast_list: Setting mcast_list failed, -110
[  371.041641] ieee80211 phy1: _brcmf_set_multicast_list: Setting allmulti failed, -110
[  373.601642] ieee80211 phy1: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -110
[  376.161620] ieee80211 phy1: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[  376.170775] ieee80211 phy1: brcmf_cfg80211_reg_notifier: Country code iovar returned err = -110
[  383.841632] ieee80211 phy1: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[  383.851056] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
[  386.401643] ieee80211 phy1: _brcmf_set_multicast_list: Setting mcast_list failed, -110
[  388.961642] ieee80211 phy1: _brcmf_set_multicast_list: Setting allmulti failed, -110
[  391.521632] ieee80211 phy1: brcmf_cfg80211_set_power_mgmt: error (-110)
[  394.081651] ieee80211 phy1: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -110
[  409.521619] ieee80211 phy1: brcmf_run_escan: error (-110)
[  409.527146] ieee80211 phy1: brcmf_cfg80211_scan: scan error (-110)
[  412.081641] ieee80211 phy1: _brcmf_set_multicast_list: Setting mcast_list failed, -110
[  414.641643] ieee80211 phy1: _brcmf_set_multicast_list: Setting allmulti failed, -110
[  417.201652] ieee80211 phy1: brcmf_run_escan: error (-110)
[  417.207175] ieee80211 phy1: brcmf_cfg80211_scan: scan error (-110)
[  419.761655] ieee80211 phy1: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -110
[  424.881645] ieee80211 phy1: brcmf_run_escan: error (-110)
[  424.887168] ieee80211 phy1: brcmf_cfg80211_scan: scan error (-110)
[  430.001645] ieee80211 phy1: _brcmf_set_multicast_list: Setting mcast_list failed, -110
[  432.561651] ieee80211 phy1: brcmf_run_escan: error (-110)
[  432.567172] ieee80211 phy1: brcmf_cfg80211_scan: scan error (-110)
[  435.121637] ieee80211 phy1: _brcmf_set_multicast_list: Setting allmulti failed, -110
[  437.681648] ieee80211 phy1: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -110
[  440.241651] ieee80211 phy1: brcmf_run_escan: error (-110)
[  440.247173] ieee80211 phy1: brcmf_cfg80211_scan: scan error (-110)
[  447.921623] ieee80211 phy1: brcmf_run_escan: error (-110)
[  447.927145] ieee80211 phy1: brcmf_cfg80211_scan: scan error (-110)

Во время вышеуказанного сбоя я запускал ifdown и ifup, которые не восстанавливали Wi-Fi. Единственное решение - либо перезагрузить пи, либо rmmod & modprobe brcmfmac.

Стоит отметить, что это происходит при выключенном управлении питанием, так как у меня в файле интерфейсов есть следующее:

pre-up iwconfig wlan0 power off