EDIMAX EW-7811UN .... Eso está usando el chipset rtl8188cus, IIRC.

Si aún no tiene uno, cree /etc/modprobe.d/8192cu.conf, con contenido ....

Deshabilitar la administración de energía

opciones 8192cu rtw_power_mgnt = 0 rtw_enusbss = 0

El rpi3 en realidad usa el controlador brcmfmac para el wifi incorporado
hay un problema que requiere que se apague el ahorro / administración de energía

Creo que los kernels raspian más nuevos ya han parcheado esto para deshabilitar el ahorro de energía de forma predeterminada, pero no creo que esté en esta rama 4.5 todavía

Lo que estoy haciendo en este momento (instalación de gentoo) es lo siguiente en el arranque para deshabilitar el ahorro de energía en la tarjeta wifi

iw wlan0 desactivó power_save

El rpi3 en realidad usa el controlador brcmfmac para el wifi incorporado

Sí, lo sé. Oh ya veo. Ya no usa el dongle EDIMAX EW-7811UN. Solía ​​usarlo con RPi2.

sí, ya no uso el wifi usb, ¿cómo configuro la línea cmd para apagar la administración de energía?
crontab
@reboot iw wlan0 configurar power_save apagado

No estoy seguro para raspian, ya que estoy usando gentoo será diferente

Pruebe esto: https://gist.github.com/mkb/40bf48bc401ffa0cc4d3

Parece que funciona desde que apagué la administración de energía. No he tenido otra falla de wlan.

Solo para mencionarlo, para reiniciar el wlan automáticamente después de un bloqueo, esto aquí ayuda:
sudo cp /etc/wpa_supplicant/ifupdown.sh /etc/ifplugd/action.d/ifupdown

Por cierto, el último kernel de actualización de apt-get tiene la administración de energía deshabilitada de forma predeterminada.
@ dh-connect, ¿esto le funciona si elimina la solución actual?

sigue fallando después de la última actualización, ahora aparece este error en syslog:
brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!

Cuando dice que está fallando, ¿hay otros síntomas además del mensaje de error?

no, solo el que he publicado aquí, pero está en el registro muchas veces

el wlan deja de funcionar, todavía puedo trabajar con él, pero para que el wlan vuelva a funcionar, tengo que reiniciarlo

Gracias, creo que "wlan deja de funcionar" cuenta como un síntoma.

He intentado algunas cosas, pero todavía se estropea

para responder a la pregunta anterior cuando recupere la configuración
Apagado inalámbrico en / etc / network / interfaces
y reiniciar
y verifique la configuración con iwconfig
la administración de energía está nuevamente encendida, por lo que, de manera predeterminada, no diría que esto está deshabilitado, así que dejaré la configuración

Intenté eso con el kernel 4.1.19 y ahora también con el kernel 4.1.20 ... sin cambios

cuando el wlan se estrelló y trato de volver a encenderlo con ifdown e ifup wlan0, obtengo esto:
Error de solicitud inalámbrica "Establecer administración de energía" (8B2C): SET falló en el dispositivo wlan0; Intercambio no válido.

También obtuve algunos errores más en syslog:

dhcpcd [532]: wlan0: xxx: caducó la opción 25

21 de marzo 17:29:35 kernel de raspberrypi: [6627.337503] brcmfmac: _brcmf_set_multicast_list: Error al configurar mcast_list, -52
21 de marzo 17:29:36 raspberrypi wpa_supplicant [6318]: wpa_supplicant inicializado correctamente
21 de marzo 17:29:36 raspberrypi dhcpcd [532]: wlan0: operador perdido

21 de marzo 17:29:43 kernel de raspberrypi: [6635.337616] brcmfmac: _brcmf_set_multicast_list: Error al configurar mcast_list, -52

21 de marzo 17:29:45 kernel de raspberrypi: [6637.337588] brcmfmac: brcmf_do_escan: error (-52)
21 de marzo 17:29:45 kernel de raspberrypi: [6637.337602] brcmfmac: brcmf_cfg80211_scan: error de escaneo (-52)

21 de marzo 17:29:47 kernel de raspberrypi: [6639.337596] brcmfmac: _brcmf_set_multicast_list: Error al configurar allmulti, -52
21 de marzo 17:29:49 kernel de raspberrypi: [6641.337632] brcmfmac: _brcmf_set_multicast_list: Error al configurar BRCMF_C_SET_PROMISC, -52

¿Hay algo más que pueda probar?

también estos:

21 de marzo 21:26:55 raspberrypi dhcpcd [526]: wlan0: xxx: caducó la opción 25
21 de marzo 21:28:54 kernel de raspberrypi: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012
21 de marzo 21:30:16 raspberrypi dhcpcd [526]: wlan0: xxx es inalcanzable, expirando

No me sorprende que iwconfig piense que el dispositivo tiene habilitado el ahorro de energía; lo bloqueé dentro del propio controlador y el estado se guarda en las capas superiores o se requiere otro cambio para informarlo correctamente. De cualquier manera, la evidencia es fuerte de que hemos evitado los errores de ahorro de energía, pero aún quedan algunos otros problemas.

¿Tiene cifras aproximadas sobre el tiempo de falla y aproximadamente cuántos datos podrían haberse transferido (desde ifconfig)?

sí, lo hago, cuando solo tengo el servidor web funcionando con poco tráfico (menos de 100 MB), dura uno o dos días, cuando transfiero archivos de datos grandes como 1 GB de wlan se bloquea en 1 hora

¿Hay algo que pueda proporcionar para ayudar a encontrar el error?

aquí hay algún error de syslog:

29 de marzo 14:20:56 raspberrypi dhcpcd [535]: wlan0: xxx: caducó la opción 25
29 de marzo 14:30:15 raspberrypi dhcpcd [535]: wlan0: xxx es inalcanzable, expirando
29 de marzo 17:18:42 kernel de raspberrypi: [186148.102420] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 de marzo 17:18:43 kernel de raspberrypi: [186149.101045] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 de marzo 17:18:43 kernel de raspberrypi: [186149.101145] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 de marzo 17:18:44 kernel de raspberrypi: [186150.101209] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 de marzo 17:18:50 raspberrypi wpa_supplicant [478]: wlan0: CTRL-EVENT-DISCONNECTED bssid = xxx motivo = 3 local_generado = 1
29 de marzo 17:18:50 kernel de raspberrypi: [186156.181033] brcmfmac: brcmf_cfg80211_disconnect: error (-52)
29 de marzo 17:18:52 kernel de raspberrypi: [186158.181028] brcmfmac: send_key_to_dongle: error wsec_key (-52)
29 de marzo 17:18:54 kernel de raspberrypi: [186160.181046] brcmfmac: send_key_to_dongle: error wsec_key (-52)
29 de marzo 17:18:56 kernel de raspberrypi: [186162.181048] brcmfmac: send_key_to_dongle: error wsec_key (-52)
29 de marzo 17:18:58 kernel de raspberrypi: [186164.181049] brcmfmac: send_key_to_dongle: error wsec_key (-52)
29 de marzo 17:18:58 kernel de raspberrypi: [186164.185477] cfg80211: Llamando a CRDA para actualizar el dominio regulatorio mundial
29 de marzo 17:18:58 raspberrypi dhcpcd [535]: wlan0: operador perdido
29 de marzo 17:18:58 raspberrypi wpa_supplicant [7354]: wpa_supplicant inicializado correctamente
29 de marzo 17:18:58 kernel de raspberrypi: [186164.314511] brcmfmac: brcmf_cfg80211_reg_notifier: no es un código ISO3166
29 de marzo 17:18:58 kernel de raspberrypi: [186164.314541] cfg80211: Dominio regulatorio mundial actualizado:
29 de marzo 17:18:58 kernel de raspberrypi: [186164.314548] cfg80211: región maestra DFS: no establecido
29 de marzo 17:18:58 kernel de raspberrypi: [186164.314555] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
29 de marzo 17:18:58 núcleo de raspberrypi: [186164.314565] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N / A, 2000 mBm), (N / A)
29 de marzo 17:18:58 kernel de raspberrypi: [186164.314573] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N / A, 2000 mBm), (N / A)
29 de marzo 17:18:58 núcleo de raspberrypi: [186164.314581] cfg80211: (2474000 KHz - 2494000 KHz a 20000 KHz), (N / A, 2000 mBm), (N / A)
29 de marzo 17:18:58 kernel de raspberrypi: [186164.314592] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (N / A)
29 de marzo 17:18:58 kernel de raspberrypi: [186164.314602] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 s)
29 de marzo 17:18:58 núcleo de raspberrypi: [186164.314611] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N / A, 2000 mBm), (0 s)
29 de marzo 17:18:58 núcleo de raspberrypi: [186164.314645] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N / A, 2000 mBm), (N / A)
29 de marzo 17:18:58 kernel de raspberrypi: [186164.314654] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 0 mBm), (N / A)

Gracias por la oferta, pero ahora está en manos de Broadcom.

¿Alguna actualización de Broadcom si se trata de un error que se solucionará? Ahora tengo una configuración de trabajo cron para bajar y subir wlan0 cuando falla al hacer ping.

actualización rápida por mi parte, pude solucionar el problema parece estar relacionado con el controlador, instalé Ubuntu MATE 16.04 con kernel 4.4.8 y no he tenido ningún problema con wifi desde

Quiero decir que anuncian: "Ubuntu MATE 16.04 también tiene Bluetooth y Wifi en pleno funcionamiento en la Raspberry Pi 3", lo cual parece cierto

tal vez también funcione con una nueva versión de Debian, que no puedo decir

@ juched78 ¿Está ejecutando un kernel 4.4? De lo contrario, ejecute sudo rpi-update para obtener la última versión 4.4.8 y ver si tiene el mismo problema.

Los controladores de Broadcom han cambiado significativamente desde 4.1, y nuestro árbol 4.4 incluye puertos posteriores de algunas correcciones que entraron en 4.5. No tengo conocimiento de ningún error sobresaliente aparte de la falla al despertar del sueño (la administración de energía aún está deshabilitada): los canales 12 y 13 se pueden usar donde está permitido y el modo Ad Hoc no se bloquea, pero aún puede haber problemas al acecho .

Oh, todavía hay un error reportado en 4.4.8: aparentemente, el uso intensivo de hostapd puede provocar una advertencia del kernel (consulte https://github.com/raspberrypi/linux/issues/1375).

Estoy corriendo:
Linux XXX 4.4.8-v7 + # 880 SMP Vie 22 de abril 21:55:04 BST 2016 armv7l GNU / Linux

27 de abril de 2016 11:06:18
Copyright (c) 2012 Broadcom
versión 9b52ab7b475f4a056658fd2d95d2440b32167390 (limpia) (versión)

Con mi Netgear R7000 ejecutando Shibby Tomato, alrededor de 2 días en las caídas de wifi, y en los registros del sistema veo:

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

Entonces parece que nunca se reconecta ...

El uso de sudo ifdown wlan0 seguido de sudo ifup wlan0 devuelve mi conexión.

Recién actualizado a:
Linux JuchePi 4.4.8-v7 + # 881 SMP Sáb 30 de abril 12:16:50 BST 2016 armv7l GNU / Linux

No estoy seguro de qué es diferente del 22 al 30. Supervisaré la conexión.

Mi RPi 3 también tuvo ese problema. Recibí algunos mensajes de kernel diferentes. Principalmente uno de los siguientes.
Después de eso, puedo hacer que el WiFi funcione, bajar wlan0 y luego subirlo no ayuda.

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)

La frambuesa se alimenta del adaptador de corriente original para la versión 3. Estoy ejecutando el último OSMC:
$ uname -a
Linux osmc 4.4.8-3-osmc # 1 SMP PREEMPT Domingo 1 de mayo 18:57:43 UTC 2016 armv7l GNU / Linux

Todavía monitoreando. Hice que openhab se desconectara después de ejecutar 3 días, pero por alguna razón todavía podía usar SSH en el Pi, lo que generalmente no podía. La parte superior de la hora y el script wifi se ejecutaron para desactivar y activar la conexión y luego se volvió a conectar a mi organización de openhab. Impar. Seguirá mirando.

También estoy experimentando el mismo problema: seguimiento de dmesg de la siguiente manera:

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)

Uso:

rp3 se está utilizando como enrutador / punto de acceso

La duración de la conectividad parece aleatoria: he tenido hasta dos semanas y tan mala como unos pocos minutos. Últimamente sale cada 20 minutos más o menos. Bajar wlan0 y hacer una copia de seguridad no resuelve el problema; se requiere un reinicio completo.

El problema parece agravarse al transmitir Netflix desde mi AppleTV. Aunque este no fue el caso cuando tuve las dos semanas de tiempo de actividad.

Estoy en 4.4.10-v7 +

Cambié el canal de 13 a 6 para verificar si ese podría ser el problema (había algunos defectos en los canales altos) y desde entonces no he tenido un freez de WiFi. Pero eso podría ser una coincidencia ...

Cambiar los canales del punto de acceso no ayudó. WiFi todavía se rompe. Las últimas veces tuve que reiniciar varias veces seguidas para que funcionara.

Experimento este problema específicamente cuando trato de hacer una transferencia SFTP entre el rpi3 y mi teléfono Galaxy S5. Cuando trato de realizar la misma transferencia desde mi computadora portátil, todo funciona sin problemas.

Ejecutando el último kernel de rpi-update:

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

Mensaje de error de syslog:

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

Parece que la única solución después de este error es reiniciar.

El mío ha abandonado la red dos veces la semana pasada. La primera vez que tenía prisa, simplemente desconecté y reinicié. Pocos días después sucedió nuevamente, se reinició nuevamente y luego ejecutó actualizaciones completas del sistema (incluido el firmware) y monitoreará. Hágalo montar sin un monitor cerca, por lo que obtener detalles sobre el error requiere más esfuerzo :)

El mismo problema aqui. Siempre se congela cuando se transfieren archivos grandes mediante sftp. Solo reiniciando para resolver

Este problema puede estar relacionado con https://github.com/raspberrypi/linux/issues/1313

Broadcom dice que # 1313 no es un problema, y ​​el último kernel ya no muestra esos mensajes.

No he podido reproducir este problema. ¿Alguien ha podido capturar un seguimiento de paquetes en el momento del error?

Si alguien tiene tiempo para hacer más pruebas con un módulo de controlador habilitado para depuración, sería muy apreciado:

1) Ejecute sudo rpi-update y reinicie. Esto es para que su kernel esté al mismo nivel que el mío para que el módulo sea compatible.

2) Descargue e instale el módulo de controlador actualizado:

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

Reinicie para activar los nuevos módulos.

3) Use su Pi como de costumbre, luego, si su WiFi se congela, ejecute:

dmesg > wifi_freeze.txt

y cárguelo en su sitio de pegado favorito (o cree un Gist). Uno o dos troncos deberían ser suficientes.

Para restaurar la versión original del módulo:

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

Gracias por adelantado.

Espere un momento mientras verificamos que la salida de depuración realmente esté habilitada.

También necesitará habilitar una función de depuración en el controlador:

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

He modificado las instrucciones anteriores.

Después de reiniciar, la salida de dmesg debería incluir algo como esto:

[   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 después de ejecutar tus instrucciones ya no tengo wifi ...

root @ pi3b : / home / pi # dmesg | grep brcmf
[15.582665] brcmfmac: símbolo desconocido brcmu_dbg_hex_dump (err 0)
[15.613709] brcmfmac: símbolo desconocido brcmu_dbg_hex_dump (err 0)

Prueba esto:

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

Y reinicia.

wlan0 no se asocia.
wireless.txt
(en uno de los muchos reinicios vi una asociación durante unos minutos, sin embargo, no la capté (todavía) en dmesg)

Parece que el problema se resolvió actualizando de 4.4.11-v7 + a 4.4.15-v7 +

Intenté recrear los problemas que tenía con las transferencias SFTP desde un teléfono Android, pero no veo ningún problema en este momento.

@pelwell después de una larga espera, wlan0 logró asociarse; dmesg adjunto al registro anterior:
wireless.txt
esperando ahora la congelación o la pérdida de asociación
espero que esto sea útil

@pelwell rápidamente perdió la conexión de nuevo; adjunto dmesg a:
wireless.txt

Gracias. Fue lento para mí la primera vez. He estado ocupado obteniendo un Raspbian limpio y aplicando los parches para intentar reproducir el problema; continuaré de todos modos.

@pelwell
wireless.txt
y reasociado de nuevo: añadido dmesg de nuevo
quieres que continúe

@pelwell : asociación perdida de nuevo
wireless_associationloss.txt

@pelwell
se enciende / apaga irregularmente
wireless_associationloss.txt

Creo que será mejor que vuelvas a cambiar ahora antes de que mi bandeja de entrada se desborde.

Okay; Volveré a mi dongle MT7601U de 3 €. ;)

Gracias por su ayuda hasta ahora,

Acabo de encontrar este problema, ¿puedo confirmar que es similar a lo que estoy viendo? He configurado un RPi 3 como punto de acceso y, de vez en cuando, no puedo conectarme a él. Puedo conectarme a través de la conexión por cable y veo que wlan0 todavía tiene la dirección IP correcta, pero la única forma de que el punto de acceso vuelva a funcionar es reiniciar. Veo rastros de pila como este en /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 ]---

Mi kernel es 4.4.13-v7 + y acabo de ejecutar rpi-update por primera vez, así que aún no sé si eso ayudará.

Me pregunto si esto podría estar relacionado, o quizás un problema separado
https://www.youtube.com/watch?v=_D_fi_ck9Vo

Mi RPI3 funcionó sin problemas a través de WiFi hasta que lo actualicé a la última versión de udev ...

Ahora, ya no se conecta ...

También instalé módulos parcheados de Pelwell pero no tuvimos éxito: simplemente no se conecta ...

Avísame si puedo ayudar

Mi mejor,
Mimmo

@ dh-connect ¿se ha resuelto su problema? Si es así, cierre este problema. Gracias.

Estoy trabajando con lan desde entonces, no he probado wlan

Hola,

Tengo lo que parece ser el mismo problema con mi rpi 3. He vuelto a usar el dongle usb wifi oficial de RPI, que es sólido como una roca, pero el wifi integrado se apaga después de ~ 20 horas de conectividad con este tipo de mensajes. en syslog

brcmfmac: brcmf_cfg80211_reg_notifier: no es un código ISO3166
cfg80211: Dominio regulatorio mundial actualizado:
cfg80211: región maestra DFS: no establecida

esto es en el último raspbian, último firmware

¿Es posible volver a abrir este problema?
¿Por qué estaba cerrado?

Estoy trabajando con lan desde entonces, no he probado wlan
dh-connect cerró esto hace 13 días

Esta no es una solución que valga la pena cerrar el problema ...

Todavía tengo el problema y puedo reproducir el error.

Mi parte relevante de dmesg es:

[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

Me encuentro con el mismo problema que @jrmhaig y actualizado ahora tengo

$ 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

Configura hostapd con un puente.

/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

/ etc / network / interfaces

# 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

Para las personas con problemas de WiFi, Cypress (antes Broadcom) nos ha proporcionado módulos de depuración para ayudar a diagnosticar los problemas. Debido a que los módulos son específicos de la versión del kernel, primero deberá actualizar (o posiblemente revertir) a una versión de firmware específica:

sudo rpi-update b0ef6e25679d3612a980708cf4c3907ce6e13e84
sudo shutdown -r now

Ahora puede descargar e instalar los módulos de depuración:

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

El comando final ejecutará el script de instalación, que copia los módulos originales a un lado antes de reemplazarlos con las versiones de depuración. Ejecutar el comando nuevamente volverá a las versiones originales.

Después de la instalación, reinicie su Pi 3; ahora dmesg | grep brcmfmac mostrará un mensaje de diagnóstico como este:

[    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..

Cuando encuentre un problema, use dmesg > wifidbg.txt para capturar el rastreo de un archivo, junto con cualquier otro mensaje del kernel, luego cargue el archivo en algún lugar (gist, pastebin, dropbox, etc.) y publique un enlace junto con una descripción de lo que estaba haciendo cuando ocurrió el error.

por favor actualice mi memoria: qué comando usar para volver a firnmware estable
si decido dejar de depurar?

sudo apt-get update
sudo apt-get upgrade

debería hacer el truco. Y sudo ./brcmdbg para volver a los controladores que no son de depuración.

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

Depuración iniciada; se necesitan unos 5 o 6 intentos para asociarse; no sé por qué fallaron todos los intentos excepto el último; Lo dejaré correr hasta que vea la pérdida de asociación y luego volcaré un nuevo dmesg. El comportamiento de asociación inconsistente era mi problema antes de dejar de usar el wifi integrado, por lo que esto podría ser en el acto. Hágame saber si alguna actividad adicional podría ser útil.

https://gist.github.com/BenoitSvB/bf8acdbb7b664df90e885603bb4774ce#file -201609081628_wifidbg-txt
Sin hacer nada más que esperar; ¿Vemos aquí varias pérdidas / recuperaciones de asociaciones?

Gracias por eso. Hmm, esos registros no son muy informativos, pero veamos con qué regresa Cypress.

https://gist.github.com/BenoitSvB/98db53ff884e7b1a57bf1475d6106c56
Pérdida inexplicable y recuperación de la asociación; el tiempo suficiente para verlo en el icono de la bandeja del sistema.
El punto de acceso es Linksys wrt160n con firmware: DD-WRT v24-sp2 (08/07/10) std.
Supongo que puedo dejar de depurar por ahora y volver a mi dongle MT7601U de 3 €, pero avíseme si puedo ser de más ayuda.

@pelwell No vi ninguna restauración de firmware después de sudo apt-get update && sudo apt-get upgrade y sudo rpi-update da
*** Su firmware ya está actualizado; Supongo que necesito ejecutar rpi-update con un hash de git específico para volver al firmware estable. ¿Sabes qué hachís?

El historial de confirmaciones en el repositorio de RPI-Distro muestra que desea confirmar 390f53ed0fd79df274bdcc81d99e09fa262f03ab desde el repositorio de firmware, así que ejecute:

sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab

@pelwell :
root @ pi3b : / home / pi # sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab
** Actualizador de firmware Raspberry Pi de Hexxeh, mejorado por AndrewS y Dom* * Realización de autoactualización
** Relanzamiento después de la actualización* * Actualizador de firmware Raspberry Pi de Hexxeh, mejorado por AndrewS y Dom
Hash de git especificado no válido

Ah, el firmware rpi de Hexxeh tiene diferentes ID de confirmación: intente 569e6611ac20c735647eb0e550484a73935a672d.

Me pregunto si https://github.com/raspberrypi/linux/issues/1552 / # 1444 también podría estar relacionado con este problema.

Recientemente implementé una configuración de 40xRPI3 que hace algunas cosas de bluetooth, teníamos que obtener interfaces wifi usb o de lo contrario wlan se congelaría constantemente. Ahora usamos el dispositivo bl interno y el módulo wifi interno está en la lista negra en modprobe.d.

Quizás sea útil hacer hcitool name 11:11:11:11:11:11 y ver si eso genera entradas de registro interesantes también. Acabo de seguir este problema, no he tenido tiempo de configurar mi entorno de laboratorio para probar nada por mí mismo. Tuvimos algunos congelamientos de wifi sin BT habilitado, pero la combinación de wifi + bt más o menos siempre puede matar el wifi en un período de tiempo muy corto. Esto siempre se podía reproducir en cualquier número de nuestros rpi

@pelwell
OKAY; uname -a proporciona Linux pi3b.thuis 4.4.13-v7 + # 894 SMP Lunes 13 de junio 13:13:27 BST 2016 armv7l GNU / Linux
Solo para información: ¿dónde podría alguien encontrar el hash de git para la versión de firmware estable real?

@thomasf
aunque tengo Bluetooth activado, no lo utilizo en este momento. El nombre de hcitool 11: 11: 11: 11: 11: 11 no devuelve nada; que es, supongo, de esperar ya que no estoy conectado a ningún dispositivo. Tal vez debería comprarme un dispositivo de audio BT para jugar.

Defina estable.

El hash que (finalmente) le di es para la versión de firmware del 20 de junio, que obtendrá si ejecuta:

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

No conozco un solo lugar que contenga el hash de la versión "estable" más reciente, pero al pasar por RPI-Distro como hice y luego hacer una referencia cruzada con el repositorio de Hexxeh, puede obtener hashes de actualización de rpi para cualquier versión. te gusta. Si considera que la versión 2016-05-23 es estable porque fue parte de la última versión completa de Raspbian, entonces desea el hash 3b98f7433649e13cf08f54f509d11491c99c4c0b, que se traduce en un hash de actualización de rpi de 2b9c0bfacfc11ee8bb9b30dc9cdb368289698f

@BenoitSvB Simplemente ejecutar ese comando hcitool desde un arranque nuevo sin tocar hci0 con ningún otro software hace que el wifi comience a comportarse mal en nuestras pruebas, no sé si importa si hay otros dispositivos bluetooth, pero es el ejemplo reproducible más pequeño Se me ocurre para desencadenar los problemas de congelación de wifi.

También probé el dongle bt externo + el wifi interno, pero el wifi interno a veces se cuelga incluso cuando el controlador bcm bt interno no está cargado. La "solución" (como en la solución rápida) para nosotros fue usar adaptadores wifi USB, que se ha demostrado estable en nuestras pruebas y uso de producción.

Todavía sospecho que el número 1313 está relacionado.

Op. 8-9-2016 om 18:07 schreef Thomas Frössman:

También probé el dongle externo bt + wifi interno, pero el interno
wifi a veces se cuelga incluso cuando el controlador interno bcm bt no
cargado. La "solución" (como en la solución rápida) para nosotros fue usar wifi USB
adaptadores, que ha demostrado ser estable en nuestras pruebas y uso de producción.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245649229,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFyzObJxRjzQ-uMUlfe8hjRasrfq3nkwks5qoDLXgaJpZM4HupC5.

@pelwell
En este caso, estable sería el firmware publicado por la Fundación con su última imagen publicitada y actualizado solo por "sudo apt-get update && sudo apt-get upgrade", por lo que sin la invocación de rpi-update (con o sin un git específico hash, que está destinado, como entendí, a actualizar a un firmware más reciente solo para fines específicos).
Lo que me lleva a la pregunta: ¿puedo leer el hash de mi firmware operativo antes de cargar un nuevo firmware para probarlo, para hacer una restauración más fácil después de la prueba, ya que no confiaría en mí mismo realizando la referencia cruzada que mencionó ...

Quizás - cat /boot/.firmware_revision está escrito por rpi-update, pero
sin probarlo, no podría decirte si los lanzamientos de Raspbian también escriben
eso.

boot / .firmware-revision es una cosa de rpi-update (
https://www.raspberrypi.org/forums/viewtopic.php?t=106073&p=732449#p731830)

Pero encontré con:

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

que yo quiero de hecho:

• firmware a partir de 390f53ed0fd79df274bdcc81d99e09fa262f03ab

Entiendo la referencia cruzada de
https://github.com/RPi-Distro/firmware/commits/debian?author=popcornmix para
https://github.com/Hexxeh/rpi-firmware/commits/master se realiza con cuidado
comparar fechas y descripciones de confirmaciones.

Aprendí algo; thnx :)

Op. 8 sep. 2016 8:28 pm schreef "Phil Elwell" [email protected] :

Quizás - cat /boot/.firmware_revision está escrito por rpi-update, pero
sin probarlo, no podría decirte si los lanzamientos de Raspbian también escriben
eso.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245693018,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFyzOQ_pfODaEmuBGR6pQVXs2W6LggW8ks5qoFO2gaJpZM4HupC5
.

@BenoitSvB : Tus rastros parecen mostrar un tipo diferente de problema: el firmware no da ninguna pista sobre por qué te desconectan. Es posible que obtenga más pistas de un rastreador de paquetes como WaveShark.

@mathieugouin @ dh-connect @ juched78 @maciex @duncanmcdowell : Tengo un ingeniero de Cypress que está ansioso por saber más sobre sus problemas; si me envías un correo electrónico, phil at raspberrypi dot org, puedo ponerte en contacto con él. Si desea acelerar las cosas, instale los módulos de depuración como se describe anteriormente y guarde la salida de dmesg cuando las cosas vayan mal.

@pelwell Google no devolvió mucho contenido en 'rastreador de paquetes Waveshark', pero supongo que se refería a WireShark. El hecho de que la lista negra de brcmutil y brcmfmac mientras se usa un dongle MT7601U hace que desaparezca el comportamiento errático de conexión / desconexión, combinado con las frecuentes ocurrencias de 'desorden' (ver # 1313, ahora oculto pero no resuelto) me hace sospechar que Broadcom / Causa del hardware Cypress.
Wireshark podría ser de ayuda, pero necesitaría ayuda para configurar / realizar un esfuerzo serio de depuración de hardware.

Sí, me refiero a wirehark.

Puede usar la utilidad dumpcap (parte del paquete tshark en modo texto) para registrar toda la actividad en un archivo y luego eliminarlo cuando el registro dmesg incluya un mensaje sospechoso. Algo como esto:

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

Tenga en cuenta que aunque se supone que "grep --max-count 1" se detiene después de una coincidencia, parece que requiere una línea más de entrada para que se detenga, pero eso no debería ser un problema en la práctica.

Si su archivo de captura se vuelve demasiado grande, puede hacer que dumpcap use una grabación de duración fija usando la opción "-b duración: 60 " (por un minuto). Existe la posibilidad de que reiniciar la captura de esta manera suceda en un mal momento y perder los paquetes interesantes, pero esto es poco probable. Siempre puede hacer que sea menos probable aumentando la duración.

@BenoitSvB Hay un hilo aquí que sugiere deshabilitar el roaming en el controlador Pi3 WiFi como una forma de evitar problemas de conectividad. El roaming permite que un dispositivo se mueva automáticamente entre AP con el mismo SSID, pero es probable que sea menos útil en un dispositivo estático como un Pi3, y existe la sugerencia de que eventualmente puede conducir a una pérdida total de conectividad.

¿Podría intentar habilitar el parámetro del módulo roamoff ? Necesita crear create /etc/modprobe.d/brcmfmac.conf que contenga lo siguiente:

options brcmfmac roamoff=1

@pelwell : Desactivar el roaming no es la solución; pero me hace jugar con diferentes canales y un segundo punto de acceso. Descubrí que el adaptador wifi integrado solo tiene problemas con algunos canales (por ejemplo, 1, 5) y solo en el Linksys WRT160N con firmware DD-WRT. Curiosamente, aunque ninguno de mis otros clientes wifi compartió este problema: se conectarán sin problemas en todos los canales ofrecidos en ambos puntos de acceso. Bien por mí, tengo una solución estable (no usar canales con wifi a bordo tiene problemas) pero no hay claridad en el asunto.
¿Quieres que realice pruebas específicas?
Por cierto, necesitamos configurar el parámetro
options brcmfmac debug = 1
en /etc/modprobe.d/brcmfmac.conf mientras usa los controladores de prueba especiales?
¿Y conoce una forma de medir el tiempo de actividad de una asociación wifi? Entonces podría probar de manera más sistemática todos los canales durante períodos más largos sin crear archivos de captura gigantes.

Se me aseguró que la depuración solicitada está habilitada en los controladores de depuración de forma predeterminada (tiene el mismo efecto que options bcrmfmac debug=0x100000 ), pero no dude en experimentar con diferentes valores.

No conozco ninguna forma de medir el tiempo de actividad de una asociación, aparte de realizar encuestas con frecuencia y esperar detectar un cambio.

Un empleado de Cypress está al tanto de este hilo, pero envíeme un correo electrónico (phil at raspberrypi dot org) si está feliz de ser contactado directamente.

Hola,

¿Hay algún progreso en este tema? Puedo conectarme a mi red Wi-Fi abierta, y después de un tiempo aleatorio tengo esto en mis registros:

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

Y luego no puedo hacer ping al enrutador.

Después de un ifdown wlan0 && ifup wlan0 vuelve a funcionar, hasta el próximo wlan0: carrier lost .

La administración de energía está deshabilitada, el bluetooth está deshabilitado, el roaming está deshabilitado (como sugirió) y mi versión es Linux pi3 4.4.17-v7+ .

siempre sucedía cuando el puente eth0 con wlan0, tenía el mismo problema que https://github.com/raspberrypi/linux/issues/1375

Tengo exactamente el mismo problema de que el WiFi integrado de Pi3 se desconecta después de un período de tiempo aleatorio. ifup lo vuelve a ejecutar sin problema.

Después de mucha investigación, descubrí que se debía a que tenía tres AP (BSSID) con un SSID (1 en cada canal 1, 6 y 11). Esta configuración admite roaming sin interrupciones y funciona perfectamente con todos los demás clientes WLAN.

Habilitar la depuración / registro con un controlador estándar parece mostrar que en algún momento el Pi decide desautenticar e incluso pone en la lista negra uno de los BSSID. La razón no está clara, pero parece ser una decisión tomada al final de Pi.

Cuando tengo exactamente la misma configuración en el Pi pero con solo un BSSID para el SSID, Pi puede aguantar durante días sin problemas.

Desafortunadamente, deshabilitar el roaming según el enlace de pelwell (http://projectable.me/optimize-my-pi-wi-fi/) no es realmente factible, tener solo un BSSID por SSID no es una opción, y yo en lugar de eso, no tiene que depender de un script que hace ping a algún host y luego ejecuta ifdown / ifup.

¿Se está realizando alguna investigación adicional para admitir múltiples BSSID por SSID, o puedo hacer algo específicamente para respaldar la investigación?

¡Gracias!

Tengo este problema y mi red es similar a la de @TheOriginalMrWolf .
Tengo una estación base de Apple y un aeropuerto expreso en una configuración de malla usando WDS.

Yo también tengo este problema. Si copio archivos a un recurso compartido de samba, la conexión wifi se pierde (raspberry 3, nuevo raspbian instalado).
Syslog:
brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012

Tengo exactamente el mismo problema al reproducir música con upnp (gmediarender).

Tengo el mismo problema al iniciar llamadas de voz en wechat, con el rpi como AP usando hostapd. Recibo un montón de spam como este:

[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 !!!

Con rastros como este:

[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 ]---

El rastro se parece sospechosamente al de @jrmhaig .

Acabo de hacer que esto vuelva a suceder e hice algunas depuraciones. Recibí algunos mensajes diferentes esta vez, que parecen interesantes (parece que son los mismos mensajes que @maciex recibió una vez):

[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. Parece que todo el sistema se congela cuando esto sucede. Ejecutar while sleep 1; do date; done en un bucle da como resultado un espacio cuando se produce la congelación. Me pregunto si esto significa que brcmf_proto_bcdc_msg que devuelve -110 (tiempo de espera) es solo un síntoma del problema real: simplemente registra donde nos congelamos.
2. Medí (con vcgencmd ) la temperatura y los voltajes en el momento de la congelación. Nada que informar allí, hasta donde yo sé.
3. Mi sistema es un AP con reenvío a un módem ZTE 4G a través de USB (es decir, client -> wlan0 -> rpi -> usb0 -> 4g . Parece que usb0 aún puede acceder a Internet cuando se congela el wifi.

Re: los comentarios anteriores, esto sucede en el modo de compartir NAT para mí con roamoff=1 . Ninguno de los dos solucionó o mitigó el problema para mí.

Después de deshabilitar WPA (usando create_ap -w 2 en mi caso para habilitar solo WPA2), el problema parece solucionado. Aunque no está claro por qué.

También me enfrento a los problemas informados aquí. En mi caso, sucede cada vez que accedo a archivos (generalmente mp3) a través de Samba desde el administrador y reproductor de archivos Samsung + ES.

Mi raspberry pi3 tiene conexión wifi a mi AP. Por lo tanto toda la comunicación con ella se piensa en red wifi. No tiene monitor ni teclado ni ratón.

Puedo reproducir fácilmente el error, así que si alguien quiere que produzca archivos de registro, hágamelo saber cómo puedo ayudar.

Debajo de mis entradas de syslog.

27 de diciembre 16:11:50 kernel de raspberrypi: [560.902063] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012
27 de diciembre 16:11:52 kernel de raspberrypi: [562.928930] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
27 de diciembre 16:11:54 kernel de raspberrypi: [564.926659] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
27 de diciembre 16:11:54 kernel de raspberrypi: [564.926820] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO falló, -52
27 de diciembre 16:11:56 kernel de raspberrypi: [566.924560] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
27 de diciembre 16:11:58 kernel de raspberrypi: [568.922555] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
27 de diciembre 16:11:58 kernel de raspberrypi: [568.928073] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO falló, -52
27 de diciembre 16:12:00 kernel de raspberrypi: [570.920675] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
27 de diciembre 16:12:02 kernel de raspberrypi: [572.918980] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
27 de diciembre 16:12:02 kernel de raspberrypi: [572.924580] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO falló, -52
27 de diciembre 16:12:04 kernel de raspberrypi: [574.917259] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
27 de diciembre 16:12:06 kernel de raspberrypi: [576.915703] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
27 de diciembre 16:12:06 kernel de raspberrypi: [576.921498] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO falló, -52
27 de diciembre 16:12:06 raspberrypi ifplugd (wlan0) [1149]: Uso del modo de detección: IFF_RUNNING

@rcassaniga
También tuve el mismo problema con la configuración idéntica.

Solución después de horas de depuración:
Apague IPv6 en la frambuesa en /etc/modprobe.d/ipv6.conf:
alias net-pf-10 off
alias ipv6 desactivado
opciones ipv6 disable_ipv6 = 1

Esta es solo una solución si no usa ipv6 en su red.

¡Gracias @ varl0g , eres mi héroe! :)
Parece que esta solución me funciona, ya no puedo reproducir el problema.

@ varl0g : Parece que la solución funciona porque no puedo reproducir el error.

Gracias y feliz 2017.

Intenté apagar ipv6. Eso no marcó la diferencia. Intenté desactivar el modo de ahorro de energía. Todavía no hay diferencia. Sin embargo, cuando configuro el canal de mi AP en 6 (en lugar de 11), ¡mi Raspberry Pi ha estado funcionando durante 2 días sin problemas!

Me gustaría confirmar que la solución alternativa para desactivar IPv6 no funciona.
Desafortunadamente, tengo el mismo problema con mi enrutador RPi3 y Apple Airport Extreme.

@rajid , @ dh-connect
Sorprendentemente, también resolvió mi problema cuando cambié el canal wifi de mi AP a 6 en lugar de automático, gracias @rajid

Yo también tengo este error - brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012
¿Dónde arreglar ????
Estoy probando el kernel 4.9, el kernel 4.4.41 - todos tienen este error. Fuente de alimentación 2.4a.

Tengo que revocar mi comentario anterior sobre el canal 6. Aparentemente, fue una coincidencia que mi RPI3 tuviera WiFi estable durante 6 días.

Me pregunto si alguien ha tenido suerte con este problema. He intentado desactivar la administración de energía, el bluetooth y el cambio de canales. Nada ha funcionado hasta ahora. Estoy ejecutando Octoprint con una cámara web adjunta. Parece suceder con bastante frecuencia, y noto que sucede con mucha más frecuencia cuando tengo más de una conexión http establecida.
Error de syslog antes del modo de ahorro de energía:
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
Error de syslog después del modo de ahorro de energía:
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 !!!
Actualmente estoy ejecutando Linux octopi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

Finalmente conseguí que mi RaspPi 3 estuviera estable en mi wifi cambiando el canal de 2.4Ghz de mi wifi a "6". Me olvidé de lo que era antes, 11 creo, pero no estoy seguro. Eso no funcionó bien y encontré una página web que decía que era un problema, pero 6 funciona bien. Ha sido mucho mejor desde que cambié el wifi de mi casa al canal 6.

/ raj

El 3 de marzo de 2017, a las 8:39 p.m., Daniel < [email protected] [email protected] > escribió:

Me pregunto si alguien ha tenido suerte con este problema. He intentado desactivar la administración de energía, el bluetooth y el cambio de canales. Nada ha funcionado hasta ahora. Estoy ejecutando Octoprint con una cámara web adjunta. Parece suceder con bastante frecuencia, y noto que sucede con mucha más frecuencia cuando tengo más de una conexión http establecida.
Error de syslog antes del modo de ahorro de energía:
brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012
Error de syslog después del modo de ahorro de energía:
kernel de pulpo: [10317.342360] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!! kernel de octopi: [10317.342593] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!! kernel de octopi: [10327.358384] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
Actualmente estoy ejecutando Linux octopi 4.1.19-v7 + # 858 SMP Mar 15 15:56:00 GMT 2016 armv7l GNU / Linux

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-284126948 , o silencie el hilo 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

canal 6, ancho de canal 20 MHz, parece estable desde hace semanas.

Había observado el mismo problema que el primero informado por @ dh-connect, es decir, estaba viendo el error -52 líneas de registro. Desactivar el ahorro de energía para la interfaz wifi no ayudó. Apagar ipv6 como lo sugirió @ varl0g resolvió mis problemas. Wifi ahora es estable durante días y días, mientras que antes se estropeaba minutos después del arranque.

No he tenido suerte en el canal 6 o 7. No he confirmado a nadie más en esos canales.
Intenté flashear mi sd con una nueva imagen y ahora mis controladores wifi no obtienen las concesiones DHCP adecuadas. Se están iniciando con 169.254.xx.xx local ips, no con la subred de mi servidor DHCP.

Decidió simplemente borrarlo e instalar el raspbian más nuevo e instalar octoprint desde la fuente. hasta ahora no hay problemas.

Por lo que puedo decir, este es un problema en el software del controlador de brcm80211 sdio.c.
La cadena 0x40012 es realmente 0x00040012, que cuando se interpreta usando las máscaras y códigos de aquí ~ línea 55, puede verse como una cadena de buzón que indica un cambio de control de flujo a DEVREADY. Lo extraño es que la cadena nunca se interpreta como tal y, por lo tanto, llega a la sección compatible con versiones anteriores del controlador ~ línea 1127 del archivo sdio.c dentro de la fuente brcm80211 / brcmfmac aquí .

No tengo una gran experiencia con el controlador en sí, ni la capacidad de recompilar y probar (solo tengo un rpi3, y prefiero no estropear el entorno en el que vive actualmente. Además, yo ' No estoy versado en recompilar / actualizar controladores de Linux ...) así que no estoy exactamente seguro, pero parece que dos mensajes HMB se envían uno tras otro tan rápidamente que el controlador no tiene tiempo suficiente para interpretarlos .

Para aquellos que se preguntan, actualmente estoy ejecutando octoprint (construido manualmente) en mi rpi3 a través de una conexión inalámbrica (duh ..) con la pantalla táctil capacitiva de adafruit pitft2.8 "y el kernel personalizado de adafruit (v 4.4.27-v7 +) y duplico el problema cuando tratando de acceder a la transmisión de video (Logitech C270) en mi Samsung Galaxy S7 a través de PrintDroid pro o Chrome. El bloqueo ocurre sin fallas cada vez que se realiza, y solo ocurre en forma inalámbrica. Actualicé la fuente de alimentación, desactivé ipv6 gestión de energía, en vano.

@TGYK ¿Puedes ver el problema al que se hace referencia

@TGYK. Se ha vinculado a la página de github de Broadcom original. ¿Puede dar alguna indicación de dónde aparecen los problemas en el árbol del kernel de Raspberry Pi aquí? Es un poco difícil rastrear a qué líneas de código se refiere.

sdio.c está aquí en el árbol 4.9 https://github.com/raspberrypi/linux/tree/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac.

@ JamesH65 En la página de github que vinculó, la línea a la que me refiero se encuentra alrededor de 1140-1147. En cuanto al error dmesg, el mensaje es el mismo problema que se ve arriba:
"Contenido de datos de buzón desconocido: 0x40012", seguido de errores de escan (-52).

No ocurre el mismo problema que el tema al que se hace referencia, ya que no estoy uniendo mis interfaces inalámbricas y cableadas de ninguna manera. Por lo que puedo decir, mi problema y el de este hilo pertenecen únicamente a la interfaz inalámbrica.

Gracias por la información. El problema posiblemente vinculado es, creo, similar en el sentido de que es un problema con el controlador Wifi que posiblemente reciba un mensaje extraño que cause más rarezas más adelante en la pila, pero todavía estoy investigando.

Tengo el mismo problema con una raspberry pi Zero W con un síntoma similar al de @TGYK. En mi caso, estoy ejecutando mpd en el cero y controlándolo a través de un cliente de Android en un Samsung Galaxy S5. Sin falta, si pongo el teléfono en modo de espera mientras se ejecuta la aplicación del controlador (es decir, sin regresar primero a la pantalla de inicio), el wifi del cero se interrumpe con el mensaje "Contenido de datos de buzón desconocido". Si dejo el dispositivo inactivo, o si tengo cuidado de cerrar siempre la aplicación antes de dejar que mi teléfono entre en reposo, permanecerá activo indefinidamente.

Tuve este problema en Raspian y ahora OSMC.

Mayormente intermitente, pero curiosamente acceder a la interfaz web de Kodi desde mi S7 siempre desencadenará este problema. Hacer lo mismo desde el iPhone de mi esposa funciona perfectamente y nunca ha desencadenado el problema.

@daedalia : Tengo un problema muy similar con un Samsung Galaxy Tab S. Sin embargo, no tengo acceso a un dispositivo iPhone / iPad para confirmar ...

Mi dispositivo Samsung bloquea el wifi cuando intento acceder a la interfaz web de tvheadend.

No sucede cuando se accede desde un navegador Firefox desde una PC con Windows.

Me alegro de haber encontrado este hilo, pensé que era el único. Tengo los mismos problemas que los carteles anteriores, el wifi se cae en mi pi3 / osmc cuando se accede desde una Samsung Galaxy Tab A. Funciona bien si se accede desde una tableta Nexus 7, un teléfono OnePlus o una computadora portátil Acer, solo Samsung da problemas. Fácilmente repetible. ¿Parece ser que el controlador wifi de Samsung no le gusta el wifi pi3 incorporado? Agregar un dongle wifi tp-link al pi3 es una solución para mí.

@philborman Tengo curiosidad, ¿usas el mismo navegador móvil en el Samsung que en el Nexus?

Ambos ejecutan Chrome, pero no es solo un problema del navegador. Si uso Yatse para
controlar kodi funciona bien desde el nexus / mobile / laptop pero pi3 WiFi cae
si intento lo mismo desde el samsung. Lo mismo si entro, se bloquea con Samsung
y no los demás. Con ssh puedo hacer un poco, pero cualquier transferencia de archivos o
incluso editar un archivo de texto hará que el wifi se desconecte.

El miércoles 12 de abril de 2017 a las 19:03 Mathieu Gouin, [email protected] escribió:

@philborman https://github.com/philborman Tengo curiosidad, ¿usas el
mismo navegador móvil en el Samsung vs el Nexus?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-293643847 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ALmHOdtJ9AQtpfU7tmeVouI-a4STg2WMks5rvQPJgaJpZM4HupC5
.

¿Alguien que comente aquí tiene la capacidad de construir un kernel con un parche que tengo que podría ayudar con esto? Se basan en 4.9 pero podrían funcionar bien en 4.4. Tenga en cuenta que estas son solo pruebas ...

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);

Hola,

Tengo el mismo problema descrito aquí con uno de mis 2 Pi3. Wifi pierde la conexión después de un tiempo, puede ser entre 30 minutos y algunas horas. Probé absolutamente todo lo sugerido aquí, incluido el cambio de canales wifi en el AP, etc., sin éxito. Lo que es extremadamente extraño es que en mi segundo Pi3 (rev 1.2 también, exactamente lo mismo), y con la misma tarjeta SD / instalación (Raspbian) que cambio entre ambas, Wifi es sólido como una roca durante días y días ...

Esto es realmente extraño. Ambos Pi3 están actualizados con rpi-update, kernel 4.9 y firmware # 991, pero ya era lo mismo con versiones anteriores de kernel / firmware.

Si realiza una actualización de rpi, obtendrá los parches anteriores aceptados por los desarrolladores del kernel; esto es para el controlador smsc9x y el controlador brcmfmac, a partir de anoche. ¿Podrías intentar eso? Si aún falla, ¿puede hacer 'dmesg' y ver si hay algo extraño en el syslog? Aunque, mi sospecha es quizás una falla de HW aparente a medida que el chip inalámbrico se calienta dado que otro Pi funciona bien con la misma tarjeta.

Gracias. Hice eso en el tablero sospechoso, wifi desconectado después de unos minutos.
dmesg da eso:
''
[266.654964] brcmfmac: brcmf_sdio_bus_sleep: error al cambiar el estado de suspensión del bus -110
[266.655033] brcmfmac: brcmf_sdio_txfail: error sdio, comando de cancelación y terminación de trama
[266.659215] brcmfmac: brcmf_sdiod_regrw_helper: no se pudieron escribir los datos F1 @ 0x1000d , err: -110
[266.663346] brcmfmac: brcmf_sdiod_regrw_helper: no se pudieron leer los datos F1 @ 0x1001a , err: -110
[266.667472] brcmfmac: brcmf_sdiod_regrw_helper: no se pudieron leer los datos F1 @ 0x10019 , err: -110
[266.671608] brcmfmac: brcmf_sdiod_regrw_helper: no se pudieron leer los datos F1 @ 0x1001a , err: -110
[266.675736] brcmfmac: brcmf_sdiod_regrw_helper: no se pudieron leer los datos F1 @ 0x10019 , err: -110
[266.679866] brcmfmac: brcmf_sdiod_regrw_helper: no se pudieron leer los datos F1 @ 0x1001a , err: -110
[266.683992] brcmfmac: brcmf_sdiod_regrw_helper: no se pudieron leer los datos F1 @ 0x10019 , err: -110
[269.655049] brcmfmac: brcmf_sdio_bus_sleep: error al cambiar el estado de suspensión del bus -110
[272.069378] net_ratelimit: 35 devoluciones de llamada suprimidas

......... entonces este "bucle" sigue llenando el registro dmesg varias veces por minuto.

Editar: Toqué todos los componentes en la placa, están todo menos calientes, diría que alrededor de 30 °, solo un poco más calientes que la piel de mis dedos.

Hmm, el material SDIO es la interfaz entre el Pi y el chip inalámbrico: se agota el tiempo (-110). Esto parece un problema de HW: a medida que el chip se calienta, tal vez haya una unión de soldadura defectuosa en las líneas de la interfaz sdio en algún lugar, lo que significa que las comunicaciones se desconectan.

Ping @ Roger-Thornton - Roger, ¿hay algo que podamos hacer para probar esto?

@Crrispy ¿Puedes verificar que tu Pi no tenga poca potencia? ¿Qué informa vcgencmd get_throttled ?

@pelwell : después de una pérdida de wifi, verifiqué y aceleré = 0x0

No creo que sea una falla de hardware, un simple reinicio siempre resuelve instantáneamente el problema.

@ JamesH65 No creo que esto parezca un problema de fabricación de hardware, ya que todas las líneas funcionan como deberían. Si hay otros indicadores sobre problemas de hardware, puedo echar un vistazo a la placa.

No parece ser el mismo problema que el mío. Solo tengo un pi3 y es
el wifi es sólido como una roca hasta que me conecto desde una tableta Samsung. Conectar con
cualquier otra cosa y está bien. No parece haber energía o sobrecalentamiento
relacionado, ya que está absolutamente bien durante días hasta que me conecto desde el
tableta y se cae.

Supongo que está relacionado con el controlador o el firmware, algo que Samsung
El controlador envía que al pi3 no le gusta.

El jueves 27 de abril de 2017 a las 22:01 Crrispy, [email protected] escribió:

@pelwell https://github.com/pelwell : después de una pérdida de wifi, verifiqué y
estrangulado = 0x0

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297823068 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5
.

Ha habido un par de correcciones para las redes en el último raspbian:
¿Cuándo fue la última vez que hiciste un

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

?
Podría valer la pena intentarlo para ver si soluciona las cosas.

El 28 de abril de 2017 a las 14:38, philborman [email protected] escribió:

No parece ser el mismo problema que el mío. Solo tengo un pi3 y es
el wifi es sólido como una roca hasta que me conecto desde una tableta Samsung. Conectar con
cualquier otra cosa y está bien. No parece haber energía o sobrecalentamiento
relacionado, ya que está absolutamente bien durante días hasta que me conecto desde el
tableta y se cae.

Supongo que está relacionado con el controlador o el firmware, algo que Samsung
El controlador envía que al pi3 no le gusta.

El jueves 27 de abril de 2017 a las 22:01 Crrispy, [email protected] escribió:

@pelwell https://github.com/pelwell : después de una pérdida de wifi, verifiqué,
y
estrangulado = 0x0

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
o silenciar el hilo
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHag08r5c96nB39R3F-mFW772qBbGks5r0evJgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Tengo el mismo problema con raspbery pi zero W. Después de un tiempo no puedo acceder a él. Probé todo. Un hecho curioso es ... cuando conecté rpi a mi televisor para solucionar algunos problemas después de que no pude conectarlo ... funcionó durante 18 horas como una roca. Luego, cambié hdmi por otro dispositivo y después de un tiempo, cuando quería ssh a pi, obtuve una hermosa información de "sin ruta al host". Cuando enchufé el cable hdmi nuevamente, pude hacer ping a la puerta de enlace. No hay errores en los registros, iwconfig parece estar bien. systemctl reiniciar la red ayudó.

Como se indicó anteriormente, pruebe la última versión de Raspbian e informe si todavía ve
el problema.

El 28 de abril de 2017 a las 19:30, frankja2 [email protected] escribió:

Tengo el mismo problema con raspbery pi zero W.Después de un tiempo, no estoy
capaz de ssh a él. Probé todo. Un hecho curioso es ... cuando me conecté
rpi a mi televisor para solucionar algunos problemas después de que no pueda ssh para
fue ... funcionó durante 18 horas como una roca. Luego, cambié hdmi por otro
dispositivo y después de un tiempo, cuando quería ssh a pi, me puse hermosa "no
ruta al host ". Cuando conecto el cable hdmi de nuevo, pude hacer ping
puerta. systemctl reiniciar la red ayudó.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Puede que yo sea el único lo suficientemente insensato como para que este sea el problema, pero descubrí que mi wpa_supplicant.conf tenía el código de país configurado incorrectamente (no entendí que era un elemento de configuración separado de las otras opciones de localización). No diré que el problema desapareció por completo, pero una vez que lo solucioné, dejó de perder su conexión de red en la forma en que "cada vez que me conecto desde mi samsung" era antes.

Acabo de actualizar a la última versión (apt-get dist-upgrade) y parece esperanzador.
Mi actualización anterior fue hace aproximadamente 2 semanas, justo antes de informar el
problemas iniciales. Funcionando bien durante las últimas horas, sin wifi
abandonos en absoluto. ¡Muchas gracias!

El 28/04/17 15:53, James Hughes escribió:

Ha habido un par de correcciones para las redes en el último raspbian:
¿Cuándo fue la última vez que hiciste un

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

?
Podría valer la pena intentarlo para ver si soluciona las cosas.

El 28 de abril de 2017 a las 14:38, philborman [email protected] escribió:

No parece ser el mismo problema que el mío. Solo tengo un pi3 y
sus
el wifi es sólido como una roca hasta que me conecto desde una tableta Samsung. Conectar con
cualquier otra cosa y está bien. No parece haber energía o sobrecalentamiento
relacionado, ya que está absolutamente bien durante días hasta que me conecto desde el
tableta y se cae.

Supongo que está relacionado con el controlador o el firmware, algo que Samsung
El controlador envía que al pi3 no le gusta.

El jueves 27 de abril de 2017 a las 22:01 Crrispy, [email protected] escribió:

@pelwell https://github.com/pelwell : después de una pérdida de wifi, verifiqué,
y
estrangulado = 0x0

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub

< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
o silenciar el hilo
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub

https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
o silenciar el hilo

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

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298003537 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ALmHORKJxKdws0fMKU5tpfoJHJSah0Ffks5r0e9FgaJpZM4HupC5 .

Está arreglado para mí en la última versión.

La mayoría de las otras "correcciones" parecen no comprender que mi sistema funcionaba
perfectamente con todo excepto una tableta (Samsung) por lo que parece el
El problema fue que samsung enviaba algo el controlador / firmware wifi pi3
no podía hacer frente.

Si mi código de país estaba mal configurado, ¿por qué solo Samsung causaría
cuestiones. Otras tabletas / teléfonos / portátiles se conectan bien.

De todos modos, está arreglado ahora, al menos no se ha caído en los últimos
horas. Más tiempo lo dirá ...

El 28/04/17 21:09, rraszews escribió:
>

Puede que yo sea el único lo suficientemente insensato como para que este sea el problema, pero
Descubrí que mi wpa_supplicant.conf tenía el código de país configurado
incorrecto (se perdió que era un elemento de configuración separado del otro
opciones de localización). No diré que el problema se fue
por completo, pero una vez que lo arreglé, dejó de perder su red
conexión en la forma "cada vez que me conecto desde mi samsung"
Fue antes.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298082370 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ALmHOWtM-_MXCz5RoQd8XShI4Mk-4LAyks5r0jlUgaJpZM4HupC5 .

En mi caso dura alrededor de las 19h. Después de eso, no pude más ssh ...

¿Cuál es la diferencia entre rpi-update y dist-upgrade?

Porque después de rpi-update tenía 4.9.25+ # 995 y luego hice dist-upgrade y el kernel volvió a 4.9.24+ # 993. De todos modos para mí el problema todavía no se ha solucionado. Lo que hice esta vez fue que usé otra rpi0w y una fuente de alimentación diferente :) El último paso es usar otra tarjeta SD.

OK gracias por la informacion.

Voy a necesitar más información para intentar replicar. Tu configuración, que
se ha conectado y el tipo de tráfico de red que se está produciendo, cualquier registro de dmesg
u otros mensajes de error una vez que el pescado deja de funcionar.

Gracias.

El 29 de abril de 2017 a las 16:16, franko [email protected] escribió:

En mi caso dura alrededor de las 19h. Después de eso, pude ssh más ...

¿Cuál es la diferencia entre rpi-update y dist-upgrade?

Porque después de rpi-update tenía 4.9.25+ # 995
https://github.com/raspberrypi/linux/pull/995 y luego hice
dist-upgrade y kernel revertidos a 4.9.24+ # 993
https://github.com/raspberrypi/linux/pull/993 . De todos modos para mi el problema es
todavía no arreglado.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298175041 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHQR8cadrEhb55YJj5PV6PP_odmJmks5r01RJgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Hola,

He puesto el Pi3 en un estuche con un ventilador bastante fuerte y la temperatura en la habitación es actualmente de 19 ° C, por lo que no puede ser un problema de calor. Cambié la fuente de alimentación por otra (5V 3A también). Usé otra tarjeta SD, dist-upgrade y luego rpi-update.
Ayer estuvo activo durante varias horas, esperaba que se solucionara, pero después de 3-4 horas se desconectó (ping -t ejecutándose desde mi máquina de ventanas).
Intenté de nuevo esta mañana, wifi desactivado después de menos de 20 minutos :-(
Aún así, el error -110 del controlador wifi en sdio (ver arriba), que se repite en un bucle hasta el reinicio.
Y mi otro Pi3 conectado durante 3-4 días ahora, no hay problema.
Entonces esto podría parecer una falla de hardware. Pero ... ¿por qué nunca falla al arrancar y siempre funciona después de un reinicio? Realmente desconcertante.
¿Por qué intenta cambiar el "estado de suspensión del bus" ya que la administración de energía está deshabilitada para wlan0? (perdón si la pregunta es tonta).

recién hecho apt-get update; apt-get dist-upgrade . Desafortunadamente, no hay cambios para mí. Desde mi observación, el problema se relaciona con el puente wlan0 pregunto si podría estar relacionado con el modo promiscuo. También me he cansado rpi-update para comprobar 4.9.25

en realidad es incluso peor que antes, ya que la conexión se pierde ahora, por lo general, solo en unos minutos y puedo ver los registros habituales

[  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

"Porque después de rpi-update tenía 4.9.25+ # 995 y luego hice dist-upgrade y el kernel volvió a 4.9.24+ # 993".

Eso es extraño. Hice la actualización de dist, fui a 4.9.24+ # 993 y cuando hago una actualización de rpi en este momento, dice que ya tengo el último firmware y no tiene nada que hacer ... ¿por qué no se actualiza a 4.9.25 / # 995?

En realidad, tengo que decir que usar brcmfmac/wlan0 bridged parece funcionar de manera más estable que con wlan0 puro (todo con hostapd)

Entonces, ¿puede dar una descripción completa y precisa de su configuración, junto con
tipos de dispositivos conectados y cualquier mensaje de error dmesg que pueda recibir
cuando falla la conexión inalámbrica.

Realmente necesito alguna forma de replicar el problema que no lleve horas, así que
cualquier información proporcionada que pueda ayudar a lograrlo se acepta con gratitud.

El 1 de mayo de 2017 a las 17:27, Szymon Stasik [email protected] escribió:

En realidad tengo que decir que usar brcmfmac / wlan0 bridged parece funcionar más
estable que con puro wlan0 (todo con hostapd)

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

No sé si esto está específicamente relacionado con este aspecto del problema, pero IIRC pude reproducir completamente una forma de caída de wifi usando un comando hcitool. Tal vez ya no sea posible, fue como hace un año y Fuimos con wifi usb para resolver el problema que funcionó para un montón de rpis ...

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

@thomasf ¿Cuál fue la configuración de su sistema (dispositivo independiente, punto de acceso, punto de acceso en puente, etc.) y en qué máquina ejecutó el comando hcitool? Una prueba rápida en un dispositivo conectado a otro Pi vía inalámbrica no mostró problemas.

@ JamesH65 Pasamos por muchos escenarios y el problema se

Cuando se ejecutaba el comando hcitool en un rpi, generalmente perdía la conexión de red (wifi) en segundos. IIRC era más fácil de reproducir si había algo de tráfico de red en el dispositivo (como una transferencia de archivos).

Mirando rápidamente nuestro sistema de aprovisionamiento final, el siguiente wpa_supplicant.conf fue el último que usamos ... Creo que no se ve tan diferente del que causó problemas con la interfaz wifi interna ,,, Estoy seguro de que Empezamos usando un solo AP sin dejar de tener problemas.

(SSID y claves redactados):

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=...
}

Acabo de encontrar un script llamado troublemaker.sh en el repositorio de aprovisionamiento ahora ...

Es muy hacky, creo que lo aprovisioné para que se ejecute al inicio ~ como una vez cada pocos minutos aproximadamente ~~ (editar: probablemente solo una vez, ya que hace algunos bucles por sí mismo) en un montón de rpi para provocar problemas y obtener algunos registros salvado..

Esto se usó principalmente antes de que entendiera más sobre los problemas ... Creo que los tiempos de ping y la pérdida de paquetes aumentaron durante un período antes de que el wifi se desconectara por completo ...

#!/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 &

La ejecución del script problemático en el último Raspbian estable (kernel 4.9) no muestra errores, lo cual es bueno, ¡pero malo para intentar replicar errores!

@ciekawy Mirando hacia atrás, parece que puede replicar fácilmente un problema que no podemos hacer aquí. ¿Puedes darme una idea de tu configuración exacta, para que pueda investigar? También vale la pena tomar la última actualización de rpi, ya que ha habido algunas correcciones para USB que pueden tener o no relevancia (si está utilizando Ethernet). Necesitaré saber la topología de su red, cómo está configurado el Pi, qué parece estar provocando el problema. ¡Cualquier cosa en realidad!

@ JamesH65 , Mi configuración actual es:

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

también en cuanto a 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

Vale la pena mencionar que este RPI se mantuvo estable durante días (aunque las transferencias de 10 mbps de mayor duración también pudieron generar algunos problemas) cuando se cambiaron los roles y se usó wlan0 brcmfmac para conectarse a Internet y el AP local se estaba ejecutando en wlan2 ath9k. Cambié la configuración porque necesito usar una mejor antena conectada a wlan2 para el acceso a Internet.

Mi rpi-updated reciente fue el 1 de mayo

Tengo exactamente el mismo problema en rpi3 usando Archlinux-ARM.

Después de algunas horas ejecutando create_ap, deja de funcionar con los mensajes de dmesg que ya han informado otros:
[11418.347554] brcmfmac: send_key_to_dongle: error de wsec_key (-110)

A veces funciona durante 1 día sin problemas y, a veces, funciona durante minutos antes de que ocurra el problema.

Alarma de Linux 4.9.25-2-ARCH # 1 SMP Vie 5 de mayo 00:46:52 UTC 2017 armv7l GNU / Linux

El mismo problema en Pi Zero W, Raspbian Lite actual. Después de algún tiempo (difiere de minutos a horas) aparece 'dmesg'
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
A partir de este momento, la conexión wifi desaparece y solo se puede reiniciar rmmod'ing y modprob'ing brcmfmac.

Inhabilité la administración de energía: sin cambios.
Actualicé todo a través de apt-get upgrade / dist-upgrade: sin cambios
Actualicé cosas a través de rpi-update: sin cambios

brcmfmac tiene errores con seguridad. Tenía el mismo problema con dmesg msg "brcmfmac: brcmf_sdio_hostmail: contenido de datos de buzón desconocido: 0x40012" y, a veces, mensajes diferentes también, como se informó en mi publicación anterior.

Estoy usando un adaptador wifi usb tp-link y mi aplicación funciona bien ahora.

Espero que broadcom pueda corregir los errores en brcmfmac.

¿Alguna solución?

Como mencioné al principio de esta conversación, cambié mi enrutador Wifi para usar el canal 6 en lugar del 11 (que estaba usando antes), y mi rPi ha estado activo desde entonces (desde enero hasta ahora) sin problemas en todos.

¿Podría esto estar relacionado con esta nota del módulo del kernel:

Esta generación de chips contiene soporte regulatorio adicional independiente del controlador. Los dispositivos utilizan un único dominio regulatorio mundial, con canales 12-14 (banda de 2,4 GHz) y canales 52-64 y 100-140 (banda de 5 GHz) restringidos al funcionamiento pasivo. La transmisión en esos canales se suprime hasta que se observe otro tráfico apropiado en esos canales. Dentro del controlador, usamos el código de país ficticio "X2" para representar este dominio regulatorio mundial. Actualmente no existe una interfaz para configurar un dominio diferente. El controlador lee el código de país SROM del chip y se lo entrega a mac80211 como sugerencia reglamentaria; sin embargo, esta información no se usa con el controlador.
(desde aquí: https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211)

Supongo que esto significa que incluso un código de país "DE" (que debería permitir canales wifi más altos) no tiene ningún efecto. Pero no estoy seguro de que esto pueda tener un efecto similar al problema Unknown mailbox data content: 0x40012 ...

Al menos para mí no es una solución alternativa: cambió del canal 11 al canal 6 hoy, 2 horas después: Unknown mailbox data content: 0x40012

Tuve ese problema hasta que aumenté la intensidad de la señal con un extensor de rango.
¿Podrías probar si la conexión es más estable moviendo el Pi a un lugar con mejor señal?

Tal vez se deba a la potencia adicional necesaria para funcionar con una señal deficiente.

Mismo problema que Crrispy.

Para aquellos que están trabajando en esto con un adaptador WiFi USB (cambio de canal, etc., tampoco funcionó para mí), Edimax EW-7811Un funcionó inmediatamente cuando lo conecté a mi cable USB OTG en RPI Zero W. No tengo que hacer ninguna configuración o ifconfig - ¡estaba en la red de inmediato! Ayer estuve agitado con el TP-Link Archer T1U AC450 durante unas horas.

@ b3nj1 - perdón por

Elegí la misma solución: compré un adaptador USB con antena externa y chipset mt7601 (alrededor de 5 Eur) para mi Zero W, funciona perfectamente. Debería haber comprado el non-W en primer lugar ... este problema existe desde hace más de un año y no hay solución a la vista.

@blacktigersoftware : es extraño, ¿no? El WiFi Zero W funciona muy bien. El Zero W Bluetooth funciona muy bien. Pero, si uso ambos al mismo tiempo, el sistema se vuelve insoportablemente lento y eventualmente inalcanzable a través de wifi.

He estado echando un vistazo al problema de maibox descrito anteriormente. Google muestra que esto parece estar sucediendo bastante (y al menos una referencia a una plataforma que no es Pi). El código del controlador detecta que un mensaje que viene del buzón (supongo que hay una conexión con el firmware de HW) tiene algunos bits configurados que no debería tener. Sin embargo, solo imprime los mensajes, no realiza ninguna recuperación ni devuelve errores. Dado que este parece ser un valor devuelto por el firmware, no tengo acceso a eso para ver realmente lo que está sucediendo, y la hoja de datos en el chip es completamente inútil. Así que creo que estos deben enviarse a Broadcom / Cypress / linux-wireless para su investigación.

También vale la pena señalar que parece que tenemos el último firmware de HW según https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm. Los archivos tienen una diferencia de longitud de uno o dos bytes, pero eso es todo.

El problema es que al error del buzón le siguen otros errores (-52, -110, etc.), y solo reiniciando el sistema, el wifi vuelve a funcionar.

-110 es un error de tiempo de espera, indicativo de que algo más está muriendo y no responde. -52 es un intercambio no válido, que está en la misma línea. Sospecho que en el momento en que se produjo el error del buzón, el firmware en el chip no estaba bien, por lo que estos otros errores continúan a partir de ahí.

¿Alguien que pueda replicar el problema es capaz de compilar el último kernel de desarrollo de Pi (4.11, disponible en nuestro github) y ver si el error del buzón aún ocurre? Antes de comenzar a impulsar el flujo ascendente, me gustaría saber que todavía sucede en el último kernel y no he podido replicarlo.

Puedo confirmar que el problema ocurre en: alarma de Linux 4.9.25-2-ARCH # 1 SMP Vie 5 de mayo 00:46:52 UTC 2017 armv7l GNU / Linux

No he probado en el kernel 4.11

El controlador utilizado en mis pruebas: brcmfmac: Versión de firmware = wl0: 15 de diciembre de 2015 18:10:45 versión 7.45.41.23 (r606571) FWID 01-cc4eda9c

@ b3nj1 - wow, gracias por el

Todo el mundo, ¿esto solo sucede cuando la gpu está encendida?

La GPU siempre está encendida (hasta cierto punto), en todos los modelos de Pi.

¿Te refieres a cuando Bluetooth está activado?

@ JamesH65 -

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

Gracias por adelantado

Verifique la rama rpi-4.11.y, luego reconstruya usando las instrucciones que
se han vinculado a.

El 25 de mayo de 2017 a las 05:02, b3nj1 [email protected] escribió:

@ 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=

• Daré una oportunidad a 4.11. ¿Simplemente clono / construyo de acuerdo con lo siguiente?
  Al clonar de acuerdo, estoy en la rama rpi-4.9.y. Debo pagar
  rpi-4.11.y en su lugar o algo más?

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

Gracias por adelantado

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Solo para repetir la información que proporcioné en otro lugar, he estado probando la conexión inalámbrica en condiciones de baja potencia. Lo llevé hasta el punto de que los dispositivos USB se cayeron, pero no vi ningún problema de conexión inalámbrica. Si bien eso es una prueba de que no es un problema de energía, vale la pena señalarlo.

Descubrí cómo reproducir esto ejecutando sudo memtester 256M 1 través de SSH usando mi teléfono; el wifi se apaga tan pronto como memtester comienza a inundarse con esos caracteres de "carga":

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

Cosa extraña, el wifi solo se cuelga mientras hago esto en mi teléfono. Probé mi PC, otro pi y mi enrutador sin suerte.

@ JamesH65 - Actualización 2: pude arrancar con 4.11 (configuré mal el kernel la primera vez).
Linux rpiz 4.11.2+ #2 Thu May 25 21:19:11 PDT 2017 armv6l GNU/Linux

Desafortunadamente, el sistema todavía responde a la cebada cuando golpeo BT.

Cuando vuelvo a enchufar el USB WiFi externo y conecto la dirección de ese adaptador, todo vuelve a estar bien.

• Benjamín

Nuevo kernel construido e instalado desde la rama rpi-4.11.y siguiendo las instrucciones aquí: 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

Desafortunadamente, wifi todavía se bloquea con el mismo error:
brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Si enciende la consola cuando se apaga el wifi, puede reiniciarlo. Estoy probando un script bash en este momento para ver si esto ayuda. Lo voy a ejecutar en cron. Aquí está si alguien está interesado.

#!/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

He estado ejecutando esto durante un día y hasta ahora no he notado la caída de mi wifi.

@ JR1994
¿Sigue funcionando?
¿Con qué frecuencia lo ejecuta?
Cada minuto ?

Lo intentaré en algunos de mis raspberrys, tengo varios que reinicio cada vez que no puedo hacer ping al enrutador

Gracias por adelantado

Hasta aquí todo bien. Estoy revisando cada 2 min.

Tenga en cuenta que la última revisión de firmware para brcmfmac es demasiado antigua:

brcmfmac: Versión de firmware = wl0: 15 de diciembre de 2015 18:10:45 versión 7.45.41.23 (r606571) FWID 01-cc4eda9c

@semeion No estoy seguro de qué firmware está utilizando; el actual debería ser "Versión: 7.45.41.26 CRC: 5932ca06 Fecha: Viernes 2016-05-27 00:15:32 PDT Ucode Ver: 1043.2060 FWID: 01-df77e4a7". Esto es efectivamente el mismo que el del repositorio de firmware de Linux, aunque obtenemos el nuestro directamente de Brcm.

@ JamesH65 Ese mensaje fue devuelto en 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

Pero usando vcgencmd version muestra:

$ /opt/vc/bin/vcgencmd version

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

Ese no es el firmware del chip Wifi, es el firmware del SoC, que obtiene
actualizado con bastante frecuencia.

Sin embargo, todavía no estoy seguro de por qué su sistema cree que tiene ese firmware antiguo. usted
tiene un firmware de SoC muy reciente, por lo que presumiblemente ha realizado una actualización de apt-get
¿recientemente?

El 5 de junio de 2017 a las 17:55, Alexandre Bolelli [email protected] escribió:

@ 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=
Ese mensaje fue devuelto en dmesg. Pero usando la versión vcgencmd muestra:
`$ / opt / vc / bin / vcgencmd versión
Versión de firmware

30 de mayo de 2017 15:23:29
Copyright (c) 2012 Broadcom
versión b8cdd5ae76f39d9f353dfa8fb48bf7e33b74903c (limpio) (lanzamiento) `

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

@ JamesH65 Como dije anteriormente, estoy usando Archlinux-ARM, es una distribución de lanzamiento continuo, y sí, mi sistema está actualizado con pacman -Syu (pacman -Syu es equivalente a apt-get upgrade / update).

No tengo idea de por qué ese firmware antiguo es antiguo en mi sistema. Tal vez pueda ser la razón de ese error. ¿Qué piensas?

De todos modos, el error ocurre con raspbian, ¿verdad? ¿El error se informó en marzo de 2016? Es viejo.

PD. El inglés no es mi idioma nativo, perdón por algún error / falta de ortografía.

De acuerdo, no me había dado cuenta de que estaba usando ARCH. Parece que no están suministrando
un blob de firmware reciente para el chip Wifi. Puede actualizarlo manualmente,
podría solucionar su problema, puede que no; creo que probablemente haya varios
errores inalámbricos, y no hay garantía de que el que está viendo sea el
una que la gente está viendo en Raspbian.

Debe informar el firmware desactualizado a los encargados del mantenimiento del arco, y
tal vez el error inalámbrico también, ya que podría deberse a la distribución Arch.

Tenga en cuenta que, por lo general, no admitimos otras distribuciones, nuestra distribución interna es
Raspbian, por lo que para investigar un problema debemos poder replicarlo en
ese.

El 5 de junio de 2017 a las 23:13, Alexandre Bolelli [email protected] escribió:

@ JamesH65 https://github.com/jamesh65 Como dije anteriormente, estoy usando
Archlinux-ARM, es una distribución de lanzamiento continuo, y sí, mi sistema está actualizado
con pacman -Syu (pacman -Syu es equivalente a apt-get upgrade / update).

No tengo idea de por qué ese firmware antiguo es antiguo en mi sistema. Tal vez pueda ser
la razón de ese error. ¿Qué piensas?

De todos modos, el error ocurre con raspbian, ¿verdad? El error se informó en
Marzo de 2016? Es viejo.

PD. El inglés no es mi idioma nativo, perdón por algún error / falta de ortografía.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306325452 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHaL4XsN5drPggS8eJDZWme4LyKXWks5sBH2CgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

@ jamesH65 Sí, de hecho. Intentaré preguntar en # archlinux-arm por qué ese firmware es antiguo. De todos modos, seguiré este problema y buscaré una solución. Informaré aquí cualquier información descubierta.

Gracias por adelantado.

@ JamesH65 Puedo replicarlo consistentemente en mi Raspbian (RPi 3). Si hay algo que pueda hacer para ayudar con esto, ¡hágamelo saber!

¿Cuál es tu configuración? ¿Cómo replica el problema?

El 6 de junio de 2017 a las 14:17, Dan [email protected] escribió:

@ JamesH65 https://github.com/jamesh65 Puedo replicarlo
consistentemente en mi Raspbian (RPi 3). Si hay algo que pueda hacer para ayudar
con esto, avísame!

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306483030 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHWyW5cQuS47k3xTmi3UX-QW7ffEYks5sBVF5gaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Echa un vistazo en los comentarios anteriores, no hace mucho te expliqué cómo reproducirlo.
El Pi está ejecutando Raspbian completo con una pantalla de 3.5 "en la parte superior usando la fuente de alimentación oficial. Nada lujoso, todo se mantiene actualizado con rpi-update y apt upgrade.

Pasados ​​unos días el wifi interno deja de funcionar con el siguiente mensaje en 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

Ejecuto hostapd en esta interfaz y tengo otra interfaz wifi USB conectada al Pi. Mi información de sistema:

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

Sí, y cuando muestre eso (-110), debe reiniciar el sistema para que vuelva a funcionar ...

Es bueno saber que también sucede en Raspbian, el error es independiente de la distribución. Pasa lo mismo en Archlinux.

Sin embargo, desde que moví mi wifi del canal 11 al canal 6, no he visto el problema desde entonces. Veo, por mis respuestas anteriores en este hilo, que ha sido desde el 7 de enero cuando hice el cambio al canal 6. Actualmente estoy ejecutando dos RaspPI Zero W y un RaspPi 3, todos sin problemas. Las dos RaspPi W ejecutan DietPi.

También tengo este problema en mi Raspberry Pi 3. Ya probé diferentes canales wifi.
Observé que si también conecto el puerto LAN, el wifi es muy estable. Tan pronto como desconecto el puerto LAN, el wifi sigue cayendo todo el tiempo.

Eso es realmente extraño......!

El 15 de junio de 2017 a las 23:02, macmeck [email protected] escribió:

También tengo este problema en mi Raspberry Pi 3. Probé diferentes canales wifi
ya.
Observé que si también conecto el puerto LAN, el wifi es muy estable.
Tan pronto como desconecto el puerto LAN, el wifi sigue cayendo todo el tiempo.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-308878043 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHbUKBO9mG3xpKHFK977h4hrFUhrGks5sEantgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Tengo
"brcmf_sdio_hostmail: contenido de datos de buzón desconocido: 0x40012"
problema también en mi rpi3. mi solución alternativa más confiable para evitar este error ha sido
"wondershaper 9000 9000"
Espero que se determine la causa raíz.

Tengo exactamente el mismo problema. Mi pi3 tiene los siguientes síntomas cuando está conectado con WIFI SOLAMENTE:

1. El wifi SALIENTE funciona MUY BIEN. Puedo conectarme a Internet y descargar archivos sin problemas en mi pi3.
2. TODAS LAS conexiones wifi ENTRANTES fallan. Pings timeout, el puerto 80 http accede a timeout, ssh falla, todo falla SOLO ENTRADA.
   NOTA:
3. Una vez que Ethernet está conectado al pi3, entonces el wifi funciona MEJOR, pero aún está perdiendo paquetes.
4. Una vez que se elimina Ethernet nuevamente, wifi falla por completo en todas las conexiones entrantes.
5. Una vez que Ethernet está conectado nuevamente al pi3, el wifi funciona MEJOR y permite algunos paquetes entrantes. pero todavía deja caer muchos de ellos.

¡Por favor arregle esto!

He notado lo siguiente en ifconfig:

Paquetes RX: 1613 errores: 0 descartado: 1074 desbordamientos: 0 trama: 0
Paquetes TX errores: 0 descartados: 0 desbordamientos: 0 portadora: 0
colisiones: 0 t x cola: 1000

Entonces, básicamente, el lado RX del WIFI del pi3 está dejando caer paquetes como loco. No es de extrañar por qué no responderá a las conexiones entrantes. TX funciona bien!

Desde que configuré ese script, no he tenido problemas con wifi en mis
RPI3.

El miércoles 21 de junio de 2017 a las 4:26 a. M., Edward Kang [email protected]
escribió:

He notado lo siguiente en ifconfig:

Paquetes RX: 1613 errores: 0 descartado: 1074 desbordamientos: 0 trama: 0
Paquetes TX errores: 0 descartados: 0 desbordamientos: 0 portadora: 0
colisiones: 0 t x cola: 1000

Entonces, básicamente, el lado RX del WIFI del pi3 está dejando caer paquetes como loco.
No es de extrañar por qué no responderá a las conexiones entrantes.

POR FAVOR ARREGLO ESTO !!

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310049620 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFHmIH6kkxraxahE22_PpstdDkqW8Pgqks5sGP3ggaJpZM4HupC5
.

Está muy bien decir "'por favor, arregla esto", pero problemas como este son absolutamente bastardos de encontrar. Me tomó un mes encontrar un error en los controladores smsc / brcmfmac al hacer un puente, y tuve suerte de encontrarlo, y sospecho que este es más raro y más difícil de encontrar. Si alguien puede encontrar un caso de prueba replicable que muestre el error rápidamente, sería de gran ayuda. Algunas personas parecen tener el error kevent con frecuencia, yo lo obtengo muy raramente.

En cuanto al problema de los paquetes descartados, se está analizando cuando tengo lagunas en el cronograma. En el caso anterior, parece que está descartando casi todos los paquetes, lo cual es muy extraño y no suele ser visto por la mayoría de las personas. ¿Sucede esto con todos los dispositivos conectados al Pi? O solo uno en particular.

lo siento, james!

No estoy seguro de a qué te refieres con todos los dispositivos conectados al Pi. Los paquetes descartados provienen de realizar ifconfig directamente en el pi. El pi está conectado a través de wifi a un enrutador. Cuando el pi está conectado solo a la red wifi, recibe y suelta paquetes constantemente.

@ JamesH65 Bueno, estoy de acuerdo contigo, es difícil de resolver ... Pero usando Arch Linux-ARM, instalando el paquete "create_ap" y habilitándolo (pacman -S create_ap; systemctl start / enable create_ap), puedes obtener el - 110 y el "Contenido de datos de buzón desconocido: 0x40012" en pocos minutos de operación ... Simplemente conecte su teléfono inteligente y / o un televisor inteligente a veces y el error vendrá.

No admitimos Arch, Raspbian es nuestro sistema operativo compatible y ese es el que yo
necesito poder solucionar el problema. No tengo idea de qué versión del
kernel o controladores que utiliza ARCH, pueden ser muy diferentes de los
los de Raspbian.

¿La gente sigue viendo el problema al usar la Pi como punto de acceso?
¿Utilizando puentes? ¿IPv4 o IPv6? Este es el tipo de información (no
exclusivo, por supuesto, se requiere tanta información como sea posible) requerido
para replicar problemas.

Tenga en cuenta que Broadcom ha sido informado del error del buzón (es su chip
y conductor, por supuesto), pero las cosas tienden a moverse lentamente con ellos.

El 21 de junio de 2017 a las 18:27, Alexandre Bolelli [email protected]
escribió:

@ 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=
Bueno, estoy de acuerdo contigo, es difícil de resolver ... Pero usando Arch Linux-ARM,
instalar el paquete "create_ap" y habilitarlo (pacman -S create_ap;
systemctl / startenable create_ap), puede obtener el error -110 y el
"Contenido de datos de buzón desconocido: 0x40012" en pocos minutos de funcionamiento ...
conecte su teléfono inteligente y / o un televisor inteligente a veces y el error
vendrá.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Estoy usando ipv4 estático en algunos dispositivos y tengo el mismo problema que el
otros usando dhcp

2017-06-22 4:06 GMT-03: 00 James Hughes [email protected] :

No admitimos Arch, Raspbian es nuestro sistema operativo compatible y ese es el que yo
necesito poder solucionar el problema. No tengo idea de qué versión del
kernel o controladores que utiliza ARCH, pueden ser muy diferentes de los
los de Raspbian.

¿La gente sigue viendo el problema al usar la Pi como punto de acceso?
¿Utilizando puentes? ¿IPv4 o IPv6? Este es el tipo de información (no
exclusivo, por supuesto, se requiere tanta información como sea posible) requerido
para replicar problemas.

Tenga en cuenta que Broadcom ha sido informado del error del buzón (es su chip
y conductor, por supuesto), pero las cosas tienden a moverse lentamente con ellos.

El 21 de junio de 2017 a las 18:27, Alexandre Bolelli [email protected]
escribió:

@ JamesH65
3A__github.com_jamesh65 & d = DwMFaQ & c = DpyQ_ftY536pf7wCBQXXU58xADDRY77THQz
Ju1OmzOo & r = w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m =
BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w & s = o90aBGb27vZvog3BdioLSa2_
MEySix0ymtnTgiNb87c & e =>
Bueno, estoy de acuerdo contigo, es difícil de resolver ... Pero usando Arch Linux-ARM,
instalar el paquete "create_ap" y habilitarlo (pacman -S create_ap;
systemctl / startenable create_ap), puede obtener el error -110 y el
"Contenido de datos de buzón desconocido: 0x40012" en pocos minutos de funcionamiento ...
Sólo
conecte su teléfono inteligente y / o un televisor inteligente a veces y el error
vendrá.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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 =>,
o silenciar el hilo
3A__github.com_notifications_unsubscribe-2Dauth_
ADqrHfDuqt5fcQ3ODkJUFKxuUaWgUpIhks5sGVKfgaJpZM4HupC5 & d = DwMFaQ & c = DpyQ_
ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo & r = w09_
2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m = BDIwUx7SC6sTRvRQKgA0QZB_
ZlIJDs3bd_wzKoIw_7w & s = Ojyj5WoAXeLeCsvarhv2rrmQUVoQGkjZmsfPB2lrOUw & e =>
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310294786 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ACeQBFj8ICNkDl7xYwYJcD6TK-k6_4K5ks5sGhJ1gaJpZM4HupC5
.

Una cosa a tener en cuenta es que el wifi funcionó perfectamente para mí desde el momento en que obtuve mi pi3 el año pasado hasta hace unos 3 meses cuando el wifi dejó de funcionar.

Claramente, debe haber habido algún tipo de cambio en el software en ese momento que hizo que el wifi dejara de funcionar.

Si su wifi ha dejado de funcionar por completo, entonces indica un problema en su extremo (que puede verse agravado por un problema de software, por supuesto), porque para todos los demás, Wifi generalmente funciona (aunque veo paquetes perdidos).

Por cierto, mi rpi3 es una marca nueva en el Reino Unido.

También he estado luchando contra esto durante algunos meses. A veces dura unos minutos. A veces semanas. El denominador común cuando pierdo una conexión es que veo las llamadas para restablecer el dominio regulatorio mundial CRDA inmediatamente antes de que pierda la conexión. Cada vez. Punto de acceso AC Ubiquiti, canal 11, ancho de canal HT40 (lo único que podría ser especial).

28 de junio 14:19:31 kernel de raspberrypi: [980.387378] cfg80211: Dominio regulatorio mundial actualizado:
28 de junio 14:19:31 kernel de raspberrypi: [980.387387] cfg80211: DFS Master región: no establecido
28 de junio 14:19:31 kernel de raspberrypi: [980.387396] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 de junio 14:19:31 kernel de raspberrypi: [980.387411] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N / A, 2000 mBm), (N / A)
28 de junio 14:19:31 kernel de raspberrypi: [980.387426] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N / A, 2000 mBm), (N / A)
28 de junio 14:19:31 núcleo de raspberrypi: [980.387439] cfg80211: (2474000 KHz - 2494000 KHz a 20000 KHz), (N / A, 2000 mBm), (N / A)
28 de junio 14:19:31 kernel de raspberrypi: [980.387453] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (N / A)
28 de junio 14:19:31 kernel de raspberrypi: [980.387468] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 s)
28 de junio 14:19:31 núcleo de raspberrypi: [980.387481] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N / A, 2000 mBm), (0 s)
28 de junio 14:19:31 núcleo de raspberrypi: [980.387493] cfg80211: (5735000 KHz - 5835000 KHz a 80000 KHz), (N / A, 2000 mBm), (N / A)
28 de junio 14:19:31 kernel de raspberrypi: [980.387505] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 0 mBm), (N / A)
28 de junio 14:19:32 kernel de raspberrypi: [981.262521] cfg80211: El dominio regulatorio cambió a país: EE. UU.
28 de junio 14:19:32 kernel de raspberrypi: [981.262536] cfg80211: DFS Master región: FCC
28 de junio 14:19:32 kernel de raspberrypi: [981.262540] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 de junio 14:19:32 núcleo de raspberrypi: [981.262549] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N / A, 3000 mBm), (N / A)
28 de junio 14:19:32 kernel de raspberrypi: [981.262557] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2300 mBm), (N / A)
28 de junio 14:19:32 kernel de raspberrypi: [981.262565] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2300 mBm), (0 s)
28 de junio 14:19:32 kernel de raspberrypi: [981.262571] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N / A, 2300 mBm), (0 s)
28 de junio 14:19:32 kernel de raspberrypi: [981.262578] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N / A, 3000 mBm), (N / A)
28 de junio 14:19:32 kernel de raspberrypi: [981.262584] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 4000 mBm), (N / A)

