EDIMAX EW-7811UN .... Está usando o chipset rtl8188cus, IIRC.

Se você ainda não tiver um, crie /etc/modprobe.d/8192cu.conf, com conteúdo ....

Desativar gerenciamento de energia

opções 8192cu rtw_power_mgnt = 0 rtw_enusbss = 0

O rpi3 realmente usa o driver brcmfmac para o wi-fi embutido
há um problema que exige que o gerenciamento / economia de energia seja desligado

Acho que os kernels raspian mais novos já corrigiram isso para desabilitar a economia de energia por padrão, mas não acho que esteja neste branch 4.5 ainda

O que estou fazendo no momento (instalação do gentoo) é o seguinte na inicialização para desabilitar a economia de energia na placa wi-fi

iw wlan0 desligar power_save

O rpi3 realmente usa o driver brcmfmac para o wi-fi embutido

Sim, eu sei. Ah eu vejo. Ele não está mais usando o dongle EDIMAX EW-7811UN. Ele costumava usá-lo com RPi2.

sim eu não uso mais o usb wi-fi, como faço para configurar a linha cmd para desligar o gerenciamento de energia?
crontab
@reboot iw wlan0 desligar power_save

Não tenho certeza para o raspian, já que estou usando o gentoo será diferente

Experimente: https://gist.github.com/mkb/40bf48bc401ffa0cc4d3

Parece funcionar desde que desliguei o gerenciamento de energia, não tive outro acidente de wlan.

Só como mencionei, reiniciar o wlan automaticamente após um travamento, aqui ajuda:
sudo cp /etc/wpa_supplicant/ifupdown.sh /etc/ifplugd/action.d/ifupdown

BTW, o kernel apt-get upgrade mais recente tem o gerenciamento de energia desabilitado por padrão.
@ dh-connect funciona para você se você remover a solução alternativa atual?

ainda está travando após a última atualização, agora recebo este erro no syslog:
brcmfmac: brcmf_sdio_bus_txdata: fora do barramento-> txq !!!

Quando você diz que está falhando, existem outros sintomas além da mensagem de erro?

não, apenas o que postei aqui, mas está no log muitas vezes

a wlan para de funcionar, eu ainda posso trabalhar com ela, mas para fazer a wlan voltar a funcionar eu tenho que reiniciá-la

Obrigado - acho que "wlan pára de funcionar" conta como um sintoma.

Eu tentei algumas coisas, mas a wlan ainda falha

para responder à pergunta acima quando eu retomar a configuração
wireless-power off em / etc / network / interfaces
e reinicie
e verifique as configurações com iwconfig
o gerenciamento de energia está ligado novamente, então por padrão eu não diria que isso está desabilitado, então vou deixar a configuração

Eu tentei isso com o kernel 4.1.19 e agora também com o kernel 4.1.20 ... sem alteração

quando a wlan travou e tento ligá-la novamente com ifdown e ifup wlan0 entendi:
Erro para solicitação wireless "Set Power Management" (8B2C): SET falhou no dispositivo wlan0; Troca inválida.

Também recebi mais alguns erros no syslog:

dhcpcd [532]: wlan0: xxx: opção 25 expirada

21 de março 17:29:35 kernel raspberrypi: [6627.337503] brcmfmac: _brcmf_set_multicast_list: Falha ao configurar mcast_list, -52
21 de março 17:29:36 raspberrypi wpa_supplicant [6318]: wpa_supplicant inicializado com sucesso
21 de março 17:29:36 raspberrypi dhcpcd [532]: wlan0: operadora perdida

21 de março 17:29:43 kernel raspberrypi: [6635.337616] brcmfmac: _brcmf_set_multicast_list: Falha ao configurar mcast_list, -52

21 de março 17:29:45 kernel raspberrypi: [6637.337588] brcmfmac: brcmf_do_escan: erro (-52)
21 de março 17:29:45 kernel raspberrypi: [6637.337602] brcmfmac: brcmf_cfg80211_scan: erro de digitalização (-52)

21 de março 17:29:47 kernel raspberrypi: [6639.337596] brcmfmac: _brcmf_set_multicast_list: Falha na configuração de allmulti, -52
21 de março 17:29:49 kernel raspberrypi: [6641.337632] brcmfmac: _brcmf_set_multicast_list: Falha na configuração de BRCMF_C_SET_PROMISC, -52

há mais alguma coisa que eu possa tentar?

também estes:

21 de março 21:26:55 raspberrypi dhcpcd [526]: wlan0: xxx: opção 25 expirada
21 de março 21:28:54 kernel raspberrypi: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
21 de março 21:30:16 raspberrypi dhcpcd [526]: wlan0: xxx está inacessível, expirando

Não estou surpreso que o iwconfig pense que o dispositivo tem economia de energia habilitada - eu bloqueei dentro do próprio driver, e o estado é salvo nas camadas superiores ou há outra alteração necessária para relatá-lo corretamente. De qualquer forma, há fortes evidências de que evitamos os bugs de economia de energia, mas alguns outros problemas ainda permanecem.

Você tem alguma estimativa aproximada do tempo até a falha e aproximadamente quantos dados podem ter sido transferidos (de ifconfig)?

sim, eu faço, quando eu tenho apenas o servidor da web rodando com pouco tráfego (menos de 100 MB) dura um ou dois dias, quando eu transfiro arquivos de dados grandes como 1 GB de falha de wlan em 1 hora

posso fornecer alguma coisa para ajudar a encontrar o bug?

aqui estão alguns erros do syslog:

29 de março 14:20:56 raspberrypi dhcpcd [535]: wlan0: xxx: opção 25 expirada
29 de março 14:30:15 raspberrypi dhcpcd [535]: wlan0: xxx está inacessível, expirando
29 de março 17:18:42 kernel raspberrypi: [186148.102420] brcmfmac: brcmf_sdio_bus_txdata: fora do barramento-> txq !!!
29 de março 17:18:43 kernel raspberrypi: [186149.101045] brcmfmac: brcmf_sdio_bus_txdata: fora do barramento-> txq !!!
29 de março 17:18:43 kernel raspberrypi: [186149.101145] brcmfmac: brcmf_sdio_bus_txdata: fora do barramento-> txq !!!
29 de março 17:18:44 kernel raspberrypi: [186150.101209] brcmfmac: brcmf_sdio_bus_txdata: fora do barramento-> txq !!!
29 de março 17:18:50 raspberrypi wpa_supplicant [478]: wlan0: CTRL-EVENT-DISCONNECTED bssid = xxx reason = 3 localmente_generated = 1
29 de março 17:18:50 kernel raspberrypi: [186156.181033] brcmfmac: brcmf_cfg80211_disconnect: erro (-52)
29 de março 17:18:52 kernel raspberrypi: [186158.181028] brcmfmac: send_key_to_dongle: erro wsec_key (-52)
29 de março 17:18:54 kernel raspberrypi: [186160.181046] brcmfmac: send_key_to_dongle: erro wsec_key (-52)
29 de março 17:18:56 kernel raspberrypi: [186162.181048] brcmfmac: send_key_to_dongle: erro wsec_key (-52)
29 de março 17:18:58 kernel raspberrypi: [186164.181049] brcmfmac: send_key_to_dongle: erro wsec_key (-52)
29 de março 17:18:58 kernel do raspberrypi: [186164.185477] cfg80211: Chamando o CRDA para atualizar o domínio regulatório mundial
29 de março 17:18:58 raspberrypi dhcpcd [535]: wlan0: operadora perdida
29 de março 17:18:58 raspberrypi wpa_supplicant [7354]: wpa_supplicant inicializado com sucesso
29 de março 17:18:58 kernel raspberrypi: [186164.314511] brcmfmac: brcmf_cfg80211_reg_notifier: não é um código ISO3166
29 de março 17:18:58 kernel raspberrypi: [186164.314541] cfg80211: Domínio regulatório mundial atualizado:
29 de março 17:18:58 kernel raspberrypi: [186164.314548] cfg80211: DFS Master region: unset
29 de março 17:18:58 kernel raspberrypi: [186164.314555] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
29 de março 17:18:58 kernel raspberrypi: [186164.314565] cfg80211: (2402000 KHz - 2472000 KHz a 40000 KHz), (N / A, 2000 mBm), (N / A)
29 de março 17:18:58 kernel raspberrypi: [186164.314573] cfg80211: (2457000 KHz - 2482000 KHz a 40000 KHz), (N / A, 2000 mBm), (N / A)
29 de março 17:18:58 kernel raspberrypi: [186164.314581] cfg80211: (2474000 KHz - 2494000 KHz a 20000 KHz), (N / A, 2000 mBm), (N / A)
29 de março 17:18:58 kernel raspberrypi: [186164.314592] cfg80211: (5170000 KHz - 5250000 KHz a 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (N / A)
29 de março 17:18:58 kernel raspberrypi: [186164.314602] cfg80211: (5250000 KHz - 5330000 KHz a 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 s)
29 de março 17:18:58 kernel raspberrypi: [186164.314611] cfg80211: (5490000 KHz - 5730000 KHz a 160000 KHz), (N / A, 2000 mBm), (0 s)
29 de março 17:18:58 kernel raspberrypi: [186164.314645] cfg80211: (5735000 KHz - 5835000 KHz a 80000 KHz), (N / A, 2000 mBm), (N / A)
29 de março 17:18:58 kernel raspberrypi: [186164.314654] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 0 mBm), (N / A)

Obrigado pela oferta, mas agora está nas mãos da Broadcom.

Qualquer atualização da Broadcom se este for um bug que será corrigido? Agora tenho uma configuração de cron job para ativar e desativar o wlan0 quando houver falha no ping.

atualização rápida de minha parte, consegui consertar o problema que parece estar relacionado ao driver, instalei o Ubuntu MATE 16.04 com kernel 4.4.8 e não tive problemas com wi-fi desde

quero dizer que eles anunciam: "Ubuntu MATE 16.04 também tem Bluetooth e Wifi totalmente funcionais no Raspberry Pi 3", o que parece verdade

talvez também funcione com uma nova versão do Debian, que eu não posso dizer

@ juched78 Você está executando um kernel 4.4? Caso contrário, execute sudo rpi-update para obter a última versão 4.4.8 e veja se ela apresenta o mesmo problema.

Os drivers Broadcom mudaram significativamente desde o 4.1, e nossa árvore 4.4 inclui back-ports de algumas correções que foram para 4.5. Não estou ciente de quaisquer bugs pendentes além da falha ao acordar do repouso (o gerenciamento de energia ainda está desativado) - os canais 12 e 13 podem ser usados ​​quando permitido e o modo Ad Hoc não trava - mas ainda pode haver problemas ocultos .

Oh, há um bug relatado ainda em 4.4.8 - o uso aparentemente pesado de hostapd pode levar a um aviso do kernel (veja https://github.com/raspberrypi/linux/issues/1375).

Eu estou correndo:
Linux XXX 4.4.8-v7 + # 880 SMP Sex. 22 de abril 21:55:04 BST 2016 armv7l GNU / Linux

27 de abril de 2016 11:06:18
Copyright (c) 2012 Broadcom
versão 9b52ab7b475f4a056658fd2d95d2440b32167390 (limpo) (lançamento)

Com meu Netgear R7000 rodando o Shibby Tomato, cerca de 2 dias no wi-fi cai e nos logs do sistema vejo:

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

Então parece que nunca mais se reconecta ...

Usar sudo ifdown wlan0 seguido por sudo ifup wlan0 traz de volta minha conexão.

Acabei de atualizar para:
Linux JuchePi 4.4.8-v7 + # 881 SMP Sáb 30 de abril 12:16:50 BST 2016 armv7l GNU / Linux

Não tenho certeza do que é diferente do dia 22 ao dia 30. Vou monitorar a conexão.

Meu RPi 3 também atingiu esse problema. Recebi algumas mensagens de kernel diferentes. Principalmente um daqueles abaixo.
Depois disso, consigo fazer o WiFi funcionar, diminuir e aumentar o wlan0 não ajuda.

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

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

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

Raspberry é alimentado por um adaptador de alimentação original para a versão 3. Estou executando o OSMC mais recente:
$ uname -a
Linux osmc 4.4.8-3-osmc # 1 SMP PREEMPT Dom 1 de maio 18:57:43 UTC 2016 armv7l GNU / Linux

Ainda monitorando. Tive o openhab offline depois de correr 3 dias, mas por alguma razão eu ainda conseguia fazer o ssh no Pi, o que normalmente não conseguia. O início da hora e o script de wi-fi executaram para desativar e ativar a conexão e, em seguida, ele se reconectou à minha org openhab. Ímpar. Vou continuar assistindo.

Também estou tendo o mesmo problema - rastreamento de dmesg da seguinte forma:

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 está sendo usado como um roteador / ponto de acesso

A duração da conectividade parece aleatória - já tive até duas semanas e apenas alguns minutos. Ultimamente, ele sai a cada 20 minutos ou mais. Desativar e fazer o backup do wlan0 não resolve o problema - uma reinicialização completa é necessária.

O problema parece ser agravado durante a transmissão do Netflix da minha AppleTV. Embora não fosse esse o caso quando eu tinha duas semanas de tempo de atividade.

Estou no 4.4.10-v7 +

Troquei de canal de 13 para 6 para verificar se esse poderia ser o problema (havia alguns defeitos nos canais altos) e desde então não tenho um freez WiFi. Mas isso pode ser uma coincidência ...

Mudar os canais do ponto de acesso não ajudou. O WiFi ainda falha. Nas últimas vezes, tive que reiniciar algumas vezes seguidas para fazê-lo funcionar.

Eu enfrento esse problema especificamente quando tento fazer uma transferência SFTP entre o rpi3 e meu telefone Galaxy S5. Quando tento realizar a mesma transferência do meu laptop, tudo funciona perfeitamente.

Executando o kernel mais recente do rpi-update:

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

Mensagem de erro do syslog:

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

Parece que a única solução após esse erro é reinicializar.

Eu tive minha queda fora da rede duas vezes na semana passada. Foi a primeira vez que tive pressa, então apenas desliguei e reiniciei. Poucos dias depois aconteceu novamente, reiniciado novamente e, em seguida, execute as atualizações completas do sistema (incluindo firmware) e monitorará. Monte-o sem monitor por perto, portanto, obter detalhes sobre o erro requer mais esforço :)

Mesmo problema aqui. Sempre congela ao transferir arquivos grandes por sftp. Basta reiniciar para resolver

Esse problema pode estar relacionado a https://github.com/raspberrypi/linux/issues/1313

A Broadcom diz que o # 1313 não é um problema e o kernel mais recente não mostra mais essas mensagens.

Não consegui reproduzir esse problema. Alguém conseguiu capturar um rastreamento de pacote próximo ao momento da falha?

Se alguém tiver tempo para fazer mais alguns testes com um módulo de driver habilitado para depuração, ficaria muito grato:

1) Execute sudo rpi-update e reinicie. Isso é para que seu kernel fique no mesmo nível que o meu para que o módulo seja compatível.

2) Baixe e instale o módulo de driver atualizado:

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

Reinicialize para ativar os novos módulos.

3) Use seu Pi normalmente e, se o WiFi congelar, execute:

dmesg > wifi_freeze.txt

e carregue-o em seu site de colagem favorito (ou crie um Gist). Um ou dois logs devem ser suficientes.

Para restaurar a versão original do 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,}

Desde já, obrigado.

Espere um momento enquanto verificamos se a saída de depuração realmente está ativada.

Você também precisará habilitar um recurso de depuração no driver:

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

Eu alterei as instruções acima.

Após uma reinicialização, a saída do dmesg deve incluir algo assim:

[   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 depois de executar suas instruções não tenho mais wi-fi ...

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

Experimente isto:

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

E reinicie.

wlan0 não associa.
wireless.txt
(em uma de muitas reinicializações, eu vi uma associação por alguns minutos, mas não percebi (ainda) no dmesg)

Parece que o problema pode ter sido resolvido para mim com a atualização de 4.4.11-v7 + para 4.4.15-v7 +

Tentei recriar os problemas que estava tendo com as transferências SFTP de um telefone Android, mas não estou vendo nenhum problema no momento.

@pelwell após uma longa espera, wlan0 conseguiu se associar; dmesg anexado ao log anterior:
wireless.txt
esperando agora pelo congelamento ou perda de associação
espero que isso seja útil

@pelwell rapidamente perdeu a conexão novamente; dmesg anexado a:
wireless.txt

Obrigado. Foi lento para mim na primeira vez. Estive ocupado conseguindo um Raspbian limpo e aplicando os patches para tentar reproduzir o problema - continuarei de qualquer maneira.

@pelwell
wireless.txt
e reassociado novamente: dmesg anexado novamente
você quer que eu continue?

@pelwell : perdeu a associação novamente
wireless_associationloss.txt

@pelwell
está ligando / desligando irregularmente
wireless_associationloss.txt

Acho melhor você voltar agora, antes que minha caixa de entrada transborde.

Está bem; Voltarei para o meu dongle MT7601U de € 3. ;)

Obrigado pela vossa ajuda até agora,

Acabei de encontrar esse problema, posso confirmar que é semelhante ao que estou vendo? Eu configurei um RPi 3 como um ponto de acesso e de vez em quando não consigo me conectar a ele. Consigo fazer o ssh pela conexão com fio e vejo que wlan0 ainda está funcionando com o endereço IP correto, mas a única maneira de fazer o ponto de acesso funcionar novamente é reinicializar. Vejo rastreamentos de pilha como este em /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 ]---

Meu kernel é 4.4.13-v7 + e acabei de executar o rpi-update pela primeira vez, então não sei ainda se isso vai ajudar.

Eu me pergunto se isso pode estar relacionado, ou talvez um problema separado
https://www.youtube.com/watch?v=_D_fi_ck9Vo

Meu RPI3 funcionou sem problemas via WiFi até que eu atualizei para o udev mais recente ...

Agora não conecta mais ...

Também instalei módulos corrigidos da Pelwell, mas não tivemos sucesso: simplesmente não conecta ...

Me diga se posso ajudar,

Meu melhor,
Mimmo

@ dh-connect o seu problema foi resolvido? Em caso afirmativo, feche este problema. Obrigado.

Estou trabalhando com lan desde então, não tentei wlan

Oi,

Eu tenho o que parece ser o mesmo problema com meu rpi 3. Eu voltei a usar o dongle USB wi-fi RPI oficial, que é sólido como uma rocha, mas o wi-fi embutido morre após ~ 20 horas de conectividade com esse tipo de mensagens no syslog

brcmfmac: brcmf_cfg80211_reg_notifier: não é um código ISO3166
cfg80211: Domínio regulatório mundial atualizado:
cfg80211: Região Mestre DFS: não definido

este é o último raspbian, o firmware mais recente

É possível reabrir este problema?
Por que foi fechado?

Estou trabalhando com lan desde então, não tentei wlan
dh-connect fechou há 13 dias

Esta não é uma solução que valha a pena encerrar o problema ...

Ainda tenho o problema e consigo reproduzir o bug.

Minha parte relevante do dmesg é:

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

Estou tendo o mesmo problema que @jrmhaig e atualizei agora

$ 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

Configure hostapd com uma ponte.

/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 pessoas com problemas de WiFi, a Cypress (era Broadcom) nos forneceu módulos de depuração para ajudar a diagnosticar os problemas. Como os módulos são específicos da versão do kernel, você primeiro precisa atualizar (ou possível reverter) para uma versão de firmware específica:

sudo rpi-update b0ef6e25679d3612a980708cf4c3907ce6e13e84
sudo shutdown -r now

Agora você pode baixar e instalar os módulos de depuração:

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

O comando final executará o script de instalação, que copia os módulos originais para um lado antes de substituí-los pelas versões de depuração. Executar o comando novamente reverterá para as versões originais.

Após a instalação, reinicie seu Pi 3 - agora dmesg | grep brcmfmac mostrará uma mensagem de diagnóstico como esta:

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

Quando você tiver um problema, use dmesg > wifidbg.txt para capturar o rastreamento em um arquivo, junto com quaisquer outras mensagens do kernel, depois carregue o arquivo em algum lugar (gist, pastebin, dropbox etc.) e poste um link para ele junto com uma descrição do que você estava fazendo quando o erro ocorreu.

por favor, atualize minha memória: qual comando usar para retornar ao firmware estável
se eu decidir parar de depurar?

sudo apt-get update
sudo apt-get upgrade

deve fazer o truque. E sudo ./brcmdbg apenas para reverter para os drivers não depurados.

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

Depuração iniciada; precisava de cerca de 5 ou 6 tentativas para associar; não sei por que todas as tentativas, exceto a última, falharam; irá deixá-lo rodar até que eu veja a perda de associação e então despeje um novo dmesg. O comportamento de associação inconsistente era meu problema antes de parar de usar o wi-fi onboard, então isso pode estar acontecendo no local. Informe se alguma atividade adicional pode ser útil.

https://gist.github.com/BenoitSvB/bf8acdbb7b664df90e885603bb4774ce#file -201609081628_wifidbg-txt
Não fazendo nada além de esperar; vemos aqui várias perdas / recuperações de associação?

Obrigado por isso. Hmm - esses logs não são muito informativos, mas vamos ver o que o Cypress traz de volta.

https://gist.github.com/BenoitSvB/98db53ff884e7b1a57bf1475d6106c56
Perda inexplicada e recuperação de associação; tempo suficiente para ver no ícone da bandeja do sistema.
O ponto de acesso é Linksys wrt160n com Firmware: DD-WRT v24-sp2 (07/08/10) std.
Acho que posso parar a depuração por agora e voltar para o meu dongle de € 3 MT7601U, mas me diga se posso ajudar mais.

@pelwell Eu não vi nenhuma restauração de firmware após sudo apt-get update && sudo apt-get upgrade e sudo rpi-update dá
*** Seu firmware já está atualizado; Acho que preciso executar o rpi-update com um hash git específico para reverter para o firmware estável. Você sabe qual hash?

O histórico de commit no repositório

sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab

@pelwell :
root @ pi3b : / home / pi # sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab
** Atualizador de firmware Raspberry Pi da Hexxeh, aprimorado por AndrewS e Dom* * Executando autoatualização
** Reiniciando após atualização* * Atualizador de firmware Raspberry Pi da Hexxeh, aprimorado por AndrewS e Dom
Git hash inválido especificado

Ah, o firmware rpi Hexxeh tem IDs de confirmação diferentes - tente 569e6611ac20c735647eb0e550484a73935a672d.

Eu me pergunto se https://github.com/raspberrypi/linux/issues/1552 / # 1444 pode estar relacionado a esse problema também.

Recentemente, implantei uma configuração de 40xRPI3 que faz algumas coisas de bluetooth, tivemos que obter interfaces wi-fi usb ou senão o wlan congelaria constantemente. Agora usamos o dispositivo bl interno e o módulo wi-fi interno está na lista negra do modprobe.d.

Pode ser útil fazer hcitool name 11:11:11:11:11:11 e ver se isso gera alguma entrada de log interessante também. Estou acompanhando esse problema, não tive tempo de configurar meu ambiente de laboratório para testar nada eu mesmo. Tivemos alguns congelamentos de wi-fi sem BT habilitado, mas a combinação de wi-fi + bt pode mais ou menos sempre matar o wi-fi em um período muito curto. Isso sempre foi reproduzível em qualquer número de nossos rpi

@pelwell
ESTÁ BEM; uname -a dá Linux pi3b.thuis 4.4.13-v7 + # 894 SMP Seg 13 de junho 13:13:27 BST 2016 armv7l GNU / Linux
Apenas para informação: onde alguém encontraria o hash git para a versão de firmware estável real?

@thomasf
embora eu tenha o Bluetooth ativado, não tenho uso para ele no momento.nome da ferramenta 11: 11: 11: 11: 11: 11 não retorna nada; o que, suponho, é de se esperar, já que não estou conectado a nenhum dispositivo. Talvez eu deva comprar um dispositivo de áudio BT para brincar.

Defina estável.

O hash que eu (finalmente) lhe dei é para o lançamento do firmware de 20 de junho, que você obterá se executar:

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

Não estou ciente de um único local que contenha o hash da versão "estável" mais recente, mas ao passar pelo RPI-Distro como fiz e fazer referência cruzada com o repo Hexxeh, você pode obter hashes de atualização do rpi para qualquer versão você gosta. Se você considerar que a versão 2016-05-23 é estável porque fazia parte da última versão Raspbian completa, então você deseja o hash 3b98f7433649e13cf08f54f509d11491c99c4c0b que se traduz em um hash de atualização rpi de 2b9c0bfacfc11ee8bb9b30dc9cfc11ee8bf9b30dc9c9c398a8968db896.

@BenoitSvB Apenas executar aquele comando hcitool de uma nova inicialização sem tocar em hci0 com qualquer outro software faz com que o wi-fi comece a se comportar mal em nossos testes, não sei se importa se há algum outro dispositivo bluetooth, mas é o menor exemplo reproduzível Posso pensar em como desencadear os problemas de congelamento de wi-fi.

Eu também testei dongle bt externo + wi-fi interno, mas o wi-fi interno às vezes trava mesmo quando o driver bt bt interno não está carregado. A "solução" (como na solução rápida) para nós foi usar adaptadores wi-fi usb, que se provaram estáveis ​​em nossos testes e uso de produção.

Eu ainda suspeito do nº 1313 como relacionado.

Op 8-9-2016 às 18:07 schreef Thomas Frössman:

Também testei bt dongle externo + wi-fi interno, mas o interno
o wi-fi às vezes trava mesmo quando o driver bcm bt interno não está
carregado. A "solução" (como uma solução rápida) para nós era usar wi-fi USB
adaptadores, que se provaram estáveis ​​em nossos testes e uso de produção.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245649229,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFyzObJxRjzQ-uMUlfe8hjRasrfq3nkwks5qoDLXgaJpZM4HupC5.

@pelwell
estável seria, neste caso, o firmware conforme lançado pela Fundação com sua última imagem publicada e atualizado apenas por "sudo apt-get update && sudo apt-get upgrade", portanto, sem invocação de rpi-update (com ou sem um git específico hash, que significa, como entendi, atualizar para um firmware mais recente apenas para fins específicos).
O que me leva à pergunta: posso ler o hash do meu firmware operacional antes de carregar um novo firmware para teste, para fazer uma restauração mais fácil após o teste, pois não confiaria em mim mesmo conduzindo a referência cruzada que você mencionou ...

Talvez - cat /boot/.firmware_revision seja escrito por rpi-update, mas
sem tentar, não saberia dizer se os lançamentos do Raspbian também escrevem
isto.

boot / .firmware-revision é uma coisa de atualização de rpi (
https://www.raspberrypi.org/forums/viewtopic.php?t=106073&p=732449#p731830)

Mas descobri com:

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

que eu realmente quero:

• firmware a partir de 390f53ed0fd79df274bdcc81d99e09fa262f03ab

Eu entendo o crossref de
https://github.com/RPi-Distro/firmware/commits/debian?author=popcornmix para
https://github.com/Hexxeh/rpi-firmware/commits/master é feito com cuidado
comparando datas e descrições de commits.

Aprendeu algo; thnx :)

Op 8 set. 2016 20:28 schreef "Phil Elwell" [email protected] :

Talvez - cat /boot/.firmware_revision seja escrito por rpi-update, mas
sem tentar, não saberia dizer se os lançamentos do Raspbian também escrevem
isto.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245693018,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFyzOQ_pfODaEmuBGR6pQVXs2W6LggW8ks5qoFO2gaJpZM4HupC5
.

@BenoitSvB : Seus rastros parecem mostrar um tipo diferente de problema - o firmware não está dando nenhuma pista sobre por que você está sendo desconectado. Você pode obter mais algumas pistas de um farejador de pacotes como o WaveShark.

@mathieugouin @ dh-connect @ juched78 @maciex @duncanmcdowell : Tenho um engenheiro da Cypress que deseja saber mais sobre seus problemas; se você me enviar um e-mail - phil em raspberrypi ponto org -, posso colocá-lo em contato com ele. Se você quiser acelerar as coisas, instale os módulos de depuração conforme descrito acima e salve a saída do dmesg quando as coisas derem errado.