Lamento echar leña al fuego, pero creo que tengo un problema similar en el Pi Zero W también.

Al cambiar wlan0 entre el modo de punto de acceso (cuando se usa hostapd) y el modo de conexión normal (es decir, conectarse a un enrutador), wlan0 a veces perderá la capacidad de asociarse con un punto de acceso.

Se quedará atascado en este estado:

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

y nada menos que un reinicio lo solucionará. Noto en dmesg los siguientes errores cuando esto sucede:

[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)

Lo que me preocupa es que sea completamente arbitrario y aleatorio. A veces puedo cambiar entre los dos modos durante bastante tiempo antes de que ocurra el problema. Pero eventualmente lo hace.

FWIW Creo que recargar el módulo del kernel wifi (haciendo "modprobe -r -v brcmfmac && modprobe brcmfmac") lo solucionó, así que tendré que crear un script que haga esto siempre que mi Pi tenga problemas de wifi.

Esto mientras que es extraño. Tuve este tipo de problemas en Raspberry pi zero & zero W, pero desaparecieron por completo cuando cambié de canal (como se discutió anteriormente en este hilo).

Además, últimamente he estado usando el sistema operativo DietPi y no he tenido ningún problema. Es posible que desee probar eso.

Realmente me hubiera gustado investigar el problema, habiéndolo visto antes, ¡pero no puedo lograr que suceda en estos días! :(

/ raj
(enviado desde iPhone)

El 5 de julio de 2017, a las 9:01 a.m., timdonovanuk [email protected] escribió:

FWIW Creo que recargar el módulo del kernel wifi (haciendo "modprobe -r -v brcmfmac && modprobe brcmfmac") lo solucionó, así que tendré que crear un script que haga esto siempre que mi Pi tenga problemas de wifi.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

Cuanta más gente pueda ver esto, mejor, estoy limitado en el tiempo
Puedo gastar en esto en este momento debido a otros proyectos. Un gran problema
es un mecanismo sólido para replicarlo.

El 5 de julio de 2017 a las 17:10, rajid [email protected] escribió:

Esto mientras que es extraño. Tuve este tipo de problemas en Raspberry pi
cero y cero W, pero desaparecieron por completo cuando cambié de canal (como
discutido anteriormente en este hilo).

Además, últimamente he estado usando el sistema operativo DietPi y no he tenido ningún problema en
todos. Es posible que desee probar eso.

Realmente me hubiera gustado investigar el problema, habiéndolo visto antes, pero
¡No puedo conseguir que suceda en estos días! :(

/ raj
(enviado desde iPhone)

El 5 de julio de 2017, a las 9:01 a. M., Timdonovanuk [email protected]
escribió:

FWIW Creo que recargar el módulo del kernel wifi (haciendo "modprobe -r -v
brcmfmac && modprobe brcmfmac ") lo arregló, así que tendré que crear un
script que hace esto cada vez que mi Pi tiene problemas de wifi.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

@timdonovanuk podría ser bueno compartir su guión con nosotros, estoy buscando una solución. Tal vez algún script de monitoreo se ejecute como el servicio systemd ... ¿Qué opinas?

¿Existe alguna forma de activar manualmente la actualización del dominio reglamentario? Como dije, parece ser bastante consistente para mí cada vez que se ejecuta, la conexión se cae. Me interesaría ejecutarlo manualmente unas cuantas veces para ver si puedo reproducirlo de manera confiable.

@rajid , ¿por casualidad estás corriendo con un ancho de canal de 40? ¿Y recuerda si estuvo viendo actualizaciones regulatorias mundiales similares antes de las caídas? Es curioso si tal vez haya una combinación alrededor del canal 11 y el ancho de canal extra ancho ... ¿y qué tipo de enrutador / AP estás usando? Solo busco algo en común, ya que estoy viendo esto en el canal 11 también, al igual que otros ... Mi AP es un Ubiquiti.

La solución para cambiar de canal automático en Apple extreme al canal 6 no funcionó para mí. Usaré LAN durante las vacaciones.

Editar: Ahora pierdo la conexión incluso con LAN, hay algo más aquí, ¿es un problema de calor usar el estuche oficial (sin ventilador)?

Hola,
Estoy enfrentando un problema muy similar en una Raspberry Pi Zero W.

Desarrollé una API que se ejecuta con Node.JS en la Pi y se integra con GPIO.
El Pi está conectado a mi LAN a través de Wifi. Todo funciona muy bien cuando los clientes de PC llaman a la API. Sin embargo, tan pronto como consulto mi API con un dispositivo Android, el Pi se bloquea. Estos bloqueos ocurren al azar: a veces, los dispositivos Android pueden llamar a la API varias veces y de repente ocurre el bloqueo.
Lo que quiero decir con bloqueo es una pérdida de ping, pero Pi todavía está en funcionamiento.

Llamar a la misma API a través de PC nunca provoca ningún bloqueo.

Intenté cambiar de canal Wifi pero no obtuve mejores resultados.

Si puedo ejecutar algo para ayudar con el diagnóstico / solución, ¡no dude en preguntar!

¿Algo en esta publicación del foro ayuda?

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

El 11 de julio de 2017 a las 16:22, matthiasbou [email protected] escribió:

Hola,
Estoy enfrentando un problema muy similar en una Raspberry Pi Zero W.

He desarrollado una API que se ejecuta con Node.JS en la Pi y la he integrado
con GPIO.
El Pi está conectado a mi LAN a través de Wifi. Todo funciona muy bien cuando la PC
los clientes llaman a la API. Sin embargo, tan pronto como consulto mi API con un Android
dispositivo, el Pi se bloquea. Estos bloqueos ocurren al azar: a veces la API puede
ser llamado por dispositivos Android varias veces y de repente ocurre el bloqueo.
Llamar a la misma API a través de PC nunca provoca ningún bloqueo.

Intenté cambiar de canal Wifi pero no obtuve mejores resultados.

Si puedo ejecutar algo para ayudar con el diagnóstico / solución, ¡no dude en preguntar!

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314479400 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHYDohQoNRBDcX4oG49rK9e6kwpjjks5sM5MpgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

@matthiasbou

Es interesante lo que dijo, mi controlador de broadcom devuelve el error -110 (a veces otro error) y se bloquea exactamente en el momento en que conecto mi teléfono inteligente Motorola X2 (Android). Pero también ocurre el mismo error al conectar mi SmartTV. De todos modos, puedo confirmar que el bloqueo ocurre en el momento en que se establece la conexión.

Mi país está configurado correctamente, ipv6 desactivado y roamoff = 1, estoy usando el canal 6, el problema sigue ocurriendo. El modo de ahorro de energía wifi y el bluetooth están desactivados de forma predeterminada en mi distribución.

@ JamesH65 :

Wifi se conecta, pero tan pronto como empiezo a "jugar" con un dispositivo Android haciendo algunas llamadas API en el Pi Zero W, después de un tiempo, se bloquea.

¿Por qué la desactivación de IPv6 debería solucionar el problema de Wifi? ¿Existe una explicación sensata de por qué está involucrado IPv6, que sea reproducible? Lo único que se me ocurre es que IPv6 puede tener una ligera carga de multidifusión adicional debido a los RA.

Por lo que vale, estoy ejecutando dos Pi Zero W como puentes IPv6 entre wlan0 integrado y eth0 externo, con IPv4 bloqueado. wlan0 está en modo AP y tiene el servidor ISC dHCPv4 en ejecución. Le estoy conectando varias tabletas y teléfonos inteligentes Android. No noté ningún problema hasta ahora, pero tal vez deba dejarlos funcionar por períodos de tiempo más largos. Estoy usando el canal 6.

Lo siento, estoy usando una caja de Apple Airport y no hay ninguna configuración ni mención de "ancho de canal". Simplemente configuro el canal 6 para la red de 2.3Ghz. Ahora estoy usando DietPi en mis pequeños sistemas RaspPi Zero W. Los otros RaspPi que tengo fueron configurados hace mucho tiempo con Edimax USB y nunca he tenido ningún problema. Creo que la única vez que vi problemas fue con Raspbian en el sistema Zero W. Tendré que cargar eso de nuevo y ver si puedo reproducirlo.

/ raj

El 5 de julio de 2017, a las 3:19 p.m., Michael Hallock < [email protected] [email protected] > escribió:

¿Existe alguna forma de activar manualmente la actualización del dominio reglamentario? Como dije, parece ser bastante consistente para mí cada vez que se ejecuta, la conexión se cae. Me interesaría ejecutarlo manualmente unas cuantas veces para ver si puedo reproducirlo de manera confiable.

@rajid https://github.com/rajid , ¿por casualidad estás corriendo con un ancho de canal de 40? ¿Y recuerda si estuvo viendo actualizaciones regulatorias mundiales similares antes de las caídas? Es curioso si tal vez haya una combinación alrededor del canal 11 y el ancho de canal extra ancho ... ¿y qué tipo de enrutador / AP estás usando? Solo busco algo en común, ya que estoy viendo esto en el canal 11 también, al igual que otros ... Mi AP es un Ubiquiti.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-313242611 , o silencia el hilo https://github.com/notifications/unsubscribe-auth/AFAlZVdfvh5QzIlsZYtt9sjpXolJqvdcmWks5sLAgaupC

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

Realicé más pruebas y cambié el enrutador al que se conecta el Pi.
Hasta ahora, todo funciona cuando el Pi está en este otro enrutador Wifi (sin cambios en el lado del dispositivo Android):
Configuración del enrutador de trabajo :
Canal 6
PSK WPA
Ancho de banda 20Mhz

Configuración del enrutador que no funciona (pérdida de Wifi después de algún acceso desde Android Wifi):
Netgear WNR1000v2
Canal 6
WPA2-PSK [AES]
Longitud de fragmentación 2346
Umbral CTS / RTS 2347

Cambiaré el enrutador que funciona a WPA2-PSK para ver si el problema se puede reproducir.

@TheDiveO Con respecto a IPv6, el controlador tiene diferentes rutas de código para ipv6, al igual que el kernel. Podría haber un error en cualquiera de esas rutas que no esté en ipv6 o, como ISTR de un error hace un tiempo, algo ejecuta una ruta de código ipv6 cuando debería ejecutar una ruta de código ipv4 o viceversa. Toda la pila está bastante complicada.

nuevo comportamiento. Cambiar la configuración regional y hacer la actualización y actualización de apt-get ahora tiene el siguiente comportamiento cuando mi pi3 está conectado a través de WIFI:

ahora los dispositivos fuera de la LAN local pueden conectarse a PI a través de TCP / IP.

PI todavía rechaza todas las conexiones (TCP / IP) en la LAN únicamente.

PI todavía puede acceder a Internet exterior a través de WIFI.

no importa. Nada ha cambiado. Este es exactamente el mismo comportamiento que antes. Pi3 wifi descarta todos los paquetes en la LAN local.

Solo para seguir un poco ... puse en marcha un nuevo AP (Linksys E4200 V2), que tenía por ahí. Lo configuré en el canal 11 para 2.4Ghz, configuré WPA2 Personal, un BSSID y una contraseña. Luego configuré esto en mi raspberry pi zero w. Se conectó muy bien. Luego moví este AP a la misma habitación donde se encuentra mi AP doméstico normal (que está en el canal 6). Mi RaspPi obtuvo ASSOC-REJECT status_code = 16. Mover el AP de nuevo a mi oficina una vez más hizo que el asociado de RaspPi estuviera bien.

Entonces, parece que en mi caso, al menos, el canal 11 es un problema si AP está en la otra habitación. Supongo que esto probablemente indica un problema de interferencia.

También publicaré aquí una página web que encontré que dice cuáles son todos los códigos de estado y códigos de falla:

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

Esto muestra que mi "status_code = 16" es causado por un tiempo de espera, por lo que uno de los sistemas simplemente no está recibiendo paquetes de manera oportuna.

Solo pensé en tirar esta información en caso de que ayude a alguien.

Cuando enciendo las luces de mi cocina, se apaga mi conexión wifi en el
sala de estar ... no sé por qué, pero cuando hablaste de interferencia, creo que
no estoy loco

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

Solo para seguir un poco ... puse en marcha un nuevo AP (Linksys E4200 V2),
que tenía por ahí. Lo configuré en el canal 11 para 2.4Ghz, configurado
WPA2 Personal, un BSSID y contraseña. Luego configuré esto en mi frambuesa
pi cero w. Se conectó muy bien. Luego moví este AP a la misma habitación
donde se encuentra mi AP de casa normal (que está en el canal 6). Mi RaspPi entonces
obtuvo ASSOC-REJECT status_code = 16. Mover el AP de nuevo a mi oficina una vez
nuevamente hizo que el RaspPi se asociara bien.

Entonces, parece que en mi caso, al menos, el canal 11 es un problema si AP está
En la otra habitacion. Supongo que esto probablemente indica una interferencia
problema.

También publicaré aquí una página web que encontré que dice lo que todos los
status_codes y códigos de falla son:

https://supportforums.cisco.com/document/141136/80211-
asociación-estado-80211-códigos-de-razón-deauth

Esto muestra que mi "status_code = 16" se debe a un tiempo de espera, por lo que uno de los
sistemas simplemente no está recibiendo paquetes de manera oportuna.

Pensé en tirar esta información en caso de que ayudara
nadie.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314872003 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ACeQBJdfk2zp1sReVVs1wvrilKHXNm53ks5sNR42gaJpZM4HupC5
.

Hay un programa Analizador de WiFi realmente agradable para Android, que muestra qué puntos de acceso hay a tu alrededor, junto con su información detallada. (Ojalá existiera algo así para iPhone / iPad, pero Apple ...)

@ JamesH65 , realmente me está incomodando decir que un controlador de capa de enlace de datos (capa 3) se mete con la capa de red 3. "Desorden" tampoco es probablemente una palabra apropiada para esta situación ...

En realidad, no estoy diciendo eso. No soy un experto en redes Linux.
pila, pero ciertamente recuerdo haber visto algunas cosas específicas de IPv6 en
un conductor en alguna parte.

Todo está en el árbol del kernel, le invitamos a echar un vistazo
usted mismo para descansar su mente.

El 13 de julio de 2017 a las 08:58, TheDiveO [email protected] escribió:

@ JamesH65 https://github.com/jamesh65 realmente me estás poniendo incómodo
diciendo que un controlador de capa de enlace de datos (capa 3) se mete con
la capa de red 3. "Lío" no es probablemente una palabra apropiada para esto
situación tampoco ...

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315002002 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHUSoqqxnhaw4k2ECkzGC9CDkIlhYks5sNc4ngaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

@TheDiveO James se
SMSC95xx, por ejemplo, solo puede admitir la descarga de suma de comprobación de IPv4 debido a que IPv6 requiere que una suma de comprobación de 0x0000 se sustituya por 0xFFFF. Consulte https://github.com/torvalds/linux/commit/fe0cd8ca1b82983db24b173bb8518ea646c02d25. Por lo tanto, IPv6 e IPv4 seguirán diferentes rutas de código. Nada dudoso ahí, pero inherente a la pila de red donde el hardware no puede cubrir todas las situaciones.

Estoy bastante seguro de que este error está en el controlador Broadcom, no en el kernel.

Casi seguro. Sin embargo, el controlador Brcm es una gran parte de código y errores
como este no son fáciles de depurar, especialmente cuando no se pueden replicar ...

El 13 de julio de 2017 a las 13:04, Alexandre Bolelli [email protected]
escribió:

Estoy bastante seguro de que este error está en el controlador Broadcom, no en el kernel.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315058283 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHbr5SiWPKvQZOY7rN8IbyIIscNfVks5sNgexgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Cuanto más lucho con esto, más me pregunto si esto está relacionado con la incapacidad de Ubuntu / Debians para conectar wlan0 y eth0 a la misma subred sin una configuración extensa. Voy a investigar esto más y ver si este es el problema.

@ JamesH65, ¿ayudaría si yo (o alguien más) configurara cero w o rpi 3 para usted en un entorno donde esto es fácilmente reproducible y le da acceso ssh allí para que pueda depurarlo? (Necesitaría comprar cero w extra para esto).

Probablemente no, pero gracias por la oferta. Tiendo a ejecutar cambios personalizados en el
controlador y kernel, con cambios realizados varias veces al día. Haciendo eso
remotamente no es factible. Los mecanismos para reproducir el problema de manera confiable son
realmente lo que se necesita.

El 13 de julio de 2017 a las 13:57, Tuomas Airaksinen [email protected]
escribió:

@ JamesH65 https://github.com/jamesh65 ¿Me ayudaría si yo (o alguien
else) configuraría cero w o rpi 3 para usted en un entorno donde esto es
fácilmente reproducible y le da acceso ssh allí para que pueda depurarlo? (YO
necesitaría comprar cero w extra para esto).

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315069935 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHeQ1RECH-uIIHWPX6ItvRdVbZG_Xks5sNhRWgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

James,
Si hago este simple ciclo de sondeo, veo rápidamente que la red wifi integrada se degrada a un estado inutilizable. Cuando apago el wifi integrado y uso un wifi USB, funciona find. No recuerdo si es sensible a que el dispositivo BT esté presente o ausente, y no puedo verificarlo fácilmente durante unos días. Me limité a 10 minutos para poder volver al pi zero w después del experimento.

bash# ((t= fecha +% s +600)); while [ fecha +% s -lt $t ] ; do hcitool name <BTMAC>; done
Espero que ayude,
Benjamín

Ese recorte de código perdió mis garrapatas traseras. Escapando de ellos ...

((t = `fecha +% s` + 600)); while [`fecha +% s` -lt $ t]; hacer hcitool nombre "insertar BT MAC"; hecho

DIOS MIO. Creo que está arreglado. La conexión wifi está activa cuando ethernet está desconectado. Increíble.

Eliminé toda mención de eth0 de mi archivo / etc / network / interfaces, reemplacé allow-hotplug con auto, y luego forcé el apagado inalámbrico en wlan0 y wlan1.

mi archivo / etc / network / interfaces:

auto lo
iface lo inet loopback

apagado inalámbrico
auto wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

apagado inalámbrico
auto wlan1
iface wlan1 inet manual
wpa-conf / etc / wpa_supplicant / wpa_supplicant.conf`

Entonces enrojecí arp:

ip -s -s neigh flush all

Luego reinicié:

sudo reboot now

Y ahora mi wifi funciona. Increíble. Gracias a todos los que comentaron este hilo.

Su problema de configuración particular podría resolverse, el error en el controlador Broadcom aún está presente.

OK, hemos estado viendo esto. Mi primer problema fue que cuando SSH en mi dispositivo de prueba, la sesión se bloqueaba A MENOS QUE el cable Ethernet también estuviera insertado. Resulta que ARP es manejado por cualquiera de las interfaces, por lo que cuando se conectó ethernet, estaba usando eso. No tenerlo conectado significaba que estaba siendo manejado por Wifi y tenía un problema. Este problema podría solucionarse desactivando QoS / ToS en SSH (consulte aquí https://expresshosting.net/ssh-hanging-authentication/), lo que a su vez implica que el controlador Broadcom Wifi no está satisfecho con el TOS (tipo de service) / campo DSCP que se está estableciendo. Esto se ha visto antes en NTP (número 1519). Sospecho que esto podría ser una causa de los problemas de Wifi relacionados con este tema y hoy voy a buscar en el controlador Brcm para ver si puedo encontrar algo.

Informe intermedio. Definitivamente estamos viendo problemas con ciertos valores de paquetes de TOS que hacen que los paquetes se descarten silenciosamente, lo que provoca bloqueos de SSH. Aún no hay nada obvio en el impenetrable código del controlador, que TBH no debería tocar esta parte del paquete de todos modos, pero claramente está sucediendo algo. ¿Tiene esto algo que ver con las congelaciones generales de wlan que se informan aquí? Aún no lo sé.

Tengo problemas similares en un Pi Zero W con raspbian jessie y kernel 4.9.35+
Tengo el mismo problema mencionado por JamesH65 con SSH y ntpd (TOS). La corrección de https://expresshosting.net/ssh-hanging-authentication/ funcionó para sshd. También tengo los problemas de desconexión de wlan0, pero con mensajes de registro algo menos detallados. A primera vista, parece que el operador se ha perdido y wpa_supplicant a veces no puede renegociar. La única forma de salir de eso es emitir ifdown wlan0, espera, ifup wlan0 para mí, entonces wlan0 comienza a funcionar nuevamente. Feliz de suministrar registros si alguien los requiere. Solo dime cual.

Informe intermedio. Quería tomar algunas notas antes de que se olvidaran. Hemos determinado que es la respuesta del pi conectado de forma inalámbrica lo que falta al acceder a través de SSH desde otro dispositivo. Si esa respuesta tiene el campo TOS configurado, el paquete se descarta silenciosamente, nunca regresa al solicitante. Podemos replicar esto usando netcat. El simple comando net cat del Pi inalámbrico con las banderas TOS configuradas no parece salir del dispositivo.
Entonces, en el PI inalámbrico, intente enviar un paquete UDP a otro dispositivo ...
nc -T 0x10 -u7
El dispositivo no parece recibir el paquete (como se muestra al ejecutar tcpdump en el destino)
nc -T 0x00 -u7
llegará al sistema remoto.
Solo lo hemos probado a través de la red inalámbrica aquí en la oficina. Necesito configurar otra red Wifi para ver si está relacionada con el enrutador o si hay un problema en el controlador.

Corrección menor al comando netcat anterior
nc -T 0x10 -u <dest_ip> 7
Se eligió el puerto UDP 7 ya que es el servicio de eco. No importa que esto no se esté ejecutando en la máquina remota, aunque eso conduce a la respuesta inaccesible ICMP apropiada, que es un indicador útil de que el extremo remoto recibió el mensaje.

Comenzar a pensar que el problema de SSH / ToS en realidad no está relacionado. He rastreado paquetes hasta el nivel de HW y no importa si las banderas TOS están configuradas o no, los paquetes parecen llegar al firmware (o al menos a la función brcmf_sdiod_send_pkt que ha superado cualquier manejo de prioridad en el controlador de Linux). Lo que indica que los problemas están en el firmware del chip (fuente cerrada) o en realidad relacionado con el enrutador, es decir, el enrutador inalámbrico que estoy usando no deja pasar los indicadores TOS que no son cero (o quizás> 0x04). Intentaré un enrutador inalámbrico diferente mañana para intentar confirmar esto.

¿Existe alguna posibilidad de localizar al departamento responsable de desarrollar el módulo brcmfmac para que alguien pueda seguir ese hilo o al menos responder si se publicará alguna solución para estos errores?

Ya estamos en contacto a través de la lista de correo de linux-wireless.

El 19 de julio de 2017 a las 19:06, "Alexandre Bolelli" [email protected] escribió:

¿Existe alguna posibilidad de localizar el departamento responsable de desarrollar
el módulo brcmfmac para que alguien pueda seguir ese hilo o al menos
responder si se publicará alguna solución para estos errores?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316469790 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHYtYvpxdKd3SBBynOnlDN-ZXiWs_ks5sPkW9gaJpZM4HupC5
.

Ya estamos en contacto a través de la lista de correo de linux-wireless.

... y rutas más directas. El problema siempre ha sido de reproducibilidad: una vez que tenemos una forma de demostrar claramente el problema, podemos presentarlo a Broadcom / Cypress y solucionarlo. Nunca pude ver el problema al usar NTP, pero James ha tenido una falla exitosa con SSH, así que soy optimista de que llegaremos a la causa raíz.

@pelwell +1 para el término "_fallo exitoso" _ :)

Tengo una solución hacky para el problema de bloqueo SSH. Parece ser un problema en el firmware. A continuación se muestran algunos detalles.

'
Hemos estado investigando un problema en Raspberry Pi, donde SSH y
Las sesiones NTP fallan cuando se establece el indicador TOS en el encabezado IPv4.

Aquí hay un extracto de lo que es TOS:

TOS es 0x08 o 0x10. Solo se permite configurar uno de los 4 bits a la vez.
0x10 - minimizar el retraso
0x08: maximizar el rendimiento
0x04 - maximizar la confiabilidad
0x02: minimiza el costo monetario.
Técnicamente, TOS ha sido reemplazado por DSCP, pero aún es compatible.

Podríamos intentar recrear este problema con DSCP si es realmente necesario, pero no es así.
parecen ser relevantes.

Los detalles sobre el problema de SSH y una solución alternativa se pueden encontrar aquí https://expresshosting.net/ssh-hanging-authentication/

Sin embargo, esto es claramente un problema en alguna parte de las comunicaciones
stack, así que esto es lo que hemos estado investigando.

Hemos podido replicar un ejemplo simple usando netcat. En primer lugar,
conectar un Pi de forma inalámbrica a un AP (PiA), con otro dispositivo conectado
ya sea de forma inalámbrica o vía ethernet a la misma red (PiB).

En ejecución PiB

sudo tcpdump -n 'udp puerto 7' -v -i wlan0 <<<< o eth0 dependiendo de la conexión

En PiA,

nc -T 0x10 -u7

Esto envía un paquete UDP al puerto 7, con el indicador TOS establecido en 0x10.

Esto NO llegará (o en algún momento se retrasará mucho: 10 segundos)

Envío de TOS como 0

nc -T 0x0 -u7

Llegará. 0x02 y 0x04 también llegarán, 0x8 y 0x10 no.

Instrumentar el controlador brcmfmac muestra que el paquete con el TOS
flag = 0x10 se envía correctamente por la pila al HW, pero luego el
el paquete se pierde.

Hemos podido pasar el paquete pirateando el código BCDC,
en la función bcdc.c! brcmf_proto_bcdc_hdrpush, la prioridad del
El paquete también se inserta en el encabezado bcdc. Al establecer esto en un
valor constante (que puede ser cualquier valor de 0 a 7), el paquete es
transmitido. Entonces parece que un valor constante para la prioridad bcdc
funciona, pero tenerlo establecido en la prioridad determinada por la entrada
Las cosas de prioridad de skb fallan SI el TOS es 0x08 o 0x10. Entonces, parece
ser una combinación de paquetes con diferentes prioridades que causa
valores de mayor prioridad para fallar, no el valor en sí.

Dado que la prioridad del encabezado BCDC está destinada al firmware, este
parecería ser un problema en el firmware en sí, no en Linux
conductor.

Aquí hay una diferencia del cambio que parece detener el problema.

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 Genial. Dado que no espero una solución de firmware pronto, ¿podría copiar esto a linux-wireless?

Voy a esperar alguna información de Broadcom / Cypress, ya que estoy
No estoy seguro de que este truco sea seguro en todas las circunstancias. Les he enviado un correo electrónico. Una vez
Recibo algunos comentarios. Enviaré un parche a linux-wireless.

El 20 de julio de 2017 a las 12:41, Stefan Wahren [email protected] escribió:

@ JamesH65 https://github.com/jamesh65 Genial. Ya que no espero un
pronto se arreglará el firmware, ¿podría copiar esto a linux-wireless?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316678154 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHY3DlxTr9mehRDlxBK3NWbjowxxyks5sPzzqgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Algunos resultados de las pruebas parecen indicar que este truco no tiene efectos nocivos. Acabo de transferir datos de un lado a otro, 500 MB al Wireless Pi, se enviaron 3,4 GB. Los paquetes RX 56 cayeron desde 794730, no se descartaron paquetes TX desde 2813930. El rendimiento parece perfecto para una conexión de 11 Mbit / s. Parece aceptable, pero este truco en realidad deshabilita algo que probablemente debería estar habilitado, por lo que no es una solución a largo plazo.

@lategoodbye He estado pensando en

@moonman
¿Crees que esto podría enviarse a ARCH linux-raspberrypi?

@ JamesH65 Seguro, tu truco no es adecuado para todos los modelos de chips. Pero no es tu trabajo encontrar una solución para todos ellos. Creo que una simple copia de su largo comentario anterior (incluido el truco) sería suficiente. Mi intención era informar a otros desarrolladores de kernel que no sean de broadcom sobre el problema. No esperaba que enviaras un parche adecuado para este problema, solo un informe de error.

Sugiero que lo incluyamos en nuestro repositorio para realizar algunas pruebas serias: comience con rpi-4.12.y, que se usa en las compilaciones de LibreElec de última generación cada noche.

Un pensamiento: ¿podría hacer que el parche sea más selectivo en su filtrado de prioridad y aún así solucionar el problema?

Solo estoy preparando un PR para que esto vaya al repositorio de Pi.

Con respecto a la verificación selectiva, intenté simplemente detectar la prioridad
6 (el que se transmite por la pila, se traduce del TOS
valor a algo más específico de la pila de Linux), y configurándolo en 0 y
que parecía funcionar, pero sospecho que es una combinación de
prioridades diferentes en lugar de específicamente 6 que causa el problema. Nosotros
También sé que un TOS de 0x08 también tiene problemas, y es que IIRC,
convertido a 2 en el momento en que llega a este punto. Podríamos simplemente decir, si
es 6 o 2, luego póngalo en cero, pero todavía no estoy seguro de que lo capte
todo lo que pueda causar problemas. Dado que el valor es 0-7 de todos modos, creo que
para este truco, es mejor establecerlo en 0 en todos los casos. Lo sabemos
funciona, puede que no sea óptimo, por supuesto, pero creo que todos los paquetes
atravesar. Tenga en cuenta que esta configuración NO afecta el valor TOS en el
Paquete IPv4: sigue siendo el mismo, es solo este sistema de envío de
prioridad al chip y cómo lo maneja que parece escamoso.

El 21 de julio de 2017 a las 09:35, Phil Elwell [email protected] escribió:

Un pensamiento: ¿podría hacer que el parche sea más selectivo en su prioridad?
filtrado y todavía tienes que solucionar el problema?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

He tenido algún contacto con Cypress, que va a intentar conseguir este
miró lo antes posible.

El 21 de julio de 2017 a las 10:11, James Hughes [email protected] escribió:

Solo estoy preparando un PR para que esto vaya al repositorio de Pi.

Con respecto a la verificación selectiva, intenté simplemente detectar
prioridad 6 (la que se pasa por la pila, se traduce de
el valor TOS a algo más específico de la pila de Linux), y configurándolo para
0 y eso pareció funcionar, pero sospecho que es una combinación
de diferentes prioridades en lugar de específicamente 6 que causa el problema.
También sabemos que un TOS de 0x08 también tiene problemas, y es que IIRC,
convertido a 2 en el momento en que llega a este punto. Podríamos simplemente decir, si
es 6 o 2, luego póngalo en cero, pero todavía no estoy seguro de que lo capte
todo lo que pueda causar problemas. Dado que el valor es 0-7 de todos modos, creo que
para este truco, es mejor establecerlo en 0 en todos los casos. Lo sabemos
funciona, puede que no sea óptimo, por supuesto, pero creo que todos los paquetes
atravesar. Tenga en cuenta que esta configuración NO afecta el valor TOS en el
Paquete IPv4: sigue siendo el mismo, es solo este sistema de envío de
prioridad al chip que parece escamoso y cómo lo maneja entonces
parece escamoso.

El 21 de julio de 2017 a las 09:35, Phil Elwell [email protected] escribió:

Un pensamiento: ¿podría hacer que el parche sea más selectivo en su prioridad?
filtrado y todavía tienes que solucionar el problema?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

También sabemos que un TOS de 0x08 también tiene problemas, y es decir, IIRC, convertido a 2 para cuando llega a este punto.

Correcto. TOS 0x08 (maximizar el rendimiento) asignado a 2. Son valores TC_PRIO_xxx de http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/pkt_sched.h#L19. 6 = INTERACTIVO, 2 = A GRANEL.

Las pruebas anteriores con la configuración de IPQoS en 8 en sshd_config o con netcat usando TOS 8 dieron como resultado paquetes descartados.
Ni 0x02 ni 0x04 causaron ningún problema, pero hay poco que un controlador wifi pueda hacer sobre la diferencia de costo (no hay ninguno) o la confiabilidad, por lo que probablemente los ignore.
editar En realidad, la tabla de mapeo en http://elixir.free-electrons.com/linux/latest/source/net/ipv4/route.c#L177 tomando tos>>1 está configurando TOS 0x02 y 0x04 a TC_PRIO_BESTEFFORT = 0 de todos modos, lo que explica por qué no tienen ningún problema.

Solo un informe rápido. Cypress ha podido replicar el problema y están
comprobando el firmware con un aspecto esperanzado. Respuesta muy agradable y rápida.
de los chicos de allí.

El 21 de julio de 2017 a las 11:07, 6by9 [email protected] escribió:

También sabemos que un TOS de 0x08 también tiene problemas, y es que IIRC,
convertido a 2 en el momento en que llega a este punto.

Correcto. TOS 0x08 (maximizar el rendimiento) asignado a 2. Son TC_PRIO_xxx
valores de http://elixir.free-electrons.com/linux/latest/source/
incluir / uapi / linux / pkt_sched.h # L19. 6 = INTERACTIVO, 2 = A GRANEL.

Pruebas anteriores configurando IPQoS en 8 en sshd_config, o con
netcat usando TOS 8 resultó en paquetes descartados.
Ni 0x02 ni 0x04 causaron ningún problema, pero hay poco controlador wifi
puede superar la diferencia de costo (no hay ninguna) o la confiabilidad, por lo que probablemente
ignorándolos (no he comprobado).

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316962443 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHXTmjzqVW0o4T9IIoYFPprKvEvS7ks5sQHhXgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Una forma más fácil de reproducir: ¡usa ping! (Había olvidado que ping / ICMP estaba por encima de IP, tonto)

ping -Q 0x10 <dest ip addr> en el Pi3
y ejecute tcpdump -n -v -i wlan0 'icmp' en el destino.
Da como resultado una pérdida de paquetes> 90% en -Q 0x10 o -Q 0x08. A menudo comienza bien con 4 paquetes secuenciales que pasan, pero luego se vuelve muy intermitente.
Es un poco más útil que netcat, ya que (a) sigue repitiéndose y (b) le indica cuándo obtiene una respuesta.

Hay una solución aquí: https://github.com/raspberrypi/linux/pull/2126
Si desea probarlo con el kernel 4.9, use rpi-update.
Luego reemplace:
módulos / 4.9.39 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko con esto
módulos / 4.9.39-v7 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko con esto

EDITAR: El último kernel rpi-update ahora incluye el parche, por lo que ya no es necesario descargar los módulos.

No estoy seguro si está relacionado. La conexión en el broadcom a bordo de mi Pi Zero W se cae cada 2 horas cuando se activa una segunda interfaz wlan1 con un dongle rt8192eu / 8192eu. No parece ser un problema de energía porque es muy cíclico, tengo un pastebin de las desconexiones en https://pastebin.com/5hMQHWeW

Cuando esto está en curso, wpa_supplicant a veces deja de intentarlo sin ninguna razón obvia que no sea la falla en la autenticación y la única forma de recuperar la conectividad en wlan0 es emitir ifdown / ifup, que luego funciona al 100%.

Ahora no sé si este es el problema relacionado con el módulo del kernel de Broadcom que causa problemas, o si es el buggy 8192eu o ambos. Feliz de proporcionar más líneas de registros si es necesario o publicar en un hilo diferente, pero alguien en #raspbian sugirió que agregue esto aquí.

Si puede confirmar que vcgencmd get_throttled devuelve 0x0 después de una desconexión, eso descartará un problema de energía.

Por lo general, sucede cuando estoy dormido / no con el Pi y descubro en retrospectiva cuando ya no puedo conectarme (luego solía conectarme a través del segundo AP y restablecer wlan0). Sin embargo, dado que el dongle 8192eu está desconectado ahora, no he tenido ningún evento. Puedo conectar el segundo dongle con el módulo con errores, pero ¿qué tan pronto después de la desconexión debo verificar vcgencmd get_throttled?

Siempre que no haya reiniciado, los bits superiores le dirán si alguna vez ha habido un evento de bajo voltaje.

Solo lo ejecutó. Definitivamente no reiniciado desde la última desconexión. Puede confirmar las devoluciones de vcgencmd get_throttled:
estrangulado = 0x0

Desafortunadamente, get_throttled no funcionará en un Pi0 / Pi0w (no tiene el circuito de detección de bajo voltaje).

Por alguna razón, copiar y pegar el diff de JamesH65 no funcionó para mí. Hizo un archivo de parche que debería aplicarse de inmediato, pensé que la gente podría encontrar esto útil: https://github.com/bortek/EZ-WifiBroadcast/blob/master/kernel/linux-4.9.28-brcmfmac-tos.patch

El nombre del archivo dice 4.9.28, pero debería aplicarse al menos hasta 4.9.35 (y probablemente también los posteriores).

Copie este archivo en el directorio raíz del árbol del kernel y aplíquelo con patch -p1 < linux-4.9.28-brcmfmac-tos.patch

Información adicional (pero extraña):

Si el Pi Zero W está conectado a wlan0, pero por lo demás no hace nada (el script cron verifica el sntp cada 15 minutos como máximo), hay desconexiones muy frecuentes, algo del orden de 1-10 / hora que dura como máximo un segundo cada una.

Sin embargo, si tuviera algo usando la conexión, por ejemplo, inactivo en IRC (múltiples canales grandes), la conexión no se cae ni una sola vez durante todo el tiempo, este es el caso.

Resulta que cargar los módulos del kernel 4.9.39 en 4.9.35 no fue una buena idea.

Otro informe de error del foro, el error del buzón parece común.

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

El último kernel de actualización de rpi ahora incluye el parche de prioridad BCDC.

Cypress (era Broadcom) nos ha proporcionado nuevos lanzamientos de firmwares WiFi y Bluetooth para probar. Puede descargar un prelanzamiento aquí . Después de descargar a su Pi, ejecute:

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

Esto extraerá y luego instalará el nuevo firmware (primero se hará una copia de seguridad de las versiones anteriores).

Para volver al firmware original (lo que le recomiendo que haga antes de instalar una versión adecuada):

./brcmfw -u

Qué ha cambiado:

1. CVE-2017-9417: solución del problema "Broadpwn"
2. Agregue la cadena "CY" en la cadena de la versión.
3. Solución de interbloqueo del número de secuencia de AMPDU (posible solución para este problema)
4. Actualización de la versión CLM
5. CVE-2017-0572: corrección de corrupción de memoria

Solo una nota al margen: desactivé el wifi interno en mi primer Pi Zero W y cambié a un dongle wifi USB, todos los problemas desaparecieron. Hace unos días instalé otra Pi Zero W para controlar mi impresora 3D (usando OctoPi). Me sorprendió un poco ver que el wifi interno parece funcionar a la perfección, pero después de algunas pruebas puedo confirmar que el wifi se interrumpe tan pronto como me conecto desde mi teléfono LG G4 Android (navegador Chrome). Cuando lo pienso, supongo que el comportamiento en el primer Pi fue bastante similar ...
La conexión desde mi PC no produce tales efectos.

Pruebe el nuevo firmware e informe con sus hallazgos.

instalé el firmware de vista previa. Sigo recibiendo el error "raspberrypi kernel: brcmfmac: brcmf_sdio_hostmail: contenido de datos de buzón desconocido:", seguido de una falla de wifi.

¿Cuál es tu caso de uso?

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

probando la configuración de trabajo publicada allí. Voy a actualizar.

Proporcione la versión de su kernel, un resumen de los dispositivos conectados y el tiempo que tarda hasta que aparezca el error.

El error del buzón aún está bajo investigación, no lo espero.
firmware para arreglarlo. Hay más depuración en este firmware para ayudar a rastrear
aunque abajo. Si habilita la depuración del controlador (lo siento, en dispositivos móviles y
no tengo detalles sobre cómo hacer eso) y ver el error, luego volcar el
Los detalles de depuración y publicación aquí cuando reciba el error del buzón serían
útil.

El 13 de agosto de 2017 a las 21:40, "Stefan Wahren" [email protected] escribió:

Proporcione su versión de kernel, un resumen de los dispositivos conectados y
mucho tiempo hasta que aparece el error.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322062745 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHRwsQyHa-QqOP7ntTqgCfWlgXpEqks5sX1DlgaJpZM4HupC5
.

La depuración está deshabilitada de forma predeterminada y necesita una reconstrucción del módulo para habilitarla (quizás deberíamos cambiar eso durante estas investigaciones). Los cambios necesarios son la adición de BRCMDBG=y a .config seguido de una reconstrucción, luego agregue brcmfmac.debug=0x???????? a /boot/cmdline.txt , donde ???????? es un número hexadecimal que comprende el valores de bits documentados aquí: https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h#L22

Probé el firmware de prueba publicado por pelwell, el problema aún persiste. La conexión se congela cada 1 a 2 horas. Cuando se cortó la conexión e intenté hacer ping ( ping 8.8.8.8 ), está funcionando de nuevo _ brevemente_ hasta el octavo ping. El comportamiento del ping es constante en todos los casos. Trabajando-> congelar-> ping 8.8.8.8-> trabajando -> octavo ping -> congela Después de eso, necesito reiniciar mi raspberry pi. Aunque no sé si es de ayuda ...

Núcleo:
Linux raspberrypi 4.9.41-v7 + # 1023 SMP Mar 8 de agosto 16:00:15 BST 2017 armv7l GNU / Linux

Firmware:
BT: test_170808
Bandeja de WiFi: test_170808
Txt de WiFi: test_170808

¿Algo relevante en dmesg cuando sucede?

El 14 de agosto de 2017 13:16, "GIlang Charismadiptya" [email protected]
escribió:

Probé el firmware de prueba publicado por pelwell, el problema aún persiste.
La conexión se congela cada 1 a 2 horas. Cuando la conexión se cayó y yo
intentó hacer ping (ping 8.8.8.8), está funcionando de nuevo brevemente hasta el día 8
silbido. Después de eso, necesito reiniciar mi raspberry pi.

Núcleo:
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 Mar 8 de agosto 16:00:15 BST 2017 armv7l GNU / Linux

Firmware:
BT: test_170808
Bandeja de WiFi: test_170808
Txt de WiFi: test_170808

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

No, nada interesante. Tal vez porque no he reconstruido el módulo con soporte de depuración. ¿Cómo hacerlo? ¿O proporcionará el módulo compilado? Gracias.

A continuación se adjuntan los registros de 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
`

Consulte la publicación de Phil anterior para obtener detalles sobre el módulo de depuración. Somos particularmente
interesado en el seguimiento de depuración cuando se produce el error del buzón.

El 14 de agosto de 2017 a las 17:52, "GIlang Charismadiptya" [email protected]
escribió:

No, nada interesante. Tal vez porque no he reconstruido el módulo con
soporte de depuración. ¿Cómo hacerlo? ¿O proporcionará el módulo compilado?
Gracias.

Adjunto debajo del registro dmesg:

` pi @ raspberrypi : ~ $ sudo dmesg

[4.654722] brcmfmac: Versión de firmware = wl0: Versión de las 00:46:29 del 7 de agosto de 2017
7.45.41.46 (r666254 CY) FWID 01-f8a78378
[5.752968] smsc95xx 1-1.1: 1.0 eth0: el hardware no es capaz de
despierta
[5.753285] IPv6: ADDRCONF (NETDEV_UP): eth0: el enlace no está listo
[6.206530] IPv6: ADDRCONF (NETDEV_UP): wlan0: el enlace no está listo
[6.206577] brcmfmac: administración de energía deshabilitada
[7.088933] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: el enlace está listo
[7.340040] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: el enlace está listo
[7.340841] smsc95xx 1-1.1: 1.0 eth0: enlace activo, 100 Mbps, dúplex completo, lpa
0xCDE1
[7.431235] Añadiendo 102396k swap en / var / swap. Prioridad: -1 extensiones: 4
a través: 217088k SSFS
[10.182342] IPv6: ADDRCONF (NETDEV_UP): wlan0: el enlace no está listo
[10.182357] brcmfmac: administración de energía deshabilitada
[10.872838] IPv6: ADDRCONF (NETDEV_UP): wlan0: el enlace no está listo
[10.872903] brcmfmac: administración de energía deshabilitada
[11.594201] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: el enlace está listo
[14.128592] ip_tables: (C) Equipo principal de Netfilter 2000-2006
[14.172268] nf_conntrack versión 0.5.0 (15360 cubos, 61440 máx.)
[54.604680] aleatorio: crng init hecho

pi @ raspberrypi : ~ $ sudo dmesg -l err
[4.501055] raspberrypi-touchscreen 3f700000.dsi.0: firmware Atmel desconocido
revisión: 0xfa
'

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322228992 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHXuy3Eo5PqPAP8FfSFiYWMUQL7fAks5sYG1HgaJpZM4HupC5
.

El último kernel de actualización de rpi habilita BRCMDBG, que debería permitir la opción de línea de comando brcmfmac.debug=0x???????? sugerida anteriormente por @pelwell .

Errrr ..... mi Pi3 que era sólido como una roca con wifi ahora también lo pierde desde que actualicé a la última raspbian hace unos días :-(

¿Cuales son los sintomas? No esperaría una regresión en el firmware, o
de hecho, el propio conductor.

El 24 de agosto de 2017 a las 20:07, Crrispy [email protected] escribió:

Errrr ..... mi Pi3 que era sólido como una roca con wifi ahora también lo pierde ya que
actualizado a la última raspbian hace unos días :-(

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-324728431 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHUxvLV3OzKGpcmEMGEoSad_piujBks5sbcoHgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

@Crrispy
Prueba esto:
Eliminé toda mención de eth0 de mi archivo / etc / network / interfaces, reemplacé allow-hotplug con auto, y luego forcé el apagado inalámbrico en wlan0 y wlan1.

mi archivo / 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`

Entonces enrojecí arp:

ip -s -s relinchar todo

Luego reinicié:

sudo reiniciar ahora

Estoy bastante seguro de que me encuentro con este error de forma regular. Ejecutar hostapd, usar el wifi interno de Broadcom para alojar un punto de acceso y enrutar a los clientes que se conectan a él a través de un dongle wifi USB que sirve como cliente inalámbrico. Hay varios dispositivos conectados, pero tan pronto como llevo el Pi fuera del alcance de los dispositivos conectados, parece que se produce el bloqueo de wlan. Al igual que con otros, es solo el dispositivo interno de wlan de broadcom el que se cae: ethernet y el otro wlan no se ven afectados. También recibo el error de "buzón" en el registro del sistema:

Aug 27 08:34:38 raspberrypi kernel: [40063.859420] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

(más detalles de registro en https://pastebin.com/NPB00ZEq)

Me había dado cuenta de que la salida de iwconfig ya no muestra el valor Tx_Power cuando el dispositivo wlan está en su estado fallido, así que lo he usado para programar un reinicio automático como una solución mientras tanto.

Acabo de actualizar a la última actualización de rpi, instalé los controladores wifi de prueba mencionados anteriormente y agregué el indicador de depuración a mi cmdline.txt, usando el valor hexadecimal para BRCMF_TRACE_VAL: bcrmfmac.debug=0x00000002

Si puede obtener regularmente el error del buzón, le agradeceríamos los resultados del controlador de depuración. Cuando reciba el error del buzón de correo, haga algo como esto para obtener los análisis forenses y publicar los resultados aquí. Puedo transmitirlos a Cypress, que está investigando el problema.

cat /sys/kernel/debug/brcmfmac/mmc1\:0001\:1/forensics

Bueno, lo que era un problema que se reproducía fácilmente ya no puedo duplicarlo, desde que ejecuté rpi-update. Es posible que pueda hacer que suceda degradando a una nueva instalación de la versión Raspbian del 21 de junio de 2017, si eso fuera útil.

@ JamesH65
Se las arregló para capturar los análisis forenses que había solicitado (después del error del buzón de correo), pero para ser claros, esto es después de degradar al kernel incluido en la compilación Raspbian del 21 de junio. Es posible que ya se haya resuelto, porque aún no he duplicado el problema después de instalar el firmware de prueba publicado por @pelwell hace unas dos semanas y ejecutar rpi-update.

Aquí hay un enlace a la ciencia forense:
https://pastebin.com/VVqVQ8FW

Espero que sea útil ...

Así que sospecho que con el firmware antiguo. Esperamos obtener los forenses para
el nuevo firmware que tiene mensajes adicionales (aparentemente) destinados a rastrear
por el problema del buzón. Esto me hace pensar que Cypress todavía parece pensar que
El problema del buzón estará allí, incluso después de las otras correcciones. Pasará los datos de todos modos en caso de que sirva de ayuda.

¡Es bueno saber que los errores son mucho más difíciles de reproducir!

El 29 de agosto de 2017 a las 15:51, randyoo [email protected] escribió:

@ 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=
Se las arregló para capturar los análisis forenses que había solicitado, pero para ser claros,
esto es después de degradar al kernel incluido en Raspbian del 21 de junio
construir. Es posible que ya se haya resuelto, porque no puedo
duplicar el problema después de instalar el firmware de prueba publicado por @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=
hace unas dos semanas.

Aquí hay un enlace a la ciencia forense:
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=

Espero que sea útil ...

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Esto me hace pensar que Cypress todavía parece pensar que
El problema del buzón estará allí, incluso después de las otras correcciones.

Sí, eso también lo entiendo.

@randyoo Gracias por los comentarios positivos.

@ JamesH65
De acuerdo, sucedió de nuevo, esta vez con el último firmware de actualización de rpi y usando el firmware de prueba publicado por @pelwell . Desafortunadamente, la salida forense parece idéntica a la de la publicación anterior. (No estoy seguro de por qué no obtengo información diferente / más detallada en el volcado forense, ya que tengo habilitada la depuración en mi cmdline.txt, según mi publicación anterior)

Seguí adelante y volqué el contenido de las otras cosas / sys / kernel / debug también. Aquí está: https://pastebin.com/pdFUPBxN

En la última congelación de wlan, el rastreo del registro del kernel parece ser más detallado. Ver el enlace:
https://pastebin.com/KTxbgpYV

Espero que ayude.

¿Hubo más detalles en el análisis forense del firmware? Creo que es el
bit Cypress está realmente interesado en cuándo ocurre el error del buzón.

El 31 de agosto de 2017 a las 21:56, randyoo [email protected] escribió:

En la última congelación de wlan, el rastreo del registro del kernel parece ser más detallado.
Ver el enlace:
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=

Espero que ayude.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Bien, lo siento. Se las arregló para obtener una captura de los forenses, y sí, parece haber muchos más detalles allí:
https://pastebin.com/qypfAfAp

Como a veces me ayudan los casos nuevos, también lo obtengo de vez en cuando:

pi @ jempi : ~ $ grep "brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012" / var / log / syslog
14 de agosto 22:16:23 kernel jempi: [501.247242] brcmfmac: brcmf_sdio_hostmail: contenido de datos de buzón desconocido: 0x40012
17 de agosto 20:26:20 kernel jempi: [509.684277] brcmfmac: brcmf_sdio_hostmail: contenido de datos de buzón desconocido: 0x40012
24 de agosto 23:57:37 kernel jempi: [573.652189] brcmfmac: brcmf_sdio_hostmail: contenido de datos de buzón desconocido: 0x40012
29 de agosto 23:50:16 kernel jempi: [5052.517999] brcmfmac: brcmf_sdio_hostmail: contenido de datos de buzón desconocido: 0x40012
30 de agosto 00:02:18 kernel jempi: [170.978988] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012
30 de agosto 23:58:03 kernel jempi: [8254.502431] brcmfmac: brcmf_sdio_hostmail: contenido de datos de buzón desconocido: 0x40012
2 de septiembre 00:33:28 kernel jempi: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012

Estoy usando el wifi interno (wlan0) como AP y conecté un dongle (wlan1) para conectarme a mi enrutador:
pi @ jempi : ~ $ ifconfig wlan0
wlan0 Encapsulado de enlace : Ethernet HWaddr b8: 27: eb: cf: db: b8
inet addr: 10.3.141.1 Bcast: 10.3.141.255 Máscara: 255.255.255.0
inet6 addr: fe80 :: 6b56: 4657: 75cd: a501 / 64 Alcance: Enlace
UP BROADCAST EJECUTANDO MULTICAST MTU: 1500 Métrico: 1
Paquetes RX errores: 0 descartados: 0 desbordamientos: 0 trama: 0
Paquetes TX errores: 0 descartados: 0 desbordamientos: 0 portadora: 0
colisiones: 0 t x cola: 1000
Bytes RX Bytes TX

pi @ jempi : ~ $ ifconfig wlan1
encapsulación de enlace wlan1: Ethernet HWaddr 00: 60: b3: db: 8a: 4a
inet addr: 192.168.1.74 Bcast: 192.168.1.255 Máscara: 255.255.255.0
inet6 addr: fe80 :: 260: b3ff: fedb: 8a4a / 64 Alcance: Enlace
UP BROADCAST EJECUTANDO MULTICAST MTU: 1500 Métrico: 1
Paquetes RX errores: 0 descartado: 2 desbordamientos: 0 trama: 0
Paquetes de TX errores: 0 descartado: 0 desbordamientos: 0 portadora: 0
colisiones: 0 t x cola: 1000
Bytes RX Bytes TX

Tenía el kernel 4.9.35-v7 + y lo actualicé ayer a 4.9.46-v7 + (con rpi-update) pero no ayuda. Entrada de syslog cuando falla:

2 de septiembre 00:33:28 kernel jempi: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012
2 de septiembre 00:34:00 kernel jempi: [6011.624839] brcmfmac: brcmf_netdev_wait_pend8021x: Se agotó el tiempo de espera para no tener paquetes 802.1x pendientes
2 de septiembre 00:34:02 kernel jempi: [6014.184823] brcmfmac: send_key_to_dongle: error wsec_key (-110)
2 de septiembre 00:34:05 kernel jempi: [6016.744833] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON falló -110
2 de septiembre 00:34:06 kernel jempi: [6017.704831] brcmfmac: brcmf_netdev_wait_pend8021x: Se agotó el tiempo de espera para que no haya paquetes 802.1x pendientes
2 de septiembre 00:34:08 kernel jempi: [6020.264850] brcmfmac: send_key_to_dongle: error wsec_key (-110)
2 de septiembre 00:34:11 kernel jempi: [6022.824903] brcmfmac: brcmf_cfg80211_change_station: No se pudo establecer la (des) autorización de SCB, -110

Reiniciar la interfaz wlan0 con sudo ifconfig wlan0 hacia abajo y luego hacia arriba no ayudó.

@bulrog Proporcione también los datos forenses como explicó James anteriormente.
¿Qué controlador usa wlan1? ¿Sigue ocurriendo este problema con el dongle desenchufado?

Algunas capturas forenses más:
https://pastebin.com/vqh3UcF3

En caso de que esto ayude a Cypress a buscar en el área correcta: he experimentado este problema muchas, muchas veces, y parece manifestarse cada vez que un dispositivo intenta conectarse. Ha sucedido muchas veces después de entrar al alcance del AP o cuando se despierta un dispositivo para dormir.

He mantenido esta configuración el tiempo suficiente para capturar datos forenses, y si hay más detalles que pueda proporcionar, estaría feliz de hacerlo, pero las fallas de WLAN ahora ocurren con tanta frecuencia que hace que mi dispositivo sea inútil. Tengo la intención de usar otro dongle wifi USB para reemplazar la radio interna, para lograr confiabilidad.

Le he transmitido sus análisis forenses más recientes a Cypress. Gracias por tomarse el tiempo.

Solo quería intervenir. Tengo exactamente el mismo problema en tres RPI3 que ejecutan el firmware más reciente. Estoy usando Octopi en los tres y accedo a ellos a través de Printoid.

bcrmfmac.debug debería ser brcmfmac.debug (gracias por ver a @MilhouseVH)
Editaré las publicaciones anteriores.

bcrmfmac.debug debería ser brcmfmac.debug (gracias por ver a @MilhouseVH)
Editaré las publicaciones anteriores.

Basado en esto, asumí que los análisis forenses que capturé no estaban completos.

He repetido la captura forense, se puede leer en la siguiente URL:
https://pastebin.com/ha5rd7SW

Además, mi archivo /var/log/kern.log tiene un tamaño cercano a los 200 MB, y la mayoría consta de entradas muy similares. Localicé el error del buzón en 00:53:19 y corté un par de segundos antes y después del error. Ojalá te ayude, míralo aquí:
https://pastebin.com/JcE0zstS

así que creo que encontré el mismo problema, consulte https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=192735

Puedo reproducirlo en 5 minutos. Necesita una gran cantidad de tráfico a través de wifi (interfaz web de la cámara) y una señal wifi muy baja. Tengo pi cero y es suficiente para poner su dedo / manos alrededor de la antena a bordo para que la señal sea casi cero (mi enrutador muestra una señal del 15-20%). Después de aproximadamente 1 minuto en este estado, el wifi se bloquea

@lategoodbye después de una semana https://pastebin.com/77tGfRcU

para wlan1, utilicé un dongle bastante antiguo. No recuerdo qué controlador tuve que instalar para que funcionara, pero esto es lo que proporciona lsusb para el HW que uso:

Bus 001 Dispositivo 005: ID 0 cde: 0008 Adaptador inalámbrico Z-Com XG-703A 802.11g [Intersil ISL3887]

No sé si eso ayuda, pero esta es mi experiencia:

Compré un Pi3 y lo probé durante unos días con wifi interno (no muy lejos del AP), y pareció funcionar bastante bien (no esperaba altas tasas de bits, solo tenía que ser útil para un shell remoto a través de ssh ).

Después de ponerlo en una caja de aluminio, todavía parecía estar bien al principio, pero luego el wifi se volvió inutilizable al azar. Hasta minutos sin ping. Todavía hubo ocasiones en las que funcionó muy bien durante algunos segundos, pero volvió a cambiar a la experiencia de "una pulsación de tecla por segundo" o dejó de funcionar por completo.

Parece que no hay una conexión "lenta pero utilizable" posible, sólo una "muy buena" o "inutilizable". Esto puede deberse a un error en el firmware. No tengo idea y, francamente, perdí la paciencia y en su lugar utilicé un dongle usb muy pequeño que funciona 100% estable.

¿Alguien ha encontrado una solución para detectar el problema (en modo AP) y reiniciar programáticamente el dispositivo wlan?

No que yo vi, reiniciar la interfaz no ayudó. Para mí la contención fue comprar un dispositivo usb wifi externo y funciona como un encanto pero es una lástima ya que ahora apagué el wifi del pi (¡suspiro!)

¿Te refieres al problema del buzón? Eso todavía está bajo investigación en Cypress.

El 21 de septiembre de 2017 a las 08:38, "morel jerome" [email protected] escribió:

No que yo vi, reiniciar la interfaz no ayudó. Para mi la contención
era comprar un dispositivo usb wifi externo y funciona como un encanto, pero es
una pena como ahora apago el wifi del pi (suspiro!)

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en 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= ,
o silenciar el hilo
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=
.

Sí, el problema del buzón. Espero que se solucione, pero como contención tuve que cambiar a un dispositivo externo.

OKAY. Estamos a merced de Cypress en este caso: es un problema de firmware y son los únicos con acceso. Seguiré recordándoles ... es posible que necesitemos más análisis forenses, pero publicaremos aquí si ese es el caso.

mi wlan se desconecta y vuelve a conectarse después de unos segundos de inactividad (supongo que esto ahorra energía, aunque lo desactivé con iw, o tal vez interferencia). No estoy seguro si este es el mismo problema que se discutió aquí (ya que se vuelve a conectar de inmediato).

Si me conecto con ssh -o ServerAliveInterval 5 ... ya no se desconecta.

$ uname -a
Linux pi3 4.4.50-hypriotos-v7+ #1 SMP PREEMPT Sun Mar 19 14:11:54 UTC 2017 armv7l GNU/Linux

@asssaf ,
No es el problema, si se vuelve a conectar, generalmente solo será un problema de latencia, pero cuando se ejecuta sin cabeza a través de WiFi (una de las principales características potenciales del PiZero-W) cuando el WiFi se desconecta y no se vuelve a conectar automáticamente, el sistema se ha bloqueado para todos los propósitos prácticos.

Incluso si tengo HDMI, mouse y teclado bajo cargas de red pesadas como con Motioneye, a veces la única forma de recuperar es apagando y apagando.

He repetido la instalación y configuración de Motioneye en un Pi2 con un dongle WiPi USB WiFi y hasta ahora ha funcionado perfectamente con cargas que mataron de manera confiable el PiZero-W en unas pocas horas. Para mí, esto parece confirmar que es un problema de controlador / chip WiFi y no un problema con Raspbian-stretch.

@ PeterTheMaster1 @randyoo @joshfria

De acuerdo, mensaje para cualquiera que vea el problema del buzón de correo con regularidad y pueda probar algo por mí.

Tenemos un firmware de diagnóstico de Cypress, que puede ayudar a localizar el problema. Si alguien con el problema del buzón de correo estaría dispuesto a ejecutar este firmware, y cuando ocurra el problema del buzón de correo, descargue los análisis forenses y publique los resultados aquí, será de gran ayuda. Tenga en cuenta que este firmware no debe usarse para nada más que para esta prueba, ya que no será óptimo. Por favor comente aquí si puede hacer la prueba, y me pondré en contacto con el firmware y las instrucciones.

@iurly : escribí un script que detectaría el problema y luego reiniciaría, ya que bajar y subir la interfaz no ayudó ... Pero entonces se reiniciaba con tanta frecuencia, que solo podía obtener un dispositivo útil tomándolo fuera del modo AP (y asignando tareas AP a mi dongle USB)

@ JamesH65 : Estaría feliz de ayudar, como antes. ¿Es una nueva versión del firmware de diagnóstico? Publiqué una captura forense hace 3 semanas (en esta página de problemas) usando el firmware de diagnóstico / depuración publicado anteriormente en esta página.

Sí, nuevo firmware de Cypress a partir del lunes 25 de septiembre. Tiene más
diagnósticos en él. Los análisis forenses anteriores que proporcionó se han reducido
el problema, necesitan un poco más de detalle. He estado ejecutando una máquina
durante 24 horas hasta ahora sin error de buzón, por lo que actualmente no se puede replicar
yo mismo.

¿Me pueden enviar un correo electrónico a James. [email protected] y puedo

El 27 de septiembre de 2017 a las 14:48, randyoo [email protected] escribió:

@iurly https://github.com/iurly : escribí un script que detectaría
el problema, y ​​luego reinicie, ya que bajó y subió la interfaz
no ayudó ... Pero entonces se reiniciaba tan a menudo, que solo podía obtener un
dispositivo útil sacándolo del modo AP (y asignando tareas AP a mi
Dispositivo USB)

@ JamesH65 https://github.com/jamesh65 : Estaría feliz de ayudar, ya que
antes de. ¿Es una nueva versión del firmware de diagnóstico? Publiqué un
captura forense hace 3 semanas (en esta página de problemas) utilizando el
firmware de diagnóstico / depuración publicado anteriormente en esta página.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332526471 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHW_vEVuxFD-9RuxE003QZc_2NoFaks5smlIjgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

@ JamesH65 Si tuviera la amabilidad de proporcionar un enlace al nuevo firmware, puedo instalarlo e intentar capturar datos forenses nuevamente, como lo solicitó.

Desafortunadamente, proporcionar un enlace aquí significa que está disponible públicamente, y
ya que se trata de un firmware de prueba, preferiría que no se me escapara
lo salvaje. De ahí que solicite hacerlo por correo electrónico. Si eso es un problema, subiré
en algún lugar y puede publicar un enlace.

El 27 de septiembre de 2017 a las 15:56, randyoo [email protected] escribió:

@ JamesH65 https://github.com/jamesh65 Si fuera tan amable de
proporcionar un enlace al nuevo firmware, puedo instalarlo e intentar capturar
forense de nuevo, como había solicitado.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332548884 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHbVhHD2rk_hp3kG51WBY0R0IQzL3ks5smmIbgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

@ JamesH65 Sé que tengo congelación regular de la tarjeta inalámbrica interna del RPI3 en modo AP, así que estaría más que dispuesto a ayudar, pero no estoy muy seguro de que sea el problema del buzón o algo más. De hecho, busqué en mis registros ese mensaje pero no lo encontré.

Estoy ejecutando el firmware enviado con el kernel 4.4.50 (y realmente no puedo actualizar a la última versión 4.9 debido a una regresión, ver # 2197), ¿esa versión mostraría ese mensaje o se agregó en una etapa posterior?

¡Gracias!

@iurly , dijiste una cosa bien, el problema de bloqueo en los controladores de broadcom ocurre en modo AP, y no sé si esto está relacionado con el error del buzón. parece que hay más de 1 error aquí, tal vez sea un error de hardware debido al momento en que existe el problema y no se encontró una solución.

Lo que realmente me molesta es la falta de una solución alternativa, salvo reiniciar todo el sistema.
Quiero decir, ¿ni siquiera hay una manera de restablecer el periférico y reiniciar hostapd?!?

@iurly , dijiste una cosa bien, el problema de bloqueo en los controladores de broadcom ocurre en modo AP, y no sé si esto está relacionado con el error del buzón. parece que hay más de 1 error aquí, tal vez sea un error de hardware debido al momento en que existe el problema y no se encontró una solución.

Solo para su información, también estoy teniendo problemas en el modo cliente / estación. Ejecutando LEDE master, kernel 4.9 y usando firmware 7.45.41.46.

@ JamesH65
Comprenda el deseo de evitar que se publique el firmware de prueba. El correo electrónico estaría bien, pero tampoco quiero publicar mi dirección aquí públicamente, y no veo una forma de enviar mensajes en github.

Use mi dirección pi anterior para enviarme un correo electrónico y le enviaré el firmware.

Re. Modo ap
Ha habido algunas correcciones desde la 4.4, por lo que vale la pena probar el último tramo
para ver si ese problema persiste.

Ah, cuando editas un comentario no se envía ninguna actualización por correo electrónico, y yo edité en mi correo electrónico Pi en la entrada anterior, por lo que es posible que no hayas sido actualizado. Use el sitio web de github para ver dónde necesita enviarme un correo electrónico.

@ JamesH65 Te envió un correo electrónico. Me alegra saber que la captura forense anterior ayudó a reducirlo, al menos ... Parece que muchas personas estarán complacidas cuando se resuelva este problema.

@ JamesH65
Aquí hay una captura forense del firmware que envió por correo electrónico: https://pastebin.com/zdB36ttj
Espero eso ayude.

Impresionante, pasará a Cypress. Gracias por hacer eso.

Tengo un pi en una configuración en este momento donde parece que puedo reproducir esto a voluntad. Si es útil recopilar más datos forenses, hágamelo saber. El error del buzón es todo lo que puedo ver en los registros.

Después de reemplazar la microSD en mi Zero W, ha estado conectada durante 7 días sin problemas. No creo que haya sobrevivido tanto tiempo. Suena extraño que una tarjeta SD pueda influir en el WiFi, pero como ambas están conectadas al bus SDIO, es posible que una influya en la otra.

La tarjeta que usé antes era una Transcend clase 4 de 8GB (probablemente barata) que venía con mi placa UDOO Quad. Ahora mismo es un Samsung EVO de 32 GB. Las personas que tienen problemas pueden querer intentarlo si el uso de una tarjeta diferente ayuda.

@stintel Interesante, pero tal vez fue algún problema al configurar el software en la otra microSD, o incluso una microSD dañada.

¿Podría estar relacionado con el poder? ¿Quizás la tarjeta barata extrajo momentáneamente demasiada energía del autobús?

Cargué el firmware publicado por Pelwell y vi una GRAN mejora. Antes, un SSH en mi Pi 0W era como marcar en un terminal con un módem de 2400 baudios y una línea telefónica de mala calidad. Ahora puedo ejecutar Remote X y funciona muy bien.

¡Gracias!

Yo tengo el mismo problema. Al transferir una gran cantidad de nombres de archivos (sincronización a través de ftp) desde raspberryPi3-internal-wifi al Galaxy S5, el wifi deja de funcionar. pero algunas veces funciona ...

Tuve el mismo problema del mensaje del buzón con mi AP WiFi RPi3, pero encontré una solución en este foro , y funcionó para mí. La solución fue cambiar los siguientes parámetros en /etc/hostapd/hostapd.conf

wpa = 3 cambiado a wpa = 2auth_algs = 3 cambiado a auth_algs = 1

Lo probé durante 1 semana y ya no muestra problemas con el buzón.

No estoy seguro de si funcionaría para todos ustedes, pero podrían probarlo y publicarlo aquí si funciona.

Este es el hostapd de trabajo, 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

¿Alguna actualización sobre este tema? ¿O hay alguna solución alternativa conocida?

Sigo experimentando esto en un Pi Zero W comprado recientemente con los últimos stretch-lite y rpi-update de ayer.

Usando el RPi para transmitir una cámara a través de RTSP (udp), puedo ver que la conexión empeora drásticamente justo antes de que se corte la conexión WiFi, después de eso, la conexión WiFi nunca se recupera y tengo que apagar y encender el Pi0W.

A dmesg > dmesg.log solo muestra:

brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Si muevo el Pi0W más cerca de mi punto de acceso, el problema no ocurre.

No estoy usando el Pi0W como punto de acceso, es solo un cliente. He probado diferentes fuentes de energía.

Actualmente estamos esperando a Cypress, los proveedores del chip inalámbrico,
para avanzar en el problema. Les haré ping de nuevo.

El 25 de octubre de 2017 a las 14:02, Matthias Urhahn [email protected]
escribió:

¿Alguna actualización sobre este tema? ¿O hay alguna solución alternativa conocida?

Sigo experimentando esto en un Pi Zero W comprado recientemente con lo último
stretch-lite y rpi-update a partir de ayer.

Usando el RPi para transmitir una transmisión de cámara a través de RTSP (udp) puedo ver el
la conexión empeora drásticamente justo antes de que se interrumpa la conexión WiFi,
después de eso, la conexión WiFi nunca se recupera y tengo que apagar y encender el
Pi0W.

Un dmesg> dmesg.log solo muestra:

brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012

Si muevo el Pi0W más cerca de mi punto de acceso, el problema no ocurre.

No estoy usando el Pi0W como punto de acceso, es solo un cliente. Yo he tratado
diferentes fuentes de energía.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-339322153 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHRlPhJBGXc3JFWbpw_Tf4_EKmgAeks5svzFQgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Bueno ... me he actualizado al último kernel / firmware (apt-get upgrade luego rpi-update), y ahora, ¡incluso mi Pi3, que tenía un wifi sólido como una roca, también lo está perdiendo después de unas horas! Lo sé, si no está roto, no lo arregles ... no debería haber actualizado, pero como hago pruebas de vez en cuando en mi segundo Pi3 con la misma tarjeta SD ...

FWIW, también puedo reproducir este problema a voluntad. Creé una publicación en el foro en Raspberry Pi que explica el problema:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=196018&p=1226143#p1226143

NOTA: No estoy usando el Pi como AP. Puedo ayudar con análisis forense o probar un firmware experimental, etc. si eso ayuda.

El mismo problema aqui. Configuré ownCloud y puedo transferir archivos desde mi computadora portátil sin ningún problema.
Pero tan pronto como transfiero archivos con mi Samsung Galaxy S7, el wifi se rompe y
raspberrypi kernel: [ 962.273390] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012 :
aparece.

Mi enrutador es un FRITZ! Box 7490.

¡Gracias @srinathava por la publicación que describe bien mi problema!

Las personas que han probado con el firmware de prueba pueden intentar lo siguiente: más información de depuración requerida por Cypress.

1. al hacer insmod, agregue "debug = 0x100000"
2. una vez que ocurra el problema, guarde la salida "dmesg"

Gracias.

Otra solicitud de ayuda en este caso.

Las personas que han probado con el firmware de prueba (ver arriba) pueden intentar lo siguiente: más información de depuración requerida por Cypress.

al hacer insmod, agregue "debug = 0x100000"
una vez que ocurra el problema, guarde la salida "dmesg" - este es el bit que nos interesa.

Gracias.

@ JamesH65 Solo para informarle, ahora estoy intentando recopilar la información, pero el problema aún no se ha mostrado. Solo hice unos pocos cambios pequeños en el archivo /etc/hostapd/hostapd.conf, pero esos cambios pueden haber solucionado este problema sin darme cuenta. Si el problema no se presenta en unos días, revertiré esos cambios en un intento de replicar el problema y recopilar los datos de depuración.

Gracias por la ayuda en esto.

Sería interesante ver los cambios que realizó en hostapd si, de hecho, eso soluciona el problema.

Después de 4 días de estabilidad, revertí mis cambios en el archivo /etc/hostapd/hostapd.conf y, después de unas pocas horas, el problema volvió a aparecer. Aquí está la salida de 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

Estoy ejecutando un paquete de software llamado RaspAP y estoy bastante seguro de que configuró el archivo hostapd.conf en mi nombre, aunque no estoy 100% seguro.

De todos modos, comentando esta línea en /etc/hostapd.conf: y reemplazándolo con esto: Tuve una operación estable durante 4 días seguidos, mientras que solía colapsar en unas pocas horas, ¡o incluso en minutos!

Espero que todo esto ayude.

Disculpas si estoy publicando en el lugar equivocado, estoy experimentando un comportamiento extraño con el wlan interno de RPi3 (broadcom) al enviar paquetes UDP Unicast bajo raspbian.
Envío un pequeño paquete de datos de 2 kb una vez por segundo, en el extremo del receptor se bloquea cada 120 segundos durante unos 3-4 segundos. Esta prueba funciona como un reloj y puedo reproducir con iperf haciendo lo siguiente

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

Ubuntu PC conectado como cliente WiFi a RPi3 (IP 192.168.1.22 como arriba)

iperf -u -s -i 1

Garantizó un bloqueo cada 120 segundos. Interesante, esto no parece ocurrir usando TCP
Finalmente, después de descargar y mirar el código del controlador (y sin entender nada) noté una mención sospechosa de

definir BRCMF_SCAN_PASSIVE_TIME 120

Que luego se usa en el código del controlador

¿Podría esto estar relacionado, estoy al final de mi ingenio tratando de resolver?
Gracias

Puse lo siguiente en /etc/rc.local y el mío parece funcionar mucho mejor:

Iwconfig wlan0 apagado

PI cero w

Sean

El 19 de diciembre de 2017, a las 3:42 a.m., LeeMooreImperas [email protected] escribió:

Disculpas si estoy publicando en el lugar equivocado, estoy experimentando un comportamiento extraño con el wlan interno de RPi3 (broadcom) al enviar paquetes UDP Unicast bajo raspbian.
Envío un pequeño paquete de datos de 2 kb una vez por segundo, en el extremo del receptor se bloquea cada 120 segundos durante unos 3-4 segundos. Esta prueba funciona como un reloj y puedo reproducir con iperf haciendo lo siguiente

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

Ubuntu PC conectado como cliente WiFi a RPi3 (IP 192.168.1.22 como arriba)

iperf -u -s -i 1

Garantizó un bloqueo cada 120 segundos. Interesante, esto no parece ocurrir usando TCP
Finalmente, después de descargar y mirar el código del controlador (y sin entender nada) noté una mención sospechosa de

definir BRCMF_SCAN_PASSIVE_TIME 120

Que luego se usa en el código del controlador

¿Podría esto estar relacionado, estoy al final de mi ingenio tratando de resolver?
Gracias

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

Hola sean
Gracias por avisar, desafortunadamente, esto no es aceptado por el dispositivo de broadcom

Error for wireless request "Set Power Management" (8B2C) 
    Set failed on device wlan0; Invalid argument

Sin embargo, utilizo el siguiente comando en mi configuración para lograr el mismo objetivo
$ iw dev wlan0 set power_save off
esto se acepta y si pregunto la configuración
$ iwconfig wlan0
Veo
Power Management:off

Estoy bastante seguro de que el ahorro de energía está desactivado, pero no resuelve este problema
Gracias

@LeeMooreImperas Sugiero abrir un problema separado para esto y proporcionar al menos la versión del Kernel y la versión del firmware Wifi.

Comenté este hilo hace mucho tiempo, pero luego tuve que dejar de mirarlo porque ya no podía reproducirlo. Bueno, tengo algunos datos nuevos y los encuentro muy interesantes.

Tengo dos Raspberry Pi; un B + V1.2 y un Raspberry PI (C) 2011 original.

Si ejecuto "4.1.19+ # 858 Tue Mar 15 15:52:03 GMT 2016" en la RaspPi B +, el chip WiFi de Edimax exhibirá el problema que otros han visto.

Si ejecuto "4.9.27+ # 1 Thu May 11 17:40:53 UTC 2017" en la misma RaspPi B +, el mismo chip WiFi de Edimax no mostrará el problema.

Ahora me pregunto si es más una incompatibilidad con el hardware y también me recuerda que con las placas RaspPi mucho más antiguas, el WiFi USB necesitaba un cable especial para aumentar la potencia de + 5V porque la potencia que provenía de la placa no era t suficiente para conducirlo. Voy a cambiar las tarjetas SD para que muestren el problema y luego veré si este tipo de cable ayuda.

Ok, creo que tenía eso incorrecto.

Ejecutar 4.9.27+ en la RaspPi anterior presentará el problema. Verificando ahora.

Ok, esto es definitivo y muy interesante.

Usando una placa Raspberry Pi original (alrededor de 2011) y ejecutando Linux 4.9.27+ (de "uname -a"), puedo reproducir el problema del chip WiFi USB Edimax que pierde la conexión WiFi y, por lo tanto, la dirección IP, cada vez , en unos minutos.

Usando la misma placa Raspberry Pi original y la misma versión de Linux, pero el ÚNICO cambio de simplemente usar un cable USB que me permite aumentar los + 5V al USB WiFi desde una fuente secundaria, el sistema es estable.

Entonces, definitivamente parece haber un problema con la tarjeta WiFi USB Edimax que no recibe suficiente energía en esta configuración. Esto, obviamente, no ayuda a aquellos que están usando una Raspberry Pi con WiFi incorporado, pero en esos casos me pregunto si tal vez esté ocurriendo un problema similar y si quizás se muestre el cambio a un adaptador USB que produce más amperios. ¿una diferencia?

Es posible que el adaptador de red a USB que alimenta el Pi no esté dando 5V limpios en algunos casos.
Dado que la CA debe regularse y luego suavizarse antes de que se convierta en 5V, todavía se obtiene un poco de ondulación en la CC de salida.
Es más probable que los 5V de una computadora portátil o PC estén libres de ondulaciones que un cargador barato de red a USB

Sería interesante colocar un osciloscopio en la fuente de alimentación del chip wifi en diferentes condiciones para ver cómo es la ondulación durante la falla / no falla

Por favor, mantenga este problema en problemas con el chip inalámbrico ONBOARD Brcm en el Pi3; si tiene problemas con otros dispositivos, use el foro para obtener consejos. Esto es simplemente para que la información que necesitamos transmitir a Cypress no se confunda demasiado.

@ JamesH65
@lategoodbye

Hola James, Stefan,
Entonces, mensajes contradictorios aquí, el problema que registré estaba directamente relacionado con RPi3 BRCM WiFi.
Entonces, ¿debería ir en un hilo diferente (como lo sugiere lategoodbye)?
¿Hubiera pensado que este hilo trata específicamente sobre mi problema?

Estoy feliz de mover el problema

Gracias

@LeeMooreImperas Aunque su problema es con la conexión inalámbrica a bordo, la

Añadiendo otro "yo también" en esto.
Hardware: Raspberyy Pi 3, Modelo B.
Kernel: Linux raspberrypi 4.9.70-v7 +
SO: Raspbian GNU / Linux 9 (estirado)
Imagen cargada: 2017-11-29-raspbian-stretch.img
Imagen MD5:
Tarjeta SD: no estoy seguro del fabricante, viene con el kit
Archivo de interfaces :
hostapd.conf: hostapd.txt
salida dmesg (mientras trabaja): dmesg_20171230.txt

El dispositivo está configurado como un punto de acceso para mi red inalámbrica. Mi enrutador principal es un firmware Linksys EA6400 versión 1.1.40 (compilación 184085). Tanto el Linksys como el Pi ofrecen el mismo SSID en diferentes canales. Pi está conectado al enrutador a través de una conexión por cable con un interruptor no administrado en el medio.
La carga del sistema operativo en el dispositivo es bastante reciente. Tenía una imagen RetroPie en el sistema y enfrenté los mismos problemas. Recargué a Raspbian para ver si funcionaba mejor.
Veo abandonos esporádicos del puente. El síntoma principal es que la red inalámbrica proporcionada por Pi parece estar aislada de la red cableada. La interfaz cableada sigue funcionando normalmente y puedo acceder al Pi a través de SSH. Si ejecuto un tcpdump en la interfaz inalámbrica (wlan0), mientras estoy en ese estado, todavía puedo ver el tráfico hacia y desde los dispositivos conectados.
Ciclar la conexión inalámbrica (ifdown; ifup) no parece solucionar el problema. Todavía no he probado a ciclar la interfaz del puente (br0) todavía. En general, he estado reiniciando el dispositivo que soluciona el problema.
No estoy seguro de que esté relacionado; sin embargo, el problema parece aparecer cuando intento controlar mi ChromeCast 2 después de haber estado funcionando durante un tiempo. Por ejemplo, si estoy reproduciendo un programa a través de Netflix en ChromeCast y luego trato de pausar el programa, el puente parece desaparecer en ese momento. Todavía no he podido detectar esto a través de tcpdump; pero ese es el siguiente paso para mí.
He considerado que podría ser un problema de calor; sin embargo, tenía /opt/vc/bin/vcgencmd measure_temp ejecutándose en un ciclo de 30 segundos durante uno de los abandonos y la temperatura de mi CPU estaba en el rango de 50 ° C. No estoy seguro de cómo obtener una lectura de temperatura en el chip LAN, ya que puede ser allí donde surja un problema de calor.

Me complace capturar registros / pcaps según sea necesario para ayudar a solucionar el problema aún más. Sin embargo, sea explícito en las instrucciones ya que tengo bastantes lagunas en mi conocimiento sobre Linux.

EDITAR: acabo de abandonar e hice un sudo ifdown br0 && sudo ifup br0 y parece haber comenzado a funcionar nuevamente. Volveré a probar en mi próxima deserción.

EDIT2: Aquí hay un volcado de dmesg con la conexión fallida. El sudo ifdown br0 && sudo ifup br0 no pareció recuperar la conexión esta vez.
dmesg_20171220_failed.txt
De particular interés parece ser el error:
brcmfmac: brcmf_cfg80211_stop_ap: la configuración del modo INFRA falló -7

EDIT3: encontré este hilo sobre un problema similar que se refería a este hilo. Ejecutó el cambio solicitado en el módulo brcmfmac para habilitar la depuración. Tenía el disparo de falla y capturó la salida dmesg:
dmesg_debug_failed.txt
Además, noté una mención de un teléfono Samsung en el otro hilo. Hemos notado que los problemas del puente con mi Pi parecen girar en torno a mi Samsung Galaxy S7. Los dispositivos Apple de mi esposa (iPhone y iPad) no parecen desencadenar el problema.

EDIT4: Ejecutó un sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000 seguido de dmesg nuevamente. Salida a continuación:
dmesg_debug_failed_reset_driver.txt

Hmm, no es el error de buzón esperado. Se lo pasaré a los desarrolladores de Cypress en el nuevo año.

No estoy seguro si este es el mismo problema, pero mi síntoma es intermitente inalámbrico integrado RPi3; 10 segundos de buenos pings, seguidos de 20-30 segundos sin pings, y se repite para siempre. Cuando no hay pings, el host remoto recibe las solicitudes de eco ICMP y envía las respuestas de eco ICMP. El punto de acceso devuelve el host ICMP inalcanzable al host remoto.

La condición previa es conexión Ethernet e inalámbrica. La probabilidad de que ocurra mejoró enormemente al reiniciar innecesariamente dhcpcd .

La solución es configurar la interfaz de red en modo promiscuo; sudo ifconfig wlan0 promisc . El síntoma regresa en diez segundos a un minuto de sudo ifconfig wlan0 -promisc .

Más información disponible si es necesario, solo pregunte.

@ Sylver-Dragon, para mí un tcpdump previno el síntoma, y ​​tal vez encontraste lo mismo; pruebe la bandera -p , que desactiva el modo promiscuo; dejó que el síntoma continuara.

https://github.com/iiab/iiab/issues/638

@quozl Intenté ejecutar tcpdump tanto en la interfaz inalámbrica como en la interfaz de puente y tuve bloqueos mientras se estaba ejecutando. Le daré una oportunidad al modo promiscuo y veré si hace la diferencia. Sin embargo, según la salida de depuración del controlador de interfaz inalámbrica, específicamente:
wl0: _wlc_bss_update_beacon: out of mem, 0 bytes malloced
Supongo que esto es una especie de fuga de recursos (¿memoria?) Por parte del controlador. Cuando tenga un poco más de tiempo, quiero hacer una captura de paquetes y profundizar en el momento en que se bloquea. Sospecho que mi teléfono está enviando algún tipo de paquete o serie de paquetes extraño o mal formado al dispositivo que está activando el bloqueo. Si puedo capturar y aislar eso, debería ayudar a informar la solución.

Parece una falla diferente al problema del buzón que estamos rastreando actualmente. Lo que es molesto. ¿Es su teléfono un Samsung BTW? El problema del buzón de correo parece ser provocado con más frecuencia por los dispositivos SS. Si puede rastrear las causas de los problemas, sería muy útil

Estoy cazando lo mismo (?) Desde hace semanas. Siento que debo haber leído todos los informes sobre este y otros temas similares. Así que aquí hay más información mía:

Utilizo el wifi interno de una raspberry pi 3 como punto de acceso. Utilizo el kernel y los módulos raspbian estándar (versión de Linux 4.9.35-v7 + (dc4 @ dc4-XPS13-9333) (gcc versión 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) # 1014 SMP vie 30 de junio 14:47:43 BST 2017).

El firmware de Wifi es: brcmfmac: Versión de firmware = wl0: 7 de agosto de 2017 00:46:29 versión 7.45.41.46 (r666254 CY) FWID 01-f8a78378

Estoy bastante seguro de que esta configuración de hardware solía funcionar, pero después de algunas actualizaciones (también del kernel) creo que las cosas se fueron al sur. Crear el AP funciona bien, pero después de usarlo durante algún tiempo (30 minutos más o menos, no es lo mismo cada vez que creo), transmitiendo usando un Chromecast, la conexión deja de funcionar. Podría ser (pero aquí no estoy seguro) que esto suceda con mayor frecuencia cuando pause / detengo la transmisión, pero rara vez en el medio de la visualización. Cuando falla, las conexiones existentes se descartan y ningún cliente acepta nuevos intentos de conexión. Recargar hostapd da como resultado brcmf_cfg80211_stop_ap: setting INFRA mode failed -7 (no se puede configurar el modo como maestro). Esto se puede solucionar temporalmente volviendo a cargar el controlador: rmmod brcmfmac; modprobe brcmfmac . Las cosas vuelven a funcionar como se esperaba hasta que falla la próxima vez. Alternativamente, un reinicio "soluciona" el problema también.

Lo único que obtengo en estado fallido (con depuración habilitada) en syslog es:

kernel: [3615.491795] brcmfmac: brcmf_netdev_wait_pend8021x: Se agotó el tiempo de espera para que no haya paquetes 802.1x pendientes
hostapd: wlan0: STA xx: xx: xx: xx: xx: xx IEEE 802.11: sin autenticación debido a una solicitud de eliminación local

Ese mensaje de error no tiene sentido para mí. ¿Se agota el tiempo mientras espera 'no hay paquetes pendientes'? De todas formas:

Tengo el ahorro de energía desactivado:

iw wlan0 get power_save Power save: off

roam_off se establece en 1 y la depuración está habilitada:

`systool -a -v -m brcmfmac
Módulo = "brcmfmac"

Atributos:
coresize = "222874"
initsize = "0"
initstate = "en vivo"
refcnt = "0"
srcversion = "10E8F4629D109E78E1F506C"
taint = ""
uevent =

Parámetros:
Alternative_fw_path =
debug = "1048576"
roamoff = "1"
'

No tengo un teléfono Samsung, pero sí algunos con Android. Ninguno de estos está conectado a ese punto de acceso. Los únicos clientes directos son dos Chromecasts (un video, uno solo de audio y una tableta Android). Todo lo demás llega a través de la interfaz cableada.

@knarrff
Busque en esta página mi comentario anterior de hace 3 semanas para obtener una buena solución.

@ JamesH65
Nunca recibí una respuesta tuya. ¿Copiaste / transmitiste la salida de dmesg que compartí de ese comentario hace 3 semanas a los chicos de Cypress?

@randyoo : Tengo "rsn_pairwise = CCMP" y "wpa = 2" en mi hostapd.conf. No ayuda en mi caso. Entradas no secretas de mi archivo:
'
interfaz = wlan0

controlador = nl80211
ssid = XXX
hw_mode = g
canal = 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
'

También queda claro que la falla siempre parece sucederme cuando trato de pausar una transmisión de Netflix en el Chromecast (lo que no significa que siempre falla cuando intento esto, solo que cada vez que falla, eso es lo que estaba haciendo. ). Por otro lado, esto podría ser una pista falsa, ya que esto es lo que hago casi todo el tiempo con esa red wifi. Podría ser que el problema se produzca simplemente cuando un dispositivo intenta autenticarse en el AP (como la tableta Android que probablemente desactivó el wifi mientras dormía). Se mostrarán más pruebas. Lo intentaré sin Chromecast, solo wifi normal en la tableta, incluidos los ciclos de suspensión de wifi.

No parece que mi problema sea el mismo que este, así que cambiaré al modo de acecho. Mi ifconfig wlan0 promisc lo solucionó para @holta (https://github.com/iiab/iiab/issues/638), pero sin que ayude a nadie más, debemos estar viendo un problema diferente.

Puedo reproducir esto de manera confiable sin Netflix o Chromecast conectándome a la red a través de la tableta de Google, luego dejo que la tableta entre en suspensión, reanude (la tableta intenta volver a asociarse) y en ese momento el AP está "muerto".

En una máquina Linux, obtengo estos en syslog cuando intento asociarme (usando las credenciales correctas):

'

[42231.476518] wlan7: enviar autenticación a b8: 27: eb: 33: 98: 14 (intente 1/3)
[42231.583434] wlan7: enviar autenticación a b8: 27: eb: 33: 98: 14 (intente 2/3)
[42231.694397] wlan7: enviar autenticación a b8: 27: eb: 33: 98: 14 (intente 3/3)
[42231.799368] wlan7: se agotó el tiempo de autenticación con b8: 27: eb: 33: 98: 14
[42236.585750] wlan7: autenticar con b8: 27: eb: 33: 98: 14
[42236.598833] wlan7: enviar autenticación a b8: 27: eb: 33: 98: 14 (intente 1/3)
[42236.602344] wlan7: autenticado
[42236.603480] wlan7: asociado con b8: 27: eb: 33: 98: 14 (intente 1/3)
[42236.619322] wlan7: RX AssocResp de b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 aid = 1)
[42236.623181] wlan7: asociado
[42236.623325] IPv6: ADDRCONF (NETDEV_CHANGE): wlan7: el enlace está listo
[42236.625464] wlan7: Limitación de la potencia de transmisión a 30 (30 - 0) dBm como lo anuncia b8: 27: eb: 33: 98: 14
[42239.730365] wlan7: anulado la autenticación de b8: 27: eb: 33: 98: 14 (Razón: 2 = PREV_AUTH_NOT_VALID)
[42241.243434] wlan7: autenticar con b8: 27: eb: 33: 98: 14
[42241.256326] wlan7: enviar autenticación a b8: 27: eb: 33: 98: 14 (intente 1/3)
[42241.260724] wlan7: autenticado
[42241.263403] wlan7: asociado con b8: 27: eb: 33: 98: 14 (intente 1/3)
[42241.279537] wlan7: RX AssocResp de b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 aid = 1)
[42241.282500] wlan7: asociado
[42241.336166] wlan7: Limitación de la potencia de transmisión a 30 (30 - 0) dBm como lo anuncia b8: 27: eb: 33: 98: 14
[42244.392213] wlan7: sin autenticación de b8: 27: eb: 33: 98: 14 (Razón: 2 = PREV_AUTH_NOT_VALID)
[42253.916626] wlan7: autenticar con b8: 27: eb: 33: 98: 14
[42253.928966] wlan7: enviar autenticación a b8: 27: eb: 33: 98: 14 (intente 1/3)
[42253.936020] wlan7: autenticado
[42253.939533] wlan7: asociado con b8: 27: eb: 33: 98: 14 (intente 1/3)
[42253.943361] wlan7: RX AssocResp de b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 aid = 2)
[42253.945415] wlan7: asociado
[42254.035149] wlan7: Limitación de la potencia de transmisión a 30 (30 - 0) dBm como lo anuncia b8: 27: eb: 33: 98: 14
[42257.053762] wlan7: anulado la autenticación de b8: 27: eb: 33: 98: 14 (Razón: 2 = PREV_AUTH_NOT_VALID)
'

b8: 27: eb: 33: 98: 14 es el RPI3 en cuestión, en el que nuevamente obtengo las entradas dmesg:
brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets

No entiendo muy bien por qué el AP envía PREV_AUTH_NOT_VALID mientras aparentemente estoy asociado. Tengo la impresión de que la autenticación es anterior a la asociación. No debería haber un caso en el que esté asociado pero no autenticado.

Hola

Estoy usando un Pi3 como servidor de medios, las comunicaciones se realizan a través del WiFi integrado

Actualización de actualización Rasbian Stretch Lite 4.9 (ahora)
Servidor de medios Plex

Me estoy poniendo...

kernel: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012

en dmesg y syslog cuando se conecta a Pi usando el cliente BubbleUPnp en un Samsung S5 SM_G900F Android 7.1.2, esto está prácticamente garantizado y requiere reiniciar para que PiWiFi vuelva a ser utilizable.

En mi antiguo Sony Xperia XP, Android 6.0.1 nuevamente ejecutando BubbleUPnp, funciona bien hasta ahora. Esta es mi solucion. Sin embargo, si puedo ser de ayuda para llegar al fondo de esto, estaré encantado de contribuir.

John

También funciona en iPad con mConnectLite

@johnthesoftwareathome Por favor escriba un correo electrónico a James Hughes de Raspberry Pi para que pueda enviarle un firmware de depuración Wifi.

Dirección de correo electrónico publicada a través de la página de contacto de Raspberry Pi fao James Hughes

Bien, tenemos un nuevo firmware de depuración de Cypress con el que quisiera que la gente lo probara; tiene más depuración, pero no correcciones, así que solo para aquellos que estén felices de probar. Si ya me ha enviado su dirección de correo electrónico, indique aquí que le gustaría hacer algunas pruebas y le enviaré el firmware, o póngase en contacto conmigo a través de PM en los foros de Pi.

Para evitar que la gente busque cómo instalar / ejecutar el nuevo firmware.

Copie el archivo de firmware de depuración en:

/lib/firmware/brcm/

(Primero querrá hacer una copia de seguridad del original)

Creo que necesitas reiniciar en esta etapa.

Ahora reinicie el controlador de Linux en modo de depuración

sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000

Haz que salga mal .. !!

Volcar dmesg a archivo y publicar aquí.

Para agregar a lo que dice James, es posible que prefiera evitar la secuencia rmmod / modprobe agregando brcmfmac.debug=0x100000 a /boot/cmdline.txt .

@ JamesH65 Estaría feliz de ayudar a probar. Aunque me acabo de registrar en el Foro de Pi, no puedo enviar mensajes. Usar el mismo nombre de usuario allí, si eso ayuda.

Ayer probé el nuevo firmware de depuración y también agregué brcmfmac.debug = 0x100000 a /boot/cmdline.txt.

Sin embargo, extrañamente no vi ninguna salida de depuración en dmesg. Aún más extraño, donde antes podía reproducir de manera confiable el problema, funcionó toda la noche independientemente de lo que hice. No tuve un solo problema, y ​​todo lo que hice de manera diferente fue usar el nuevo archivo de firmware (md5 sum ba679a85c1dc76e9775603af45440bc0) en lugar del anterior y agregar la entrada a /boot/cmdline.txt en lugar de agregar la opción usando modprobe. Ayer no tuve tiempo de volver al firmware anterior para ver si esto revierte a los problemas anteriores. Informaré una vez que lo hice. Mientras tanto: ¿todo lo que ha cambiado en ese firmware es realmente "más depurado"?

Pensé que era solo depuración, pero volveré a Cypress con la misma claridad
algo más ha cambiado, ¡ojalá en el buen sentido!

El 11 de enero de 2018 a las 06:48, Frank Löffler [email protected] escribió:

Ayer probé el nuevo firmware de depuración y también agregué
brcmfmac.debug = 0x100000 a /boot/cmdline.txt.

Sin embargo, extrañamente no vi ninguna salida de depuración en dmesg. Aún más
extrañamente, donde antes podía reproducir el problema de manera confiable, funcionó
toda la noche sin importar lo que hice. No tuve un solo problema, y
todo lo que hice fue usar el nuevo archivo de firmware (md5 sum
ba679a85c1dc76e9775603af45440bc0). Ayer no tuve tiempo para ir
Vuelva al firmware anterior para ver si vuelve a los problemas anteriores. Enfermo
informe una vez que lo hice. Mientras tanto: ¿ha cambiado todo lo que
firmware realmente "más depuración"?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-356842102 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHam4jUgDCkSFxMXS-KW4axCLoPZhks5tJa6fgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Mi experiencia fue similar a la de @knarrf , excepto que vi mensajes de depuración en dmesg.

Anteriormente, mi Samsung S5 no se podía usar como cliente plexserver, pero cuando cargué el firmware de depuración funcionó (con, como dije, mensajes de depuración en dmesg), volví a mi binario original (copia de seguridad y tamaño verificado) y aún funciona. Así que ahora estoy corriendo de nuevo con el firmware de depuración (no he probado el mod cmdline.txt, solo el rmmod / modprobe) y he escuchado algunas horas de música sin errores. He intentado activar la mayoría de los muchos dispositivos WiFi que tengo dispersos, sin ningún resultado.

Intentaré esto durante unos días para ver si pasa algo, luego recargaré el original y volveré a intentarlo. Es posible que no haya apagado la Pi entre reinicios. Me aseguraré de hacer esto cuando vuelva atrás para ver si podría ser algún tipo de retención de registro.

Esta noche cargué firmware más antiguo (tomado de una imagen de instalación raspian; más información sobre las versiones que uso a continuación), y recargué el módulo con eso (y depuración habilitada), incluso reinicié en el medio. La salida corta en dmesg confirma que la versión anterior ya está cargada. Y al igual que con @johnthesoftwareathome , continuó funcionando durante toda la noche, a pesar de hacer cosas que habrían interrumpido el wifi varias veces en el pasado.

Entonces, por ahora, mi tarea parece ser que vuelva a "no funcionar" para tener la oportunidad de averiguar qué está pasando. Mi próximo intento, aunque ya no hoy, será hacer un restablecimiento completo (quitar la energía durante algún tiempo en lugar de simplemente usar el comando 'reiniciar') y usar una instalación completamente nueva a partir de una imagen nueva.

Además, lamentablemente no puedo excluir la posibilidad de que la imagen con la que obtuve fallas fuera una versión diferente, ya que olvidé hacer una copia de seguridad antes de sobrescribirla con la imagen de depuración. ¿Quizás @johnthesoftwareathome podría publicar qué imagen exacta está usando y con la que tuvo / tiene problemas? Por otro lado, en ese entonces solo actualicé el firmware usando los paquetes estándar, y tengo instalada la versión del paquete firmware-brcm80211 (1: 0.43 + rpi6). Aunque la última entrada en el registro de cambios no especifica la versión de firmware, la penúltima sí: 7.45.41.26, que es más antigua que la de la imagen. Suponiendo que el registro de cambios se escribió correctamente, eso sería una fuerte indicación de que el firmware no se reemplazó desde que se creó la imagen, y que el que llamo 'imagen' es el que usé antes.

Información sobre mis dos archivos de firmware (imagen: el de la imagen de instalación de raspbian, depuración: el que recibí directamente de @ JamesH65 :

depurar:
Versión de firmware = wl0: 23 de octubre de 2017 03:55:53 versión 7.45.98.38 (r674442 CY) FWID 01-e58d219f
md5sum: ba679a85c1dc76e9775603af45440bc0
imagen:
Versión de firmware = wl0: 7 de agosto de 2017 00:46:29 versión 7.45.41.46 (r666254 CY) FWID 01-f8a78378
md5sum: 5f520a38ab4e943bfa1ba102f80fb2a0

@johnthesoftwareathome : ¿cómo se ve la nueva salida de "depuración"? Todavía no obtengo nada que parezca una depuración extensa, incluso remotamente, independientemente de cómo cargue el módulo. Obtengo cero entradas durante la operación, e incluso después del arranque, todo el aspecto algo relevante es:

como root: dmesg | grep brcm
[0.000000] Línea de comando del kernel: 8250.nr_uarts = 0 bcm2708_fb.fbwidth = 640 bcm2708_fb.fbheight = 480 bcm2708_fb.fbdepth = 16 bcm2708_fb.fbswap = 1 vc_mem.mem_base = 0x3eag.mem.mem_base = 0x3eag00000 v3c_sty0000 = 0x3eag.mem.mem.mem_base = 0x3eag. , 115200 consola = tty1 root = PARTUUID = f8e4f7c2-02 rootfstype = ext4 ascensor = fecha límite fsck.repair = sí rootwait brcmfmac.debug = 0x100000
[3.500135] usbcore: nuevo controlador de interfaz registrado brcmfmac
[3.662113] brcmfmac: Versión de firmware = wl0: 7 de agosto de 2017 00:46:29 versión 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[3.774278] brcmfmac: administración de energía deshabilitada
[4.711443] brcmfmac: administración de energía deshabilitada

Pequeña actualización: mirando hacia atrás en uno de mis comentarios anteriores en este hilo, en realidad puedo confirmar que el firmware anterior que usé hoy ('imagen') es con el que tuve problemas hasta que probé la imagen de depuración más nueva.

Casa vacía, así que finalmente pude escuchar el último álbum de Bowie. Todo funcionó a la perfección (el disco no es así). Fuera de casa hasta mañana, recogeré esto entonces.

Se las arregló para que el firmware original fallara como antes, pero no de manera confiable entre su uso y el firmware de depuración. Actualmente solo reiniciando con las cosas de depuración sin fallas todavía.

Entendí mal lo que

Además, uno de los fallos no se resolvió inmediatamente. Me permitió volver a entrar antes de necesitar un reinicio. Syslog contiene lo siguiente ...

13 de enero 08:34:48 kernel de plexServer: [46.648630] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012
13 de enero 08:35:14 kernel de plexServer: [72.161473] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
13 de enero 08:35:14 kernel de plexServer: [72.161484] brcmfmac: brcmf_cfg80211_get_channel: chanspec falló (-110)

Ese es un conjunto de mensajes de error muy familiar, pero aún es útil saber que estaba experimentando el mismo problema que ahora parece que se puede solucionar.

Cypress está preparando una nueva versión de firmware para nosotros; publicaremos aquí cuando haya algo disponible para probar. Gracias a todos por su interés, tiempo y paciencia.

Okay. Gracias por un conductor que trabaja.

Es posible que las cosas hayan cambiado desde entonces ...

https://tech4research.wordpress.com/2014/07/23/brcmfmac-debugging-and-apropiado-debug-values/

y aprecio que el conmutador de depuración para el nuevo firmware puede ser una adición especial, pero estos conmutadores parecen funcionar tanto para el firmware original como para el de "depuración" y se lanza el flujo esperado de depuración.

Probablemente ya se haya visto; pero TPLink afirma que los dispositivos Android están haciendo DoS en sus dispositivos con paquetes MDNS cuando se despiertan de la suspensión e intentan volver a conectarse con Chromecast o dispositivos similares.
Profundizando en un pcap, obtuve una desconexión de mi propio dispositivo, puedo ver ~ 3500 paquetes MDNS que llegan en más de ~ 2.25 segundos justo antes de que mi conexión muera. Parece ajustarse a este patrón y puede estar relacionado.

Solo para agregar / confirmar información en este número:

• Configurar la interfaz wifi en promiscuo ( ifconfig wlan0 promisc ) parece mitigar el problema
• El problema parece ser causado solo por mi teléfono Android 7.1.2 Galaxy S7 (que obtuve hace una semana y aquí es cuando comenzaron los problemas)

Estoy ejecutando Debian Buster con aarch64 en mi Pi3 y ejecuto un servidor Nextcloud en él. scp'ing archivos más grandes desde una computadora portátil Linux no causa ningún problema ni Nextcloud se sincroniza desde esa computadora portátil, pero tan pronto como subo un lote de archivos desde Galaxy, aparecerá el error Unknown mailbox data content: 0x40012 y la conectividad Wifi será perdió.

El firmware brcmfmac que estoy usando es 7.45.41.26 (r640327) FWID 01-4527cfab

Desafortunadamente, no tengo un Android anterior para probar.

Hice una carga desde el Samsung al Pi3, pero luego el Wifi estaba en modo promiscuo y todo funcionó bien. Si encuentro el tiempo, echaré un vistazo al pcap e informaré si encuentro algo útil / interesante.

PD: Cast (el delincuente principal descrito en el artículo de TPLink) no está activo (o al menos no puedo verlo en la configuración de conectividad).

Hola a todos,

Solo quiero confirmar que apagar el modo de seguridad y habilitar el modo promiscuis solucionó el problema para mí: por primera vez logró permanecer conectado durante 24 horas.

sudo iw wlan0 establecer power_save off
sudo ifconfig wlan0 promisc

Gracias,
Luc

Consulte esta publicación del foro para obtener detalles sobre una nueva versión de firmware. Cualquiera que vea el problema del buzón de correo o, de hecho, cualquier problema inalámbrico, debería probar esto para ver si ayuda.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508

@ JamesH65
Hola James,
¿Puede proporcionar algunas instrucciones de instalación? ¿Es el archivo .bin del archivo un ejecutable de autoinstalación?
Gracias
Sotavento

Instrucciones ahora en la página del foro vinculado.

Regresando después de ejecutar el nuevo firmware durante un poco más de una semana. Hasta ahora ha sido sólido. He despertado repetidamente mi dispositivo Samsung después de largos períodos y la interfaz inalámbrica de mi Pi ha seguido funcionando. Creo que tuve una instancia en la que cayó temporalmente y luego se recuperó; sin embargo, no he podido reproducir eso. Considerándolo todo, parece sólido. Gracias tanto a James por seguir con esto como al equipo de Cypress por arreglarlo.

Gracias por el informe.

¿Alguien puede decirme si la corrección de firmware ya se ha incluido en la distribución oficial de Raspbian para que pueda instalarse a través de apt update o si aún no lo ha hecho, informarme después de que haya sido el caso?

¿Alguien puede decirme si la corrección de firmware ya está en la distribución oficial de Raspbian para que pueda instalarse a través de la actualización de apt o, si aún no, informarme después de que haya sido el caso?

Si. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508&start=25#p1270212
Se informan algunos problemas en Pi0W después de la actualización general, pero no está del todo claro si se trata solo del cambio de firmware u otra cosa: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=204882

He actualizado el firmware

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.bin
ba679a85c1dc76e9775603af45440bc0  /lib/firmware/brcm/brcmfmac43430-sdio.bin

pero sigo teniendo el mismo problema

$ 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

Lo siguiente tampoco evita este problema

sudo iw wlan0 set power_save off
sudo ifconfig wlan0 promisc

Estoy usando el RPi3 como punto de acceso con hostapd y dnsmasq .
Siempre puedo reproducir el problema al iniciar una descarga en la aplicación Spotify en mi teléfono Android.

¿Necesito actualizar también el siguiente archivo?

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.txt
9a88b55134d9f8f3ad2331b93f4b7b79  /lib/firmware/brcm/brcmfmac43430-sdio.txt

¿Lo utilizará el conductor o se puede ignorar?

Editar:
Si. También se requiere el archivo brcmfmac43430-sdio.txt.
Pero estoy usando las últimas mejores versiones de https://github.com/RPi-Distro/firmware-nonfree/tree/927fa8ebdf5bcfb90944465b40ec4981e01d6015/brcm

También he actualizado mi kernel 4.9.35-v7 + a 4.14.18-v7 +.
Pero el problema aún existe.

Me encuentro con el mismo problema en mi RPi3: Wifi se cae después de un tiempo de actividad (por ejemplo, durante la noche) sin casi tráfico.
La salida de dmesg solo muestra:

[ +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)

Intenté volver a cargar el controlador (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

Eso de alguna manera no funcionó: controlador cargado pero no, no tengo interfaz
Intentó de nuevo:

[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

..y me levanto de nuevo.

Pi3 ejecuta el kernel '4.14.24-v7 + # 1097' - el firmware es el más antiguo del 7 de agosto de 2017 - el mismo blob de firmware que funciona perfectamente (tiempo de actividad> 2 meses) en un Pi Zero W que ejecuta el kernel '4.9.77+ # 1081'
Ambos Pis están conectados al mismo enrutador y una habitación aparte. Ambos están conectados solo a través de WiFi.

Probablemente valga la pena usar el último firmware en 4.14, ya que 4.14 tiene todos los cambios necesarios para funcionar con ese firmware.

:) Actualizado a la última versión de firmware (23 de octubre de 2017 03:55:53 versión 7.45.98.38) ayer después de la publicación, parece que funciona en un cajero automático, veamos qué sucede.

Parece que raspbian volvió al paquete de firmware de agosto de 2017. ¿Existen nuevos requisitos para el rpi 3B + inalámbrico?

El último paquete de firmware de repositorio

También tengo ese problema con el wifi muriendo.

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

Esto es con 4.14.27-v7 + y con
/ sbin / iw dev wlan0 desactiva el ahorro de energía
/ sbin / ifconfig wlan0 promisc
en /etc/rc.local.

mismos mensajes de error que @ flok99 - usando el último firmware (rpi-update) en stretch.

De acuerdo, el error que pensamos que Cypress había solucionado sigue ahí. De regreso
Cypress se va. Tardó un año en conseguir esta versión. Aguantando la respiración no
recomendado.

Sin embargo, debe confirmar la versión, publique el contenido de

dmesg | grep brcmfmac

El 18 de marzo de 2018 a las 01:44, Rebroad [email protected] escribió:

mismos mensajes de error que @ flok99 https://github.com/flok99 - usando el último
firmware (rpi-update) en stretch.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373966343 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHY1Cmntz_kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

[4.112717] brcmfmac: Firma F1 leída @ 0x18000000 = 0x15264345
[4.119827] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm / brcmfmac43455-sdio.bin para el chip 0x004345 (17221) rev 0x000006
[4.120314] usbcore: nuevo controlador de interfaz registrado brcmfmac
[4.440371] brcmfmac: brcmf_c_preinit_dcmds: Versión de firmware = wl0: febrero
27 2018 03:15:32 versión 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[4.440958] brcmfmac: brcmf_c_preinit_dcmds: versión CLM = API: 12.2
Datos: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Creación: 2018-03-09
18:56:28
[10.911757] brcmfmac: administración de energía deshabilitada
[12.016088] brcmfmac: administración de energía deshabilitada
[2074.090674] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
fallido con estado -5
[2074.090687] brcmfmac: brcmf_cfg80211_get_tx_power: error (-5)
[2074.090745] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[2074.090753] brcmfmac: brcmf_link_down: WLC_DISASSOC falló (-5)
[2074.610583] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[2074.611992] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[2074.613945] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[2074.613971] brcmfmac: brcmf_cfg80211_get_channel: chanspec falló (-5)
[2074.729716] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[2074.729733] brcmfmac: brcmf_cfg80211_reg_notifier: código de país iovar
devuelto err = -5
[2074.871693] usbcore: anulación del registro del controlador de interfaz brcmfmac
[2074.929084] brcmfmac: Firma F1 leída @ 0x18000000 = 0x15264345
[2074.936897] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm / brcmfmac43455-sdio.bin para el chip 0x004345 (17221) rev 0x000006
[2074.937139] usbcore: nuevo controlador de interfaz registrado brcmfmac
[2075.118180] brcmfmac: brcmf_c_preinit_dcmds: Versión de firmware = wl0: febrero
27 2018 03:15:32 versión 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2075.118706] brcmfmac: brcmf_c_preinit_dcmds: versión CLM = API: 12.2
Datos: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Creación: 2018-03-09
18:56:28
[2075.215365] brcmfmac: administración de energía deshabilitada
[2075.263751] brcmfmac: administración de energía deshabilitada
[2085.475001] brcmfmac: administración de energía deshabilitada
[2124.380808] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[2124.381146] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[2124.381156] brcmfmac: brcmf_cfg80211_get_channel: chanspec falló (-5)
[2124.622345] usbcore: anulación del registro del controlador de interfaz brcmfmac
[2124.705432] brcmfmac: Firma F1 leída @ 0x18000000 = 0x15264345
[2124.714194] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para el chip 0x004345 (17221) rev 0x000006
[2124.716213] usbcore: nuevo controlador de interfaz registrado brcmfmac
[2124.929556] brcmfmac: brcmf_c_preinit_dcmds: Versión de firmware = wl0: febrero
27 2018 03:15:32 versión 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2124.929993] brcmfmac: brcmf_c_preinit_dcmds: versión CLM = API: 12.2
Datos: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Creación: 2018-03-09
18:56:28
[2125.105218] brcmfmac: administración de energía deshabilitada
[2125.150290] brcmfmac: administración de energía deshabilitada
[8237.434034] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido:
0x40012
[8239.890302] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[8239.890822] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en el dongle
[8239.890835] brcmfmac: brcmf_run_escan: error (-110)
[8239.890845] brcmfmac: brcmf_cfg80211_scan: error de escaneo (-110)
[8254.280425] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
fallido con estado -5
[8254.280438] brcmfmac: brcmf_cfg80211_get_tx_power: error (-5)
[8254.280491] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8254.280498] brcmfmac: brcmf_link_down: WLC_DISASSOC falló (-5)
[8254.800394] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8254.803873] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8254.808353] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8254.808370] brcmfmac: brcmf_cfg80211_get_channel: chanspec falló (-5)
[8254.881402] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8254.881420] brcmfmac: brcmf_cfg80211_reg_notifier: código de país iovar
devuelto err = -5
[8255.001550] usbcore: anulación del registro del controlador de interfaz brcmfmac
[8255.071184] brcmfmac: Firma F1 leída @ 0x18000000 = 0x15264345
[8255.077098] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para el chip 0x004345 (17221) rev 0x000006
[8255.077348] usbcore: nuevo controlador de interfaz registrado brcmfmac
[8257.730418] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[8257.751038] brcmfmac: brcmf_c_get_clm_name: recuperando información de revisión
fallido (-110)
[8257.751049] brcmfmac: brcmf_c_process_clm_blob: obtiene el nombre del archivo blob de CLM
fallido (-110)
[8257.751068] brcmfmac: brcmf_c_preinit_dcmds: descargar archivo de blob CLM
fallido, -110
[8257.751076] brcmfmac: brcmf_bus_started: falló: -110
[8257.751114] brcmfmac: brcmf_sdio_firmware_callback: el dongle no es
respondiendo
[8304.417684] usbcore: anulación del registro del controlador de interfaz brcmfmac
[8304.486099] brcmfmac: Firma F1 leída @ 0x18000000 = 0x15264345
[8304.493613] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para el chip 0x004345 (17221) rev 0x000006
[8304.494078] usbcore: nuevo controlador de interfaz registrado brcmfmac
[8304.686761] brcmfmac: brcmf_c_preinit_dcmds: Versión de firmware = wl0: febrero
27 2018 03:15:32 versión 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8304.687203] brcmfmac: brcmf_c_preinit_dcmds: versión CLM = API: 12.2
Datos: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Creación: 2018-03-09
18:56:28
[8304.829994] brcmfmac: administración de energía deshabilitada
[8304.907662] brcmfmac: administración de energía deshabilitada
[8357.441791] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido:
0x40012
[8359.891146] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[8359.891655] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en el dongle
[8359.891668] brcmfmac: brcmf_run_escan: error (-110)
[8359.891677] brcmfmac: brcmf_cfg80211_scan: error de escaneo (-110)
[8371.731226] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[8371.731731] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en el dongle
[8371.731746] brcmfmac: brcmf_cfg80211_get_channel: chanspec falló (-110)
[8373.941267] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
fallido con estado -5
[8373.941280] brcmfmac: brcmf_cfg80211_get_tx_power: error (-5)
[8373.941330] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8373.941338] brcmfmac: brcmf_link_down: WLC_DISASSOC falló (-5)
[8374.461245] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8374.461942] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8374.463553] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8374.463573] brcmfmac: brcmf_cfg80211_get_channel: chanspec falló (-5)
[8374.564729] brcmfmac: brcmf_fil_cmd_data: el bus está inactivo. no tenemos nada
que hacer.
[8374.564750] brcmfmac: brcmf_cfg80211_reg_notifier: código de país iovar
devuelto err = -5
[8374.702401] usbcore: anulación del registro del controlador de interfaz brcmfmac
[8374.759839] brcmfmac: Firma F1 leída @ 0x18000000 = 0x15264345
[8374.767561] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para el chip 0x004345 (17221) rev 0x000006
[8374.771137] usbcore: nuevo controlador de interfaz registrado brcmfmac
[8377.411255] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[8377.431924] brcmfmac: brcmf_c_get_clm_name: recuperando información de revisión
fallido (-110)
[8377.431934] brcmfmac: brcmf_c_process_clm_blob: obtener el nombre del archivo blob de CLM
fallido (-110)
[8377.431941] brcmfmac: brcmf_c_preinit_dcmds: descargar archivo blob CLM
fallido, -110
[8377.431949] brcmfmac: brcmf_bus_started: falló: -110
[8377.432003] brcmfmac: brcmf_sdio_firmware_callback: el dongle no es
respondiendo
[8424.133114] usbcore: anulación del registro del controlador de interfaz brcmfmac
[8424.229631] brcmfmac: Firma F1 leída @ 0x18000000 = 0x15264345
[8424.237210] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para el chip 0x004345 (17221) rev 0x000006
[8424.239352] usbcore: nuevo controlador de interfaz registrado brcmfmac
[8424.460736] brcmfmac: brcmf_c_preinit_dcmds: Versión de firmware = wl0: febrero
27 2018 03:15:32 versión 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8424.461174] brcmfmac: brcmf_c_preinit_dcmds: versión CLM = API: 12.2
Datos: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Creación: 2018-03-09
18:56:28
[8424.646993] brcmfmac: administración de energía deshabilitada
[8424.708633] brcmfmac: administración de energía deshabilitada

El domingo 18 de marzo de 2018 a las 11:30 a. M., James Hughes [email protected]
escribió:

De acuerdo, el error que pensamos que Cypress había solucionado sigue ahí. De regreso
Cypress se va. Tardó un año en conseguir esta versión. Aguantando la respiración no
recomendado.

Sin embargo, debe confirmar la versión, publique el contenido de

dmesg | grep brcmfmac

El 18 de marzo de 2018 a las 01:44, Rebroad [email protected] escribió:

mismos mensajes de error que @ flok99 https://github.com/flok99 - usando
último
firmware (rpi-update) en stretch.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -373966343
,
o silenciar el hilo
kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5>
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373987387 ,
o silenciar el hilo
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 

Casi parece que estás en el Pi3b + más nuevo y no en el Pi3 original: entonces, ¿tal vez algo diferente?

Chip y firmware completamente diferentes, aunque el controlador del lado de Linux es el
mismo. (brcmfmac).

El 19 de marzo de 2018 a las 16:26, macmpi [email protected] escribió:

@ flok99 https://github.com/flok99

brcmfmac: brcmf_fw_map_chip_to_name: usando brcm / brcmfmac43455-sdio.bin para el chip
Versión de firmware = wl0: 27 de febrero de 2018 03:15:32 versión 7.45.154 (r684107 CY) FWID 01-4fbe0b04

Casi parece que estás en el Pi3b + más nuevo y no en el Pi3 original: entonces
tal vez un asunto diferente?

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-374274045 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADqrHeP6-sc-P-OSggQFPrl3O8z_B2aRks5tf9wbgaJpZM4HupC5
.

-
James Hughes
Ingeniero Principal de Software,
Raspberry Pi (Trading) Ltd

Creo que es mejor tener otro hilo para los problemas de Pi3B +, y consultar este si es necesario, de lo contrario, será muy difícil de rastrear. Can @ flok99, por favor, cree un nuevo número con sus informes, asegurándose de que el título se refiere al 3b +. Cambiaré el título de este para reflejarlo solo para Pi3B.

hecho

¿Alguien suscrito a este problema, ejecutando 3B (no plus), todavía ve los problemas con el último firmware y kernel? Me gustaría recibir informes de fallas continuas: las últimas publicaciones sobre el tema anterior parecen implicar que las cosas ahora están funcionando bien.

Mi 3B ha subido desde hace 44 días con esto:

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

Sin problemas desde entonces ...

Buenas noticias. A menos que escuche lo contrario, probablemente cerraré este hilo en una semana o dos, aunque se puede volver a abrir en cualquier momento si los problemas vuelven a ocurrir.

Empecé a tener este problema hace una semana, sin haber oído hablar de él antes. También uso el pi con mayor frecuencia con un teléfono Samsung como enrutador; el mío es un s4. Estoy escribiendo esto conectado directamente al s4 con usb, es decir, usando rndis. Aquí están mis detalles del arranque de hoy:
0 actualizado, 0 recién instalado, 0 para eliminar y 0 no actualizado.
thenry @ pi3portable : ~ $ dmesg | grep brcmfmac
[9.965782] brcmfmac: Firma F1 leída @ 0x18000000 = 0x1541a9a6
[9.972059] brcmfmac: brcmf_fw_map_chip_to_name: usando brcm / brcmfmac43430-sdio.bin para el chip 0x00a9a6 (43430) rev 0x000001
[9.972250] usbcore: nuevo controlador de interfaz registrado brcmfmac
[10.147562] brcmfmac: brcmf_c_preinit_dcmds: Versión de firmware = wl0: 7 de agosto de 2017 00:46:29 versión 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.148507] brcmfmac: brcmf_c_preinit_dcmds: versión CLM = API: 12.2 Datos: 7.11.15 Compilador: 1.24.2 ClmImport: 1.24.1 Creación: 2014-05-26 10:53:55 Datos Inc: 9.10.41 Compilador Inc: 1.29 .4 Inc ClmImport: 1.36.3 Creación: 2017-08-07 00:37:47
[18.538641] brcmfmac: administración de energía deshabilitada
[30.629545] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012
[33.191450] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[33.194850] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en dongle
[35.751496] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[35.754898] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en dongle
[35.754906] brcmfmac: brcmf_pno_clean: código fallido -110
[43.271438] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[43.274800] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en dongle
[43.274807] brcmfmac: brcmf_do_escan: error (-110)
[43.274811] brcmfmac: brcmf_cfg80211_scan: error de escaneo (-110)
[7673.758073] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[7673.761437] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en el dongle
[7673.761454] brcmfmac: _brcmf_set_multicast_list: Error al configurar mcast_list, -110
[7676.328075] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[7676.331449] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en dongle
[7676.331466] brcmfmac: _brcmf_set_multicast_list: Error al configurar allmulti, -110
[7678.878084] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[7678.881460] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en el dongle
[7681.448101] brcmfmac: _brcmf_set_multicast_list: Error al configurar BRCMF_C_SET_PROMISC, -110
[7689.118098] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
[7689.118241] brcmfmac: administración de energía deshabilitada
[7691.678100] brcmfmac: brcmf_cfg80211_set_power_mgmt: error (-110)
[7694.238122] brcmfmac: _brcmf_set_multicast_list: Error al configurar mcast_list, -110
[7696.798118] brcmfmac: _brcmf_set_multicast_list: Error al configurar allmulti, -110
[7699.358158] brcmfmac: brcmf_do_escan: error (-110)
[7699.358167] brcmfmac: brcmf_cfg80211_scan: error de escaneo (-110)
[7701.918127] brcmfmac: _brcmf_set_multicast_list: Error al configurar BRCMF_C_SET_PROMISC, -110
[11406.881341] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falló con estado -110
[11406.881352] brcmfmac: brcmf_cfg80211_reg_notifier: El código de país iovar devolvió err = -110
[11579.921479] brcmfmac: _brcmf_set_multicast_list: Error al configurar mcast_list, -110
[11582.491485] brcmfmac: _brcmf_set_multicast_list: Error al configurar allmulti, -110
[11587.611478] brcmfmac: _brcmf_set_multicast_list: Error al configurar BRCMF_C_SET_PROMISC, -110
thenry @ pi3portable : ~ $
thenry @ pi3portable : ~ $ uname -a
Linux pi3portable 4.14.27-v7 + # 1100 SMP Vie 16 de marzo 13:51:48 GMT 2018 armv7l GNU / Linux
thenry @ pi3portable : ~ $
Estoy ejecutando este kernel porque cambié a la siguiente secuencia cuando estaba probando el arranque desde usb y no volví a cambiar después. Luego recibí el aviso sobre el nuevo kernel (4.14), así que decidí probarlo, hace aproximadamente un mes. Ha estado bien, sin problemas hasta este. El único cambio importante es que cambié de NetworkManager a systemd-networkd hace varios días, pero eso fue después de que este problema se mostrara por primera vez.
Saludos,
Trevor Henry

Actualizar:
Después de leer todas las publicaciones relacionadas, encontré el último firmware en la publicación https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508
y esto solucionó mi problema.

versión de prueba de brcmfmas43430-sdio.bin instalada 250418

versión 7.45.98.38 23 de octubre de 2017, reemplazada a la versión 7.45.41.46 7 de agosto de 2017

antes de:

[10.368086] brcmfmac: Firma F1 leída @ 0x18000000 = 0x1541a9a6
[10.376702] brcmfmac: brcmf_fw_map_chip_to_name: usando brcm / brcmfmac43430-sdio.bin para el chip 0x00a9a6 (43430) rev 0x000001
[10.377026] usbcore: nuevo controlador de interfaz registrado brcmfmac
[10.599523] brcmfmac: brcmf_c_preinit_dcmds: Versión de firmware = wl0: 7 de agosto de 2017 00:46:29 versión 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.600577] brcmfmac: brcmf_c_preinit_dcmds: Versión CLM = API: 12.2 Datos: 7.11.15 Compilador: 1.24.2 ClmImport: 1.24.1 Creación: 2014-05-26 10:53:55 Datos Inc: 9.10.41 Compilador Inc: 1.29 .4 Inc ClmImport: 1.36.3 Creación: 2017-08-07 00:37:47
[126.642710] brcmfmac: administración de energía deshabilitada
[139.249230] brcmfmac: brcmf_sdio_hostmail: Contenido de datos de buzón desconocido: 0x40012
[141.751545] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[141.754973] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en dongle
[144.311482] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[144.314959] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en dongle
[144.314975] brcmfmac: brcmf_pno_clean: código fallido -110
[151.831564] brcmfmac: brcmf_sdio_bus_rxctl: reanudado en el tiempo de espera
[151.835066] brcmfmac: brcmf_sdio_checkdied: trampa de firmware en dongle
[151.835079] brcmfmac: brcmf_do_escan: error (-110)
[151.835084] brcmfmac: brcmf_cfg80211_scan: error de escaneo (-110)

después:

thenry @ pi3portable : ~ $ dmesg | grep brcm
[10.115833] brcmfmac: Firma F1 leída @ 0x18000000 = 0x1541a9a6
[10.134926] brcmfmac: brcmf_fw_map_chip_to_name: usando brcm / brcmfmac43430-sdio.bin para el chip 0x00a9a6 (43430) rev 0x000001
[10.135115] usbcore: nuevo controlador de interfaz registrado brcmfmac
[10.367703] brcmfmac: brcmf_c_preinit_dcmds: Versión de firmware = wl0: 23 de octubre de 2017 03:55:53 versión 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[10.368419] brcmfmac: brcmf_c_preinit_dcmds: Versión CLM = API: 12.2 Datos: 7.11.15 Compilador: 1.24.2 ClmImport: 1.24.1 Creación: 2014-05-26 10:53:55 Datos Inc: 9.10.39 Compilador Inc: 1.29 .4 Inc ClmImport: 1.36.3 Creación: 2017-10-23 03:47:14
[18.045308] brcmfmac: administración de energía deshabilitada
thenry @ pi3portable : ~ $

Ha seguido funcionando a través de varios arranques y ahora lo estoy usando, conectado por wifi al teléfono samsung s4.
Gracias por tu ayuda, saludos, Trevor Henry.

Pensé que el firmware más reciente ya estaba en las imágenes más recientes, por lo que habría esperado que una actualización a 4.14 hubiera traído el firmware más reciente. ¿Creó su propio kernel?

Sí, las imágenes actuales de Raspbian tienen el firmware 7.45.98.38 del 23 de octubre de 2017.

Hola, no, no construí el kernel, actualicé con rpi-update y, como puede ver, todavía estaba ejecutando el firmware de agosto de 2017 después de la actualización.

rpi-update solo actualiza el kernel, el firmware y una pequeña cantidad de utilidades específicas de VideoCore. Para actualizar todo, incluido el firmware de WiFi, debe usar apt-get upgrade / distupgrade.

Hola,
Así que tengo este problema y es mejor con el último FW, 7.45.98.38, de lo que era, pero todavía tengo problemas.
Observaciones
Si arranco la frambuesa sin hacer nada, la WLAN aparece como debería.
Si intento usar el teclado o el mouse bluetooth antes de que la WLAN esté activa, el problema persiste, no obtengo conexión.
Si tengo una conexión y deshabilito / habilito la red inalámbrica, la WLAN no se conecta.
Si dejo la WLAN encendida durante la noche, la conexión deja de funcionar.
Tengo tres configuraciones idénticas y el comportamiento es el mismo en todas ellas.
No sé si importa pero estamos usando WPA2 Enterprise, PEAP y MSCHAPv2

¿Estos problemas solo ocurren cuando los dispositivos BT están conectados?

¡Si! Bluetooth desactivado y teclados y mouse USB conectados y la WLAN se conectó más rápido que nunca.

Todavía coexisten algunos problemas con entonces. Tendrá que estar marcado en Cypress, supongo.

Solo para comprobar, ¿está utilizando la última versión de Raspbian? ¿O algo bastante nuevo?

@pelwell ping

Descripción: Raspbian GNU / Linux 9.4 (stretch)
¿Necesitas más información?

Cuelga después de:
14 de mayo 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD Proveedor EAP 0 método 25 (PEAP) seleccionado

ver el recorte de registro a continuación

14 de mayo 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.7887] dispositivo (wlan0): estado de la interfaz suplicante: desconectado -> asociando
14 de mayo 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: asociado con 44: d9: e7: f7: d5: 34
14 de mayo 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-STARTED Autenticación EAP iniciada
14 de mayo 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.9263] dispositivo (wlan0): estado de interfaz suplicante: asociando -> asociado
14 de mayo 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD proveedor = 0 método = 25
14 de mayo 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD Proveedor EAP 0 método 25 (PEAP) seleccionado
14 de mayo 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0716] dispositivo (wlan0): Activación: la asociación (wifi) tardó demasiado
14 de mayo 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0718] dispositivo (wlan0): cambio de estado: config -> need-auth (motivo 'ninguno') [50 60 0]
14 de mayo 15:44:24 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-DISCONNECTED bssid = 44: d9: e7: f7: d5: 34 motivo = 3 local_generado = 1
14 de mayo 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0937] dispositivo (wlan0): Activación: (wifi) solicitando nuevos secretos
14 de mayo 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0959] sup-iface [0x1c438c0, wlan0]: conexión desconectada (motivo -3)

Tengo el mismo problema con octoPi 0.14 (cada paquete actualizado, firmware rpi a más tardar, cada complemento de octoprint actualizado).

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

con esta configuración es 100% reproducible. Accediendo al sitio web de octoprint en el pi (acceso por primera vez después del arranque) desde mi samsung s4 active (android 5.0.1, usando chrome) o desde mi tablet samsung de 10 pulgadas note con también android 5.xi guess y chrome mata el wifi cuando la página está medio cargada.
No hay cable conectado a mi Pi3, wifi en el canal 11 con wpa2.
Intenté deshabilitar la energía wifi y cambiar al canal wifi 6 sin suerte (consejos de arriba); sin embargo, tuve la sensación de que era un poco mejor con el canal 6.

Pero ahora viene la pista interesante sobre el error:
No tengo ningún problema cuando abro el sitio octopi / octoprint (en el pi) desde mi máquina con Windows 10 o ubuntu 16 (usando Chrome, conexión de cable al enrutador). Supongo que ahora es un error relacionado con Android, Samsung o wifi a wifi. Y creo que hace un tiempo leí algo sobre problemas de android / rpi.

Espero que esto ayude. Si necesita un probador para alguna versión, lo probaría.

Solo pensé en sonar aquí y decir que también hemos visto lo que parecen ser bloqueos de bloqueo relacionados con WiFi alrededor de este controlador que pueden estar relacionados en otro SBC. No es específico de Raspberry PI.

Esto me está pasando a mí también.

Preparar

• Pi 3B 1.2 (a02082)
• Núcleo:

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

Ejecutando la versión 9.4 de Raspbian:

pi<strong i="14">@raspberrypi</strong>:~ $ cat /etc/debian_version
9.4

Versión de firmware:

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 La administración de energía está apagada:

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

Estoy usando el wifi incorporado. No hay nada conectado al puerto Ethernet.

El sistema se ha actualizado usando apt-get upgrade , apt-get dist-upgrade y rpi-update .

Lo que veo

Después de que el pi ha estado activo durante aproximadamente una hora, se vuelve inalcanzable desde la red. No puedo alcanzar el Pi desde mi red local (ping y ssh no funcionan).

En dmesg , veo que obtengo:

brcmfmac: power management disabled
...
snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned

Pero sin errores.

Algo interesante

Me di cuenta de que cuando esto sucede, si me conecto al pi directamente y hago ping a mi computadora portátil, las cosas vuelven a funcionar. Además, los tiempos de ping son un poco extraños, parece que se necesita un poco de tiempo para que las cosas se 'calienten':

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

Si alguien necesita más información, me complacerá proporcionársela.

@bugok , ¿configurar la interfaz de red en promiscuo alivia el problema? ( ifconfig wlan0 promisc ).

@quozl : No ayudó. Después de un tiempo, el ping comenzó a fallar:

$ 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
...

Informar: Mi problema parece estar resuelto y parece no estar relacionado con el problema en este hilo.

Detalles aquí , pero la esencia es que configuré una IP estática en la propia Pi (en /etc/dhcpcd.conf ). Después de definir la IP estática en el enrutador, eliminar la configuración de IP estática de /etc/dhcpcd.conf y reiniciar, las cosas parecen funcionar.

Una actualización rápida: este problema (error "Contenido de datos de buzón desconocido" acompañado de bloqueo inalámbrico completo) persiste en el último firmware con todas las actualizaciones instaladas (dist-upgrade).

Cambiar una sola línea en el archivo hostapd.conf (según mi comentario anterior) todavía me elimina el problema.

Usando Rpi3B con kernel 4.14.52-v7 (raspberrypi-kernel 1.20180703-1) y (firmware-brcm80211 1: 20161130-3 + rpt4)
También sigo enfrentando el problema de que wlan se congela (90 dispositivos de los cuales 2 por día tienen el problema). En algunos casos falta el adaptador y en otros no responde. No estoy usando el Pi en modo AP, simplemente
Intenté volver a enlazarlo como en

Actualmente creé una solución cuando no se detecta ninguna conexión de red, el pi se reinicia. Sin embargo, esta no es una solución adecuada y al menos estoy intentando volver a cargar el controlador

Constantemente veía el mismo problema en un Pi 3 que funcionaba anteriormente. Me di cuenta de que el único cambio que había hecho era enchufar una pantalla táctil LCD, obteniendo energía del Pi. Cuando desconecté la pantalla táctil, WiFi funcionaba correctamente. Así que ciertamente parece estar relacionado con el poder. Esto estaba usando el adaptador de CA oficial de Raspberry.

Ese es un dato muy interesante. ¿Era uno de nuestros LCD?

@ JamesH65 También comencé a experimentar fallas de wifi y picos de latencia después de instalar https://www.waveshare.com/wiki/5inch_HDMI_LCD , tengo una 3b + a rpi cam v2 y la pantalla, conectada a una fuente de alimentación de 3 amperios, no reciba ninguna advertencia de energía ...

Hola chicos, ¿alguna actualización sobre esto? Estaba tratando de usar raspivid en cero W con una transmisión TCP y después de algunos minutos mi Wi-Fi se fue, supongo que es el mismo problema.

No he tenido el problema en al menos un año más o menos. Estoy empezando a pensar cada vez más que puede estar simplemente relacionado con la fuente de alimentación USB que no proporciona suficientes amperios, pero agradecería una prueba de que este no es el caso. Como prueba, intente conectar su cable USB a un adaptador de mayor amperaje, especialmente si puede reproducir fácilmente el problema.

Estoy bastante seguro de que no está directamente relacionado con el amplificador porque solo uso suministros de 2 amperios. en su mayoría cargadores Samsung antiguos. sin embargo, podría ser una ondulación o algo con la fuente de alimentación o el hardware pi. Von meinem Samsung Gerät gesendet.

-------- Ursprüngliche Nachricht --------
Von: rajid [email protected]
Fecha: 07.04.2019 02:15 (GMT + 01: 00)
An: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , comentario [email protected]
Betreff: Re: [raspberrypi / linux] wlan se congela en raspberry pi 3 / PiZeroW (no
3B +) (# 1342)

No he tenido el problema en al menos un año más o menos. Estoy empezando a pensar cada vez más que puede estar simplemente relacionado con la fuente de alimentación USB que no proporciona suficientes amperios, pero agradecería una prueba de que este no es el caso. Como prueba, intente conectar su cable USB a un adaptador de mayor amperaje, especialmente si puede reproducir fácilmente el problema.

—Está recibiendo esto porque comentó. Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.
{"api_version": "1.0", "publisher": {"api_key": "05dde50f1d1a384dd78767c55493e4bb", "name": "GitHub"}, "entity": {"external_key": "github / raspberrypi / linux", "title ":" raspberrypi / linux "," subtitle ":" Repositorio de 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 ":" Abrir en GitHub "," url ":" https://github.com/raspberrypi/linux "}}," updates ": {" snippets ": [{" icon ":" PERSON "," message ":" @rajid in # 1342: No he tenido el problema en al menos un año más o menos. Estoy empezando a pensar cada vez más que puede estar simplemente relacionado con la fuente de alimentación USB que no proporciona suficientes amperios, pero agradecería una prueba de que este no es el caso. Como prueba, intente conectar su cable USB a un adaptador de mayor amperaje, especialmente si puede reproducir el problema fácilmente. "}]," action ": {" name ":" Ver problema "," url ":" https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753 "}}}
[
{
"@context": " http://schema.org ",
"@type": "Mensaje de correo electrónico",
"potencialAcción": {
"@type": "ViewAction",
"target": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"name": "Ver problema"
},
"description": "Ver este problema en GitHub",
"editor": {
"@type": "Organización",
"nombre": "GitHub",
"url": " https://github.com "
}
}
]

Todavía tengo el problema, pero no con tanta frecuencia, tal vez algunas semanas, y ya no puedo inducirlo de manera confiable conectándome desde dispositivos Android de Samsung.

De hecho, estoy alimentando el Pi zero w con una fuente de alimentación USB de 3 A y un cable USB de 15 cm que se usa para cargar bancos de energía (sin líneas de datos, solo líneas eléctricas)

Si utilizo la conexión con regularidad (como un usuario normal), entonces funciona bien, pero si transmito MJPEG a 5 Mbps, se bloquea después de unos minutos, veo un error de buzón (o similar) en journalct (no puedo recordar porque estoy fuera de casa durante una semana), ssh se detiene, no hay ping, Wi-Fi cae, iwconfig tarda unos segundos en mostrar los resultados y están casi vacíos.

@vascojdb Si está utilizando el Pi como un punto de acceso (modo AP), entonces esta solución (vea el texto en negrita en la parte inferior) debería resolver su problema.

¿Haznos saber?

No, no está en modo AP, estoy conectado a la red Wi-Fi de 2,4 GHz de mi casa

Hola,

Tengo un problema de wifi para sincronizar la hora al inicio con el servidor NTP usando LibreELEC en RPI3B + desde la versión 9.0.0.
Después de algunas discusiones con algunos miembros del equipo LE ( ver aquí ), el problema se ha solucionado después de esta modificación .

Pero parece que esta solución se revirtió y el problema sigue presente.
¿Es posible arreglarlo de nuevo?

¿Nadie para responder o escalar este problema?

Mismo problema. ¿Alguna noticia sobre esto?

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)

Intenté apagar la administración de energía por ahora. ¿Es este un error antiguo reintroducido?

https://patchwork.kernel.org/patch/9948825/

Mismo problema. ¿Alguna noticia sobre esto?

Este mensaje solo dice que el firmware del chip wifi falló. No hay nada que el kernel de Linux pueda hacer excepto reiniciar. Un útil informe de errores contiene la siguiente información:

¿Qué firmware wifi estás usando?
¿Cómo opera el wifi (AP, cliente, ...)?
¿Puedes reproducir esto en un tiempo definido?
¿Qué otros dispositivos wifi están involucrados?

está en mi último comentario, ya que era reproducible en ese entonces, pero es malo reproducirlo y cambia con los cambios de software cuando falla.

-------- Ursprüngliche Nachricht --------
Von: Stefan Wahren [email protected]
Fecha: 01.05.2020 10:21 (GMT + 01: 00)
An: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , comentario [email protected]
Betreff: Re: [raspberrypi / linux] wlan se congela en raspberry pi 3 / PiZeroW (no
3B +) (# 1342)

Mismo problema. ¿Alguna noticia sobre esto?

Este mensaje solo dice que el firmware del chip wifi falló. No hay nada que el kernel de Linux pueda hacer excepto reiniciar. Un útil informe de errores contiene la siguiente información:
¿Qué firmware wifi estás usando?
¿Cómo opera el wifi (AP, cliente, ...)?
¿Puedes reproducir esto en un tiempo definido?
¿Qué otros dispositivos wifi están involucrados?

—Está recibiendo esto porque comentó. Responda a este correo electrónico directamente, véalo en GitHub o cancele la suscripción.
[
{
"@context": " http://schema.org ",
"@type": "Mensaje de correo electrónico",
"potencialAcción": {
"@type": "ViewAction",
"objetivo": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"name": "Ver problema"
},
"description": "Ver este problema en GitHub",
"editor": {
"@type": "Organización",
"nombre": "GitHub",
"url": " https://github.com "
}
}
]

Mismo problema. ¿Alguna noticia sobre esto?

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)

Intenté apagar la administración de energía por ahora. ¿Es este un error antiguo reintroducido?

https://patchwork.kernel.org/patch/9948825/

No hay solución de la que hablar, pero tengo exactamente el mismo problema en un Rpi4 con el último firmware instalado. Lo devolví a una imagen de tarjeta SD que hice hace unos meses y el problema desapareció. Mientras uso hostapd, creo que una de estas actualizaciones o una combinación de ellas me rompió:

$ apt list - actualizable
Listado ... Hecho
...
hostapd / estable 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u2 armhf [actualizable desde: 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u1]
firmware-brcm80211 / testing 1: 20190114-1 + rpt6 all [actualizable desde: 1: 20190114-1 + rpt4]
raspberrypi-kernel / testing 1.20200212-1 armhf [actualizable desde: 1.20200114-1]
...

Intenté apagar la administración de energía también (y confirmé que estaba apagado con iwconfig), pero no tuvo ningún efecto al ejecutar hostapd. Tendré que renunciar a las actualizaciones de firmware hasta que se solucione, ya que estamos enviando muchos de estos y necesitamos AP estables para nuestros clientes.

Cualquiera que experimente trampas de firmware, tiempos de espera (-110), etc., habilite la depuración de firmware para que podamos recopilar algunos datos.

Agregue brcmfmac.debug=0x100000 a /boot/cmdline.txt, manteniéndolo en una sola línea larga, luego reinicie. Ejecutar dmesg | grep brcmfmac debería dar como resultado un resultado como este:

[    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
...

Luego, continúe con normalidad. Cuando el firmware de brcmfmac muera, capture la salida de dmesg en un archivo y adjúntelo (o un enlace a pastebin, etc.) aquí.

Dado que la falla desencadena otros mensajes del kernel, existe el peligro de que la salida útil se pierda antes de que tenga la oportunidad de capturarla. Una forma de evitar esto es dejar un shell guardando constantemente los mensajes del kernel en un archivo:

$ dmesg -w > kernel_log.txt &

Viendo el mismo problema aquí. Intentará la depuración mencionada anteriormente.

Ejecutando hostapd en modo AP, wireguard y frr. También usando sombrero celular 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

También puedo recrear esto en la rama 5.4. FWIW, siempre puedo activar este error manualmente SCPing un archivo grande (> 400 MB) a mi Pi Zero W.

Si ayuda, mi versión del kernel es a partir de este compromiso: 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

Registro de fallos con depuración:

[  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)

Durante el bloqueo anterior ejecuté un ifdown e ifup que no restauraron wifi. La única solución es reiniciar el pi o rmmod & modprobe brcmfmac.

Vale la pena señalar que esto sucede con la administración de energía desactivada, ya que tengo esto en mi archivo de interfaces:

pre-up iwconfig wlan0 power off