@pelwell O Google não retornou muito sobre 'packet sniffer Waveshark', mas acho que você quis dizer WireShark. O fato de que a lista negra de brcmutil & brcmfmac ao usar um dongle MT7601U faz com que o comportamento errático de conexão / desconexão desapareça, combinado com as ocorrências frequentes 'fora de ordem' (consulte # 1313, agora oculto, mas não resolvido) me faz suspeitar de um Broadcom / Causa do hardware Cypress.
O Wireshark pode ajudar, mas eu precisaria de ajuda para configurar / conduzir um esforço sério de depuração de hardware.

Sim, eu quis dizer wirehark.

Você pode usar o utilitário dumpcap (parte do pacote tshark em modo texto) para registrar todas as atividades em um arquivo e, em seguida, eliminá-lo quando o log dmesg incluir uma mensagem suspeita. Algo assim:

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

Observe que embora "grep --max-count 1" deva parar após uma correspondência, parece exigir mais uma linha de entrada para fazê-lo realmente parar, mas isso não deve ser um problema na prática.

Se o seu arquivo de captura ficar muito grande, você pode fazer com que o dumpcap use uma gravação de duração fixa usando a opção "-b duration: 60 " (por um minuto). Existe a possibilidade de reiniciar a captura dessa forma em um momento ruim e perder os pacotes interessantes, mas isso é improvável. Você sempre pode tornar isso menos provável aumentando a duração.

@BenoitSvB Há um tópico aqui que sugere desativar o roaming no driver Pi3 WiFi como uma forma de evitar problemas de conectividade. O roaming permite que um dispositivo se mova automaticamente entre APs com o mesmo SSID, mas isso provavelmente será menos útil em um dispositivo estático como o Pi3, e há uma sugestão de que isso pode levar a uma perda total de conectividade.

Você poderia tentar habilitar o parâmetro do módulo roamoff ? Você precisa criar create /etc/modprobe.d/brcmfmac.conf contendo o seguinte:

options brcmfmac roamoff=1

@pelwell : Desativar o roaming não é a solução; mas me faz brincar com diferentes canais e um segundo ponto de acesso. Descobri que o adaptador wi-fi integrado só tem problemas com alguns canais (por exemplo, 1, 5) e apenas no Linksys WRT160N com firmware DD-WRT. Curiosamente, embora nenhum dos meus outros clientes wi-fi compartilhassem esses problemas: eles se conectarão sem problemas em todos os canais oferecidos em ambos os pontos de acesso. Bom para mim, tenho uma solução estável (não usar canais wi-fi onboard tem problemas), mas não há clareza no assunto.
Você quer que eu faça um teste específico?
A propósito, precisamos definir o parâmetro
options brcmfmac debug = 1
no /etc/modprobe.d/brcmfmac.conf enquanto usa os test-drivers especiais?
E você conhece uma maneira de medir o tempo de atividade de uma associação wi-fi: então eu poderia testar mais sistematicamente todos os canais por períodos mais longos sem fazer arquivos de captura gigantescos.

Tive certeza de que a depuração solicitada está habilitada nos drivers de depuração por padrão (tem o mesmo efeito que options bcrmfmac debug=0x100000 ), mas sinta-se à vontade para experimentar valores diferentes.

Não conheço nenhuma maneira de medir o tempo de atividade de uma associação, a não ser fazer pesquisas frequentes e esperar encontrar uma mudança.

Um funcionário da Cypress está ciente desse tópico, mas mande-me um e-mail (phil em raspberrypi dot org) se quiser ser contatado diretamente.

Olá,

Existe algum progresso nesta questão? Posso me conectar à minha rede Wi-Fi aberta e, após um tempo aleatório, tenho isto em meus 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

E não consigo fazer ping no roteador.

Depois de ifdown wlan0 && ifup wlan0 ele funciona novamente, até o próximo wlan0: carrier lost .

O gerenciamento de energia está desativado, o bluetooth está desativado, o roaming está desativado (como você sugeriu) e minha versão é Linux pi3 4.4.17-v7+ .

sempre acontecia quando fazia a ponte eth0 com wlan0, tive o mesmo problema que https://github.com/raspberrypi/linux/issues/1375

Eu tenho exatamente o mesmo problema de Pi3 onboard WiFi cair depois de um período de tempo aleatório. ifup faz com que funcione novamente sem problemas.

Depois de muita investigação, descobri que era devido a ter três APs (BSSIDs) com um SSID (1 cada no canal 1, 6 e 11). Esta configuração oferece suporte a roaming contínuo e funciona perfeitamente com todos os outros clientes WLAN.

Habilitar depuração / registro com driver padrão parece mostrar que em algum estágio o Pi decide desautenticar e até mesmo colocar na lista negra um dos BSSIDs. A razão não é clara, mas parece ser uma decisão tomada no final do Pi.

Quando eu tenho exatamente a mesma configuração no Pi, mas com apenas um BSSID para o SSID, o Pi pode aguentar por dias sem problemas.

Infelizmente, desativar o roaming de acordo com o link do pelwell (http://projectable.me/optimize-my-pi-wi-fi/) não é realmente viável, tendo apenas um BSSID por SSID não é uma opção, e eu em vez disso, não precisa depender de um script que executa ping em algum host e executa ifdown / ifup.

Está sendo feita alguma investigação adicional para oferecer suporte a vários BSSIDs por SSID ou posso fazer algo especificamente para apoiar a investigação?

Obrigado!

Estou tendo esse problema e minha rede é semelhante à de @TheOriginalMrWolf .
Tenho uma estação base da Apple e um expresso de aeroporto em uma configuração de malha usando WDS.

Eu também estou tendo esse problema. Se eu copiar arquivos para um compartilhamento de samba, a conexão wi-fi é perdida (raspberry 3, raspbian novo instalado).
Syslog:
brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012

Estou tendo exatamente o mesmo problema ao reproduzir música com upnp (gmediarender).

Estou tendo o mesmo problema ao iniciar chamadas de voz no wechat, com o rpi como um AP usando hostapd. Eu recebo um monte 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 !!!

Com traços 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 ]---

O rastreamento é suspeitamente semelhante ao de @jrmhaig .

Acabei de fazer isso acontecer novamente e fiz algumas depurações. Recebi algumas mensagens diferentes desta vez, que parecem interessantes (parece que são as mesmas mensagens que @maciex recebeu uma 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 o sistema congela quando isso acontece. Executar while sleep 1; do date; done em um loop resulta em um intervalo quando ocorre o congelamento. Eu me pergunto se isso significa que brcmf_proto_bcdc_msg retornando -110 (tempo limite) é apenas um sintoma do problema real - ele apenas registra onde quer que travamos.
2. Medi (com vcgencmd ) a temperatura e as tensões no momento do congelamento. Nada a relatar lá, pelo que posso dizer.
3. Meu sistema é um AP com encaminhamento para um modem ZTE 4G via USB (ou seja, client -> wlan0 -> rpi -> usb0 -> 4g . Parece que o usb0 ainda consegue acessar a internet quando ocorre o congelamento do wi-fi.

Re: os comentários acima, isso acontece no modo de compartilhamento NAT para mim com roamoff=1 . Nenhum deles corrigiu ou atenuou o problema para mim.

Depois de desabilitar o WPA (usando create_ap -w 2 no meu caso para habilitar apenas o WPA2), o problema parece resolvido. Não está claro por quê.

Também estou enfrentando os problemas relatados aqui. No meu caso, isso acontece sempre que acesso arquivos (geralmente mp3) através do Samba do gerenciador de arquivos e player Samsung + ES.

Meu raspberry pi3 é wi-fi conectado ao meu AP. Portanto, toda a comunicação com ele é via rede wi-fi. Não possui monitor, teclado ou mouse.

Posso reproduzir o erro facilmente, então se alguém quiser que eu produza arquivos de log, me diga como posso ajudar.

Abaixo de minhas entradas de syslog.

27 de dezembro 16:11:50 kernel raspberrypi: [560.902063] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
27 de dezembro 16:11:52 kernel raspberrypi: [562.928930] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
27 de dezembro 16:11:54 kernel raspberrypi: [564.926659] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
27 de dezembro 16:11:54 kernel raspberrypi: [564.926820] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO falhou, -52
27 de dezembro 16:11:56 kernel raspberrypi: [566.924560] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
27 de dezembro 16:11:58 kernel do raspberrypi: [568.922555] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
27 de dezembro 16:11:58 kernel raspberrypi: [568.928073] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO falhou, -52
27 de dezembro 16:12:00 kernel raspberrypi: [570.920675] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
27 de dezembro 16:12:02 kernel raspberrypi: [572.918980] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
27 de dezembro 16:12:02 kernel raspberrypi: [572.924580] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO falhou, -52
27 de dezembro 16:12:04 kernel raspberrypi: [574.917259] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
27 de dezembro 16:12:06 kernel raspberrypi: [576.915703] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
27 de dezembro 16:12:06 kernel raspberrypi: [576.921498] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO falhou, -52
27 de dezembro 16:12:06 raspberrypi ifplugd (wlan0) [1149]: Usando o modo de detecção: IFF_RUNNING

@rcassaniga
Eu também tive o mesmo problema com a configuração idêntica.

Solução após horas de depuração:
Desative o IPv6 no raspberry em /etc/modprobe.d/ipv6.conf:
alias net-pf-10 off
alias ipv6 desligado
options ipv6 disable_ipv6 = 1

Esta é apenas uma solução alternativa se você não usar ipv6 em sua rede.

Obrigado @ varl0g você é meu herói! :)
Parece que esta solução alternativa está funcionando para mim, não consigo mais reproduzir o problema.

@ varl0g : Parece que a solução alternativa funcionou porque não consigo reproduzir o erro.

Obrigado e feliz 2017.

Tentei desligar o ipv6. Isso não fez diferença. Tentei desligar o modo de economia de energia. Ainda sem diferença. No entanto, quando eu configuro o canal do meu AP para 6 (em vez de 11), meu Raspberry Pi está ativo há 2 dias sem problemas!

Gostaria de confirmar que a solução alternativa para desligar o IPv6 não funciona.
Infelizmente, tenho o mesmo problema com meu RPi3 e roteador Apple Airport Extreme.

@rajid , @ dh-connect
Surpreendentemente, também resolveu meu problema quando mudei o canal wi-fi do meu AP para 6 em vez de automático, obrigado @rajid

eu também tenho esse bug - brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
Onde consertar ????
Estou tentando o kernel 4.9, kernel 4.4.41 - todos têm esse bug. Fonte de alimentação 2.4a.

Tenho que revogar meu comentário anterior sobre o canal 6. Aparentemente, foi uma coincidência que meu RPI3 teve WiFi estável por 6 dias.

Gostaria de saber se alguém teve alguma sorte com esse problema. Tentei desativar o gerenciamento de energia, o bluetooth e a troca de canais. Nada até agora funcionou. Estou executando o Octoprint com uma webcam conectada. Parece acontecer com bastante frequência e noto que acontece com muito mais frequência quando tenho mais de uma conexão http estabelecida.
Erro de syslog antes do modo de economia de energia:
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
erro de syslog após modo de economia de energia:
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 !!!
Atualmente estou executando Linux octopi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

Eu finalmente consegui estabilizar meu RaspPi 3 em meu wi-fi mudando o canal de 2.4 Ghz do meu wi-fi para "6". Eu esqueci o que era antes, 11 eu acho, mas não tenho certeza. Isso não funcionou bem e eu encontrei uma página da web que dizia que era um problema, mas funciona bem. Tem estado muito melhor desde que mudei o wi-fi da minha casa para o canal 6.

/ raj

Em 3 de março de 2017, às 20h39, Daniel < [email protected] [email protected] > escreveu:

Gostaria de saber se alguém teve alguma sorte com esse problema. Tentei desativar o gerenciamento de energia, o bluetooth e a troca de canais. Nada até agora funcionou. Estou executando o Octoprint com uma webcam conectada. Parece acontecer com bastante frequência e noto que acontece com muito mais frequência quando tenho mais de uma conexão http estabelecida.
Erro de syslog antes do modo de economia de energia:
brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
erro de syslog após modo de economia de energia:
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 !!!
Atualmente estou executando o polvo Linux 4.1.19-v7 + # 858 SMP Ter 15 de março 15:56:00 GMT 2016 armv7l GNU / Linux

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-284126948 ou silencie o tópico 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, largura de canal de 20 MHz, parece estável há semanas.

Eu tinha observado o mesmo problema relatado pela Desligar o ipv6 como sugerido por @ varl0g resolveu meus problemas. Wifi agora fica estável por dias e dias, embora antes parasse minutos após a inicialização.

Não tive sorte no canal 6 ou 7. não confirmei mais ninguém nesses canais.
Eu tentei piscar meu sd com uma nova imagem e agora meus controladores de wi-fi não estão recebendo concessões de DHCP adequadas. Eles estão inicializando com 169.254.xx.xx ips locais, não a sub-rede do meu servidor dhcp.

Decidi apenas limpá-lo e instalar o mais novo raspbian e instalar o octoprint da fonte. até agora sem problemas.

Pelo que eu posso dizer, este é um problema no software de driver do próprio sdio.c brcm80211.
A string 0x40012 é realmente 0x00040012, que quando interpretada usando as máscaras e códigos daqui ~ linha 55, pode ser vista como uma string de caixa de correio indicando uma mudança de controle de fluxo para DEVREADY. O que é estranho é que a string nunca é interpretada como tal e, portanto, atinge a seção compatível com versões anteriores do driver ~ linha 1127 do arquivo sdio.c dentro da fonte brcm80211 / brcmfmac aqui .

Não tenho grande experiência com o driver em si, nem a capacidade de recompilar e testar (só tenho um rpi3, e prefiro não bagunçar o ambiente em que ele vive atualmente. não sou versado em recompilar / atualizar drivers linux ..) então não estou exatamente certo, mas parece que duas mensagens HMB estão sendo enviadas uma após a outra tão rapidamente que o driver não tem tempo suficiente para interpretar ambas .

Para aqueles que estão se perguntando, estou atualmente executando o octoprint (construído manualmente) no meu rpi3 via wireless (duh ..) com a tela de toque capacitiva pitft2.8 "da adafruit e o kernel personalizado da adafruit (v 4.4.27-v7 +) e duplicar o problema quando tentando acessar o stream de vídeo (Logitech C270) no meu Samsung Galaxy S7 via PrintDroid pro ou via Chrome. O travamento ocorre sem falhas cada vez que isso é feito e só acontece sem fio. Eu atualizei a fonte de alimentação, desativei o ipv6 e gerenciamento de energia, sem sucesso.

@TGYK Você pode verificar o problema mencionado - parece o mesmo para você? Que mensagens você recebe no dmesg? kevent caiu?

@TGYK. Você vinculou a página original do github do Broadcom - você pode dar alguma indicação de onde os problemas estão aparecendo na árvore do kernel do Raspberry Pi aqui? É um pouco difícil rastrear a quais linhas de código você está se referindo.

sdio.c está aqui na árvore 4.9 https://github.com/raspberrypi/linux/tree/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac.

@ JamesH65 Na página do github que você vinculou, a linha a que me refiro está em torno de 1140-1147. Quanto ao erro dmesg, a mensagem é o mesmo problema visto acima:
"Conteúdo de dados de caixa de correio desconhecido: 0x40012", seguido por erros escan (-52).

O mesmo problema que seu tópico referenciado não acontece, pois não estou conectando minhas interfaces com e sem fio de nenhuma forma. Pelo que eu posso dizer, meu problema, e este desta discussão, diz respeito apenas à interface sem fio.

Obrigado pela informação. O problema possivelmente vinculado é, creio eu, semelhante no sentido de que é um problema com o driver Wifi possivelmente recebendo uma mensagem estranha causando mais estranheza na pilha, mas ainda estou cavando.

Estou tendo o mesmo problema com um raspberry pi Zero W com um sintoma semelhante ao @TGYK. No meu caso, estou executando o mpd no zero e controlando-o por meio de um cliente Android em um Samsung Galaxy S5. Sem falhar, se eu colocar o telefone em espera enquanto o aplicativo controlador estiver em execução (ou seja, sem retornar à tela inicial primeiro), o wi-fi do zero será interrompido com a mensagem "Conteúdo de dados de caixa de correio desconhecido". Se eu apenas deixar o dispositivo inativo ou tiver o cuidado de sempre fechar o aplicativo antes de deixar meu telefone hibernar, ele permanecerá ligado indefinidamente.

Tive esse problema no Raspian e agora no OSMC.

Geralmente intermitente, mas o interessante é que acessar a interface da Web do Kodi no meu S7 sempre causará esse problema. Fazer o mesmo com o iPhone da minha esposa funciona perfeitamente e nunca desencadeou o problema.

@daedalia : Tenho um problema muito semelhante com um Samsung Galaxy Tab S. No entanto, não tenho acesso a um dispositivo iPhone / iPad para confirmar ...

Meu dispositivo Samsung trava o wi-fi ao tentar acessar a interface da web do tvheadend.

Isso não acontece quando acessado de um navegador Firefox de um PC com Windows.

Ainda bem que encontrei este tópico, pensei que fosse o único. Estou tendo os mesmos problemas que os pôsteres acima, queda de wi-fi no meu pi3 / osmc quando acessado de um Samsung Galaxy Tab A. Funciona bem se acessado de tablet Nexus 7, telefone OnePlus ou laptop Acer, apenas o Samsung dá problemas. Facilmente repetível. Parece ser o driver samsung wi-fi não gosta do pi3 wi-fi embutido? Adicionar um dongle wi-fi tp-link ao pi3 é uma solução alternativa para mim.

@philborman estou curioso, você usa o mesmo navegador móvel no Samsung vs Nexus?

Ambos executando o Chrome, mas não é apenas um problema do navegador. Se eu usar o Yatse para
controlar kodi funciona bem no Nexus / móvel / laptop, mas o WiFi pi3 cai
se eu tentar o mesmo do Samsung. Mesmo se eu ssh in, trava com Samsung
e não os outros. Com ssh posso fazer um pouco, mas qualquer transferência de arquivo ou
até mesmo a edição de um arquivo de texto fará com que o wifi seja desconectado.

Na quarta-feira, 12 de abril de 2017, 19:03 Mathieu Gouin, [email protected] escreveu:

@philborman https://github.com/philborman Estou curioso, você usa o
mesmo navegador móvel no Samsung vs Nexus?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-293643847 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ALmHOdtJ9AQtpfU7tmeVouI-a4STg2WMks5rvQPJgaJpZM4HupC5
.

Alguém comentando aqui tem a capacidade de construir um kernel com um patch que eu tenho que pode ajudar com isso? Eles são baseados no 4.9, mas podem funcionar bem no 4.4. Observe, estes são apenas testes ...

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

Olá,

Eu tenho o mesmo problema descrito aqui com um dos meus 2 Pi3. Wifi perde a conexão depois de algum tempo, pode ser algo entre 30 minutos e algumas horas. Tentei absolutamente tudo o que foi sugerido aqui, inclusive mudar de canal wifi no AP, etc ... sem sucesso. O que é extremamente estranho é que no meu segundo Pi3 (rev 1.2 também, exatamente o mesmo), e com o mesmo cartão SD / instalação (Raspbian) que troco entre os dois, o Wifi é sólido como uma rocha por dias e dias ...

Isso é muito estranho. Ambos Pi3 são atualizados com rpi-update, kernel 4.9 e firmware # 991, mas já era o mesmo com as versões anteriores do kernel / firmware.

Se você fizer uma atualização rpi, obterá os patches acima aceitos pelos desenvolvedores do kernel - isto é para o driver smsc9x e o driver brcmfmac, da noite passada. Você poderia tentar isso? Se isso ainda falhar, você pode fazer 'dmesg' e ver se há algo estranho no syslog? Embora, minha suspeita seja talvez uma falha de HW aparente enquanto o chip wireless aquece, visto que outro Pi funciona bem com a mesma placa.

Obrigado. Eu fiz isso na placa suspeita, wi-fi desconectado depois de alguns minutos.
dmesg dá isso:
``
[266.654964] brcmfmac: brcmf_sdio_bus_sleep: erro ao alterar o estado de hibernação do barramento -110
[266.655033] brcmfmac: brcmf_sdio_txfail: erro sdio, comando abortar e encerrar quadro
[266.659215] brcmfmac: brcmf_sdiod_regrw_helper: falha ao gravar dados F1 @ 0x1000d , erro: -110
[266.663346] brcmfmac: brcmf_sdiod_regrw_helper: falha ao ler os dados F1 @ 0x1001a , erro: -110
[266.667472] brcmfmac: brcmf_sdiod_regrw_helper: falha ao ler os dados F1 @ 0x10019 , erro: -110
[266.671608] brcmfmac: brcmf_sdiod_regrw_helper: falha ao ler os dados F1 @ 0x1001a , erro: -110
[266.675736] brcmfmac: brcmf_sdiod_regrw_helper: falha ao ler os dados F1 @ 0x10019 , erro: -110
[266.679866] brcmfmac: brcmf_sdiod_regrw_helper: falha ao ler os dados F1 @ 0x1001a , erro: -110
[266.683992] brcmfmac: brcmf_sdiod_regrw_helper: falha ao ler os dados F1 @ 0x10019 , erro: -110
[269.655049] brcmfmac: brcmf_sdio_bus_sleep: erro ao alterar o estado de hibernação do barramento -110
[272.069378] net_ratelimit: 35 retornos de chamada suprimidos

......... então este "loop" continua enchendo o log dmesg várias vezes por minuto.

Edit: Toquei todos os componentes da placa, eles estão tudo menos quentes, eu diria em torno de 30 °, só um pouco mais quente do que a pele dos meus dedos.

Hmm, o material SDIO é a interface entre o Pi e o chip wireless - está expirando (-110). Isso parece um problema de HW - conforme o chip esquenta, talvez haja uma junta de solda ruim nas linhas de interface do sdio em algum lugar, o que significa que o comunicador se desconecta.

Ping @ Roger-Thornton - Roger, há algo que possamos fazer para testar isso?

@Crrispy Você pode verificar se o seu Pi não tem força insuficiente - o que vcgencmd get_throttled reporta?

@pelwell : após uma perda de wi-fi, eu verifiquei e limpei = 0x0

Não acho que seja uma falha de hardware, uma simples reinicialização sempre resolve o problema instantaneamente.

@ JamesH65 Não acho que isso seja um problema de fabricação de hardware, pois todas as linhas estão funcionando como deveriam. Se houver outras dicas para problemas de hardware, posso dar uma olhada na placa.

Não parece ser o mesmo problema que o meu. Eu só tenho um pi3 e é
O wi-fi é sólido como uma rocha até que eu me conecte de um tablet Samsung. Conectar com
qualquer outra coisa e está bem. Não parece ser energia ou superaquecimento
relacionado, pois está absolutamente bom por dias até que eu me conecte do errado
tablet e ele cai.

Suponho que seja um driver ou firmware relacionado, algo que o Samsung
motorista manda que o pi3 não gosta.

Em Qui, 27 de abril de 2017, 22:01 Crrispy, [email protected] escreveu:

@pelwell https://github.com/pelwell : após uma perda de wi-fi, verifiquei e
estrangulado = 0x0

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297823068 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5
.

Houve algumas correções para a rede no último raspbian -
quando foi a última vez que você fez um

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

?
Pode valer a pena tentar para ver se corrige as coisas.

Em 28 de abril de 2017 às 14:38, philborman [email protected] escreveu:

Não parece ser o mesmo problema que o meu. Eu só tenho um pi3 e é
O wi-fi é sólido como uma rocha até que eu me conecte de um tablet Samsung. Conectar com
qualquer outra coisa e está bem. Não parece ser energia ou superaquecimento
relacionado, pois está absolutamente bom por dias até que eu me conecte do errado
tablet e ele cai.

Suponho que seja um driver ou firmware relacionado, algo que o Samsung
motorista manda que o pi3 não gosta.

Em Qui, 27 de abril de 2017, 22:01 Crrispy, [email protected] escreveu:

@pelwell https://github.com/pelwell : depois de uma perda de wi-fi, eu verifiquei,
e
estrangulado = 0x0

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
ou silenciar o tópico
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHag08r5c96nB39R3F-mFW772qBbGks5r0evJgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Eu tenho o mesmo problema com raspbery pi zero W. Depois de algum tempo, não consigo fazer o ssh. Eu tentei de tudo. Um fato engraçado é ... quando eu conectei a rpi à minha TV para solucionar alguns problemas depois de não conseguir fazer o ssh nela ... ela estava funcionando por 18 horas. Então, troquei o HDMI por outro dispositivo e depois de algum tempo, quando eu queria ssh para pi, obtive informações lindas de "nenhuma rota para o host". Quando eu conectei o cabo HDMI novamente, consegui fazer o ping do gateway. Nenhum erro nos logs, iwconfig parece ok. systemctl restart networking ajudou.

Como acima, tente o Raspbian mais recente e informe se você ainda vir
o problema.

Em 28 de abril de 2017 às 19:30, frankja2 [email protected] escreveu:

Tenho o mesmo problema com raspbery pi zero W. Depois de algum tempo, não
capaz de ssh para ele. Eu tentei de tudo. Um fato engraçado é ... quando eu conectei
rpi para minha TV para solucionar alguns problemas depois de não conseguir fazer o ssh para
isso ... estava funcionando por 18h como uma rocha sólida. Então, troquei HDMI por outro
dispositivo e depois de algum tempo quando eu queria ssh para pi eu fiquei linda "não
rota para o host ". Quando conectei o cabo HDMI novamente, consegui executar o ping
Porta de entrada. systemctl restart networking ajudou.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Posso ser o único estúpido o suficiente para que esse seja o problema, mas descobri que meu wpa_supplicant.conf tinha o código do país definido incorretamente (esqueci que era um item de configuração separado das outras opções de localização). Não vou dizer que o problema desapareceu por completo, mas assim que consertei isso, ele parou de perder sua conexão de rede do jeito que era antes "toda vez que me conectar do meu Samsung".

Acabei de atualizar para o mais recente (apt-get dist-upgrade) e parece otimista.
Minha atualização anterior foi há cerca de 2 semanas, pouco antes de eu relatar o
problemas iniciais. Funcionando bem nas últimas horas, sem Wi-Fi
abandonos em tudo. Muito Obrigado!

Em 28/04/17 15:53, James Hughes escreveu:

Houve algumas correções para a rede no último raspbian -
quando foi a última vez que você fez um

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

?
Pode valer a pena tentar para ver se corrige as coisas.

Em 28 de abril de 2017 às 14:38, philborman [email protected] escreveu:

Não parece ser o mesmo problema que o meu. Eu só tenho um pi3 e
Está
O wi-fi é sólido como uma rocha até que eu me conecte de um tablet Samsung. Conectar com
qualquer outra coisa e está bem. Não parece ser energia ou superaquecimento
relacionado, pois está absolutamente bom por dias até que eu me conecte do errado
tablet e ele cai.

Suponho que seja um driver ou firmware relacionado, algo que o Samsung
motorista manda que o pi3 não gosta.

Em Qui, 27 de abril de 2017, 22:01 Crrispy, [email protected] escreveu:

@pelwell https://github.com/pelwell : depois de uma perda de wi-fi, eu verifiquei,
e
estrangulado = 0x0

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub

< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
ou silenciar o tópico
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub

https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
ou silenciar o tópico

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

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298003537 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ALmHORKJxKdws0fMKU5tpfoJHJSah0Ffks5r0e9FgaJpZM4HupC5 .

Foi corrigido para mim na versão mais recente.

A maioria das outras "correções" parecem não perceber que meu sistema funcionava
perfeitamente com tudo, exceto um tablet (Samsung), então parece que o
problema era o samsung enviando algo o driver / firmware pi3 wifi
não poderia lidar com.

Se meu código de país foi definido errado, por que apenas a Samsung causaria
problemas. Outros tablets / telefones / laptops se conectam perfeitamente.

De qualquer forma, está consertado agora - pelo menos não caiu nos últimos
horas. Mais o tempo dirá ...

Em 28/04/17 21:09, rraszews escreveu:
>

Posso ser o único idiota o suficiente para que esse seja o problema, mas
Eu descobri que meu wpa_supplicant.conf tinha o código do país definido
errado (esquecido que era um item de configuração separado do outro
opções de localização). Não vou dizer que o problema foi embora
inteiramente, mas depois de consertar isso, ele parou de perder sua rede
conexão no modo "toda vez que eu conectar do meu Samsung"
era antes.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298082370 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ALmHOWtM-_MXCz5RoQd8XShI4Mk-4LAyks5r0jlUgaJpZM4HupC5 .

No meu caso durou cerca de 19h. Depois disso não pude mais ssh ...

Qual é a diferença entre rpi-update e dist-upgrade?

Porque após o rpi-update eu tinha 4.9.25+ # 995 e então fiz dist-upgrade e o kernel revertido para 4.9.24+ # 993. Enfim, para mim o problema ainda não foi resolvido. O que fiz desta vez foi usar outro rpi0w e outro PSU :) a última etapa foi usar outro cartão SD.

OK, obrigado pela informação.

Vou precisar de mais algumas informações para tentar replicar. Sua configuração, o que
você se conectou e o tipo de tráfego de rede acontecendo, qualquer log do dmesg
ou outras mensagens de erro quando o sh parar de funcionar.

Obrigado.

Em 29 de abril de 2017 às 16:16, franko [email protected] escreveu:

No meu caso durou cerca de 19h. Depois disso eu poderia ssh mais ...

Qual é a diferença entre rpi-update e dist-upgrade?

Porque após a atualização da rpi eu tinha 4.9.25+ # 995
https://github.com/raspberrypi/linux/pull/995 e então fiz
dist-upgrade e kernel revertido para 4.9.24+ # 993
https://github.com/raspberrypi/linux/pull/993 . Enfim, para mim, o problema é
ainda não corrigido.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298175041 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHQR8cadrEhb55YJj5PV6PP_odmJmks5r01RJgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Olá,

Coloquei o Pi3 em um gabinete com um ventilador bastante forte e a temperatura no quarto está atualmente em 19 ° C, então não pode ser um problema de aquecimento. Trocou a fonte de alimentação por outra (5V 3A também). Usou outro cartão SD, dist-upgrade e rpi-update.
Ontem ele ficou ligado por várias horas, eu esperava que tivesse sido consertado, mas depois de 3-4 horas ele se desconectou (ping -t em execução na minha máquina de janela).
Tentei novamente esta manhã, desliguei o Wi-Fi depois de menos de 20 minutos :-(
Continua o erro -110 do driver wifi no sdio (veja acima), que se repete em um loop até a reinicialização.
E meu outro Pi3 conectado por 3-4 dias agora, sem problemas.
Portanto, isso pode parecer uma falha de hardware. Mas .. por que ele nunca falha na inicialização e sempre funciona após uma reinicialização? Realmente intrigante.
Por que ele tenta alterar o "estado de suspensão do barramento", já que o gerenciamento de energia está desativado para wlan0? (desculpe se a pergunta for idiota).

acabou de fazer apt-get update; apt-get dist-upgrade . Infelizmente, nenhuma mudança para mim. De minha observação, o problema está relacionado à ponte wlan0 pergunto se isso poderia estar relacionado ao modo promíscuo. Também cansei rpi-update para verificar 4.9.25

na verdade, é ainda pior do que antes, já que a conexão é perdida agora, geralmente em poucos minutos e posso ver os registros usuais

[  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 após o rpi-update eu tinha 4.9.25+ # 995 e então fiz dist-upgrade e o kernel revertido para 4.9.24+ # 993."

Isso é estranho. Fiz o dist-upgrade, fui para 4.9.24+ # 993 e quando faço uma atualização de rpi agora, diz que já tenho o firmware mais recente e não tem nada a fazer ... por que não atualiza para 4.9.25 / # 995?

Na verdade, tenho que dizer que usar brcmfmac/wlan0 ponte parece funcionar mais estável do que com wlan0 puro (tudo com hostapd)

Então, você pode dar uma descrição completa e precisa de sua configuração, junto com
tipos de dispositivos conectados e quaisquer mensagens de erro dmesg que você possa receber
quando o wireless falha.

Eu realmente preciso de alguma maneira de replicar o problema que não leve horas, então
qualquer informação fornecida que possa ajudar nesse sentido é aceita com gratidão.

Em 1 de maio de 2017 às 17:27, Szymon Stasik [email protected] escreveu:

Na verdade, tenho que dizer que usar brcmfmac / wlan0 bridged parece funcionar mais
estável do que com wlan0 puro (todos com hostapd)

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Não sei se isso está especificamente relacionado a este aspecto do problema, mas IIRC consegui reproduzir totalmente uma forma de queda de wi-fi usando um comando hcitool. Talvez não seja mais possível, era como há um ano agora e optamos por usb wi-fi para resolver o problema que funcionou para vários rpis ...

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

@thomasf Qual foi a configuração do seu sistema (dispositivo autônomo, ponto de acesso, ponto de acesso com ponte, etc.) e em qual máquina você executa o comando hcitool? Um teste rápido em um dispositivo conectado a outro Pi via wireless não mostrou problemas.

@ JamesH65 Passamos por vários cenários e o problema era reproduzível em qualquer configuração.

Quando o comando hcitool era executado em um rpi, geralmente perdia a conexão de rede (wi-fi) em segundos. IIRC era mais fácil de reproduzir se houvesse algum tráfego de rede no dispositivo (como uma transferência de arquivo).

Olhando rapidamente para o nosso sistema de provisionamento final, o seguinte wpa_supplicant.conf foi o último que usamos. Acho que não parece muito diferente daquele que causou problemas com a interface wi-fi interna ... Tenho certeza de que começamos usando apenas um único AP, mas ainda com problemas.

(SSIDs e chaves editados):

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

Acabei de encontrar um script chamado troublemaker.sh no repositório de provisionamento agora ..

É muito hacky, acho que provisionei para rodar na inicialização ~ como uma vez a cada poucos minutos ou algo assim ~~ (editar: provavelmente apenas uma vez, pois ele faz alguns loops por si mesmo) em um monte de rpi para provocar problemas e obter alguns logs salvou..

Isso foi usado principalmente antes de eu entender mais sobre os problemas .. Acho que os tempos de ping e perda de pacotes estavam aumentando por um período antes de o wi-fi totalmente desconectado.

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

Executar o script do encrenqueiro no último Raspbian estável (kernel 4.9) não mostra erros, o que é bom, mas ruim para tentar replicar erros!

@ciekawy Olhando para trás, parece que você consegue reproduzir facilmente um problema que não podemos fazer aqui. Você pode me dar uma ideia de sua configuração exata, para que eu possa investigar. Também vale a pena pegar a atualização de rpi mais recente, pois houve algumas correções para USB que podem ou não ser relevantes (se você estiver usando ethernet). Vou precisar saber a topologia da sua rede, como o Pi está configurado, o que parece estar instigando o problema. Qualquer coisa, mesmo!

@ JamesH65 , Minha configuração atual é:

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

também como para 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 a pena mencionar que este RPI ficou estável por dias (embora transferências mais duradouras de 10mbps também pudessem causar alguns problemas) quando as funções foram trocadas e wlan0 brcmfmac foi usado para se conectar à internet e o AP local estava rodando em wlan2 ath9k. Mudei config pois preciso usar melhor antena conectada a wlan2 para acesso a internet.

Meu rpi-updated recente foi em 1º de maio

Eu tenho exatamente o mesmo problema em rpi3 usando Archlinux-ARM.

Depois de algumas horas executando o create_ap, ele para de funcionar com as msgs dmesg já relatadas por outros:
[11418.347554] brcmfmac: send_key_to_dongle: erro wsec_key (-110)

Às vezes funciona por 1 dia sem problemas, e às vezes funciona por minutos antes de o problema ocorrer.

Alarme Linux 4.9.25-2-ARCH # 1 SMP Sex, 5 de maio 00:46:52 UTC 2017 armv7l GNU / Linux

Mesmo problema em Pi Zero W, Raspbian Lite atual. Depois de algum tempo (difere de minutos a horas) 'dmesg' mostra
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
A partir deste ponto, a conexão wi-fi acabou e só pode ser reiniciada por rmmod'ing e modprob'ing brcmfmac.

Desativei o gerenciamento de energia: sem alteração.
Eu atualizei tudo via apt-get upgrade / dist-upgrade: nenhuma mudança
Eu atualizei o material via rpi-update: sem alteração

brcmfmac está bugado com certeza. Eu estava tendo o mesmo problema com dmesg msg "brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012" e às vezes mensagens diferentes também, como relatado em meu post acima.

Estou usando um adaptador wi-fi tp-link usb e meu aplicativo está funcionando bem agora.

Espero que a Broadcom consiga corrigir os bugs do brcmfmac.

Alguma solução alternativa?

Como mencionei no início desta conversa, mudei meu roteador Wifi para usar o canal 6 em vez do 11 (que estava usando antes), e meu rPi está ativo desde então (desde janeiro até agora) sem problemas em todos.

Isso pode estar relacionado a esta nota do módulo do kernel:

Esta geração de chips contém suporte regulamentar adicional independente do driver. Os dispositivos usam um único domínio regulatório mundial, com canais 12-14 (banda de 2,4 GHz) e canais 52-64 e 100-140 (banda de 5 GHz) restritos à operação passiva. A transmissão nesses canais é suprimida até que outro tráfego apropriado seja observado nesses canais. No driver, usamos o código de país fictício “X2” para representar esse domínio regulatório mundial. Atualmente não há interface para configurar um domínio diferente. O driver lê o código de país SROM do chip e o entrega ao mac80211 como a dica regulamentar, no entanto, essa informação não é usada pelo driver.
(aqui: https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211)

Eu acho que isso significa que mesmo um código de país "DE" (que deve permitir os canais wi-fi superiores) não tem efeito? Mas não tenho certeza se isso poderia ter um efeito semelhante ao problema de Unknown mailbox data content: 0x40012 ...

Pelo menos para mim não é uma solução alternativa - mudei do canal 11 para o canal 6 hoje, 2 horas depois: Unknown mailbox data content: 0x40012

Tive esse problema até aumentar a intensidade do sinal com um extensor de alcance.
Você poderia testar se a conexão está mais estável movendo o Pi para um ponto com melhor sinal?

Talvez seja causado por energia adicional necessária para operar com sinal fraco.

O mesmo problema do Crrispy.

Para aqueles que estão trabalhando em torno disso com um adaptador USB WiFi (mudança de canal, etc, também não funcionou para mim), Edimax EW-7811Un funcionou imediatamente quando eu o conectei ao meu cabo USB OTG em RPI Zero W. Eu não Não preciso fazer nenhuma configuração ou ifconfig - já estava na rede! Ontem, eu me debati com o TP-Link Archer T1U AC450 por algumas horas.

@ b3nj1 - desculpe

Optei pela mesma solução - comprei um adaptador USB com antena externa e chipset mt7601 (cerca de 5 Eur) para o meu Zero W, funciona perfeitamente. Deveria ter comprado o não-W em primeiro lugar ... esse problema existe há mais de um ano e nenhuma correção à vista.

@blacktigersoftware - é estranho, não é !? O Zero W WiFi funciona muito bem. O Zero W Bluetooth funciona muito bem. Mas, se eu usar os dois ao mesmo tempo, o sistema torna-se insuportavelmente lento e, eventualmente, inacessível por wi-fi.

Estou dando uma olhada rápida no problema maibox descrito acima. O Google mostra que isso parece estar acontecendo um pouco (e pelo menos uma referência a uma plataforma não-Pi). O código do driver detecta que uma mensagem voltando da caixa de correio (presumo uma conexão com o firmware HW) tem alguns bits definidos que não deveria ter. No entanto, ele apenas imprime as mensagens - não faz nenhuma recuperação ou retorno de erro. Como esse parece ser um valor retornado do firmware, não tenho acesso a ele para realmente ver o que está acontecendo, e a folha de dados no chip é totalmente inútil. Então eu acho que este precisa ser enviado para Broadcom / Cypress / linux-wireless para investigação.

Também vale a pena notar que parece que temos o firmware HW mais recente de acordo com https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm. Os arquivos têm uma ou duas diferenças de comprimento de byte, mas é isso.

O problema é que o erro da caixa de correio é seguido por outros erros (-52, -110, etc), e só reiniciando o sistema o wifi volta a funcionar.

-110 é um erro de tempo limite, indicativo de outra coisa morrendo e não respondendo. -52 é uma troca inválida, que segue as mesmas linhas. Suspeito que, no momento em que o erro da caixa de correio ocorreu, o firmware do chip não está bem, então esses outros erros continuam a partir daí.

Alguém que pode replicar o problema é capaz de construir o kernel Pi dev mais recente (4.11, disponível em nosso github) e ver se o erro de caixa de correio ainda ocorre. Antes de começar a usar o upstream, gostaria de saber que isso ainda acontece no kernel mais recente e não fui capaz de replicá-lo.

Posso confirmar que o problema acontece em: Alarme Linux 4.9.25-2-ARCH # 1 SMP Sex 5 de maio 00:46:52 UTC 2017 armv7l GNU / Linux

Não testei no kernel 4.11

O driver usado em meus testes: brcmfmac: versão do firmware = wl0: 15 de dezembro de 2015 18:10:45 versão 7.45.41.23 (r606571) FWID 01-cc4eda9c

@ b3nj1 - uau, obrigado pelo

Pessoal - isso só acontece quando o gpu está ligado?

A GPU está sempre ligada (até certo ponto), em todos os modelos de Pi.

Você quer dizer quando o Bluetooth está ligado?

@ JamesH65 - Vou tentar o 4.11. Devo clonar / construir de acordo com o seguinte? Ao clonar de acordo com essas instruções, estou no branch rpi-4.9.y. Devo verificar rpi-4.11.y em vez disso ou algo mais?

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

desde já, obrigado

Verifique o branch rpi-4.11.y e reconstrua usando as instruções que você
vinculou a.

Em 25 de maio de 2017 às 05:02, b3nj1 [email protected] escreveu:

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

• Vou dar uma chance ao 4.11. Devo clonar / construir de acordo com o seguinte?
  Ao clonar de acordo, estou no branch rpi-4.9.y. Devo fazer o checkout
  rpi-4.11.y em vez disso ou algo mais?

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

desde já, obrigado

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Só para repetir algumas informações que forneci em outro lugar, estou testando a conexão sem fio em condições de baixa energia. Eu diminuí a ponto de os dispositivos USB caírem, mas não vi nenhum problema de conexão sem fio. Embora isso seja prova de que não é um problema de energia, é importante notar.

Acontece que descobri como reproduzir isso executando sudo memtester 256M 1 via SSH usando meu telefone; o wi-fi morre assim que memtester começa a ser inundado com esses caracteres "carregando":

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

Coisa estranha, o wi-fi só trava ao fazer isso no meu telefone. Tentei meu PC, outro pi e meu roteador sem sorte.

@ JamesH65 - Atualização 2: Consegui inicializar com 4.11 (configurei incorretamente o kernel na primeira vez).
Linux rpiz 4.11.2+ #2 Thu May 25 21:19:11 PDT 2017 armv6l GNU/Linux

Infelizmente, o sistema ainda responde quando eu martelo no BT.

Quando eu reconecto o USB WiFi externo e conecto o endereço do adaptador, está tudo bem novamente.

• Benjamin

Novo kernel construído e instalado a partir do branch rpi-4.11.y seguindo as instruções aqui: 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

Infelizmente, o wifi ainda trava com o mesmo erro:
brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Se você consolar quando o wi-fi cair, você pode reiniciá-lo. Estou testando um script bash agora para ver se isso ajuda. Vou executá-lo no cron. Aqui está, se alguém estiver interessado.

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

Estou executando isso há um dia e até agora não notei que meu wi-fi caiu.

@ JR1994
Ainda está funcionando?
Com que frequência você o executa?
Todo minuto ?

Vou tentar em alguns dos meus raspberrys, tenho vários que reinicio toda vez que não consigo pingar no roteador

desde já, obrigado

Por enquanto, tudo bem. Estou verificando a cada 2 minutos.

Observe que a última revisão de firmware para brcmfmac é muito antiga:

brcmfmac: versão do firmware = wl0: 15 de dezembro de 2015 18:10:45 versão 7.45.41.23 (r606571) FWID 01-cc4eda9c

@semeion Não tenho certeza de qual firmware você está usando - o atual deve ser "Versão: 7.45.41.26 CRC: 5932ca06 Data: Sex. 2016-05-27 00:15:32 PDT Ucode Ver: 1043.2060 FWID: 01-df77e4a7". Este é efetivamente o mesmo que o do repositório de firmware do Linux, embora recebamos o nosso direto do Brcm.

@ JamesH65 Essa mensagem foi retornada em 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

Mas usando vcgencmd version ele mostra:

$ /opt/vc/bin/vcgencmd version

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

Esse não é o firmware do chip Wifi, é o firmware SoC, que fica
atualizado com bastante frequência.

Ainda não tenho certeza por que seu sistema pensa que tem esse firmware antigo. Você
tem firmware SoC muito recente, então presumivelmente você fez uma atualização do apt-get
recentemente?

Em 5 de junho de 2017 às 17:55, Alexandre Bolelli [email protected] escreveu:

@ 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=
Essa mensagem foi retornada em dmesg. Mas usando a versão vcgencmd mostra:
`$ / opt / vc / bin / vcgencmd versão
Versão do firmware

30 de maio de 2017 15:23:29
Copyright (c) 2012 Broadcom
versão b8cdd5ae76f39d9f353dfa8fb48bf7e33b74903c (limpo) (lançamento) `

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

@ JamesH65 Como eu disse acima, estou usando o Archlinux-ARM, é uma distribuição de lançamento contínuo e, sim, meu sistema é atualizado com pacman -Syu (pacman -Syu é equivalente ao apt-get upgrade / update).

Não tenho ideia de por que esse firmware antigo é antigo no meu sistema. Talvez seja esse o motivo desse bug. O que você acha?

Enfim, o bug acontece com a framboesa certo? O bug foi relatado em março de 2016? Isso é velho.

PS. Inglês não é minha língua nativa, desculpe por algum erro / erro de ortografia.

OK, não tinha percebido que estava usando o ARCH. Parece que eles não estão fornecendo
um recente blob de firmware para o chip Wifi. Você pode atualizá-lo manualmente,
pode resolver o seu problema, talvez não - acho que provavelmente há vários
bugs sem fio, e não há garantia de que aquele que você está vendo seja o
uma pessoa está vendo no Raspbian.

Você deve relatar o firmware desatualizado para os mantenedores do arquivo, e
talvez o bug wireless também, já que pode ser atribuído à distro Arch.

Observe que geralmente não oferecemos suporte a outras distros, nossa distribuição interna é
Raspbian, para investigar um problema, precisamos ser capazes de replicá-lo em
este.

Em 5 de junho de 2017 às 23:13, Alexandre Bolelli [email protected] escreveu:

@ JamesH65 https://github.com/jamesh65 Como eu disse acima, estou usando
Archlinux-ARM, é uma distribuição de lançamento contínuo, e sim meu sistema está atualizado
com pacman -Syu (pacman -Syu é equivalente ao apt-get upgrade / update).

Não tenho ideia de por que esse firmware antigo é antigo no meu sistema. Talvez possa ser
a razão desse bug. O que você acha?

Enfim, o bug acontece com a framboesa certo? O bug foi relatado em
Março de 2016? Isso é velho.

PS. Inglês não é minha língua nativa, desculpe por algum erro / erro de ortografia.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306325452 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHaL4XsN5drPggS8eJDZWme4LyKXWks5sBH2CgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

@ jamesH65 Sim, de fato. Vou tentar perguntar em # archlinux-arm porque esse firmware é antigo. De qualquer forma estarei acompanhando esse problema e procurando uma solução. Vou relatar aqui qualquer informação descoberta.

Desde já, obrigado.

@ JamesH65 Consigo replicar consistentemente no meu Raspbian (RPi 3). Se houver algo que eu possa fazer para ajudar nisso, me avise!

Qual é a sua configuração? Como você replica o problema?

Em 6 de junho de 2017 às 14:17, Dan [email protected] escreveu:

@ JamesH65 https://github.com/jamesh65 Eu sou capaz de replicá-lo
consistentemente no meu Raspbian (RPi 3). Se houver algo que eu possa fazer para ajudar
com isso, me avisa!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306483030 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHWyW5cQuS47k3xTmi3UX-QW7ffEYks5sBVF5gaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Dê uma olhada nos comentários anteriores, expliquei como reproduzi-lo há não muito tempo.
O Pi está rodando Raspbian completo com uma tela de 3,5 "na parte superior usando a fonte de alimentação oficial. Nada de especial, tudo é mantido atualizado com rpi-update e apt upgrade.

Após alguns dias, o wi-fi interno para de funcionar com a seguinte mensagem no 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

Eu executo o hostapd nesta interface e tenho outra interface wi-fi USB anexada ao Pi. Informações do meu 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

Sim, e quando mostrar que (-110) você precisa reiniciar o sistema para fazê-lo funcionar novamente ...

É bom saber que isso acontece no Raspbian também, o bug é independente da distribuição. Acontece o mesmo no Archlinux.

No entanto, desde que mudei meu wi-fi do canal 11 para o canal 6, não vi o problema desde então. Vejo, pelas minhas respostas anteriores neste tópico, que foi desde 7 de janeiro quando fiz a mudança para o canal 6. No momento, estou executando dois RaspPI Zero W e um RaspPi 3, todos sem problemas. Os dois RaspPi W estão executando o DietPi.

Também tenho esse problema no meu Raspberry Pi 3. Já tentei diferentes canais de wi-fi.
Observei que se eu conectar a porta LAN também, o wi-fi fica estável como o diabo. Assim que eu desconectar a porta LAN, o wi-fi fica caindo o tempo todo.

Isso é muito estranho ......!

Em 15 de junho de 2017 às 23:02, macmeck [email protected] escreveu:

Também tenho esse problema no meu Raspberry Pi 3. Tentei diferentes canais wi-fi
já.
Observei que se eu conectar a porta LAN também, o wi-fi fica estável como o diabo.
Assim que eu desconectar a porta LAN, o wi-fi fica caindo o tempo todo.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-308878043 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHbUKBO9mG3xpKHFK977h4hrFUhrGks5sEantgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Eu tenho o
"brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012"
problema também no meu rpi3. minha solução mais confiável para evitar esse erro tem sido
"Wonderhaper 9000 9000"
Espero que a causa raiz seja determinada.

Tenho exatamente o mesmo problema. Meu pi3 apresenta os seguintes sintomas quando conectado APENAS com WIFI:

1. O wifi de saída funciona muito bem. Posso me conectar à internet e baixar arquivos sem problemas no meu pi3.
2. Todas as conexões wi-fi RECEBIDAS falham. Tempo limite de pings, tempo limite de acessos http da porta 80, ssh falha, tudo falha SOMENTE ENTRADA.
   NOTA:
3. Uma vez que a Ethernet é conectada ao pi3, o wi-fi funciona MELHOR, mas ainda está perdendo pacotes.
4. Assim que a Ethernet for removida novamente, o wi-fi falha completamente em todas as conexões de entrada.
5. Assim que a Ethernet for conectada novamente ao pi3, o wi-fi funciona MELHOR e permite a entrada de alguns pacotes. mas ainda descarta muitos deles.

Corrija isso!

Eu percebi o seguinte no ifconfig:

Pacotes RX: 1613 erros: 0 descartados: 1074 saturações: 0 quadro: 0
Pacotes TX erros: 0 descartados: 0 overruns: 0 portadora: 0
colisões: 0 t xqueuelen: 1000

Então, basicamente, o lado RX do WIFI do pi3 está perdendo pacotes como um louco. Não admira por que ele não responde a conexões de entrada. TX funciona bem!

Desde que configurei esse script, não tive problemas com wi-fi em ambos os
RPI3s.

Na quarta-feira, 21 de junho de 2017 às 4:26 AM, Edward Kang [email protected]
escrevi:

Eu percebi o seguinte no ifconfig:

Pacotes RX: 1613 erros: 0 descartados: 1074 saturações: 0 quadro: 0
Pacotes TX erros: 0 descartados: 0 overruns: 0 portadora: 0
colisões: 0 t xqueuelen: 1000

Então, basicamente, o lado RX do WIFI do pi3 está perdendo pacotes como um louco.
Não admira por que ele não responde a conexões de entrada.

CORRIGIR ISSO !!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310049620 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AFHmIH6kkxraxahE22_PpstdDkqW8Pgqks5sGP3ggaJpZM4HupC5
.

É muito bom dizer "'por favor, conserte isso", mas problemas como esse são bastardos absolutos de se encontrar. Demorou um mês para encontrar um erro nos drivers smsc / brcmfmac ao fazer a ponte, tive sorte em encontrá-lo, e suspeito que este seja mais raro e difícil de encontrar. Se alguém puder encontrar um caso de teste replicável que mostre o erro rapidamente, isso seria de grande ajuda. Algumas pessoas parecem obter o erro kevent com frequência, eu o recebo muito raramente.

Quanto ao problema com pacotes perdidos, isso está sendo analisado quando há lacunas na programação. No caso acima, você parece estar perdendo quase todos os pacotes, o que é muito estranho e geralmente não é visto pela maioria das pessoas. Isso acontece com todos os dispositivos conectados ao Pi? Ou apenas um em particular.

desculpe, james!

Não tenho certeza do que você quer dizer com todos os dispositivos conectados ao Pi. Os pacotes descartados são de executar ifconfig diretamente no pi. O pi está conectado via wi-fi a um roteador. Quando o pi está conectado apenas à rede wi-fi, ele está constantemente recebendo e descartando pacotes.

@ JamesH65 Bem, eu concordo com você, é difícil de resolver ... Mas usando Arch Linux-ARM, instalando o pacote "create_ap" e habilitando-o (pacman -S create_ap; systemctl start / enable create_ap), você pode obter o - Erro 110 e o "Conteúdo de dados de caixa de correio desconhecido: 0x40012" em poucos minutos de operação ... Basta conectar seu smartphone e / ou smart TV às vezes e o erro virá.

Não oferecemos suporte para Arch, Raspbian é nosso sistema operacional compatível e é o que eu
precisa ser capaz de corrigir o problema. Não tenho ideia de qual versão do
kernel ou drivers que o ARCH usa, eles podem ser muito diferentes do
uns em Raspbian.

As pessoas ainda estão vendo o problema de usar o Pi como ponto de acesso?
Usando bridging? IPv4 ou IPv6? Este é o tipo de informação (não
exclusivo, é claro, o máximo de informações possível é necessário)
para replicar problemas.

Observe que a Broadcom foi informada do erro da caixa de correio (é o chip
e motorista, é claro), mas as coisas tendem a se mover lentamente com eles.

Em 21 de junho de 2017 às 18:27, Alexandre Bolelli [email protected]
escrevi:

@ 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=
Bem, eu concordo com você, é difícil de resolver ... Mas usando Arch Linux-ARM,
instalar o pacote "create_ap" e habilitá-lo (pacman -S create_ap;
systemctl / startenable create_ap), você pode obter o erro -110 e o
"Conteúdo de dados de caixa de correio desconhecido: 0x40012" em poucos minutos de operação ... Apenas
conecte seu smartphone e / ou uma smart TV nele às vezes e o erro
virá.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Estou usando ipv4 estático em alguns dispositivos e tendo o mesmo problema que o
outros usando dhcp

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

Não oferecemos suporte para Arch, Raspbian é nosso sistema operacional compatível e é o que eu
precisa ser capaz de corrigir o problema. Não tenho ideia de qual versão do
kernel ou drivers que o ARCH usa, eles podem ser muito diferentes do
uns em Raspbian.

As pessoas ainda estão vendo o problema de usar o Pi como ponto de acesso?
Usando bridging? IPv4 ou IPv6? Este é o tipo de informação (não
exclusivo, é claro, o máximo de informações possível é necessário)
para replicar problemas.

Observe que a Broadcom foi informada do erro da caixa de correio (é o chip
e motorista, é claro), mas as coisas tendem a se mover lentamente com eles.

Em 21 de junho de 2017 às 18:27, Alexandre Bolelli [email protected]
escrevi:

@ JamesH65
3A__github.com_jamesh65 & d = DwMFaQ & c = DpyQ_ftY536pf7wCBQXXU58xADDRY77THQz
Ju1OmzOo & r = w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m =
BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w & s = o90aBGb27vZvog3BdioLSa2_
MEySix0ymtnTgiNb87c & e =>
Bem, eu concordo com você, é difícil de resolver ... Mas usando Arch Linux-ARM,
instalar o pacote "create_ap" e habilitá-lo (pacman -S create_ap;
systemctl / startenable create_ap), você pode obter o erro -110 e o
"Conteúdo de dados de caixa de correio desconhecido: 0x40012" em poucos minutos de operação ...
Somente
conecte seu smartphone e / ou uma smart TV nele às vezes e o erro
virá.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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 =>,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310294786 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ACeQBFj8ICNkDl7xYwYJcD6TK-k6_4K5ks5sGhJ1gaJpZM4HupC5
.

Uma coisa a notar é que o wi-fi estava funcionando perfeitamente para mim desde o momento em que recebi meu pi3 no ano passado até cerca de 3 meses atrás, quando o wi-fi parou de funcionar.

É evidente que deve ter havido algum tipo de alteração no software nessa época que fez com que o wi-fi parasse de funcionar.

Se o seu wi-fi parou de funcionar completamente, isso indica um problema no seu lado (que pode ser agravado por um problema de software, é claro), porque para todos os outros, o wi-fi geralmente funciona (embora eu veja pacotes perdidos).

BTW, meu rpi3 é uma marca nova no Reino Unido.

Eu também tenho lutado contra isso há alguns meses. Às vezes, dura minutos. Às vezes semanas. O denominador comum quando eu perco uma conexão é que vejo as chamadas para redefinir o domínio regulatório mundial CRDA imediatamente antes que ele perca a conexão. Toda vez. Ponto de acesso Ubiquiti AC, canal 11, largura de canal HT40 (única coisa que pode ser especial).

28 de junho 14:19:31 kernel raspberrypi: [980.387378] cfg80211: Domínio regulatório mundial atualizado:
28 de junho 14:19:31 kernel raspberrypi: [980.387387] cfg80211: DFS Master region: unset
28 de junho 14:19:31 kernel raspberrypi: [980.387396] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 de junho 14:19:31 kernel raspberrypi: [980.387411] cfg80211: (2402000 KHz - 2472000 KHz a 40000 KHz), (N / A, 2000 mBm), (N / A)
28 de junho 14:19:31 kernel raspberrypi: [980.387426] cfg80211: (2457000 KHz - 2482000 KHz a 20000 KHz, 92000 KHz AUTO), (N / A, 2000 mBm), (N / A)
28 de junho 14:19:31 kernel raspberrypi: [980.387439] cfg80211: (2474000 KHz - 2494000 KHz a 20000 KHz), (N / A, 2000 mBm), (N / A)
28 de junho 14:19:31 kernel raspberrypi: [980.387453] cfg80211: (5170000 KHz - 5250000 KHz a 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (N / A)
28 de junho 14:19:31 kernel raspberrypi: [980.387468] cfg80211: (5250000 KHz - 5330000 KHz a 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 s)
28 de junho 14:19:31 kernel raspberrypi: [980.387481] cfg80211: (5490000 KHz - 5730000 KHz a 160000 KHz), (N / A, 2000 mBm), (0 s)
28 de junho 14:19:31 kernel raspberrypi: [980.387493] cfg80211: (5735000 KHz - 5835000 KHz a 80000 KHz), (N / A, 2000 mBm), (N / A)
28 de junho 14:19:31 kernel raspberrypi: [980.387505] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 0 mBm), (N / A)
28 de junho 14:19:32 kernel raspberrypi: [981.262521] cfg80211: Domínio regulatório alterado para país: EUA
28 de junho 14:19:32 kernel raspberrypi: [981.262536] cfg80211: Região mestre DFS: FCC
28 de junho 14:19:32 kernel raspberrypi: [981.262540] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 de junho 14:19:32 kernel raspberrypi: [981.262549] cfg80211: (2402000 KHz - 2472000 KHz a 40000 KHz), (N / A, 3000 mBm), (N / A)
28 de junho 14:19:32 kernel raspberrypi: [981.262557] cfg80211: (5170000 KHz - 5250000 KHz a 80000 KHz, 160000 KHz AUTO), (N / A, 2300 mBm), (N / A)
28 de junho 14:19:32 kernel raspberrypi: [981.262565] cfg80211: (5250000 KHz - 5330000 KHz a 80000 KHz, 160000 KHz AUTO), (N / A, 2300 mBm), (0 s)
28 de junho 14:19:32 kernel raspberrypi: [981.262571] cfg80211: (5490000 KHz - 5730000 KHz a 160000 KHz), (N / A, 2300 mBm), (0 s)
28 de junho 14:19:32 kernel raspberrypi: [981.262578] cfg80211: (5735000 KHz - 5835000 KHz a 80000 KHz), (N / A, 3000 mBm), (N / A)
28 de junho 14:19:32 kernel raspberrypi: [981.262584] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 4000 mBm), (N / A)

Desculpe jogar lenha no fogo, mas acho que estou tendo um problema semelhante no Pi Zero W também.

Ao alternar o wlan0 entre o modo de ponto de acesso (ao usar hostapd) e o modo de conexão normal (ou seja, conectando-se a um roteador), o wlan0 às vezes perderá a capacidade de se associar a um ponto de acesso.

Ele ficará preso neste estado:

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

e nada menos que uma reinicialização irá consertá-lo. Percebo no dmesg os seguintes erros quando isso acontece:

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

O que me preocupa é que seja completamente arbitrário e aleatório. Às vezes, posso alternar entre os dois modos por um bom tempo antes que o problema aconteça. Mas eventualmente acontece.

FWIW Acho que recarregar o módulo do kernel wi-fi (fazendo "modprobe -r -v brcmfmac && modprobe brcmfmac") consertou, então terei que criar um script que faça isso sempre que meu Pi tiver problemas de wi-fi.

Essa coisa de enquanto é estranha. Tive esses tipos de problemas no Raspberry pi zero e zero W, mas eles desapareceram completamente quando mudei de canal (conforme discutido anteriormente neste tópico).

Além disso, ultimamente tenho usado o sistema operacional DietPi e não tive nenhum problema. Você pode querer tentar isso.

Eu realmente gostei de investigar o problema, já que tinha visto antes, mas eu simplesmente não consigo fazer isso acontecer hoje em dia! :(

/ raj
(enviado do iPhone)

Em 5 de julho de 2017, às 9:01, timdonovanuk [email protected] escreveu:

FWIW Acho que recarregar o módulo do kernel wi-fi (fazendo "modprobe -r -v brcmfmac && modprobe brcmfmac") consertou, então terei que criar um script que faça isso sempre que meu Pi tiver problemas de wi-fi.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Quanto mais pessoas puderem olhar para isso, melhor, estou limitado no tempo
Posso gastar com isso no momento devido a outros projetos. Um grande problema
é um mecanismo sólido para replicá-lo.

Em 5 de julho de 2017 às 17:10, rajid [email protected] escreveu:

Essa coisa de enquanto é estranha. Tive esses tipos de problemas no Raspberry pi
zero e zero W, mas eles desapareceram completamente quando mudei de canal (como
discutido anteriormente neste tópico).

Além disso, ultimamente tenho usado o sistema operacional DietPi e não tive problemas em
todos. Você pode querer tentar isso.

Eu realmente gostei de olhar para o problema, tendo visto isso antes, mas eu
simplesmente não consigo fazer isso acontecer hoje em dia! :(

/ raj
(enviado do iPhone)

Em 5 de julho de 2017, às 9:01, timdonovanuk [email protected]
escrevi:

FWIW, acho que recarregar o módulo do kernel wi-fi (fazendo "modprobe -r -v
brcmfmac && modprobe brcmfmac ") consertou, então terei que criar um
script que faz isso sempre que meu Pi tem problemas de wi-fi.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

@timdonovanuk poderia ser legal, compartilhe seu script conosco, estou procurando uma solução alternativa. Talvez algum script de monitoramento rodando como serviço systemd ... O que você acha?

Existe uma maneira de acionar a atualização do domínio regulatório manualmente? Como eu disse, parece ser bastante consistente para mim sempre que funciona, a conexão cai. Eu gostaria de executá-lo manualmente algumas vezes para ver se posso reproduzi-lo de maneira confiável para você.

@rajid , por acaso você está rodando com largura de canal 40? E você se lembra se estava vendo atualizações regulatórias mundiais semelhantes antes das quedas? Curioso se talvez haja uma combinação em torno do canal 11 e a largura extra larga do canal ... e que tipo de roteador / AP você está usando? Só procurando alguma coisa em comum, já que estou vendo isso no canal 11 também, como foram outros ... Meu AP é um Ubiquiti.

A solução alternativa para mudar do canal automático no Apple Extreme para o canal 6 não funcionou para mim. Vou usar LAN durante as férias.

Edit: Agora eu perco a conexão mesmo com a LAN, deve haver algo mais aqui, é um problema de calor usando o case Oficial (sem ventilador)?

Olá,
Estou enfrentando um problema muito semelhante em um Raspberry Pi Zero W.

Desenvolvi uma API rodando com Node.JS no Pi e integrada com GPIOs.
O Pi está conectado à minha LAN através de Wifi. Tudo funciona muito bem quando os clientes de PC chamam a API. No entanto, assim que eu consultar minha API com um dispositivo Android, o Pi trava. Esses travamentos acontecem aleatoriamente: às vezes, a API pode ser chamada por dispositivos Android várias vezes e, de repente, o travamento acontece.
O que quero dizer com travamento é uma perda de ping, mas o Pi ainda está instalado e funcionando.

Chamar a mesma API por meio de PCs nunca causa nenhum travamento.

Tentei mudar o canal Wifi, mas não obtive melhores resultados.

Se eu puder executar algo para ajudar no diagnóstico / solução, fique à vontade para perguntar!

Alguma coisa nesta postagem do fórum ajuda?

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

Em 11 de julho de 2017 às 16:22, matthiasbou [email protected] escreveu:

Olá,
Estou enfrentando um problema muito semelhante em um Raspberry Pi Zero W.

Desenvolvi uma API rodando com Node.JS no Pi e integrei
com GPIOs.
O Pi está conectado à minha LAN através de Wifi. Tudo funciona bem no PC
clientes chamam a API. No entanto, assim que eu consultar minha API com um Android
dispositivo, o Pi falha. Essas falhas acontecem aleatoriamente: às vezes a API pode
ser chamado por dispositivos Android várias vezes e de repente a falha acontece.
Chamar a mesma API por meio de PCs nunca causa nenhum travamento.

Tentei mudar o canal Wifi, mas não obtive melhores resultados.

Se eu puder executar algo para ajudar no diagnóstico / solução, fique à vontade para perguntar!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314479400 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHYDohQoNRBDcX4oG49rK9e6kwpjjks5sM5MpgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

@matthiasbou

Interessante o que você disse, meu driver broadcom retorna o erro -110 (às vezes outro erro) e falha exatamente no momento em que eu conecto meu smartphone Motorola X2 (Android). Mas também ocorre o mesmo erro ao conectar minha SmartTV. De qualquer forma, posso confirmar que o travamento ocorre no momento em que a conexão é feita.

Meu país está configurado corretamente, ipv6 disable e roamoff = 1, estou usando o canal 6, o problema ainda está acontecendo. O modo de economia de energia wi-fi e o bluetooth estão desabilitados por padrão na minha distribuição.

@ JamesH65 : Tentei a solução interessante de definir o país correto (não era o caso), desabilitando o IPV6 e o ​​roaming, mas ainda com o mesmo problema :(

Wifi conecta, mas assim que eu começo a "brincar" com um dispositivo Android fazendo algumas chamadas de API no Pi Zero W, depois de um tempo, ele trava.

Por que a desativação do IPv6 deve resolver o problema do Wifi? Existe uma explicação sensata para o envolvimento do IPv6, que seja reproduzível? A única coisa que posso pensar é que o IPv6 pode ter uma pequena carga multicast adicional devido aos RAs.

Pelo que vale a pena, estou executando dois Pi Zero Ws como pontes IPv6 entre wlan0 integrado e eth0 externo, com IPv4 bloqueado. wlan0 está no modo AP e tem o servidor ISC dHCPv4 em execução. Estou conectando vários tablets e smartphones Android a ele. Não notei nenhum problema até agora, mas talvez eu precise deixá-los rodando por mais tempo. Estou usando o canal 6.

Estou usando um aparelho Apple Airport e não há configuração ou menção à "largura do canal". Eu simplesmente defini o canal 6 para a rede de 2,3 GHz. Agora estou usando DietPi em meus pequenos sistemas RaspPi Zero W. Os outros RaspPi que tenho foram configurados há muito tempo com Edimax USB e nunca tiveram problemas. Acredito que a única vez que vi problemas foi com Raspbian no sistema Zero W. Vou ter que carregar de novo e ver se consigo reproduzi-lo.

/ raj

Em 5 de julho de 2017, às 15:19, Michael Hallock < [email protected] [email protected] > escreveu:

Existe uma maneira de acionar a atualização do domínio regulatório manualmente? Como eu disse, parece ser bastante consistente para mim sempre que funciona, a conexão cai. Eu gostaria de executá-lo manualmente algumas vezes para ver se posso reproduzi-lo de maneira confiável para você.

@rajid https://github.com/rajid , por acaso você está rodando com largura de canal 40? E você se lembra se estava vendo atualizações regulatórias mundiais semelhantes antes das quedas? Curioso se talvez haja uma combinação em torno do canal 11 e a largura extra larga do canal ... e que tipo de roteador / AP você está usando? Só procurando alguma coisa em comum, já que estou vendo isso no canal 11 também, como foram outros ... Meu AP é um Ubiquiti.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-313242611 ou desative a conversa https://github.com/notifications/unsubscribe-auth/AFAlZVdfvh5QzIlsZYtt9sjpXolJqcmWks5s .

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

Acabei de realizar mais testes e mudei o roteador ao qual o Pi se conecta.
Até agora, tudo funciona quando o Pi está neste outro roteador Wifi (sem alteração no dispositivo Android):
Configuração do roteador de trabalho :
Canal 6
WPA-PSK
Largura de banda 20Mhz

Configuração do roteador que não funciona (perda de Wi-Fi após algum acesso do Android Wifi):
Netgear WNR1000v2
Canal 6
WPA2-PSK [AES]
Comprimento de Fragmentação 2346
Limiar CTS / RTS 2347

Vou mudar o roteador em funcionamento para WPA2-PSK para ver se o problema pode ser reproduzido.

@TheDiveO Com relação ao IPv6, o driver possui caminhos de código diferentes para o ipv6, assim como o kernel. Pode haver um bug em qualquer um desses caminhos que não está no ipv6 ou, como ISTR de um bug de um tempo atrás, algo executa um codepath ipv6 quando deveria executar um codepath ipv4 ou vice-versa. A pilha inteira é bastante complicada.

novo comportamento. Alterar a localidade e fazer o apt-get upgrade e update agora tem o seguinte comportamento quando meu pi3 está conectado via WIFI:

agora, dispositivos fora da LAN local podem se conectar ao PI via TCP / IP.

PI ainda recusa todas as conexões (TCP / IP) na LAN apenas.

PI ainda pode acessar a Internet externa via WIFI.

deixa pra lá. Nada mudou. Este é exatamente o mesmo comportamento de antes. O wifi Pi3 descarta todos os pacotes na LAN local.

Só para acompanhar um pouco ... eu comecei um novo AP (Linksys E4200 V2), que eu tinha por aí. Configurei no canal 11 para 2.4Ghz, configurei WPA2 Personal, um BSSID e senha. Então configurei isso no meu raspberry pi zero w. Ele conectou muito bem. Mudei então esse AP para a mesma sala onde está localizado meu AP normal de casa (que está no canal 6). Meu RaspPi obteve ASSOC-REJECT status_code = 16. Mover o AP de volta para o meu escritório mais uma vez fez com que o associado RaspPi ficasse bem.

Então, parece que no meu caso, pelo menos, o canal 11 é um problema se o AP estiver na outra sala. Suponho que isso provavelmente indica um problema de interferência.

Também postarei aqui uma página da web que encontrei que diz quais são todos os status_codes e códigos de falha:

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

Isso mostra que meu "status_code = 16" foi causado por um tempo limite, então um dos sistemas simplesmente não está recebendo pacotes em tempo hábil.

Só pensei em lançar essa informação lá, caso ajude alguém.

Quando eu acendo as luzes da minha cozinha, minha conexão wi-fi no
sala de estar ... não sei porque, mas quando você falou sobre interferência, eu acho
eu não sou louco

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

Só para acompanhar um pouco ... Iniciei um novo AP (Linksys E4200 V2),
que eu tinha por aí. Eu configurei no canal 11 para 2,4 Ghz, configurado
WPA2 Personal, um BSSID e senha. Então configurei isso no meu framboesa
pi zero w. Ele conectou muito bem. Em seguida, movi este AP para a mesma sala
onde meu AP normal de casa está localizado (que fica no canal 6). Minha RaspPi então
obteve ASSOC-REJECT status_code = 16. Movendo o AP de volta ao meu escritório uma vez
novamente fez o RaspPi associado muito bem.

Então, parece que no meu caso, pelo menos, o canal 11 é um problema se o AP for
na outra sala. Suponho que isso provavelmente indica uma interferência
problema.

Também postarei aqui uma página da web que encontrei que conta o que todos os
status_codes e códigos de falha são:

https://supportforums.cisco.com/document/141136/80211-
associação-status-80211-deauth-reason-codes

Isso mostra que meu "status_code = 16" foi causado por um tempo limite, então um dos
sistemas simplesmente não estão recebendo pacotes em tempo hábil.

Eu só pensei em lançar essa informação para o caso de ajudar
alguém.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314872003 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ACeQBJdfk2zp1sReVVs1wvrilKHXNm53ks5sNR42gaJpZM4HupC5
.

Existe um programa WiFi Analyzer muito bom para Android, que mostra quais APs estão ao seu redor, junto com suas informações detalhadas. (Eu gostaria que algo assim existisse para iPhone / iPad, mas Apple ...)

@ JamesH65 você está realmente me deixando desconfortável dizendo que um driver da camada de enlace de dados (camada 3) bagunça a camada de rede 3. "Desordem" provavelmente também não é uma palavra apropriada para esta situação ...

Na verdade, não estou dizendo isso. Não sou um especialista em redes Linux
pilha, mas certamente me lembro de ter visto algumas coisas específicas do IPv6 em
um motorista em algum lugar.

Tudo está na árvore do kernel, você está convidado a dar uma olhada
você mesmo para colocar sua mente em repouso.

Em 13 de julho de 2017 às 08:58, TheDiveO [email protected] escreveu:

@ JamesH65 https://github.com/jamesh65 você está realmente me deixando inquieto
dizendo que um driver da camada de enlace (camada 3) confunde com
a camada de rede 3. "Desordem" provavelmente não é uma palavra apropriada para isso
situação também ...

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315002002 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHUSoqqxnhaw4k2ECkzGC9CDkIlhYks5sNc4ngaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

@TheDiveO James está se referindo a coisas como descarregamento de checksum de hardware.
SMSC95xx, por exemplo, só pode suportar o descarregamento de checksum IPv4 devido ao IPv6 requerer um checksum de 0x0000 sendo substituído por 0xFFFF. Consulte https://github.com/torvalds/linux/commit/fe0cd8ca1b82983db24b173bb8518ea646c02d25. Conseqüentemente, o IPv6 e o ​​IPv4 seguirão caminhos de código diferentes. Nada duvidoso aí, mas inerente à pilha de rede onde o hardware não pode cobrir todas as situações.

Tenho quase certeza de que o bug está no driver Broadcom, não no kernel.

Quase com certeza. O driver Brcm é um grande pedaço de código, porém, e bugs
assim, não são fáceis de depurar. Especialmente quando você não pode replicá-los ...

Em 13 de julho de 2017 às 13:04, Alexandre Bolelli [email protected]
escrevi:

Tenho quase certeza de que o bug está no driver Broadcom, não no kernel.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315058283 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHbr5SiWPKvQZOY7rN8IbyIIscNfVks5sNgexgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Quanto mais luto com isso, mais começo a me perguntar se isso está relacionado à incapacidade do Ubuntu / Debians de conectar wlan0 e eth0 à mesma sub-rede sem alguma configuração extensa. Vou examinar isso mais detalhadamente e ver se esse é o problema.

@ JamesH65 ajudaria se eu (ou outra pessoa) configurasse zero w ou rpi 3 para você em um ambiente onde isso fosse facilmente reproduzível e desse acesso ssh para você depurar? (Eu precisaria comprar zero w extra para isso).

Provavelmente não, mas obrigado pela oferta. Eu costumo fazer mudanças personalizadas no
driver e kernel, com alterações feitas várias vezes ao dia. Fazendo isso
remotamente não é viável. Os mecanismos para reproduzir o problema de forma confiável são
realmente o que é necessário.

Em 13 de julho de 2017 às 13:57, Tuomas Airaksinen [email protected]
escrevi:

@ JamesH65 https://github.com/jamesh65 ajudaria se eu (ou alguém
else) configuraria zero w ou rpi 3 para você em um ambiente onde este é
facilmente reproduzível e dá acesso ssh lá para você depurar? (EU
precisaria comprar zero w extra para isso).

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315069935 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHeQ1RECH-uIIHWPX6ItvRdVbZG_Xks5sNhRWgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

James,
Se eu fizer este loop de pesquisa simples, vejo rapidamente a rede wi-fi integrada degradar para um estado inutilizável. Quando eu desligo o wi-fi onboard e uso um wi-fi USB, ele funciona localizar. Não me lembro se é sensível ao dispositivo BT estar presente ou ausente e não posso verificar isso facilmente por alguns dias. Limitei-me a 10 minutos para poder voltar ao pi zero w após o experimento.

bash# ((t= data +% s +600)); while [ data +% s -lt $t ] ; do hcitool name <BTMAC>; done
Espero que ajude,
Benjamin

Esse recorte de código perdeu minhas pulsações. Fugindo deles ...

((t = `data +% s` + 600)); enquanto [`data +% s` -lt $ t]; do hcitool name "insert BT MAC"; feito

AMD. Acho que está consertado. Wifi é ativado quando a Ethernet é desconectada. Inacreditável.

Removi todas as menções a eth0 do meu arquivo / etc / network / interfaces, substituí allow-hotplug por auto e forcei o wireless-power off em ambos wlan0 e wlan1.

meu arquivo / etc / network / interfaces:

auto lo
iface lo inet loopback

sem fio desligado
wlan0 automático
manual iface wlan0 inet
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

sem fio desligado
wlan1 automático
manual iface wlan1 inet
wpa-conf / etc / wpa_supplicant / wpa_supplicant.conf`

Então eu corei arp:

ip -s -s neigh flush all

Então eu reiniciei:

sudo reboot now

E agora meu wi-fi funciona. Inacreditável. Obrigado a todos que comentaram neste tópico.

Seu problema de configuração específico pode ser resolvido, o bug no driver Broadcom ainda está presente.

OK, estivemos examinando isso. Meu primeiro problema foi que, ao fazer SSH no meu dispositivo de teste, a sessão estava travando, A MENOS que o cabo Ethernet também fosse inserido. Acontece que o ARP é controlado por qualquer uma das interfaces, então quando a ethernet foi conectada ela estava usando isso. Não ter conectado significava que estava sendo tratado pelo Wifi e encontrando um problema. Este problema poderia ser corrigido desligando o QoS / ToS no SSH (veja aqui https://expresshosting.net/ssh-hanging-authentication/), o que por sua vez implica que o driver Broadcom Wifi está muito descontente com o TOS (tipo de serviço) / campo DSCP sendo definido. Isso já foi visto antes no NTP (problema no. 1519). Suspeito que isso possa ser a causa dos problemas de Wifi relacionados a esse problema e vou dar uma olhada no driver Brcm hoje para ver se consigo encontrar algo.

Relatório provisório. Definitivamente, estamos vendo problemas com determinados valores de pacote TOS, fazendo com que os pacotes sejam descartados silenciosamente, causando travamentos de SSH. Nada óbvio ainda no código do driver impenetrável, que TBH não deveria tocar nesta parte do pacote de qualquer maneira, mas há claramente algo acontecendo. Isso tem algo a ver com os congelamentos gerais de wlan relatados aqui? Ainda não sei.

Tenho problemas semelhantes em um Pi Zero W com raspbian jessie e kernel 4.9.35+
Tenho o mesmo problema mencionado por JamesH65 com SSH e ntpd (TOS). Correção de https://expresshosting.net/ssh-hanging-authentication/ funcionou para sshd. Eu também tenho problemas de desconexão wlan0, mas com mensagens de log um pouco menos verbosas. Superficialmente, parece que a operadora está perdida e o wpa_supplicant às vezes falha na renegociação. A única maneira de sair disso é emitir ifdown wlan0, espere, ifup wlan0 para mim, então wlan0 começa a funcionar novamente. Fico feliz em fornecer logs se alguém precisar deles. Apenas me diga qual.

Relatório provisório. Queria fazer algumas anotações antes que fossem esquecidas. Determinamos que é a resposta do pi conectado sem fio que está faltando ao acessar via SSH de outro dispositivo. Se essa resposta tiver o campo TOS definido, o pacote será descartado silenciosamente - nunca retornará ao solicitante. Podemos replicar isso usando o netcat. O comando net cat simples do Pi sem fio com os sinalizadores de TOS definidos não parece sair do dispositivo.
Então, no PI wireless, tente enviar um pacote UDP para outro dispositivo ...
nc -T 0x10 -u7
O dispositivo parece não receber o pacote (conforme mostrado ao executar tcpdump no destino)
nc -T 0x00 -u7
chegará ao sistema remoto.
Só tentamos isso pela rede sem fio aqui no escritório. Preciso configurar outra rede Wifi para ver se ela está relacionada ao roteador ou se há um problema no driver.

Correção menor para o comando netcat acima
nc -T 0x10 -u <dest_ip> 7
A porta 7 UDP foi escolhida por ser o serviço de eco. Não importa que isso não esteja sendo executado na máquina remota, embora isso leve à resposta ICMP inacessível apropriada, o que é uma indicação útil de que a extremidade remota recebeu a mensagem.

Começo a pensar que o problema SSH / ToS não está realmente relacionado. Eu rastreei os pacotes até o nível HW e não importa se os sinalizadores de TOS estão definidos ou não, os pacotes parecem chegar ao firmware (ou pelo menos a função brcmf_sdiod_send_pkt que está além de qualquer tratamento de prioridade no o driver Linux). O que indica que o problema está no firmware do chip (código fechado) ou realmente relacionado ao roteador - ou seja, o roteador sem fio que estou usando não deixa passar os sinalizadores de TOS diferentes de zero (ou talvez> 0x04). Vou tentar um roteador sem fio diferente amanhã para tentar confirmar isso.

Existe alguma chance de localizar o departamento responsável pelo desenvolvimento do módulo brcmfmac para que alguém possa seguir aquele thread ou pelo menos responder se alguma correção para esses bugs for lançada?

Já estamos em contato através da mailing list linux-wireless.

Em 19 de julho de 2017 19:06, "Alexandre Bolelli" [email protected] escreveu:

Existe alguma chance de localizar o departamento responsável pelo desenvolvimento
o módulo brcmfmac para que alguém possa seguir esse tópico ou pelo menos
responder se alguma correção para esses bugs for lançada?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316469790 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHYtYvpxdKd3SBBynOnlDN-ZXiWs_ks5sPkW9gaJpZM4HupC5
.

Já estamos em contato através da mailing list linux-wireless.

... e rotas mais diretas. O problema sempre foi de reprodutibilidade - uma vez que temos uma maneira de demonstrar claramente o problema, podemos apresentá-lo à Broadcom / Cypress e consertá-lo. Nunca consegui ver o problema com o NTP, mas James teve uma falha bem-sucedida com SSH, então estou otimista de que chegaremos à causa raiz.

@pelwell +1 para o termo "_falha com sucesso" _ :)

Eu tenho uma correção de hacky para o problema de bloqueio SSH. Parece ser um problema no firmware. Aqui estão alguns detalhes.

`
Estamos investigando um problema no Raspberry Pi, onde SSH e
As sessões NTP estão falhando quando o sinalizador TOS é definido no cabeçalho IPv4.

Aqui está um trecho do que é o TOS:

TOS é 0x08 ou 0x10. Apenas um dos 4 bits pode ser definido por vez.
0x10 - minimizar o atraso
0x08 - maximiza o rendimento
0x04 - maximizar a confiabilidade
0x02 - minimiza o custo monetário.
Tecnicamente, o TOS foi substituído pelo DSCP, mas ainda é compatível.

Poderíamos tentar recriar esse problema com o DSCP se realmente necessário, mas ele não
parecem ser relevantes.

Detalhes sobre o problema de SSH e uma solução alternativa podem ser encontrados aqui https://expresshosting.net/ssh-hanging-authentication/

No entanto, este é claramente um problema em algum lugar nas comunicações
pilha, então é isso que estamos investigando.

Conseguimos replicar um exemplo simples usando o netcat. Primeiramente,
conectar um Pi sem fio a um AP (PiA), com outro dispositivo conectado
sem fio ou via ethernet para a mesma rede (PiB).

Na corrida PiB

sudo tcpdump -n 'udp porta 7' -v -i wlan0 <<<< ou eth0 dependendo da conexão

No PiA,

nc -T 0x10 -u7

Isso envia um pacote UDP para a porta 7, com o sinalizador TOS definido como 0x10.

Isso NÃO chegará (ou às vezes será muito atrasado - 10 segundos)

Enviando TOS como 0

nc -T 0x0 -u7

Chegará. 0x02 e 0x04 também chegarão, 0x8 e 0x10 não.

Instrumentando o driver brcmfmac mostra que o pacote com o TOS
flag = 0x10 é enviado corretamente para baixo na pilha para o HW, mas então o
pacote desaparece.

Conseguimos passar o pacote hackeando o código BCDC,
na função bcdc.c! brcmf_proto_bcdc_hdrpush, a prioridade do
o pacote também é enviado para o cabeçalho bcdc. Definindo isso para um
valor constante (que pode ser qualquer coisa de 0-7), o pacote é
transmitido. Portanto, parece que um valor constante para a prioridade bcdc
funciona, mas tendo-o definido para a prioridade, conforme determinado pelo
as coisas de prioridade do skb falham SE o TOS for 0x08 ou 0x10. Então, parece
ser uma combinação de pacotes com prioridades variadas que faz com que
valores de prioridade mais alta falhem, não o valor em si.

Uma vez que a prioridade do cabeçalho BCDC é destinada ao firmware, este
parece ser um problema no próprio firmware, não no Linux
motorista.

Aqui está uma diferença da mudança que parece impedir que o problema aconteça.

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 Ótimo. Já que não espero uma correção de firmware em breve, você poderia copiar isso para linux-wireless?

Vou aguardar algumas informações da Broadcom / Cypress, já que estou
não tenho certeza se este hack é seguro em todas as circunstâncias. Eu mandei um email para eles. Uma vez
Se eu receber algum feedback, enviarei um patch para o linux-wireless.

Em 20 de julho de 2017 às 12h41, Stefan Wahren [email protected] escreveu:

@ JamesH65 https://github.com/jamesh65 Ótimo. Já que eu não espero um
em breve correção de firmware, poderia copiar isso para linux-wireless?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316678154 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHY3DlxTr9mehRDlxBK3NWbjowxxyks5sPzzqgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Alguns resultados de teste parecem indicar que não há efeitos nocivos desse hack. Acabei de transferir dados de um lado para o outro, 500 MB para o Wireless Pi, 3,4 GB enviados. Pacotes RX 56 descartados de 794730, nenhum pacote TX descartado de 2813930. O desempenho parece perfeito para uma conexão de 11 Mbits / s. Parece aceitável, mas esse hack na verdade desabilita algo que provavelmente deveria ser habilitado, então não é uma solução de longo prazo.

@lategoodbye Tenho pensado em levar isso para o linux-wireless. Uma vez que esse hack é realmente relevante / testado apenas para o chip específico no Pi (BCM43438?), E o código do driver é para vários modelos de chip, o patch precisaria determinar o tipo de chip sendo usado antes de fazer a alteração, e eu suspeito aquele linux-wireless ficaria descontente com esse tipo de mudança e eu não seria capaz de testá-lo de qualquer maneira. Definitivamente vou fazer uma PR no nosso repo (a menos que uma correção de firmware esteja chegando, duvido que em um cronograma razoável). Só não tenho certeza de como colocá-lo no Linux sem fio, se o fizer.

@moonman
Você acha que isso poderia ser enviado para ARCH linux-raspberrypi?

@ JamesH65 Claro, seu hack não é adequado para todos os modelos de chip. Mas não é seu trabalho encontrar uma solução para todos eles. Acho que uma simples cópia do seu longo comentário acima (incluindo hack) seria suficiente. Minha intenção era informar outro desenvolvedor de kernel não-broadcom sobre o problema. Não esperava que você enviasse um patch adequado para esse problema, apenas um relatório de bug.

Eu sugiro que o coloquemos em nosso repositório para fazer alguns testes sérios - comece com rpi-4.12.y que é usado por compilações LibreElec noturnas de ponta.

Um pensamento - você poderia tornar o patch mais seletivo em sua filtragem de prioridade e ainda corrigir o problema?

Estou apenas preparando um PR para isso ir para o repo Pi.

Com relação à verificação seletiva, tentei simplesmente detectar a prioridade
6 (aquele que é passado pela pilha - é traduzido do TOS
valor para algo mais específico da pilha do Linux), e defini-lo como 0 e
isso pareceu funcionar, mas minha suspeita é que é uma combinação de
prioridades diferentes, em vez de especificamente 6 que causa o problema. Nós
também saiba que um TOS de 0x08 também tem problemas, ou seja, IIRC,
convertido para 2 quando chegar a este ponto. Poderíamos simplesmente dizer, se
é 6 ou 2 e, em seguida, defina-o como zero, mas ainda não tenho certeza de que pegaria
tudo o que pode causar problemas. Já que o valor é 0-7 de qualquer maneira, eu acho,
para este hack, é melhor apenas definir como 0 em todos os casos. Nós sabemos isso
funciona, pode não ser o ideal, é claro, mas acho que todos os pacotes seriam
atravessar. Observe que esta configuração NÃO afeta o valor TOS no
Pacote IPv4 - que permanece o mesmo, é apenas este sistema de envio de
prioridade para o chip e como ele lida com isso que parece fragmentado.

Em 21 de julho de 2017 às 09:35, Phil Elwell [email protected] escreveu:

Um pensamento - você poderia tornar o patch mais seletivo em sua prioridade
filtrando e ainda corrigiu o problema?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Tive algum contato com Cypress, que vai tentar obter este
olhou para o mais rápido possível.

Em 21 de julho de 2017 às 10:11, James Hughes [email protected] escreveu:

Estou apenas preparando um PR para isso ir para o repo Pi.

Com relação à verificação seletiva, tentei simplesmente detectar
prioridade 6 (aquela que é passada pela pilha - é traduzida de
o valor TOS para algo mais específico da pilha do Linux), e definindo isso para
0 e isso pareceu funcionar, mas minha suspeita é que é uma combinação
de prioridades diferentes, em vez de 6 especificamente que causa o problema.
Também sabemos que um TOS de 0x08 também tem problemas, ou seja, IIRC,
convertido para 2 quando chegar a este ponto. Poderíamos simplesmente dizer, se
é 6 ou 2 e, em seguida, defina-o como zero, mas ainda não tenho certeza de que pegaria
tudo o que pode causar problemas. Já que o valor é 0-7 de qualquer maneira, eu acho,
para este hack, é melhor apenas definir como 0 em todos os casos. Nós sabemos isso
funciona, pode não ser o ideal, é claro, mas acho que todos os pacotes seriam
atravessar. Observe que esta configuração NÃO afeta o valor TOS no
Pacote IPv4 - que permanece o mesmo, é apenas este sistema de envio de
prioridade para o chip que parece escamoso e como ele lida com isso
parece escamoso.

Em 21 de julho de 2017 às 09:35, Phil Elwell [email protected] escreveu:

Um pensamento - você poderia tornar o patch mais seletivo em sua prioridade
filtrando e ainda corrigiu o problema?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Também sabemos que um TOS de 0x08 também tem problemas, ou seja, IIRC, convertido para 2 no momento em que chega a este ponto.

Corrigir. TOS 0x08 (maximizar taxa de transferência) mapeado para 2. Eles são valores TC_PRIO_xxx de http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/pkt_sched.h#L19. 6 = INTERATIVO, 2 = EM GRANEL.

Os testes anteriores com a configuração de IPQoS para 8 em sshd_config ou com netcat usando TOS 8 resultaram em pacotes descartados.
Nem 0x02 nem 0x04 causaram quaisquer problemas, mas há pouco que um driver de wi-fi possa fazer em relação à diferença de custo (não há nenhuma) ou confiabilidade, então provavelmente os está ignorando.
editar Na verdade, a tabela de mapeamento em http://elixir.free-electrons.com/linux/latest/source/net/ipv4/route.c#L177 levando tos>>1 está configurando TOS 0x02 e 0x04 para TC_PRIO_BESTEFFORT = 0 de qualquer maneira, o que explica por que eles não têm problemas.

Apenas um relatório rápido. A Cypress foi capaz de replicar o problema e são
verificar o firmware com uma aparência esperançosa. Resposta muito agradável e rápida
dos caras lá.

Em 21 de julho de 2017 às 11:07, 6by9 [email protected] escreveu:

Também sabemos que um TOS de 0x08 também tem problemas, ou seja, IIRC,
convertido para 2 quando chegar a este ponto.

Corrigir. TOS 0x08 (maximizar rendimento) mapeado para 2. Eles são TC_PRIO_xxx
valores de http://elixir.free-electrons.com/linux/latest/source/
inclua / uapi / linux / pkt_sched.h # L19. 6 = INTERATIVO, 2 = EM GRANEL.

Teste anterior com configuração de IPQoS para 8 em sshd_config ou com
netcat usando TOS 8 resultou em pacotes perdidos.
Nem 0x02 nem 0x04 causaram problemas, mas há poucos drivers de wi-fi
pode fazer sobre a diferença de custo (não há nenhuma) ou confiabilidade, então provavelmente é
ignorando-os (não verifiquei).

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316962443 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHXTmjzqVW0o4T9IIoYFPprKvEvS7ks5sQHhXgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Maneira mais fácil de reproduzir - use o ping! (Eu tinha esquecido que ping / ICMP estava acima do IP - bobagem)

ping -Q 0x10 <dest ip addr> no Pi3
e execute tcpdump -n -v -i wlan0 'icmp' no destino.
Resulta em> 90% de perda de pacotes em -Q 0x10 ou -Q 0x08. Geralmente começa bem com 4 pacotes sequenciais passando, mas depois fica muito intermitente.
É um pouco mais útil do que o netcat porque (a) ele continua se repetindo e (b) ele avisa quando obtém uma resposta.

Há uma solução alternativa aqui: https://github.com/raspberrypi/linux/pull/2126
Se você quiser testá-lo com o kernel 4.9, use rpi-update.
Em seguida, substitua:
modules / 4.9.39 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko com isso
modules / 4.9.39-v7 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko com isso

EDITAR: O kernel rpi-update mais recente agora inclui o patch, então o download dos módulos não é mais necessário.

Não tenho certeza se relacionado. A conexão na broadcom on-board no meu Pi Zero W cai a cada 2 horas quando uma segunda interface wlan1 é ativada com um dongle rt8192eu / 8192eu. Não parece ser um problema de energia porque é muito cíclico, eu tenho um pastebin das desconexões em https://pastebin.com/5hMQHWeW

Quando isso está em andamento, wpa_supplicant às vezes desiste de tentar por nenhuma razão óbvia além da falha na autenticação e a única maneira de obter a conectividade de volta em wlan0 é emitir ifdown / ifup que funciona 100%.

Não sei se são os problemas do módulo do kernel Broadcom que estão causando problemas, ou se é o bug 8192eu ou ambos. Fico feliz em fornecer mais linhas de registros se necessário ou postar em um tópico diferente, mas alguém no #raspbian sugeriu que eu adicionasse isso aqui.

Se você puder confirmar que vcgencmd get_throttled retorna 0x0 após uma desconexão que irá descartar um problema de energia.

Geralmente acontece quando estou dormindo / não com o Pi e descubro em retrospecto quando não consigo mais me conectar a ele (então costumava me conectar pelo segundo AP e reiniciar o wlan0). No entanto, como o dongle 8192eu está desconectado agora, não houve um evento. Posso conectar o segundo dongle com o módulo com bugs, mas quanto tempo após a desconexão, preciso verificar o vcgencmd get_throttled?

Desde que você não tenha reiniciado, os bits superiores dirão se já houve um evento de subtensão.

Apenas corri. Definitivamente, não reiniciado desde a última desconexão. Pode confirmar os retornos de vcgencmd get_throttled:
estrangulado = 0x0

Infelizmente get_throttled não funcionará em um Pi0 / Pi0w (não tem o circuito de detecção de subtensão).

Por alguma razão, copiar e colar o diff do JamesH65 não funcionou para mim. Fizemos um patchfile que deve ser aplicado imediatamente, mas as pessoas podem achar isso útil: https://github.com/bortek/EZ-WifiBroadcast/blob/master/kernel/linux-4.9.28-brcmfmac-tos.patch

O nome do arquivo diz 4.9.28, mas deve ser aplicado pelo menos até 4.9.35 (e provavelmente os posteriores também).

Copie este arquivo para o diretório raiz da árvore do kernel e aplique com patch -p1 < linux-4.9.28-brcmfmac-tos.patch

Informações adicionais (mas estranhas):

Se o Pi Zero W estiver conectado a wlan0, mas sem fazer nada (cron script checando o sntp a cada 15 minutos no máximo), haverá desconexões muito frequentes, algo na ordem de 1-10 / hora durando no máximo um segundo cada.

Porém, se eu tivesse algo usando a conexão, por exemplo, ocioso no IRC (vários canais grandes), a conexão não cairia uma única vez durante todo o tempo, este é o caso.

Acontece que carregar os módulos do kernel 4.9.39 no 4.9.35 não foi uma boa ideia.

Outro relatório de bug do fórum, erro de caixa de correio parece comum.

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

O kernel rpi-update mais recente agora inclui o patch de prioridade BCDC.

Cypress (era Broadcom) nos deu novos lançamentos de firmwares WiFi e Bluetooth para testar. Você pode baixar um pré-lançamento aqui . Depois de baixar para o seu Pi, execute:

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

Isso irá extrair e instalar o novo firmware (primeiro será feito o backup das versões antigas).

Para reverter para o firmware original (o que eu recomendo que você faça antes de instalar uma versão adequada):

./brcmfw -u

O que mudou:

1. CVE-2017-9417: Correção do problema “Broadpwn”
2. Adicione a string “CY” na string da versão.
3. Correção de impasse de número de sequência AMPDU (possível correção para este problema)
4. Atualização da versão CLM
5. CVE-2017-0572: correção de corrupção de memória

Apenas uma observação - desativei o wi-fi interno no meu primeiro Pi Zero W e mudei para um dongle wi-fi USB, sem problemas. Há alguns dias instalei outro Pi Zero W para controlar minha impressora 3D (usando OctoPi). Fiquei um pouco surpreso ao ver que o wi-fi interno parece funcionar perfeitamente - mas depois de alguns testes, posso confirmar que o wi-fi quebra assim que me conecto do meu telefone LG G4 Android (navegador Chrome). Quando penso nisso, acho que o comportamento no primeiro Pi foi bastante semelhante ...
A conexão do meu PC não causa tais efeitos.

Experimente o novo firmware e relate suas descobertas.

Eu instalei o firmware de visualização. Ainda recebo o erro "kernel do raspberrypi: brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados da caixa de correio desconhecido:" seguido de falha de wifi.

Qual é o seu caso de uso?

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

tentando a configuração de trabalho postada lá. Eu vou atualizar.

Forneça sua versão do kernel, um resumo dos dispositivos conectados e quanto tempo leva para o erro aparecer.

O erro da caixa de correio ainda está sob investigação, não estou esperando isso
firmware para corrigi-lo. Há mais depuração neste firmware para ajudar a rastrear
embora. Se você habilitar a depuração do driver (desculpe, no celular e
não tem detalhes sobre como fazer isso) e ver o erro e, em seguida, despejar o
depurar e postar detalhes aqui quando você receber o erro de caixa de correio seria
útil.

Em 13 de agosto de 2017, 21:40, "Stefan Wahren" [email protected] escreveu:

Forneça sua versão do kernel, um resumo dos dispositivos conectados e
demora até que o erro apareça.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322062745 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHRwsQyHa-QqOP7ntTqgCfWlgXpEqks5sX1DlgaJpZM4HupC5
.

A depuração é desabilitada por padrão e precisa de uma reconstrução do módulo para habilitar (talvez devamos mudar isso durante essas investigações). As alterações necessárias são a adição de BRCMDBG=y a .config seguida por uma reconstrução e, a seguir, adicione brcmfmac.debug=0x???????? a /boot/cmdline.txt , onde ???????? é um número hexadecimal que compreende o valores de bits documentados aqui: https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h#L22

Tentei o firmware de teste postado por pelwell, o problema ainda persiste. A conexão congela a cada 1 - 2 horas. Quando a conexão caiu e eu tentei fazer o ping ( ping 8.8.8.8 ), ele está funcionando _brevidamente_ novamente até o 8º ping. O comportamento do ping é consistente em congelamentos. Trabalhando-> congelar-> ping 8.8.8.8-> trabalhando -> 8º ping -> congela Depois disso, eu preciso reiniciar meu pi do raspberry. Não sei se isso ajuda embora ..

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

Firmware:
BT: test_170808
Bin WiFi: test_170808
WiFi txt: test_170808

Algo relevante no dmesg quando isso acontecer?

Em 14 de agosto de 2017, 13:16, "GIlang Charismadiptya" [email protected]
escrevi:

Tentei o firmware de teste postado por pelwell, o problema ainda persiste.
A conexão congela a cada 1 - 2 horas. Quando a conexão caiu e eu
tentou fazer ping (ping 8.8.8.8), está funcionando novamente por alguns instantes até o dia 8
ping. Depois disso, preciso reiniciar meu pi de framboesa.

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 Tue Ago 8 16:00:15 BST 2017 armv7l GNU / Linux

Firmware:
BT: test_170808
Bin WiFi: test_170808
WiFi txt: test_170808

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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=
.

Não, nada de interessante. Talvez porque eu não reconstruí o módulo com suporte para depuração. Como fazer isso? ou você fornecerá o módulo compilado? Obrigado.

Anexados abaixo estão os logs 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
`

Veja a postagem de Phil acima para obter detalhes sobre o módulo de depuração. Nós somos particularmente
interessado no rastreamento de depuração quando ocorre o erro da caixa de correio.

Em 14 de agosto de 2017 17:52, "GIlang Charismadiptya" [email protected]
escrevi:

Não, nada de interessante. Talvez porque eu não reconstruí o módulo com
suporte para depuração. Como fazer isso? ou você fornecerá o módulo compilado?
Obrigado.

Em anexo abaixo do log dmesg:

` pi @ raspberrypi : ~ $ sudo dmesg

[4.654722] brcmfmac: versão do firmware = wl0: versão de 7 de agosto de 2017 00:46:29
7.45.41.46 (r666254 CY) FWID 01-f8a78378
[5.752968] smsc95xx 1-1.1: 1.0 eth0: o hardware não é capaz de remoto
acorde
[5.753285] IPv6: ADDRCONF (NETDEV_UP): eth0: o link não está pronto
[6.206530] IPv6: ADDRCONF (NETDEV_UP): wlan0: o link não está pronto
[6.206577] brcmfmac: gerenciamento de energia desativado
[7.088933] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: o link fica pronto
[7.340040] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: o link fica pronto
[7.340841] smsc95xx 1-1.1: 1.0 eth0: link up, 100 Mbps, full-duplex, lpa
0xCDE1
[7.431235] Adicionando 102396k swap em / var / swap. Prioridade: -1 extensões: 4
em: 217088k SSFS
[10.182342] IPv6: ADDRCONF (NETDEV_UP): wlan0: o link não está pronto
[10.182357] brcmfmac: gerenciamento de energia desativado
[10.872838] IPv6: ADDRCONF (NETDEV_UP): wlan0: o link não está pronto
[10.872903] brcmfmac: gerenciamento de energia desativado
[11.594201] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: o link fica pronto
[14.128592] ip_tables: (C) 2000-2006 Netfilter Core Team
[14.172268] nf_conntrack versão 0.5.0 (15.360 baldes, 61440 máx.)
[54.604680] random: inicialização crng feita

pi @ raspberrypi : ~ $ sudo dmesg -l err
[4.501055] raspberrypi-touchscreen 3f700000.dsi.0: firmware Atmel desconhecido
revisão: 0xfa
`

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322228992 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHXuy3Eo5PqPAP8FfSFiYWMUQL7fAks5sYG1HgaJpZM4HupC5
.

O kernel rpi-update mais recente habilita o BRCMDBG, que deve permitir a opção de linha de comando brcmfmac.debug=0x???????? sugerida por @pelwell anteriormente.

Errrr ... meu Pi3 que era sólido como uma rocha com wi-fi agora também perdeu desde que atualizei para o último raspbian há alguns dias :-(

Quais são os sintomas? Eu não esperaria uma regressão no firmware, ou
na verdade, o próprio driver.

Em 24 de agosto de 2017 às 20:07, Crrispy [email protected] escreveu:

Errrr ..... meu Pi3 que era sólido como uma rocha com wi-fi agora também o perde, pois eu
atualizado para o último raspbian há alguns dias :-(

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-324728431 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHUxvLV3OzKGpcmEMGEoSad_piujBks5sbcoHgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

@Crrispy
Experimente isto:
Removi todas as menções a eth0 do meu arquivo / etc / network / interfaces, substituí allow-hotplug por auto e forcei o wireless-power off em ambos wlan0 e wlan1.

meu arquivo / 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`

Então eu corei arp:

ip -s -s neigh flush all

Então eu reiniciei:

sudo reinicie agora

Tenho certeza de que estou encontrando esse bug regularmente. Executando hostapd, usando o wi-fi Broadcom interno para hospedar um ponto de acesso e roteando os clientes que se conectam a ele por meio de um dongle wi-fi USB que funciona como um cliente sem fio. Vários dispositivos estão conectados, mas assim que eu carrego o Pi fora do alcance dos dispositivos conectados, o travamento do wlan parece ocorrer. Tal como acontece com os outros, é apenas o dispositivo wlan interno da broadcom que é desativado: a ethernet e a outra wlan permanecem inalteradas. Também estou recebendo o erro "caixa de correio" no log do sistema:

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

(mais detalhes de registro em https://pastebin.com/NPB00ZEq)

Percebi que a saída de iwconfig não mostra mais o valor Tx_Power quando o dispositivo wlan está em seu estado de falha, então usei isso para fazer um script de reinicialização automática como uma solução alternativa nesse meio tempo.

Acabei de atualizar para a atualização rpi mais recente, instalei os drivers de teste wi-fi mencionados acima e adicionei o sinalizador de depuração ao meu cmdline.txt, usando o valor hexadecimal para BRCMF_TRACE_VAL: bcrmfmac.debug=0x00000002

Se você conseguir obter regularmente o erro da caixa de correio, ficaríamos gratos pelos resultados do driver de depuração. Quando você receber o erro da caixa de correio, por favor, faça algo assim para obter a perícia e postar os resultados aqui, posso encaminhá-los para a Cypress, que está investigando o problema.

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

Bem, o que era um problema facilmente reproduzido, não sou mais capaz de duplicar, desde a execução do rpi-update. Eu posso fazer isso acontecer fazendo o downgrade para uma nova instalação do Raspbian a partir de 21 de junho de 2017, se isso for útil.

@ JamesH65
Conseguiu capturar a análise forense que você solicitou (após o erro da caixa de correio), mas para ser claro, isso ocorre após o downgrade para o kernel incluído na compilação Raspbian de 21 de junho. Pode muito bem já ter sido resolvido, porque ainda não dupliquei o problema depois de instalar o firmware de teste postado por @pelwell cerca de duas semanas atrás e executar rpi-update.

Aqui está um link para a perícia:
https://pastebin.com/VVqVQ8FW

Espero que isso ajude ...

Assim, com o antigo firmware, eu suspeito. Esperamos obter a perícia para
o novo firmware que tem mensagens extras (aparentemente) destinadas a rastrear
o problema da caixa de correio. Isso me faz pensar que Cypress ainda parece pensar que
o problema da caixa de correio estará lá, mesmo após as outras correções. Irá transmitir os dados de qualquer maneira, caso isso ajude.

É bom saber que os erros são muito mais difíceis de reproduzir!

Em 29 de agosto de 2017 às 15:51, randyoo [email protected] escreveu:

@ 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=
Conseguiu capturar a perícia que você havia solicitado, mas para ser claro,
isso ocorre após o downgrade para o kernel incluído no Raspbian de 21 de junho
Construir. Pode muito bem já ter sido resolvido, porque não consigo
duplicar o problema após instalar o firmware de teste postado 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=
cerca de duas semanas atrás.

Aqui está um link para a perícia:
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 isso ajude ...

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Isso me faz pensar que Cypress ainda parece pensar que
o problema da caixa de correio estará lá, mesmo após as outras correções.

Sim, esse é o meu entendimento também.

@randyoo Obrigado pelo feedback positivo.

@ JamesH65
Ok, aconteceu de novo, desta vez com o firmware de atualização rpi mais recente e usando o firmware de teste postado por @pelwell . Infelizmente, o resultado da perícia parece idêntico ao do post anterior. (Não sei por que não estou obtendo informações diferentes / mais detalhadas no despejo forense, já que tenho a depuração habilitada em meu cmdline.txt, de acordo com meu post anterior)

Eu fui em frente e despejei o conteúdo das outras coisas de / sys / kernel / debug também. Aqui está: https://pastebin.com/pdFUPBxN

No último congelamento do wlan, o rastreamento de log do kernel parece ser mais detalhado. Veja o link:
https://pastebin.com/KTxbgpYV

Espero que ajude.

Houve mais detalhes na análise forense do firmware? Eu acho que é o
bit Cypress está realmente interessado em quando ocorre o erro na caixa de correio.

Em 31 de agosto de 2017 às 21:56, randyoo [email protected] escreveu:

No último congelamento do wlan, o rastreamento de log do kernel parece ser mais detalhado.
Veja o link:
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 ajude.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Certo, desculpe. Consegui obter uma captura da perícia e, sim, parece haver muito mais detalhes lá:
https://pastebin.com/qypfAfAp

Como às vezes ajuda em novos casos, eu também recebo de vez em quando:

pi @ jempi : ~ $ grep "brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012" / var / log / syslog
14 de agosto 22:16:23 kernel jempi: [501.247242] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
17 de agosto 20:26:20 kernel jempi: [509.684277] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
24 de agosto 23:57:37 kernel jempi: [573.652189] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
29 de agosto 23:50:16 kernel jempi: [5052.517999] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
30 de agosto 00:02:18 kernel jempi: [170.978988] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
30 de agosto 23:58:03 kernel jempi: [8254.502431] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
2 de setembro 00:33:28 kernel jempi: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012

Estou usando o wi-fi interno (wlan0) como AP e conectei um dongle (wlan1) para me conectar ao meu roteador:
pi @ jempi : ~ $ ifconfig wlan0
wlan0 Link encap: 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 Escopo: Link
UP BROADCAST RUNNING MULTICAST MTU: 1500 Métrica: 1
Pacotes RX erros: 0 descartados: 0 overruns: 0 frame: 0
Pacotes TX erros: 0 descartados: 0 ultrapassagens: 0 portadora: 0
colisões: 0 t xqueuelen: 1000
Bytes RX bytes TX

pi @ jempi : ~ $ ifconfig wlan1
wlan1 Link encap: 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 Escopo: Link
UP BROADCAST RUNNING MULTICAST MTU: 1500 Métrica: 1
Pacotes RX erros: 0 descartados: 2 saturações: 0 quadro: 0
Pacotes TX erros: 0 descartados: 0 overruns: 0 portadora: 0
colisões: 0 t xqueuelen: 1000
Bytes RX Bytes TX

Eu tinha o kernel 4.9.35-v7 + e atualizei ontem para 4.9.46-v7 + (com rpi-update), mas não ajuda. Entrada do syslog quando ele falha:

2 de setembro 00:33:28 kernel jempi: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
2 de setembro 00:34:00 kernel jempi: [6011.624839] brcmfmac: brcmf_netdev_wait_pend8021x: Tempo limite esgotado à espera de nenhum pacote 802.1x pendente
2 de setembro 00:34:02 kernel jempi: [6014.184823] brcmfmac: send_key_to_dongle: erro wsec_key (-110)
2 de setembro 00:34:05 kernel jempi: [6016.744833] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON falhou -110
2 de setembro 00:34:06 kernel jempi: [6017.704831] brcmfmac: brcmf_netdev_wait_pend8021x: Tempo limite esgotado ao aguardar nenhum pacote 802.1x pendente
2 de setembro 00:34:08 kernel jempi: [6020.264850] brcmfmac: send_key_to_dongle: erro wsec_key (-110)
2 de setembro 00:34:11 kernel jempi: [6022.824903] brcmfmac: brcmf_cfg80211_change_station: Configuração de SCB (des) autorizar falhou, -110

Reinicie a interface wlan0 com sudo ifconfig wlan0 para baixo e depois para cima não ajudou.

@bulrog Forneça também a
Qual driver wlan1 usa? Esse problema ainda ocorre com o dongle desconectado?

Mais algumas capturas forenses:
https://pastebin.com/vqh3UcF3

Caso isso ajude o Cypress a procurar na área certa: Eu experimentei esse problema muitas e muitas vezes agora, e parece se manifestar sempre que um dispositivo tenta se conectar. Isso aconteceu muitas vezes depois de entrar no alcance do AP ou quando um dispositivo em espera é ativado.

Eu mantive essa configuração por tempo suficiente para capturar a perícia e se houver mais detalhes que eu possa fornecer, ficaria feliz em fazê-lo, mas as falhas de wlan agora estão acontecendo com tanta frequência que torna meu dispositivo inútil. Pretendo usar outro dongle wi-fi USB para substituir o rádio interno, a fim de obter confiabilidade.

Passei seus exames forenses mais recentes para a Cypress - obrigado por dedicar seu tempo.

Só queria entrar na conversa. Tenho exatamente o mesmo problema em três RPI3s executando o firmware mais recente. Estou usando Octopi em todos os três e acessando-os via Printoid.

bcrmfmac.debug deve ser brcmfmac.debug (obrigado por identificar @MilhouseVH)
Vou editar as postagens anteriores.

bcrmfmac.debug deve ser brcmfmac.debug (obrigado por identificar @MilhouseVH)
Vou editar as postagens anteriores.

Com base nisso, presumi que a perícia que capturei não estava completa.

Repeti a captura forense, ela pode ser lida no seguinte URL:
https://pastebin.com/ha5rd7SW

Além disso, meu arquivo /var/log/kern.log tem quase 200 MB, a maior parte dele consistindo de entradas muito semelhantes. Localizei o erro da caixa de correio em 00:53:19 e cortei alguns segundos antes e depois do erro. Espero que ajude, veja aqui:
https://pastebin.com/JcE0zstS

então acho que encontrei o mesmo problema, consulte https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=192735

posso reproduzi-lo em 5 minutos. Você precisa de uma grande quantidade de tráfego por wi-fi (interface da web da câmera) e um sinal wi-fi muito baixo. Eu tenho pi zero e é o suficiente para colocar seus dedos / mãos ao redor da antena onboard para obter o sinal quase zero (meu roteador mostra sinal de 15-20%). Após cerca de 1 minuto neste estado, o wi-fi falha

@lategoodbye depois de uma semana https://pastebin.com/77tGfRcU

para wlan1, usei um dongle bem antigo. Não consigo me lembrar qual driver eu tive que instalar para fazê-lo funcionar, mas isto é o que lsusb dá para o HW que eu uso:

Dispositivo de barramento 001 005: ID 0 cde: 0008 Adaptador sem fio Z-Com XG-703A 802.11g [Intersil ISL3887]

Não sei se isso ajuda, mas aqui está minha experiência:

Comprei um Pi3 e testei por alguns dias com wi-fi interno (não muito longe do AP), e parecia funcionar muito bem (não esperava altas taxas de bits, só deveria ser útil para um shell remoto via ssh )

Depois de colocá-lo em uma caixa de alumínio, ele ainda parecia ok primeiro, mas o wi-fi continuou se tornando inutilizável aleatoriamente. Até minutos sem nenhum ping. Ainda houve ocasiões em que funcionou muito bem por alguns segundos, mas mudou para a experiência de "um toque de tecla por segundo" novamente ou parou de funcionar completamente.

Parece que não há nenhuma conexão "lenta, mas utilizável" possível, apenas uma "muito boa" ou "inutilizável". Isso pode ser devido a um bug no firmware. Não tenho ideia e, francamente, perdi a paciência e uso um dongle USB muito pequeno, que funciona 100% estável.

Alguém encontrou uma solução alternativa para detectar o problema (no modo AP) e redefinir programaticamente o dispositivo wlan?

Não que eu tenha visto, reiniciar a interface não ajudou. Pra mim a contenção foi comprar um dispositivo wi-fi usb externo e funciona que é um encanto mas é uma pena pois agora desliguei o wi-fi do pi (suspiro!)

Você quer dizer o problema da caixa de correio? Isso ainda está sob investigação na Cypress.

Em 21 de setembro de 2017 08:38, "morel jerome" [email protected] escreveu:

Não que eu tenha visto, reiniciar a interface não ajudou. Para mim a contenção
era comprar um dispositivo USB wi-fi externo e funciona perfeitamente, mas é
uma pena como agora desliguei o wi-fi do pi (suspiro!)

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no 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= ,
ou silenciar o tópico
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=
.

Sim, o problema da caixa de correio. Espero que seja corrigido, mas como contenção tive que mudar para um dispositivo externo.

ESTÁ BEM. Estamos à mercê da Cypress neste caso - é um problema de firmware e eles são os únicos com acesso. Vou continuar a lembrá-los ... podemos precisar de mais análises forenses, mas postaremos aqui se for o caso.

meu wlan se desconecta e se reconecta após alguns segundos de inatividade (presumo que seja uma economia de energia, embora eu tenha desativado com iw, ou talvez interferência). Não tenho certeza se este é o mesmo problema discutido aqui (já que ele se reconecta imediatamente).

Se eu conectar com ssh -o ServerAliveInterval 5 ... ele não se desconectará mais.

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

@asssaf ,
Não é o problema, se ele fosse reconectado geralmente seria apenas um problema de latência, mas ao executar sem controle sobre WiFi (um dos principais recursos potenciais do PiZero-W) quando o WiFi cai e não reconecta automaticamente, o sistema travou para todos os fins práticos.

Mesmo se eu tiver HDMI, mouse e teclado sob cargas pesadas de rede, como o Motioneye, às vezes a única maneira de recuperar é desligar e ligar.

Repeti a instalação e configuração do Motioneye em um Pi2 com um dongle WiPi USB WiFi e até agora funcionou perfeitamente com cargas que desligaram o PiZero-W em poucas horas. Para mim, isso parece confirmar que é um problema de chip / driver WiFi e não um problema com Raspbian-stretch.

@ PeterTheMaster1 @randyoo @joshfria

OK, mensagem para quem vê o problema da caixa de correio regularmente e pode testar algo para mim

Temos um firmware de diagnóstico da Cypress, que pode ajudar a rastrear o problema. Se alguém com o problema da caixa de correio estiver disposto a executar este firmware, e quando o problema da caixa de correio ocorrer, descarte a perícia e poste os resultados aqui, isso será de grande ajuda. Observe que este firmware não deve ser usado para mais nada além deste teste, pois será 'não ideal'! Comente aqui se você está conseguindo fazer o teste, e entrarei em contato com o firmware e instruções.

@iurly : Eu escrevi um script que detectaria o problema, e então reinicie, já que trazer a interface para baixo e para cima não ajudou ... Mas ele estava reiniciando com tanta frequência, que eu só conseguia um dispositivo útil pegando fora do modo AP (e atribuindo funções de AP ao meu dongle USB)

@ JamesH65 :

Sim, novo firmware da Cypress na segunda-feira, 25 de setembro. Tem mais
diagnósticos nele. Os exames forenses anteriores que você forneceu restringiram
o problema, eles precisam de um pouco mais de detalhes. Estou operando uma máquina
por 24 horas até agora sem nenhum erro de caixa de correio, portanto, atualmente não é possível replicá-lo
Eu mesmo.

Você pode me enviar um e-mail no James. [email protected] e posso enviar o firmware para você. Não quero divulgá-lo de forma mais global porque é apenas para fins de teste.

Em 27 de setembro de 2017 às 14:48, randyoo [email protected] escreveu:

@iurly https://github.com/iurly : escrevi um script que detectaria
o problema e, em seguida, reinicie, desde a desativação e ativação da interface
não ajudou ... Mas estava reiniciando com tanta frequência, que eu só pude obter um
dispositivo útil tirando-o do modo AP (e atribuindo funções de AP ao meu
Dongle USB)

@ JamesH65 https://github.com/jamesh65 : Ficarei feliz em ajudar, pois
antes. É uma nova versão do firmware de diagnóstico? Eu postei um
captura forense há 3 semanas (nesta página do problema) usando o
firmware de diagnóstico / depuração postado anteriormente nesta página.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332526471 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHW_vEVuxFD-9RuxE003QZc_2NoFaks5smlIjgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

@ JamesH65 Se você tiver a gentileza de fornecer um link para o novo firmware, posso instalá-lo e tentar capturar o forense novamente, conforme solicitado.

Infelizmente, fornecer um link aqui significa que ele está disponível publicamente e
já que se trata de um firmware de teste, prefiro que não escape para
o selvagem. Daí o pedido para fazer via e-mail. Se isso for um problema, farei upload
em algum lugar e pode postar um link.

Em 27 de setembro de 2017 às 15:56, randyoo [email protected] escreveu:

@ JamesH65 https://github.com/jamesh65 Se você pudesse fazer a gentileza de
fornecer um link para o novo firmware, posso instalá-lo e tentar capturar
forense novamente, como você solicitou.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332548884 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHbVhHD2rk_hp3kG51WBY0R0IQzL3ks5smmIbgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

@ JamesH65 Sei que congela regularmente a placa wireless interna do RPI3 no modo AP, então estou mais do que disposto a ajudar, mas não tenho certeza se é o problema da caixa de correio ou outra coisa. Na verdade, procurei em meus logs por essa mensagem, mas não a encontrei.

Estou executando o firmware fornecido com o kernel 4.4.50 (e realmente não consigo atualizar para o 4.9 mais recente devido a uma regressão, consulte # 2197), essa versão mostraria essa mensagem ou ela foi adicionada em um estágio posterior?

Obrigado!

@iurly você disse uma coisa certa, o problema de travamento nos drivers da broadcom ocorre no modo AP, e não sei se isso está relacionado ao erro da caixa de correio. parece que há mais de 1 bug aqui, talvez seja algum bug de hardware devido ao tempo em que o problema existe e nenhuma solução foi encontrada.

O que realmente me incomoda é a falta de uma solução alternativa, exceto reiniciar o sistema inteiro.
Quer dizer, não há nem mesmo uma maneira de redefinir o periférico e reiniciar o hostapd?!?

@iurly você disse uma coisa certa, o problema de travamento nos drivers da broadcom ocorre no modo AP, e não sei se isso está relacionado ao erro da caixa de correio. parece que há mais de 1 bug aqui, talvez seja algum bug de hardware devido ao tempo em que o problema existe e nenhuma solução foi encontrada.

Apenas para sua informação, estou tendo problemas no modo cliente / estação também. Rodando LEDE mestre, kernel 4.9 e usando firmware 7.45.41.46.

@ JamesH65
Entenda o desejo de evitar que o firmware de teste seja publicado. Tudo bem com e-mail, mas também não quero postar meu endereço aqui publicamente e não vejo uma maneira de enviar mensagens no github.

Use meu endereço pi acima para me enviar um e-mail e eu lhe enviarei o firmware.

Ré. Modo Ap
Houve algumas correções desde 4.4, então vale a pena tentar o trecho mais recente
para ver se esse problema ainda ocorre.

Ah, quando você edita um comentário, nenhuma atualização de e-mail é enviada, e eu editei meu e-mail Pi para a entrada acima, então você pode não ter sido atualizado. Use o site do github para ver onde você precisa me enviar um e-mail.

@ JamesH65 Enviou um e-mail para você. Fico feliz em saber que a captura forense anterior ajudou a reduzi-lo, pelo menos ... Parece que muitas pessoas ficarão satisfeitas quando esse problema for resolvido.

@ JamesH65
Aqui está uma captura forense do firmware que você enviou por e-mail: https://pastebin.com/zdB36ttj
Espero que ajude.

Incrível, vou passar para o Cypress. Obrigado por fazer isso.

Eu tenho um pi em uma configuração agora onde parece que posso reproduzir isso à vontade. Se coletar mais análises forenses for útil, me avise. O erro da caixa de correio é tudo o que posso ver nos logs.

Depois de substituir o microSD em meu Zero W, ele ficou conectado por 7 dias sem problemas. Não acho que tenha sobrevivido tanto tempo. Parece estranho que um cartão SD possa influenciar o WiFi, mas como ambos estão conectados ao barramento SDIO, é possível que um influencie o outro.

O cartão que usei antes era um (provavelmente barato) 8GB Transcend classe 4 que veio com minha placa UDOO Quad. Agora é um Samsung EVO de 32 GB. As pessoas que estão tendo problemas podem querer tentar se usar um cartão diferente ajuda.

@stintel Interessante, mas talvez tenha sido algum problema ao configurar o software no outro microSD, ou até mesmo um microSD danificado.

Isso poderia estar relacionado ao poder? Talvez o cartão barato extraiu momentaneamente muita energia do ônibus?

Eu carreguei o firmware postado da Pelwell e vi uma ENORME melhoria. Antes, um SSH para meu Pi 0W era como discar para um terminal com um modem de 2400 bauds e uma linha telefônica ruim. Agora, posso executar o X remoto e funciona muito bem.

Obrigado!

Eu tenho o mesmo problema. Ao transferir uma grande quantidade de nomes de arquivos (sync-over-ftp) de raspberryPi3-internal-wi-fi para o wi-fi Galaxy S5 pare de funcionar. mas às vezes funciona ...

Tive o mesmo problema de mensagem de caixa de correio com meu RPi3 WiFi AP, mas encontrei uma solução neste fórum e funcionou para mim. A solução foi alterar os seguintes parâmetros em /etc/hostapd/hostapd.conf

wpa = 3 alterado para wpa = 2auth_algs = 3 alterado para auth_algs = 1

Eu testei por 1 semana e ele não mostra mais problemas de caixa de correio.

Não tenho certeza se funcionaria para todos vocês, mas você pode tentar e postar aqui se funcionar.

Este é o hostapd funcional, 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

Alguma atualização sobre este problema? Ou existe alguma solução alternativa conhecida?

Ainda experimentando isso em um Pi Zero W comprado recentemente com os últimos stretch-lite e rpi-update de ontem.

Usando o RPi para transmitir um feed de câmera via RTSP (udp), posso ver que a conexão piorou drasticamente antes de a conexão WiFi ser cortada, depois disso a conexão WiFi nunca foi recuperada e eu tenho que desligar e ligar o Pi0W.

A dmesg > dmesg.log mostra apenas:

brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Se eu mover o Pi0W para mais perto do meu ponto de acesso, o problema não ocorre.

Não estou usando o Pi0W como ponto de acesso, é apenas um cliente. Tentei diferentes fontes de energia.

No momento, estamos esperando pela Cypress, a fornecedora do chip sem fio,
para avançar o problema. Vou mandar um ping novamente.

Em 25 de outubro de 2017 às 14:02, Matthias Urhahn [email protected]
escrevi:

Alguma atualização sobre este problema? Ou existe alguma solução alternativa conhecida?

Ainda experimentando isso em um Pi Zero W comprado recentemente com o
stretch-lite e rpi-update a partir de ontem.

Usando o RPi para transmitir um feed de câmera via RTSP (udp), posso ver o
a conexão piorar drasticamente antes de a conexão WiFi ser interrompida,
depois disso, a conexão WiFi nunca mais se recupera e tenho que desligar e ligar
Pi0W.

Um dmesg> dmesg.log mostra apenas:

brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012

Se eu mover o Pi0W para mais perto do meu ponto de acesso, o problema não ocorre.

Não estou usando o Pi0W como ponto de acesso, é apenas um cliente. eu tentei
diferentes fontes de energia.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-339322153 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHRlPhJBGXc3JFWbpw_Tf4_EKmgAeks5svzFQgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Bem ... Eu atualizei para o kernel / firmware mais recente (apt-get upgrade e rpi-update), e agora, até mesmo meu Pi3 que tinha um wi-fi sólido como rocha também está perdendo depois de algumas horas !! Eu sei, se não quebrou não conserta ... não deveria ter atualizado, mas como faço testes de vez em quando no meu 2º Pi3 com o mesmo cartão SD ..

FWIW, também posso reproduzir esse problema à vontade. Criei uma postagem no fórum no Raspberry Pi que explica o problema:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=196018&p=1226143#p1226143

NOTA: Não estou usando o Pi como AP. Posso ajudar na perícia ou no teste de um firmware experimental, etc., se isso ajudar.

Mesmo problema aqui. Eu configurei o ownCloud e posso transferir arquivos do meu laptop sem nenhum problema.
Mas assim que eu transfiro arquivos com meu Wi-Fi Samsung Galaxy S7 quebras e
raspberrypi kernel: [ 962.273390] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012 :
parece.

Meu roteador é um FRITZ! Box 7490.

Obrigado @srinathava pelo post que descreve bem o meu problema!

As pessoas que testaram com o firmware de teste podem tentar o seguinte - mais informações de depuração exigidas pelo Cypress.

1. ao fazer insmod, adicione "debug = 0x100000"
2. assim que o problema acontecer, salve a saída "dmesg"

Obrigado.

Outro pedido de ajuda neste.

As pessoas que testaram com o firmware de teste (veja acima) podem tentar o seguinte - mais informações de depuração exigidas pelo Cypress.

ao fazer insmod, adicione "debug = 0x100000"
assim que o problema ocorrer, salve a saída "dmesg" - esta é a parte em que estamos interessados.

Obrigado.

@ JamesH65 Só para avisar, estou tentando coletar as informações, mas o problema ainda não

Obrigado pela ajuda sobre este assunto.

Seria interessante ver as mudanças que você fez no hostapd se, de fato, isso contornar o problema.

Após 4 dias de estabilidade, reverti minhas alterações no arquivo /etc/hostapd/hostapd.conf e, após apenas algumas horas, o problema voltou a ocorrer. Aqui está a saída do 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

Estou executando um pacote de software chamado RaspAP e tenho quase certeza de que configurou o arquivo hostapd.conf em meu nome, embora não tenha 100% de certeza.

De qualquer forma, comentando esta linha em /etc/hostapd.conf: e substituindo-o por este: Tive uma operação estável por 4 dias seguidos, mas costumava travar em algumas horas, ou às vezes até minutos!

Espero que tudo isso ajude.

Desculpas se eu estiver postando no lugar errado, estou tendo um comportamento estranho com o wlan interno RPi3 (broadcom) ao enviar pacotes UDP Unicast sob o raspbian.
Eu envio um pequeno pacote de dados de 2kb uma vez por segundo, no final do receptor, ele é bloqueado a cada 120 segundos por cerca de 3-4 segundos. Este teste funciona como um relógio, e posso reproduzir com iperf fazendo o seguinte

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

Ubuntu PC conectado como cliente WiFi ao RPi3 (IP 192.168.1.22 como acima)

iperf -u -s -i 1

Bloqueio garantido a cada 120 segundos. Interessante, isso não parece ocorrer usando TCP
Finalmente, tendo baixado e olhado o código do driver (e não entendendo nada), notei uma menção suspeita de

definir BRCMF_SCAN_PASSIVE_TIME 120

Que é então usado no código do driver

isso poderia estar relacionado, estou no meu fim de juízo tentando resolver?
THX

Coloquei o seguinte em /etc/rc.local e o meu parece estar funcionando muito melhor:

Iwconfig wlan0 desligado

PI zero w

Sean

Em 19 de dezembro de 2017, às 03h42, LeeMooreImperas [email protected] escreveu:

Desculpas se eu estiver postando no lugar errado, estou tendo um comportamento estranho com o wlan interno RPi3 (broadcom) ao enviar pacotes UDP Unicast sob o raspbian.
Eu envio um pequeno pacote de dados de 2kb uma vez por segundo, no final do receptor, ele é bloqueado a cada 120 segundos por cerca de 3-4 segundos. Este teste funciona como um relógio, e posso reproduzir com iperf fazendo o seguinte

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

Ubuntu PC conectado como cliente WiFi ao RPi3 (IP 192.168.1.22 como acima)

iperf -u -s -i 1

Bloqueio garantido a cada 120 segundos. Interessante, isso não parece ocorrer usando TCP
Finalmente, tendo baixado e olhado o código do driver (e não entendendo nada), notei uma menção suspeita de

definir BRCMF_SCAN_PASSIVE_TIME 120

Que é então usado no código do driver

isso poderia estar relacionado, estou no meu fim de juízo tentando resolver?
THX

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Oi sean
Obrigado pelo aviso, infelizmente, isso não é aceito pelo dispositivo da broadcom, eu recebo

Error for wireless request "Set Power Management" (8B2C) 
    Set failed on device wlan0; Invalid argument

No entanto, eu uso o seguinte comando em minha configuração para atingir o mesmo objetivo
$ iw dev wlan0 set power_save off
isso é aceito e se eu consultar as configurações
$ iwconfig wlan0
Eu vejo
Power Management:off

Portanto, tenho certeza de que a economia de energia está desligada, mas não resolve este problema
THX

@LeeMooreImperas Eu sugiro abrir um problema separado para isso e fornecer pelo menos a versão do Kernel e a versão do firmware Wifi.

Eu comentei sobre este tópico há muito tempo, mas então tive que parar de olhar para ele porque não era mais capaz de reproduzi-lo. Bem, eu tenho alguns dados novos e acho isso muito interessante.

Eu tenho dois Raspberry Pi; um B + V1.2 e um Raspberry PI (C) 2011 original.

Se eu executar "4.1.19+ # 858 Tue Mar 15 15:52:03 GMT 2016" no RaspPi B +, o chip Edimax WiFi exibirá o problema que outros viram.

Se eu executar "4.9.27+ # 1 Thu May 11 17:40:53 UTC 2017" no mesmo RaspPi B +, o mesmo chip WiFi Edimax não mostrará o problema.

Agora estou me perguntando se é mais uma incompatibilidade com o hardware e também sou lembrado de que com placas RaspPi muito mais antigas, o WiFi USB precisava de um cabo especial para aumentar a potência de + 5V porque a potência que vinha da placa não era t o suficiente para conduzi-lo. Vou trocar os cartões SD de volta para que exibam o problema e ver se esse tipo de cabo ajuda.

Ok, acho que entendi incorretamente.

Executar 4.9.27+ no RaspPi mais antigo exibirá o problema. Verificando agora.

Ok, isso é definitivo e muito interessante.

Usando uma placa Raspberry Pi original (por volta de 2011) e executando o Linux 4.9.27+ (de "uname -a"), posso reproduzir o problema do chip Edimax USB WiFi perdendo a conexão WiFi e, portanto, o endereço IP, todas as vezes , dentro de alguns minutos.

Usando a mesma placa Raspberry Pi original e a mesma versão do Linux, mas a ÚNICA mudança de simplesmente usar um cabo USB que me permite aumentar o + 5V para o WiFi USB de uma fonte secundária, o sistema é estável.

Portanto, definitivamente parece haver um problema com a placa WiFi USB Edimax não obtendo energia suficiente nesta configuração. Isso, obviamente, não ajuda quem está usando um Raspberry Pi com Wi-Fi embutido, mas nesses casos eu me pergunto se talvez um problema semelhante esteja acontecendo e se talvez a mudança para um adaptador USB que produza mais amplificadores possa mostrar uma diferença?

É possível que o adaptador de rede para USB que alimenta o Pi não esteja fornecendo 5 V limpos em alguns casos.
Já que o AC tem que ser regulado e então suavizado antes de se tornar 5 V, mas você ainda tem um pouco de ondulação na saída DC.
O 5V de um laptop ou PC é mais provável de ser livre de ondulações do que um carregador de rede elétrica para USB barato

Seria interessante colocar um osciloscópio na fonte de alimentação do chip wi-fi sob diferentes condições para ver como é a ondulação durante falha / não falha

Por favor, mantenha este problema com os problemas com o chip sem fio ONBOARD Brcm no Pi3 - se você tiver problemas com outros dispositivos, use o fórum para obter conselhos. Isso é simplesmente para que as informações que precisamos passar ao Cypress não fiquem muito confusas.

@ JamesH65
@lategoodbye

Olá James, Stefan,
Portanto, mensagens conflitantes aqui, o problema que registrei estava diretamente relacionado ao RPi3 BRCM WiFi.
Então, isso deve ir em um tópico diferente (como sugerido por lategoodbye)?
Eu teria pensado que este tópico é especificamente sobre o meu problema.

Estou feliz em mover o problema

THX

@LeeMooreImperas Embora o seu problema seja com o wireless onboard, o seu é uma pausa a cada 2 minutos, este problema descreve uma falha completa de travamento wireless que acontece em intervalos aleatórios, então parece que não está relacionado. Portanto, pode valer a pena criar outro problema. Infelizmente, fui um pouco vago na minha mensagem anterior.

Adicionando outro "eu também" sobre isso.
Hardware: Raspberyy Pi 3, Modelo B.
Kernel: Linux raspberrypi 4.9.70-v7 +
SO: Raspbian GNU / Linux 9 (extensão)
Imagem carregada: 2017-11-29-raspbian-stretch.img
Image MD5:
SDCard: não tenho certeza do fabricante, ele veio com o kit
Arquivo de interfaces :
hostapd.conf: hostapd.txt
Saída dmesg (durante o trabalho): dmesg_20171230.txt

O dispositivo está configurado como um ponto de acesso para minha rede sem fio. Meu roteador principal é um firmware Linksys EA6400 versão 1.1.40 (compilação 184085). Tanto o Linksys quanto o Pi estão oferecendo o mesmo SSID em canais diferentes. Pi é conectado ao roteador por meio de uma conexão com fio com um switch não gerenciado no meio.
A carga do SO no dispositivo é bastante recente. Eu tinha uma imagem RetroPie no sistema e enfrentei os mesmos problemas. Eu recarreguei no Raspbian para ver se funcionava melhor.
Estou vendo abandonos esporádicos da ponte. O principal sintoma é que a rede sem fio fornecida pelo Pi parece ficar isolada da rede com fio. A interface com fio continua a funcionar normalmente e posso alcançar o Pi via SSH. Se eu executar um tcpdump na interface wireless (wlan0), enquanto estiver nesse estado, ainda posso ver o tráfego de e para os dispositivos conectados.
Reiniciar a conexão sem fio (ifdown; ifup) não parece resolver o problema. Ainda não tentei desligar e religar a interface da ponte (br0). Em geral, tenho reiniciado o dispositivo, o que corrige o problema.
Não tenho certeza se está relacionado; no entanto, o problema parece surgir quando tento controlar meu ChromeCast 2 depois que ele está em execução há algum tempo. Por exemplo, se estou fazendo um show via Netflix no ChromeCast e tento pausar o show, a ponte parece cair naquele momento. Eu não consegui pegar isso via tcpdump ainda; mas, esse é um próximo passo para mim.
Eu considerei que pode ser um problema de calor; entretanto, eu tinha /opt/vc/bin/vcgencmd measure_temp em execução em um loop de 30 segundos durante uma das interrupções e a temperatura da minha cpu estava na faixa de 50 ° C. Não tenho certeza de como obter uma leitura de temperatura no chip LAN, pois pode ser onde um problema de calor está surgindo.

Terei prazer em capturar logs / pcaps conforme necessário para ajudar a solucionar o problema posteriormente. Porém, seja explícito nas instruções, pois tenho algumas lacunas no meu conhecimento sobre Linux.

EDITAR: acabei de desistir e fiz sudo ifdown br0 && sudo ifup br0 e parece ter começado a funcionar novamente. Vou testar novamente no meu próximo abandono.

EDIT2: Aqui está um despejo dmesg com a conexão falhou. O sudo ifdown br0 && sudo ifup br0 não pareceu recuperar a conexão desta vez.
dmesg_20171220_failed.txt
De particular interesse parece ser o erro:
brcmfmac: brcmf_cfg80211_stop_ap: configuração do modo INFRA falhou -7

EDIT3: Encontrei este tópico sobre um problema semelhante que se referia a este tópico. Executou a alteração solicitada no módulo brcmfmac para habilitar a depuração. Teve o gatilho de falha e capturou a saída dmesg:
dmesg_debug_failed.txt
Além disso, notei a menção de um telefone Samsung no outro tópico. Notamos que os problemas de ponte com meu Pi parecem girar em torno do meu Samsung Galaxy S7. Os dispositivos Apple de minha esposa (iPhone e iPad) não parecem desencadear o problema.

EDIT4: Executou um sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000 seguido por dmesg novamente. Resultado abaixo:
dmesg_debug_failed_reset_driver.txt

Hmm, não o erro de caixa de correio esperado. Vou repassar aos desenvolvedores do Cypress no ano novo.

Não tenho certeza se este é o mesmo problema, mas meu sintoma é intermitente wireless onboard RPi3; 10 segundos de pings bons, seguidos de 20 a 30 segundos sem pings, e repita para sempre. Quando não há pings, o host remoto recebe as solicitações de eco ICMP e envia as respostas de eco ICMP. O ponto de acesso retorna o host ICMP inacessível para o host remoto.

A pré-condição é Ethernet e sem fio conectadas. A chance de isso acontecer melhorou muito reiniciando desnecessariamente dhcpcd .

A solução alternativa é definir a interface de rede para o modo promíscuo; sudo ifconfig wlan0 promisc . O sintoma retorna dentro de dez segundos a um minuto de sudo ifconfig wlan0 -promisc .

Mais informações disponíveis, se necessário, basta perguntar.

@ Sylver-Dragon, para mim um tcpdump evitou o sintoma, e talvez você tenha encontrado o mesmo; tente o sinalizador -p , que desativa o modo promíscuo; ele deixou o sintoma continuar.

https://github.com/iiab/iiab/issues/638

@quozl Eu tentei executar o tcpdump na interface wireless e na interface bridge e travou enquanto ele estava em execução. Vou dar uma chance ao modo promíscuo e ver se faz diferença. Porém, com base na saída de depuração do driver de interface sem fio, especificamente:
wl0: _wlc_bss_update_beacon: out of mem, 0 bytes malloced
Suponho que seja algum tipo de vazamento de recurso (memória?) Por parte do driver. Quando eu tiver um pouco mais de tempo, quero fazer uma captura de pacote e me aprofundar no momento em que ele travou. Suspeito que meu telefone está enviando algum tipo de pacote estranho ou malformado ou série de pacotes ao dispositivo que está acionando o travamento. Se eu puder capturar e isolar isso, isso ajudará a informar a correção.

Parece uma falha diferente do problema da caixa de correio que estamos rastreando no momento. O que é irritante. O seu telefone é um Samsung BTW? O problema da caixa de correio parece ser acionado com mais frequência por dispositivos SS. Se você puder rastrear o que está causando os problemas, isso seria muito útil

Estou caçando o mesmo (?) Há semanas. Acho que devo ter lido todos os relatórios sobre este e outros assuntos semelhantes. Então aqui estão mais algumas informações minhas:

Eu uso o wi-fi interno de um raspberry pi 3 como ponto de acesso. Eu uso o kernel e módulos raspbian padrão (Linux versão 4.9.35-v7 + (dc4 @ dc4-XPS13-9333) (gcc versão 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) # 1014 SMP Fri Jun 30 14:47:43 BST 2017).

O firmware do Wifi é: brcmfmac: versão do firmware = wl0: 7 de agosto de 2017 00:46:29 versão 7.45.41.46 (r666254 CY) FWID 01-f8a78378

Tenho quase certeza de que essa configuração de hardware funcionava, mas depois de algumas atualizações (também do kernel), acredito, as coisas deram errado. Criar o AP funciona bem, mas depois de usá-lo por algum tempo (30 minutos ou mais, não é o mesmo sempre, eu acho), fazendo streaming usando um Chromecast, a conexão para de funcionar. Pode ser (mas aqui não tenho certeza) que isso aconteça com mais frequência quando eu pauso / paro o stream, mas apenas raramente no meio da exibição. Quando ele falha, as conexões existentes são interrompidas e novas tentativas de conexão não são aceitas por nenhum cliente. O recarregamento do hostapd resulta em brcmf_cfg80211_stop_ap: setting INFRA mode failed -7 (não é possível definir o modo como mestre). Isso pode ser corrigido temporariamente recarregando o driver: rmmod brcmfmac; modprobe brcmfmac . As coisas funcionam conforme o esperado novamente até que falhe na próxima vez. Como alternativa, uma reinicialização "corrige" o problema também.

A única coisa que recebo no estado de falha (com depuração habilitada) no syslog é:

kernel: [3615.491795] brcmfmac: brcmf_netdev_wait_pend8021x: Tempo limite esgotado à espera de nenhum pacote 802.1x pendente
hostapd: wlan0: STA xx: xx: xx: xx: xx: xx IEEE 802.11: desautenticado devido à solicitação local de desautorização

Essa mensagem de erro não faz sentido para mim. Ele está expirando enquanto espera 'por nenhum pacote pendente'? De qualquer forma:

Eu tenho economia de energia desligada:

iw wlan0 get power_save Power save: off

roam_off é definido como 1 e a depuração está habilitada:

`systool -a -v -m brcmfmac
Módulo = "brcmfmac"

Atributos:
coresize = "222874"
initsize = "0"
initstate = "ao vivo"
refcnt = "0"
srcversion = "10E8F4629D109E78E1F506C"
taint = ""
uevent =

Parâmetros:
alternativa_fw_path =
debug = "1048576"
roamoff = "1"
`

Não tenho um telefone Samsung, mas alguns Android. Nenhum deles está conectado a esse ponto de acesso. Os únicos clientes diretos são dois Chromecasts (um vídeo, um apenas áudio e um Tablet Android). Todo o resto vem por meio da interface com fio.

@knarrff
Por favor, procure nesta página meu comentário anterior de 3 semanas atrás para uma boa solução alternativa.

@ JamesH65
Nunca recebi um ack de você. Você copiou / retransmitiu a saída do dmesg que compartilhei desse comentário há 3 semanas para os caras do Cypress?

@randyoo : Eu tenho "rsn_pairwise = CCMP" e "wpa = 2" no meu hostapd.conf. Não ajuda no meu caso. Entradas não secretas de meu arquivo:
`
interface = wlan0

driver = 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
`

Também fica claro que a falha sempre parece acontecer para mim quando tento pausar um stream do netflix para o Chromecast (o que não significa que sempre falha quando tento isso, apenas que sempre que falha, era o que eu estava fazendo ) Por outro lado, isso pode ser uma pista falsa, pois é o que eu faço quase todo o tempo com essa rede wifi. Pode ser que o problema ocorra simplesmente quando um dispositivo tenta se autenticar no AP (como o tablet Android que provavelmente desativou o wi-fi durante o sono). Mais testes serão mostrados. Vou tentar sem o Chromecast - apenas wi-fi normal no tablet, incluindo ciclos de wi-fi-hibernação.

Parece que meu problema não é igual a este, então vou mudar para o modo oculto. Meu ifconfig wlan0 promisc corrigiu isso para @holta (https://github.com/iiab/iiab/issues/638), mas sem que isso ajude ninguém, devemos estar olhando para um problema diferente.

Posso reproduzir isso de forma confiável sem Netflix ou Chromecast conectando-me à rede via tablet do Google, depois deixe o tablet dormir, retome (o tablet tenta se reassociar) e, nesse momento, o AP está "morto".

Em uma máquina Linux, recebo estes no syslog ao tentar associar (usando as credenciais corretas):

`

[42231.476518] wlan7: enviar autenticação para b8: 27: eb: 33: 98: 14 (tente 1/3)
[42231.583434] wlan7: enviar autenticação para b8: 27: eb: 33: 98: 14 (tente 2/3)
[42231.694397] wlan7: enviar autenticação para b8: 27: eb: 33: 98: 14 (tente 3/3)
[42231.799368] wlan7: autenticação com b8: 27: eb: 33: 98: 14 expirou
[42236.585750] wlan7: autenticar com b8: 27: eb: 33: 98: 14
[42236.598833] wlan7: enviar autenticação para b8: 27: eb: 33: 98: 14 (tente 1/3)
[42236.602344] wlan7: autenticado
[42236.603480] wlan7: associar com b8: 27: eb: 33: 98: 14 (tente 1/3)
[42236.619322] wlan7: RX AssocResp de b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 auxílio = 1)
[42236.623181] wlan7: associado
[42236.623325] IPv6: ADDRCONF (NETDEV_CHANGE): wlan7: o link fica pronto
[42236.625464] wlan7: Limitando a potência TX a 30 (30 - 0) dBm conforme anunciado por b8: 27: eb: 33: 98: 14
[42239.730365] wlan7: desautenticado de b8: 27: eb: 33: 98: 14 (Razão: 2 = PREV_AUTH_NOT_VALID)
[42241.243434] wlan7: autenticar com b8: 27: eb: 33: 98: 14
[42241.256326] wlan7: enviar autenticação para b8: 27: eb: 33: 98: 14 (tente 1/3)
[42241.260724] wlan7: autenticado
[42241.263403] wlan7: associar com b8: 27: eb: 33: 98: 14 (tente 1/3)
[42241.279537] wlan7: RX AssocResp de b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 auxílio = 1)
[42241.282500] wlan7: associado
[42241.336166] wlan7: Limitando a potência TX a 30 (30 - 0) dBm conforme anunciado por b8: 27: eb: 33: 98: 14
[42244.392213] wlan7: desautenticado de b8: 27: eb: 33: 98: 14 (Razão: 2 = PREV_AUTH_NOT_VALID)
[42253.916626] wlan7: autenticar com b8: 27: eb: 33: 98: 14
[42253.928966] wlan7: enviar autenticação para b8: 27: eb: 33: 98: 14 (tente 1/3)
[42253.936020] wlan7: autenticado
[42253.939533] wlan7: associar com b8: 27: eb: 33: 98: 14 (tente 1/3)
[42253.943361] wlan7: RX AssocResp de b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 auxílio = 2)
[42253.945415] wlan7: associado
[42254.035149] wlan7: Limitando a potência TX a 30 (30 - 0) dBm conforme anunciado por b8: 27: eb: 33: 98: 14
[42257.053762] wlan7: desautenticado de b8: 27: eb: 33: 98: 14 (Razão: 2 = PREV_AUTH_NOT_VALID)
`

b8: 27: eb: 33: 98: 14 é o RPI3 em questão, no qual obtenho novamente as entradas dmesg:
brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets

Não entendo muito bem por que o AP está enviando PREV_AUTH_NOT_VALID enquanto estou aparentemente associado. Tenho a impressão de que a autenticação vem antes da associação. Não deve haver um caso em que eu esteja associado, mas não seja autenticado.

Oi

Estou usando um Pi3 como servidor de mídia, as comunicações são feitas por WiFi on-board

Atualização de atualização Rasbian Stretch Lite 4.9 (agora)
Plex Media Server

Estou entendendo...

kernel: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012

em dmesg e syslog ao se conectar ao Pi usando o cliente BubbleUPnp em um Samsung S5 SM_G900F Android 7.1.2 isso é praticamente garantido e requer uma reinicialização para que o PiWiFi se torne utilizável novamente.

No meu antigo Sony Xperia XP Android 6.0.1 executando novamente o BubbleUPnp, ele funciona bem até agora. Esta é a minha solução. No entanto, se eu puder ajudar em chegar ao fundo disso, terei o prazer de contribuir.

John

Também funciona no iPad com mConnectLite

@johnthesoftwareathome Por favor, escreva um e-mail para James Hughes do Raspberry Pi para que ele possa enviar um firmware de depuração Wifi.

Endereço de e-mail postado através da página de contato do Raspberry Pi por James Hughes

OK, temos um novo firmware de depuração da Cypress com o qual eu gostaria que as pessoas testassem - tem mais depuração, mas não consertos, apenas para aqueles que desejam testar. Se você já me enviou seu e-mail, indique aqui que gostaria de fazer alguns testes e enviarei o firmware, ou entre em contato comigo via PM nos fóruns do Pi.

Para evitar que as pessoas fujam para saber como instalar / executar o novo firmware.

Copie o arquivo de depuração do firmware para:

/lib/firmware/brcm/

(Você vai querer fazer backup do original primeiro)

Acho que você precisa reiniciar neste estágio.

Agora reinicie o driver Linux no modo de depuração

sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000

Faça com que dê errado .. !!

Despeje dmesg para arquivo e poste aqui.

Para aumentar o que James diz, você pode preferir evitar a sequência rmmod / modprobe adicionando brcmfmac.debug=0x100000 a /boot/cmdline.txt .

@ JamesH65 Terei todo o gosto em ajudar no teste. Apesar de ter acabado de me registrar no Pi Forum, não consigo enviar mensagens. Usando o mesmo nome de usuário ali, se isso ajudar.

Experimentei o novo firmware de depuração ontem e também adicionei brcmfmac.debug = 0x100000 a /boot/cmdline.txt.

No entanto, estranhamente, não vi nenhuma saída de depuração no dmesg. Ainda mais estranho, onde eu podia reproduzir o problema de forma confiável antes, funcionou durante toda a noite, independentemente do que eu fizesse. Não tive um único problema e tudo o que fiz de forma diferente foi usar o novo arquivo de firmware (md5 sum ba679a85c1dc76e9775603af45440bc0) em vez do antigo e adicionar a entrada a /boot/cmdline.txt em vez de adicionar a opção usando modprobe. Não tive tempo ontem para voltar ao firmware antigo para ver se isso reverte para os problemas antigos. Vou relatar assim que eu fizer. Nesse ínterim: tudo o que mudou nesse firmware é realmente "mais depurado"?

Eu pensei que era apenas depuração, mas voltarei ao Cypress tão claramente
algo mais mudou, espero que no bom sentido!

Em 11 de janeiro de 2018 às 06:48, Frank Löffler [email protected] escreveu:

Eu tentei o novo firmware de depuração ontem e também adicionei
brcmfmac.debug = 0x100000 para /boot/cmdline.txt.

No entanto, estranhamente, não vi nenhuma saída de depuração no dmesg. Ainda mais
estranhamente, onde eu podia reproduzir o problema de forma confiável antes, funcionou
a noite toda, independentemente do que eu fiz. Eu não tive um único problema, e
tudo o que fiz foi usar o novo arquivo de firmware (soma md5
ba679a85c1dc76e9775603af45440bc0). Não tive tempo ontem para ir
de volta ao firmware antigo para ver se isso reverte para os problemas antigos. eu vou
relatar uma vez que eu fiz. Nesse ínterim: tudo isso mudou nisso
firmware realmente "mais depurar"?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-356842102 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHam4jUgDCkSFxMXS-KW4axCLoPZhks5tJa6fgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Minha experiência foi semelhante à de @knarrf , exceto que eu vi mensagens de depuração no dmesg.

Anteriormente, meu Samsung S5 estava inutilizável como cliente plexserver, mas quando carreguei o firmware de depuração ele funcionou (com, como eu disse, mensagens de depuração no dmesg), então eu reverti para o meu binário original (backup e tamanho verificado) e ainda funciona. Portanto, agora estou executando novamente com o firmware de depuração (não experimentei o mod cmdline.txt, apenas o rmmod / modprobe) e ouvi algumas horas de música sem erros. Tentei ativar a maioria dos muitos dispositivos WiFi que espalhei, mas sem sucesso.

Vou tentar fazer isso por alguns dias para ver se algo acontece, em seguida, recarregue o original e tente novamente. Posso não ter desligado o Pi entre as reinicializações. Vou fazer isso quando voltar para ver se pode ser algum tipo de retenção de registro.

Hoje à noite eu carreguei um firmware mais antigo (tirado de uma imagem de instalação raspian; mais informações sobre as versões que uso abaixo) e recarreguei o módulo com isso (e depuração habilitada), até reiniciei no meio. A saída curta em dmesg confirma que a versão antiga agora está carregada. E como com @johnthesoftwareathome , continuou a funcionar durante toda a noite, apesar de fazer coisas que teriam desligado o wi-fi algumas vezes no passado.

Então, por enquanto, minha tarefa parece ser fazer com que "não funcione" novamente para ter uma chance de descobrir o que está acontecendo. Minha próxima tentativa, embora não seja mais hoje, será fazer um hard reset (removendo a energia por algum tempo em vez de apenas usar o comando 'reboot') e usando uma instalação completamente nova a partir de uma imagem nova.

Além disso, infelizmente não posso excluir a possibilidade de que a imagem com a qual obtive falhas ainda fosse uma versão diferente, pois esqueci de fazer um backup antes de sobrescrevê-la com a imagem de depuração. Talvez @johnthesoftwareathome possa postar qual imagem exata ele está usando e com a qual teve / tem problemas? Por outro lado, naquela época eu só atualizava o firmware usando os pacotes padrão e tenho a versão do pacote firmware-brcm80211 (1: 0,43 + rpi6) instalada. Embora a última entrada no log de mudanças não especifique a versão do firmware, a penúltima faz: 7.45.41.26, que é mais antigo do que o da imagem. Assumindo que o changelog foi escrito corretamente, seria uma forte indicação de que o firmware não foi substituído desde que a imagem foi criada e que o que chamo de 'imagem' é o que usei antes.

Informações sobre meus dois arquivos de firmware (imagem: o da imagem de instalação do raspbian, depurar: o que recebi diretamente de @ JamesH65 :

depurar:
Versão do firmware = wl0: 23 de outubro de 2017 03:55:53 versão 7.45.98.38 (r674442 CY) FWID 01-e58d219f
md5sum: ba679a85c1dc76e9775603af45440bc0
imagem:
Versão do firmware = wl0: 7 de agosto de 2017 00:46:29 versão 7.45.41.46 (r666254 CY) FWID 01-f8a78378
md5sum: 5f520a38ab4e943bfa1ba102f80fb2a0

@johnthesoftwareathome : como é a nova saída de "depuração"? Ainda não recebo nada que, mesmo remotamente, pareça uma depuração extensiva, independentemente de como carrego o módulo. Eu obtenho zero entradas durante a operação, e mesmo após a inicialização todos os aspectos relevantes são:

como root: dmesg | grep brcm
[0,000000] Linha de comando do kernel: 8250.nr_uarts = 0 bcm2708_fb.fbwidth = 640 bcm2708_fb.fbheight = 480 bcm2708_fb.fbdepth = 16 bcm2708_fb.fbswap = 1 vc_mem.mem_baseem = 0x3ea00_pt.mc0000_dem_ console = 0x3ea00_0x000 vc0000_dem_mc = 0x3ea00_0x000_dmc00_vc0000_ console_00000_vc0000 , 115200 console = tty1 root = PARTUUID = f8e4f7c2-02 rootfstype = ext4 elevator = deadline fsck.repair = yes rootwait brcmfmac.debug = 0x100000
[3.500135] usbcore: novo driver de interface registrado brcmfmac
[3.662113] brcmfmac: versão do firmware = wl0: 7 de agosto de 2017 00:46:29 versão 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[3.774278] brcmfmac: gerenciamento de energia desativado
[4.711443] brcmfmac: gerenciamento de energia desativado

Pequena atualização: olhando para um dos meus comentários mais antigos neste tópico, posso realmente confirmar que o firmware antigo que usei hoje ('imagem') é aquele com o qual tive problemas até tentar a imagem de depuração mais recente.

Casa vazia, então finalmente consegui ouvir o último álbum de Bowie. Tudo funcionou perfeitamente (o álbum não é assim). Longe de casa até amanhã, eu pego isto então.

Gerenciado para fazer com que o firmware original falhe como antes, mas não de forma confiável entre usá-lo e o firmware de depuração. Atualmente apenas reiniciando com o material de depuração sem falhas ainda.

Eu entendi mal o que @knarrf quis dizer sobre a saída de depuração e presumi que ele não podia ver que o novo firmware havia sido instalado em vez de significar que esperava algum tipo de fluxo de depuração (que também não consigo ver). Ele tem razão. No caso dessa falha, veremos algo ou o hex de depuração está errado?

Além disso, uma das falhas não desapareceu imediatamente. Isso me permitiu fazer o ssh de volta antes de precisar reiniciar. Syslog contém o seguinte ..

13 de janeiro 08:34:48 kernel do plexServer: [46.648630] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
13 de janeiro 08:35:14 kernel do plexServer: [72.161473] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
13 de janeiro 08:35:14 kernel do plexServer: [72.161484] brcmfmac: brcmf_cfg80211_get_channel: chanspec falhou (-110)

Esse é um conjunto muito familiar de mensagens de erro, mas ainda é útil saber que você estava enfrentando o mesmo problema que agora parece que pode ter sido corrigido.

A Cypress está preparando um novo lançamento de firmware para nós - publicaremos aqui quando algo estiver disponível para teste. Obrigado a todos pelo interesse, tempo e paciência.

Está bem. Obrigado por um driver de trabalho.

As coisas podem ter mudado desde isso ..

https://tech4research.wordpress.com/2014/07/23/brcmfmac-debugging-and-adequ-debug-values/

e eu aprecio que a opção de depuração para o novo firmware pode ser uma adição especial, mas essas opções parecem funcionar para o firmware original e de 'depuração' e o fluxo esperado de depuração é expelido.

Provavelmente já foi visto; mas a TPLink afirma que os dispositivos Android estão fazendo DoS em seus dispositivos com pacotes MDNS quando acordam do sono e tentam se reconectar com o Chromecast ou dispositivos semelhantes.
Procurando em um pcap que desliguei um meu próprio dispositivo, posso ver ~ 3.500 pacotes MDNS chegando em cerca de 2,25 segundos antes de minha conexão terminar. Parece se encaixar nesse padrão e pode estar relacionado.

Apenas para adicionar / confirmar algumas informações sobre este assunto:

• Definir a interface wi-fi como promíscua ( ifconfig wlan0 promisc ) parece atenuar o problema
• O problema parece ser causado apenas pelo meu telefone Android 7.1.2 Galaxy S7 (que comprei há uma semana e foi quando os problemas começaram)

Estou executando o Debian Buster com aarch64 no meu Pi3 e um servidor Nextcloud nele. Capturar arquivos maiores de um laptop Linux não causa problemas nem o Nextcloud sincroniza desse laptop, mas assim que eu carregar um lote de arquivos do Galaxy, o erro Unknown mailbox data content: 0x40012 aparecerá e a conectividade Wifi será perdido.

O firmware brcmfmac que estou usando é 7.45.41.26 (r640327) FWID 01-4527cfab

Infelizmente, não tenho um Android mais antigo para testar.

Eu pulei um upload do Samsung para o Pi3, mas o Wifi estava no modo promíscuo e tudo funcionou bem. Se eu encontrar tempo, vou dar uma olhada no pcap e relatar se eu encontrar algo útil / interessante.

PS: Cast (o principal infrator descrito no artigo do TPLink) não está ativo (ou pelo menos não consigo vê-lo nas configurações de conectividade).

Oi pessoal,

Só quero confirmar que desligar o modo powersafe e habilitar o modo promiscuis resolveu o problema para mim: pela primeira vez, ele conseguiu ficar conectado por 24 horas.

sudo iw wlan0 desligar power_save
sudo ifconfig wlan0 promisc

Obrigado,
Luc

Consulte esta postagem do fórum para obter detalhes sobre uma nova versão de firmware. Qualquer pessoa que perceber o problema da caixa de correio, ou mesmo qualquer problema de conexão sem fio, deve experimentar para ver se ajuda.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508

@ JamesH65
Olá James,
Você pode fornecer algumas instruções de instalação. O arquivo .bin no arquivo é um executável de instalação automática?
THX
Lee

Instruções agora na página do fórum vinculado.

Verifique novamente depois de executar o novo firmware por pouco mais de uma semana. Até agora, tem sido sólido. Eu acordei repetidamente meu dispositivo Samsung após longos períodos e a interface sem fio do meu Pi continuou funcionando. Acredito que tive um caso em que caiu temporariamente e depois se recuperou; entretanto, não fui capaz de reproduzir isso. Ao todo, parece sólido. Obrigado a James por insistir nisso e à equipe Cypress por consertar este.

Obrigado pelo relatório.

Alguém pode me dizer se a correção do firmware já foi feita na distribuição oficial do Raspbian para que possa ser instalada via apt update ou se ainda não, me informar depois de ter sido o caso?

Alguém pode me dizer se a correção do firmware já foi feita na distribuição oficial do Raspbian para que possa ser instalada via atualização do apt ou se ainda não, me informe depois que for o caso?

Sim. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508&start=25#p1270212
Alguns problemas relatados no Pi0W após a atualização geral, mas não está totalmente claro se é apenas a mudança de firmware ou outra coisa - https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=204882

Eu atualizei o firmware

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.bin
ba679a85c1dc76e9775603af45440bc0  /lib/firmware/brcm/brcmfmac43430-sdio.bin

mas ainda tem o mesmo 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

O seguinte também não está evitando esse problema

sudo iw wlan0 set power_save off
sudo ifconfig wlan0 promisc

Estou usando o RPi3 como um ponto de acesso com hostapd e dnsmasq .
Sempre posso reproduzir o problema ao iniciar um download no aplicativo Spotify no meu telefone Android.

Eu preciso atualizar o seguinte arquivo também?

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.txt
9a88b55134d9f8f3ad2331b93f4b7b79  /lib/firmware/brcm/brcmfmac43430-sdio.txt

Será usado pelo motorista ou pode ser ignorado?

Editar:
Sim. O brcmfmac43430-sdio.txt também é necessário.
Mas estou usando as melhores versões mais recentes de https://github.com/RPi-Distro/firmware-nonfree/tree/927fa8ebdf5bcfb90944465b40ec4981e01d6015/brcm

Eu também atualizei meu kernel 4.9.35-v7 + para 4.14.18-v7 +.
Mas o problema ainda existe.

Tive o mesmo problema no meu RPi3: o wi-fi caiu após algum tempo de atividade (por exemplo, durante a noite) com quase nenhum tráfego.
A saída dmesg mostra apenas:

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

Tentei recarregar o driver (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

Isso de alguma forma não funcionou - driver carregado, mas não, não tenho interface
Tentei outra vez:

[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

..e estou de pé novamente.

Pi3 executa kernel '4.14.24-v7 + # 1097' - firmware é o mais antigo de 7 de agosto de 2017 - mesmo blob de firmware que funciona perfeitamente (tempo de atividade> 2 meses) em um kernel Pi Zero W executando '4.9.77+ # 1081'
Ambos os Pis estão conectados ao mesmo roteador e em uma sala separada. Ambos estão conectados apenas via WiFi.

Provavelmente vale a pena usar o firmware mais recente no 4.14, já que o 4.14 tem todas as alterações necessárias para funcionar com esse firmware.

:) Atualizado para o último fw (23 de outubro de 2017 03:55:53 versão 7.45.98.38) ontem após a postagem - parece funcionar atm - vamos ver o que acontece ..

Parece que o raspbian voltou ao pacote de firmware de agosto de 2017. Há algum novo requisito para a rpi 3B + wireless?

O pacote mais recente do stretch repo firmware-brcm80211 1: 20161130-3 + rpt3 tem 23 de outubro de 2017 versão de firmware 7.45.98.38 para Pi3 / Pi0W e outro pacote adequado para Pi3 +

Eu também tenho aquele problema com o wi-fi morrendo.

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

Isso é com 4.14.27-v7 + e com
/ sbin / iw dev wlan0 desligar power_save
/ sbin / ifconfig wlan0 promisc
em /etc/rc.local.

mesmas mensagens de erro que @ flok99 - usando o firmware mais recente (rpi-update) na extensão.

OK, então o bug que pensamos que o Cypress corrigiu ainda está lá. De volta a
Cypress vai. Demorou um ano para obter esta versão. Prendendo a respiração não
recomendado.

Deve confirmar a versão, no entanto, poste o conteúdo de

dmesg | grep brcmfmac

Em 18 de março de 2018 às 01h44, Rebroad [email protected] escreveu:

mesmas mensagens de erro que @ flok99 https://github.com/flok99 - usando o mais recente
firmware (atualização de rpi) em extensão.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373966343 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHY1Cmntz_kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

[4.112717] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x15264345
[4.119827] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para chip 0x004345 (17221) rev 0x000006
[4.120314] usbcore: novo driver de interface registrado brcmfmac
[4.440371] brcmfmac: brcmf_c_preinit_dcmds: versão do firmware = wl0: fevereiro
27 2018 03:15:32 versão 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[4.440958] brcmfmac: brcmf_c_preinit_dcmds: versão CLM = API: 12.2
Dados: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Criação: 09/03/2018
18:56:28
[10.911757] brcmfmac: gerenciamento de energia desabilitado
[12.016088] brcmfmac: gerenciamento de energia desativado
[2074.090674] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
falhou com status -5
[2074.090687] brcmfmac: brcmf_cfg80211_get_tx_power: erro (-5)
[2074.090745] brcmfmac: brcmf_fil_cmd_data: o ônibus está inativo. não temos nada
façam.
[2074.090753] brcmfmac: brcmf_link_down: WLC_DISASSOC falhou (-5)
[2074.610583] brcmfmac: brcmf_fil_cmd_data: o ônibus está fora do ar. não temos nada
façam.
[2074.611992] brcmfmac: brcmf_fil_cmd_data: o ônibus está inativo. não temos nada
façam.
[2074.613945] brcmfmac: brcmf_fil_cmd_data: o ônibus está inativo. não temos nada
façam.
[2074.613971] brcmfmac: brcmf_cfg80211_get_channel: chanspec falhou (-5)
[2074.729716] brcmfmac: brcmf_fil_cmd_data: o ônibus está fora do ar. não temos nada
façam.
[2074.729733] brcmfmac: brcmf_cfg80211_reg_notifier: Código do país iovar
retornou err = -5
[2074.871693] usbcore: cancelando o registro do driver de interface brcmfmac
[2074.929084] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x15264345
[2074.936897] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para chip 0x004345 (17221) rev 0x000006
[2074.937139] usbcore: novo driver de interface registrado brcmfmac
[2075.118180] brcmfmac: brcmf_c_preinit_dcmds: versão do firmware = wl0: fevereiro
27 2018 03:15:32 versão 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2075.118706] brcmfmac: brcmf_c_preinit_dcmds: versão CLM = API: 12.2
Dados: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Criação: 09/03/2018
18:56:28
[2075.215365] brcmfmac: gerenciamento de energia desabilitado
[2075.263751] brcmfmac: gerenciamento de energia desativado
[2085.475001] brcmfmac: gerenciamento de energia desativado
[2124.380808] brcmfmac: brcmf_fil_cmd_data: o ônibus está inativo. não temos nada
façam.
[2124.381146] brcmfmac: brcmf_fil_cmd_data: o ônibus está fora do ar. não temos nada
façam.
[2124.381156] brcmfmac: brcmf_cfg80211_get_channel: chanspec falhou (-5)
[2124.622345] usbcore: cancelando o registro do driver de interface brcmfmac
[2124.705432] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x15264345
[2124.714194] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para chip 0x004345 (17221) rev 0x000006
[2124.716213] usbcore: novo driver de interface registrado brcmfmac
[2124.929556] brcmfmac: brcmf_c_preinit_dcmds: Versão do firmware = wl0: fevereiro
27 2018 03:15:32 versão 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2124.929993] brcmfmac: brcmf_c_preinit_dcmds: versão CLM = API: 12.2
Dados: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Criação: 09/03/2018
18:56:28
[2125.105218] brcmfmac: gerenciamento de energia desativado
[2125.150290] brcmfmac: gerenciamento de energia desativado
[8237.434034] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido:
0x40012
[8239.890302] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[8239.890822] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware em dongle
[8239.890835] brcmfmac: brcmf_run_escan: erro (-110)
[8239.890845] brcmfmac: brcmf_cfg80211_scan: erro de digitalização (-110)
[8254.280425] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
falhou com status -5
[8254.280438] brcmfmac: brcmf_cfg80211_get_tx_power: erro (-5)
[8254.280491] brcmfmac: brcmf_fil_cmd_data: o ônibus está inativo. não temos nada
façam.
[8254.280498] brcmfmac: brcmf_link_down: WLC_DISASSOC falhou (-5)
[8254.800394] brcmfmac: brcmf_fil_cmd_data: o ônibus está fora do ar. não temos nada
façam.
[8254.803873] brcmfmac: brcmf_fil_cmd_data: o ônibus está inativo. não temos nada
façam.
[8254.808353] brcmfmac: brcmf_fil_cmd_data: o ônibus está fora do ar. não temos nada
façam.
[8254.808370] brcmfmac: brcmf_cfg80211_get_channel: chanspec falhou (-5)
[8254.881402] brcmfmac: brcmf_fil_cmd_data: o ônibus está inativo. não temos nada
façam.
[8254.881420] brcmfmac: brcmf_cfg80211_reg_notifier: Código do país iovar
retornou err = -5
[8255.001550] usbcore: cancelando o registro do driver de interface brcmfmac
[8255.071184] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x15264345
[8255.077098] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para chip 0x004345 (17221) rev 0x000006
[8255.077348] usbcore: novo driver de interface registrado brcmfmac
[8257.730418] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[8257.751038] brcmfmac: brcmf_c_get_clm_name: recuperando informações de revisão
falhou (-110)
[8257.751049] brcmfmac: brcmf_c_process_clm_blob: obter o nome do arquivo blob CLM
falhou (-110)
[8257.751068] brcmfmac: brcmf_c_preinit_dcmds: baixe o arquivo blob CLM
falhou, -110
[8257.751076] brcmfmac: brcmf_bus_started: falhou: -110
[8257.751114] brcmfmac: brcmf_sdio_firmware_callback: dongle não é
respondendo
[8304.417684] usbcore: cancelando o registro do driver de interface brcmfmac
[8304.486099] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x15264345
[8304.493613] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para chip 0x004345 (17221) rev 0x000006
[8304.494078] usbcore: novo driver de interface registrado brcmfmac
[8304.686761] brcmfmac: brcmf_c_preinit_dcmds: versão do firmware = wl0: fevereiro
27 2018 03:15:32 versão 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8304.687203] brcmfmac: brcmf_c_preinit_dcmds: versão CLM = API: 12.2
Dados: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Criação: 09/03/2018
18:56:28
[8304.829994] brcmfmac: gerenciamento de energia desativado
[8304.907662] brcmfmac: gerenciamento de energia desativado
[8357.441791] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido:
0x40012
[8359.891146] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[8359.891655] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware em dongle
[8359.891668] brcmfmac: brcmf_run_escan: erro (-110)
[8359.891677] brcmfmac: brcmf_cfg80211_scan: erro de digitalização (-110)
[8371.731226] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[8371.731731] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware em dongle
[8371.731746] brcmfmac: brcmf_cfg80211_get_channel: chanspec falhou (-110)
[8373.941267] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
falhou com status -5
[8373.941280] brcmfmac: brcmf_cfg80211_get_tx_power: erro (-5)
[8373.941330] brcmfmac: brcmf_fil_cmd_data: o barramento está inativo. não temos nada
façam.
[8373.941338] brcmfmac: brcmf_link_down: WLC_DISASSOC falhou (-5)
[8374.461245] brcmfmac: brcmf_fil_cmd_data: o barramento está inativo. não temos nada
façam.
[8374.461942] brcmfmac: brcmf_fil_cmd_data: o ônibus está inativo. não temos nada
façam.
[8374.463553] brcmfmac: brcmf_fil_cmd_data: o ônibus está fora do ar. não temos nada
façam.
[8374.463573] brcmfmac: brcmf_cfg80211_get_channel: chanspec falhou (-5)
[8374.564729] brcmfmac: brcmf_fil_cmd_data: o barramento está inativo. não temos nada
façam.
[8374.564750] brcmfmac: brcmf_cfg80211_reg_notifier: Código do país iovar
retornou err = -5
[8374.702401] usbcore: cancelando o registro do driver de interface brcmfmac
[8374.759839] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x15264345
[8374.767561] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para chip 0x004345 (17221) rev 0x000006
[8374.771137] usbcore: novo driver de interface registrado brcmfmac
[8377.411255] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[8377.431924] brcmfmac: brcmf_c_get_clm_name: recuperando informações de revisão
falhou (-110)
[8377.431934] brcmfmac: brcmf_c_process_clm_blob: obter o nome do arquivo blob CLM
falhou (-110)
[8377.431941] brcmfmac: brcmf_c_preinit_dcmds: baixe o arquivo blob CLM
falhou, -110
[8377.431949] brcmfmac: brcmf_bus_started: falhou: -110
[8377.432003] brcmfmac: brcmf_sdio_firmware_callback: dongle não é
respondendo
[8424.133114] usbcore: cancelando o registro do driver de interface brcmfmac
[8424.229631] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x15264345
[8424.237210] brcmfmac: brcmf_fw_map_chip_to_name: usando
brcm / brcmfmac43455-sdio.bin para chip 0x004345 (17221) rev 0x000006
[8424.239352] usbcore: novo driver de interface registrado brcmfmac
[8424.460736] brcmfmac: brcmf_c_preinit_dcmds: versão do firmware = wl0: fevereiro
27 2018 03:15:32 versão 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8424.461174] brcmfmac: brcmf_c_preinit_dcmds: versão CLM = API: 12.2
Dados: 9.10.105 Compilador: 1.29.4 ClmImport: 1.36.3 Criação: 09/03/2018
18:56:28
[8424.646993] brcmfmac: gerenciamento de energia desabilitado
[8424.708633] brcmfmac: gerenciamento de energia desabilitado

No domingo, 18 de março de 2018 às 11h30, James Hughes [email protected]
escrevi:

OK, então o bug que pensamos que o Cypress corrigiu ainda está lá. De volta a
Cypress vai. Demorou um ano para obter esta versão. Prendendo a respiração não
recomendado.

Deve confirmar a versão, no entanto, poste o conteúdo de

dmesg | grep brcmfmac

Em 18 de março de 2018 às 01h44, Rebroad [email protected] escreveu:

mesmas mensagens de erro que @ flok99 https://github.com/flok99 - usando
Mais recentes
firmware (atualização de rpi) em extensão.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -373966343
,
ou silenciar o tópico
kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5>
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373987387 ,
ou silenciar o tópico
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 

Parece que você está no Pi3b + mais recente e não no Pi3 original: então, talvez seja diferente?

Chip e firmware totalmente diferentes, embora o driver do lado do Linux seja o
mesmo. (brcmfmac).

Em 19 de março de 2018 às 16:26, macmpi [email protected] escreveu:

@ flok99 https://github.com/flok99

brcmfmac: brcmf_fw_map_chip_to_name: usando brcm / brcmfmac43455-sdio.bin para chip
Versão do firmware = wl0: 27 de fevereiro de 2018 03:15:32 versão 7.45.154 (r684107 CY) FWID 01-4fbe0b04

Parece que você está no Pi3b + mais recente e não no Pi3 original: então
talvez assunto diferente?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-374274045 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHeP6-sc-P-OSggQFPrl3O8z_B2aRks5tf9wbgaJpZM4HupC5
.

-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd

Acho que é melhor ter outro tópico para problemas do Pi3B + e consultar este quando necessário, caso contrário, será muito difícil rastrear. Pode @ flok99 criar um novo fascículo com seus relatórios, garantindo que o título se refira ao 3b +. Vou mudar o título deste para refletir apenas para Pi3B.

feito

Alguém se inscreveu neste problema, executando o 3B (não plus), ainda vê os problemas com o firmware e kernel mais recentes? Gostaria de qualquer relatório de falha contínua - as últimas postagens sobre o assunto acima parecem indicar que as coisas agora estão funcionando bem.

Meu 3B está ativo há 44 dias com este:

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

Sem problemas desde então ..

Boas notícias. A menos que eu ouça o contrário, provavelmente fecharei este tópico em uma ou duas semanas, embora ele possa ser reaberto a qualquer momento se problemas ocorrerem novamente.

Comecei a ter esse problema há cerca de uma semana, não tendo ouvido falar dele antes. Eu também uso o pi na maioria das vezes com um telefone samsung como roteador - o meu é um s4. Estou escrevendo isso conectado direto ao s4 com usb, ou seja, usando rndis. Aqui estão meus detalhes do boot de hoje:
0 atualizado, 0 recém-instalado, 0 para remover e 0 não atualizado.
thenry @ pi3portable : ~ $ dmesg | grep brcmfmac
[9.965782] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x1541a9a6
[9.972059] brcmfmac: brcmf_fw_map_chip_to_name: usando brcm / brcmfmac43430-sdio.bin para chip 0x00a9a6 (43430) rev 0x000001
[9.972250] usbcore: novo driver de interface registrado brcmfmac
[10.147562] brcmfmac: brcmf_c_preinit_dcmds: versão do firmware = wl0: 7 de agosto de 2017 00:46:29 versão 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.148507] brcmfmac: brcmf_c_preinit_dcmds: versão CLM = API: 12.2 Dados: 7.11.15 Compilador: 1.24.2 ClmImport: 1.24.1 Criação: 2014-05-26 10:53:55 Dados Inc: 9.10.41 Compilador Inc: 1.29 .4 Inc ClmImport: 1.36.3 Criação: 2017-08-07 00:37:47
[18.538641] brcmfmac: gerenciamento de energia desativado
[30.629545] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
[33.191450] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[33.194850] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware no dongle
[35.751496] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[35.754898] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware no dongle
[35.754906] brcmfmac: brcmf_pno_clean: código falhou -110
[43.271438] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[43.274800] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware no dongle
[43.274807] brcmfmac: brcmf_do_escan: erro (-110)
[43.274811] brcmfmac: brcmf_cfg80211_scan: erro de digitalização (-110)
[7673.758073] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[7673.761437] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware em dongle
[7673.761454] brcmfmac: _brcmf_set_multicast_list: Falha ao definir mcast_list, -110
[7676.328075] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[7676.331449] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware em dongle
[7676.331466] brcmfmac: _brcmf_set_multicast_list: Falha ao definir allmulti, -110
[7678.878084] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[7678.881460] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware em dongle
[7681.448101] brcmfmac: _brcmf_set_multicast_list: Falha na configuração BRCMF_C_SET_PROMISC, -110
[7689.118098] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
[7689.118241] brcmfmac: gerenciamento de energia desativado
[7691.678100] brcmfmac: brcmf_cfg80211_set_power_mgmt: erro (-110)
[7694.238122] brcmfmac: _brcmf_set_multicast_list: Falha ao configurar mcast_list, -110
[7696.798118] brcmfmac: _brcmf_set_multicast_list: Falha ao configurar allmulti, -110
[7699.358158] brcmfmac: brcmf_do_escan: erro (-110)
[7699.358167] brcmfmac: brcmf_cfg80211_scan: erro de digitalização (-110)
[7701.918127] brcmfmac: _brcmf_set_multicast_list: Falha na configuração BRCMF_C_SET_PROMISC, -110
[11406.881341] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg falhou com status -110
[11406.881352] brcmfmac: brcmf_cfg80211_reg_notifier: Código do país iovar retornou err = -110
[11579.921479] brcmfmac: _brcmf_set_multicast_list: Falha ao definir mcast_list, -110
[11582.491485] brcmfmac: _brcmf_set_multicast_list: Falha na configuração de allmulti, -110
[11587.611478] brcmfmac: _brcmf_set_multicast_list: Falha na configuração BRCMF_C_SET_PROMISC, -110
thenry @ pi3portable : ~ $
thenry @ pi3portable : ~ $ uname -a
Linux pi3portable 4.14.27-v7 + # 1100 SMP Sex. 16 de março 13:51:48 GMT 2018 armv7l GNU / Linux
thenry @ pi3portable : ~ $
Estou executando este kernel porque mudei para o próximo fluxo quando estava testando a inicialização de usb e não mudei de volta depois. Então recebi o aviso sobre o novo kernel (4.14), então decidi tentar isso, cerca de um mês atrás. Tem estado bem, sem problemas até este. A única outra mudança importante foi que mudei do NetworkManager para o systemd-networkd vários dias atrás, mas isso foi depois que o problema apareceu pela primeira vez.
Saudações,
Trevor Henry

Atualizar:
Depois de ler todos os posts relacionados, encontrei o firmware mais recente no post https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508
e isso resolveu meu problema.

versão de teste de brcmfmas43430-sdio.bin instalado 250418

versão 7.45.98.38 23 de outubro de 2017, versão substituída 7.45.41.46 7 de agosto de 2017

antes:

[10.368086] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x1541a9a6
[10.376702] brcmfmac: brcmf_fw_map_chip_to_name: usando brcm / brcmfmac43430-sdio.bin para chip 0x00a9a6 (43430) rev 0x000001
[10.377026] usbcore: novo driver de interface registrado brcmfmac
[10.599523] brcmfmac: brcmf_c_preinit_dcmds: versão do firmware = wl0: 7 de agosto de 2017 00:46:29 versão 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.600577] brcmfmac: brcmf_c_preinit_dcmds: versão CLM = API: 12.2 Dados: 7.11.15 Compilador: 1.24.2 ClmImport: 1.24.1 Criação: 2014-05-26 10:53:55 Dados Inc: 9.10.41 Compilador: 1.29 .4 Inc ClmImport: 1.36.3 Criação: 2017-08-07 00:37:47
[126.642710] brcmfmac: gerenciamento de energia desabilitado
[139.249230] brcmfmac: brcmf_sdio_hostmail: Conteúdo de dados de caixa de correio desconhecido: 0x40012
[141.751545] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[141.754973] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware no dongle
[144.311482] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[144.314959] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware em dongle
[144.314975] brcmfmac: brcmf_pno_clean: código com falha -110
[151.831564] brcmfmac: brcmf_sdio_bus_rxctl: retomado no tempo limite
[151.835066] brcmfmac: brcmf_sdio_checkdied: armadilha de firmware em dongle
[151.835079] brcmfmac: brcmf_do_escan: erro (-110)
[151.835084] brcmfmac: brcmf_cfg80211_scan: erro de digitalização (-110)

depois de:

thenry @ pi3portable : ~ $ dmesg | grep brcm
[10.115833] brcmfmac: assinatura F1 lida @ 0x18000000 = 0x1541a9a6
[10.134926] brcmfmac: brcmf_fw_map_chip_to_name: usando brcm / brcmfmac43430-sdio.bin para chip 0x00a9a6 (43430) rev 0x000001
[10.135115] usbcore: novo driver de interface registrado brcmfmac
[10.367703] brcmfmac: brcmf_c_preinit_dcmds: versão do firmware = wl0: 23 de outubro de 2017 03:55:53 versão 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[10.368419] brcmfmac: brcmf_c_preinit_dcmds: versão CLM = API: 12.2 Dados: 7.11.15 Compilador: 1.24.2 ClmImport: 1.24.1 Criação: 2014-05-26 10:53:55 Dados Inc: 9.10.39 Compilador Inc: 1.29 .4 Inc ClmImport: 1.36.3 Criação: 2017-10-23 03:47:14
[18.045308] brcmfmac: gerenciamento de energia desativado
thenry @ pi3portable : ~ $

Continuou a funcionar através de várias botas e agora estou a utilizá-lo, ligado por wi-fi a um telefone samsung s4.
Obrigado pela ajuda, cumprimentos, Trevor Henry.

Achei que o firmware mais recente já estava nas imagens mais recentes, então seria de se esperar que uma atualização para 4.14 trouxesse o firmware mais recente. Você construiu seu próprio kernel?

Sim - as imagens Raspbian atuais têm firmware 7.45.98.38 de 23 de outubro de 2017.

Olá, não, eu não construí o kernel, atualizei com o rpi-update e, como você pode ver, ele ainda estava executando o firmware de agosto de 2017 após a atualização.

O rpi-update apenas atualiza o kernel, firmware e um pequeno número de utilitários específicos do VideoCore. Para atualizar tudo, incluindo o firmware WiFi, você deve usar apt-get upgrade / distupgrade.

Oi,
Então, eu tenho esse problema e é melhor com o FW mais recente, 7.45.98.38, do que era, mas ainda tenho problemas.
Observações
Se eu inicializar o Raspberry sem fazer nada, a WLAN será ativada como deveria.
Se tento usar o teclado ou mouse bluetooth antes de a WLAN estar ativa, o problema persiste, não consigo conexão.
Se eu tiver uma conexão e desativar / ativar a rede sem fio, a WLAN não se conecta.
Se eu deixar a WLAN ligada durante a noite, a conexão para de funcionar.
Tenho três configurações idênticas e o comportamento é o mesmo em todas elas.
Não sei se isso importa, mas estamos usando WPA2 enterprise, PEAP e MSCHAPv2

Esses problemas acontecem apenas quando os dispositivos BT estão conectados?

Sim! Bluetooth desativado e teclados e mouse usb conectados e WLAN conectado mais rápido do que eu já vi antes.

Ainda assim, alguns problemas coexistem. Terá de ser sinalizado para Cypress, eu acho.

Só para verificar, você está usando o Raspbian mais recente? Ou algo bem novo?

@pelwell ping

Descrição: Raspbian GNU / Linux 9.4 (extensão)
Você precisa de mais informações?

Ele trava depois de:
14 de maio 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD Fornecedor EAP 0 método 25 (PEAP) selecionado

veja o recorte de registro abaixo

14 de maio 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.7887] dispositivo (wlan0): estado da interface do suplicante: desconectado -> associando
14 de maio 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: Associado a 44: d9: e7: f7: d5: 34
14 de maio 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-STARTED Autenticação EAP iniciada
14 de maio 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.9263] dispositivo (wlan0): estado da interface do suplicante: associando -> associado
14 de maio 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD fornecedor = 0 method = 25
14 de maio 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD Fornecedor EAP 0 método 25 (PEAP) selecionado
14 de maio 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0716] dispositivo (wlan0): Ativação: a associação (wi-fi) demorou muito
14 de maio 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0718] dispositivo (wlan0): mudança de estado: config -> need-auth (motivo 'nenhum') [50 60 0]
14 de maio 15:44:24 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-DISCONNECTED bssid = 44: d9: e7: f7: d5: 34 motivo = 3 localmente_generado = 1
14 de maio 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:Dispositivo [1526305464.0937] (wlan0): Ativação: (wi-fi) solicitando novos segredos
14 de maio 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0959] sup-iface [0x1c438c0, wlan0]: conexão desconectada (motivo -3)

Tenho o mesmo problema com o octoPi 0.14 (todos os pacotes atualizados, firmware rpi no máximo, todos os plug-ins octoprint atualizados).

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

com esta configuração é 100% reproduzível. Acessando o site do octoprint no pi (acesso pela primeira vez após a inicialização) do meu samsung s4 ativo (android 5.0.1, usando o cromo) ou do meu tablet samsung 10 polegadas nota coisa com também android 5.xi chute e o cromo mata o wi-fi quando o a página está carregada pela metade.
Nenhum cabo conectado ao meu Pi3, wi-fi no canal 11 com wpa2.
Tentei desabilitar o recurso de energia do wi-fi e mudar para o canal 6 do wi-fi sem qualquer sorte (dicas de cima) - porém, tive a sensação de que era um pouco melhor com o canal 6

Mas agora vem a pista interessante sobre o bug:
Não tenho nenhum problema quando abro o site octopi / octoprint (no pi) da minha máquina windows 10 ou ubuntu 16 (usando cromo, conexão por cabo para o roteador). Meu palpite é que agora é um bug relacionado a android, samsung ou wi-fi para wi-fi. E acho que li algo sobre problemas com Android / rpi há algum tempo.

Espero que isto ajude. Se você precisar de um testador para alguma versão, eu tentaria.

Apenas pensei em gritar aqui e dizer que também vimos o que parece ser um bloqueio relacionado ao WiFi em torno deste driver, que pode estar relacionado em outro SBC. Não é específico do Raspberry PI.

Isso está acontecendo comigo também.

Estabelecer

• 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

Executando o Raspbian versão 9.4:

pi<strong i="14">@raspberrypi</strong>:~ $ cat /etc/debian_version
9.4

Versão do 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 O gerenciamento de energia está desativado:

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

Estou usando o wi-fi embutido. Nada está conectado à porta Ethernet.

O sistema foi atualizado usando apt-get upgrade , apt-get dist-upgrade e rpi-update .

O que eu vejo

Depois que o pi estiver ativo por cerca de uma hora, ele se tornará inacessível pela rede. Não consigo acessar o Pi da minha rede local (ping e ssh não funcionam).

Em dmesg , vejo que obtenho:

brcmfmac: power management disabled
...
snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned

Mas sem erros.

Algo interessante

Percebi que, quando isso acontece, se eu conectar ao pi diretamente e executar ping no meu laptop, as coisas voltam ao trabalho. Além disso, os tempos de ping são um pouco estranhos - parece que leva um pouco de tempo para fazer as coisas "esquentarem":

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

Se alguém precisar de mais informações, ficarei feliz em fornecê-las.

@bugok , configurar a interface de rede como promíscua alivia o problema para você? ( ifconfig wlan0 promisc ).

@quozl : Não ajudou. Depois de um tempo, o ping começou a falhar:

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

Reportando de volta: Meu problema parece ter sido resolvido e parece não estar relacionado ao problema neste tópico.

Detalhes aqui , mas a essência é que eu defini um IP estático no próprio Pi (em /etc/dhcpcd.conf ). Depois de definir o IP estático no roteador, remover a configuração do IP estático de /etc/dhcpcd.conf e reinicializar - as coisas parecem funcionar.

Uma atualização rápida: esse problema (erro "Conteúdo de dados de caixa de correio desconhecido" acompanhado de bloqueio completo da rede sem fio) persiste no firmware mais recente com todas as atualizações instaladas (dist-upgrade).

Alterar uma única linha no arquivo hostapd.conf (conforme meu comentário anterior) ainda elimina o problema para mim.

Usando Rpi3B com kernel 4.14.52-v7 (raspberrypi-kernel 1.20180703-1) e (firmware-brcm80211 1: 20161130-3 + rpt4)
Eu também ainda estou enfrentando o problema de travamento de wlan (90 dispositivos dos quais 2 por dia têm o problema). Em alguns casos, o adaptador está ausente e em outros, não está respondendo. Eu não estou usando o Pi no modo AP, apenas
Tentei religá- lo como em

Atualmente, criei uma solução quando nenhuma conexão de rede é detectada, o pi reinicia. No entanto, esta não é uma solução adequada e pelo menos estou tentando recarregar o driver

Eu estava constantemente vendo esse mesmo problema em um Pi 3 que funcionava anteriormente. Percebi que a única alteração que fiz foi conectar uma tela de toque LCD, tirando energia do Pi. Quando desconectei a tela sensível ao toque, o WiFi funcionou corretamente. Portanto, certamente parece estar relacionado ao poder. Isso estava usando o adaptador AC oficial do Raspberry.

Esse é um ponto de dados muito interessante. Foi um dos nossos LCD?

@ JamesH65 Eu também comecei a experimentar falhas de wi-fi e picos de latência depois que instalei https://www.waveshare.com/wiki/5inch_HDMI_LCD , eu tenho uma 3b + a rpi cam v2 e a tela, conectada a um psu 3amp, i não recebo nenhum aviso de energia ...

Oi pessoal, alguma atualização sobre isso? Eu estava tentando usar raspivid em um zero W com um fluxo TCP e depois de alguns minutos meu Wi-Fi acabou, acho que é o mesmo problema.

Não tenho esse problema há pelo menos um ano ou mais. Estou começando a pensar cada vez mais que pode estar simplesmente relacionado ao fato de a fonte de alimentação USB não fornecer amplificadores suficientes, mas gostaria de provar que não é o caso. Como teste, tente conectar o cabo USB em um adaptador de amplificador superior, especialmente se você puder reproduzir o problema facilmente.

Tenho certeza de que não está diretamente relacionado com o amplificador porque eu só uso suprimentos de cerca de 2amp. principalmente carregadores Samsung antigos. no entanto, pode ser ondulação ou algo com a fonte de alimentação ou hardware pi.Von meinem Samsung Gerät gesendet.

-------- Ursprüngliche Nachricht --------
Von: rajid [email protected]
Datum: 04.07.2019 02:15 (GMT + 01: 00)
An: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , Comentário [email protected]
Betreff: Re: [raspberrypi / linux] wlan congela em raspberry pi 3 / PiZeroW (não
3B +) (# 1342)

Não tenho esse problema há pelo menos um ano ou mais. Estou começando a pensar cada vez mais que pode estar simplesmente relacionado ao fato de a fonte de alimentação USB não fornecer amplificadores suficientes, mas gostaria de provar que não é o caso. Como teste, tente conectar o cabo USB em um adaptador de amplificador superior, especialmente se você puder reproduzir o problema facilmente.

—Você está recebendo isto porque comentou.Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.
{"api_version": "1.0", "publisher": {"api_key": "05dde50f1d1a384dd78767c55493e4bb", "name": "GitHub"}, "entity": {"external_key": "github / raspberrypi / linux", "título ":" raspberrypi / linux "," subtitle ":" Repositório do 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 no GitHub "," url ":" https://github.com/raspberrypi/linux "}}," updates ": {" snippets ": [{" icon ":" PERSON "," message ":" @rajid in # 1342: Não tenho esse problema há pelo menos um ano ou mais. Eu estou cada vez mais começando a pensar que pode estar simplesmente relacionado ao fato de a fonte de alimentação USB não fornecer amplificadores suficientes, mas gostaria de provar que não é o caso. Como um teste, tente conectar o cabo USB a um adaptador de amplificador superior, especialmente se você puder reproduzir o problema facilmente. "}]," action ": {" name ":" View Issue "," url ":" https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753 "}}}
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"potencialAção": {
"@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"
},
"descrição": "Ver este problema no GitHub",
"editor": {
"@type": "Organização",
"nome": "GitHub",
"url": " https://github.com "
}
}
]

Ainda estou tendo o problema, mas não com tanta frequência - talvez algumas semanas - e não posso mais induzi-lo de forma confiável conectando-me a partir de dispositivos Android da Samsung.

Na verdade, estou ligando o Pi zero w com uma fonte de alimentação USB de 3A e um cabo USB de 15 cm usado para carregar bancos de energia (sem linhas de dados, apenas linhas de energia)

Se eu usar a conexão regularmente (como um usuário normal), ela funciona bem, mas se eu transmitir MJPEG a 5 Mbps, ele trava após alguns minutos, vejo algum erro de caixa de correio (ou semelhante) no journalct (não me lembro, pois estou fora de casa por uma semana), o ssh para, sem ping, o wi-fi cai, o iwconfig leva alguns segundos para mostrar os resultados e eles estão quase vazios.

@vascojdb Se você estiver usando o Pi como um ponto de acesso (modo AP), esta solução alternativa (consulte o texto em negrito na parte inferior) deve resolver seu problema.

Nos informe?

Não, não está no modo AP, estou conectado à minha rede Wi-Fi doméstica de 2,4 GHz

Olá,

Tenho um problema de wifi para sincronizar o tempo na inicialização com o servidor NTP usando LibreELEC no RPI3B + desde a versão 9.0.0.
Após algumas discussões com alguns membros da equipe LE ( veja aqui ), o problema foi corrigido após esta modificação .

Mas parece que essa solução alternativa foi revertida e o problema ainda está presente.
É possível consertar novamente?

Ninguém para responder ou escalar este problema?

O mesmo problema. Alguma novidade sobre isso?

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)

Tentei desligar o gerenciamento de energia por enquanto. Este é um bug antigo reintroduzido?

https://patchwork.kernel.org/patch/9948825/

O mesmo problema. Alguma novidade sobre isso?

Esta mensagem apenas diz que o firmware do chip wi-fi travou. Não há nada que o kernel do Linux possa fazer exceto redefinir. Um relatório de bug útil contém as seguintes informações:

Qual firmware wi-fi você está usando?
Como vc opera o wifi (AP, cliente, ...)?
Você pode reproduzir isso dentro de um tempo definido?
Que outros dispositivos wi-fi estão envolvidos?

está no meu último comentário, uma vez que era reproduzível naquela época, mas é ruim para reproduzir e muda com alterações de software quando ele trava.

-------- Ursprüngliche Nachricht --------
Von: Stefan Wahren [email protected]
Datum: 01.05.2020 10:21 (GMT + 01: 00)
An: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , Comentário [email protected]
Betreff: Re: [raspberrypi / linux] wlan congela em raspberry pi 3 / PiZeroW (não
3B +) (# 1342)

O mesmo problema. Alguma novidade sobre isso?

Esta mensagem apenas diz que o firmware do chip wi-fi travou. Não há nada que o kernel do Linux possa fazer exceto redefinir. Um relatório de bug útil contém as seguintes informações:
Qual firmware wi-fi você está usando?
Como vc opera o wifi (AP, cliente, ...)?
Você pode reproduzir isso dentro de um tempo definido?
Que outros dispositivos wi-fi estão envolvidos?

—Você está recebendo isto porque comentou. Responda a este e-mail diretamente, visualize-o no GitHub ou cancele a inscrição.
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"potencialAção": {
"@type": "ViewAction",
"target": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"name": "Ver problema"
},
"descrição": "Ver este problema no GitHub",
"editor": {
"@type": "Organização",
"nome": "GitHub",
"url": " https://github.com "
}
}
]

O mesmo problema. Alguma novidade sobre isso?

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)

Tentei desligar o gerenciamento de energia por enquanto. Este é um bug antigo reintroduzido?

https://patchwork.kernel.org/patch/9948825/

Nenhuma solução para falar, mas eu tenho exatamente o mesmo problema em um Rpi4 com o firmware mais recente instalado. Reverti para uma imagem de cartão SD que fiz há alguns meses e o problema desapareceu. Como estou usando o hostapd, acredito que uma ou uma combinação dessas atualizações quebrou tudo para mim:

$ apt list --upgradeable
Listando ... Feito
...
hostapd / stable 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u2 armhf [atualizável de: 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u1]
firmware-brcm80211 / testing 1: 20190114-1 + rpt6 all [atualizável de: 1: 20190114-1 + rpt4]
raspberrypi-kernel / testing 1.20200212-1 armhf [atualizável de: 1.20200114-1]
...

Tentei desligar o gerenciamento de energia também (e confirmei que estava desligado com iwconfig), mas não teve efeito ao executar o hostapd. Terei que abrir mão das atualizações de firmware até que sejam consertadas, já que estamos enviando muitos desses e precisamos de APs estáveis ​​para nossos clientes.

Qualquer pessoa com armadilhas de firmware, tempos limite (-110) etc. - habilite a depuração de firmware para que possamos coletar alguns dados.

Adicione brcmfmac.debug=0x100000 a /boot/cmdline.txt, mantendo-o em uma única linha longa e reinicie. Executar dmesg | grep brcmfmac deve resultar em uma saída como esta:

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

Em seguida, continue normalmente. Quando o firmware brcmfmac morre, capture a saída de dmesg em um arquivo e anexe-o (ou um link para pastebin, etc.) aqui.

Como a falha aciona outras mensagens do kernel, existe o perigo de que a saída útil seja perdida antes que você tenha a chance de capturá-la. Uma maneira de evitar isso é deixar um shell salvando constantemente as mensagens do kernel em um arquivo:

$ dmesg -w > kernel_log.txt &

Vendo o mesmo problema aqui. Vou tentar o debug mencionado acima.

Executando hostapd no modo AP, wireguard e frr. Também usando o chapéu 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

Também consigo recriar isso no branch 5.4. FWIW, sempre posso acionar manualmente esse bug SCPing um arquivo grande (> 400 MB) para meu Pi Zero W.

Se ajudar, minha versão do kernel é a partir deste commit - 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

Crash Log com depuração:

[  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 a falha acima, executei um ifdown e ifup que não restaurou o wi-fi. A única solução é reiniciar o pi ou rmmod & modprobe brcmfmac.

É importante notar que isso acontece com o gerenciamento de energia desativado, pois tenho isso em meu arquivo de interfaces:

pre-up iwconfig wlan0 power off