EDIMAX EW-7811UN .... Cela utilise le chipset rtl8188cus, IIRC.

Si vous n'en avez pas déjà un, créez /etc/modprobe.d/8192cu.conf, avec le contenu ....

Désactiver la gestion de l'alimentation

options 8192cu rtw_power_mgnt = 0 rtw_enusbss = 0

Le rpi3 utilise en fait le pilote brcmfmac pour le wifi intégré
il y a un problème qui nécessite la désactivation de l'économie d'énergie / de la gestion

Je pense que les nouveaux noyaux raspian ont déjà corrigé cela pour désactiver l'économie d'énergie par défaut, mais je ne pense pas que ce soit encore dans cette branche 4.5

Ce que je fais en ce moment (installation gentoo) est ce qui suit au démarrage pour désactiver l'économie d'énergie sur la carte wifi

iw wlan0 met power_save off

Le rpi3 utilise en fait le pilote brcmfmac pour le wifi intégré

Oui je sais. Oh je vois. Il n'utilise plus le dongle EDIMAX EW-7811UN. Il l'utilisait avec RPi2.

oui je n'utilise plus le wifi usb, comment configurer la ligne cmd pour désactiver la gestion de l'alimentation?
crontab
@reboot iw wlan0 met power_save off

Pas sûr pour raspian, puisque j'utilise gentoo ce sera différent

Essayez ceci: https://gist.github.com/mkb/40bf48bc401ffa0cc4d3

Semble fonctionner depuis que j'ai désactivé la gestion de l'alimentation, je n'ai pas eu un autre crash wlan.

Juste pour le mentionner, pour redémarrer le wlan automatiquement après un crash, ceci aide ici:
sudo cp /etc/wpa_supplicant/ifupdown.sh /etc/ifplugd/action.d/ifupdown

BTW, le dernier noyau de mise à niveau apt-get a la gestion de l'alimentation désactivée par défaut.
@ dh-connect est-ce que cela fonctionne pour vous si vous supprimez votre solution de contournement actuelle?

il plante toujours après la dernière mise à jour, maintenant j'obtiens cette erreur dans syslog:
brcmfmac: brcmf_sdio_bus_txdata: hors bus-> txq !!!

Lorsque vous dites qu'il plante, y a-t-il des symptômes autres que le message d'erreur?

non, juste celui que j'ai posté ici mais il est dans le journal plusieurs fois

le wlan cesse de fonctionner, je peux toujours travailler avec mais pour que le wlan fonctionne à nouveau, je dois le redémarrer

Merci - Je pense que "wlan cesse de fonctionner" compte comme un symptôme.

J'ai essayé quelques trucs, mais le wlan tombe toujours en panne

pour répondre à la question ci-dessus lorsque je reprends la configuration
mise hors tension sans fil dans / etc / network / interfaces
et redémarrer
et vérifiez les paramètres avec iwconfig
la gestion de l'alimentation est réactivée, donc par défaut, je ne dirais pas qu'elle est désactivée, je vais donc quitter la configuration

J'ai essayé cela avec le noyau 4.1.19 et maintenant aussi avec le noyau 4.1.20 ... aucun changement

lorsque le wlan s'est écrasé et que j'essaye de le rallumer avec ifdown et ifup wlan0, j'obtiens ceci:
Erreur pour la demande sans fil "Set Power Management" (8B2C): SET a échoué sur le périphérique wlan0; Échange invalide.

J'ai également eu quelques erreurs supplémentaires dans syslog:

dhcpcd [532]: wlan0: xxx: option 25 expirée

21 mars 17:29:35 noyau raspberrypi: [6627.337503] brcmfmac: _brcmf_set_multicast_list: Échec de la configuration de mcast_list, -52
21 mars 17:29:36 raspberrypi wpa_supplicant [6318]: wpa_supplicant initialisé avec succès
21 mars 17:29:36 raspberrypi dhcpcd [532]: wlan0: transporteur perdu

21 mars 17:29:43 noyau raspberrypi: [6635.337616] brcmfmac: _brcmf_set_multicast_list: Échec de la configuration de mcast_list, -52

21 mars 17:29:45 noyau raspberrypi: [6637.337588] brcmfmac: brcmf_do_escan: erreur (-52)
21 mars 17:29:45 noyau raspberrypi: [6637.337602] brcmfmac: brcmf_cfg80211_scan: erreur d'analyse (-52)

21 mars 17:29:47 noyau raspberrypi: [6639.337596] brcmfmac: _brcmf_set_multicast_list: Échec de la configuration de allmulti, -52
21 mars 17:29:49 noyau raspberrypi: [6641.337632] brcmfmac: _brcmf_set_multicast_list: Échec de la configuration de BRCMF_C_SET_PROMISC, -52

y a-t-il autre chose que je pourrais essayer?

aussi ceux-ci:

21 mars 21:26:55 raspberrypi dhcpcd [526]: wlan0: xxx: option 25 expirée
21 mars 21:28:54 noyau raspberrypi: [1958.899715] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
21 mars 21:30:16 raspberrypi dhcpcd [526]: wlan0: xxx est inaccessible, expirant

Je ne suis pas surpris qu'iwconfig pense que le périphérique a activé l'économie d'énergie - je l'ai bloqué dans le pilote lui-même, et soit l'état est enregistré dans les couches supérieures, soit il y a un autre changement nécessaire pour le signaler correctement. Quoi qu'il en soit, il est évident que nous avons évité les bogues d'économie d'énergie, mais d'autres problèmes persistent.

Avez-vous des chiffres approximatifs sur le temps de défaillance et la quantité approximative de données transférées (à partir d'ifconfig)?

oui je le fais, quand je n'ai que le serveur Web fonctionnant avec peu de trafic (moins de 100 Mo), cela dure un jour ou deux, lorsque je transfère des fichiers de données volumineux comme 1 Go, le wlan plante en 1 heure

tout ce que je peux fournir pour aider à trouver le bogue?

voici une erreur de syslog:

29 mars 14:20:56 raspberrypi dhcpcd [535]: wlan0: xxx: option 25 expirée
29 mars 14:30:15 raspberrypi dhcpcd [535]: wlan0: xxx est inaccessible, expirant
29 mars 17:18:42 noyau raspberrypi: [186148.102420] brcmfmac: brcmf_sdio_bus_txdata: hors bus-> txq !!!
29 mars 17:18:43 noyau raspberrypi: [186149.101045] brcmfmac: brcmf_sdio_bus_txdata: hors bus-> txq !!!
29 mars 17:18:43 noyau raspberrypi: [186149.101145] brcmfmac: brcmf_sdio_bus_txdata: hors bus-> txq !!!
29 mars 17:18:44 noyau raspberrypi: [186150.101209] brcmfmac: brcmf_sdio_bus_txdata: hors bus-> txq !!!
29 mars 17:18:50 raspberrypi wpa_supplicant [478]: wlan0: CTRL-EVENT-DISCONNECTED bssid = xxx reason = 3 local_generated = 1
29 mars 17:18:50 noyau raspberrypi: [186156.181033] brcmfmac: brcmf_cfg80211_disconnect: erreur (-52)
29 mars 17:18:52 noyau raspberrypi: [186158.181028] brcmfmac: send_key_to_dongle: erreur wsec_key (-52)
29 mars 17:18:54 noyau raspberrypi: [186160.181046] brcmfmac: send_key_to_dongle: erreur wsec_key (-52)
29 mars 17:18:56 noyau raspberrypi: [186162.181048] brcmfmac: send_key_to_dongle: erreur wsec_key (-52)
29 mars 17:18:58 noyau raspberrypi: [186164.181049] brcmfmac: send_key_to_dongle: erreur wsec_key (-52)
29 mars 17:18:58 noyau raspberrypi: [186164.185477] cfg80211: Appel du CRDA pour mettre à jour le domaine réglementaire mondial
29 mars 17:18:58 raspberrypi dhcpcd [535]: wlan0: transporteur perdu
29 mars 17:18:58 raspberrypi wpa_supplicant [7354]: wpa_supplicant initialisé avec succès
29 mars 17:18:58 noyau raspberrypi: [186164.314511] brcmfmac: brcmf_cfg80211_reg_notifier: pas un code ISO3166
29 mars 17:18:58 noyau raspberrypi: [186164.314541] cfg80211: domaine de réglementation mondial mis à jour:
29 mars 17:18:58 noyau raspberrypi: [186164.314548] cfg80211: région maître DFS: non définie
29 mars 17:18:58 noyau raspberrypi: [186164.314555] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
29 mars 17:18:58 noyau raspberrypi: [186164.314565] cfg80211: (2402000 KHz - 2472000 KHz à 40000 KHz), (N / A, 2000 mBm), (N / A)
29 mars 17:18:58 noyau raspberrypi: [186164.314573] cfg80211: (2457000 KHz - 2482000 KHz à 40000 KHz), (N / A, 2000 mBm), (N / A)
29 mars 17:18:58 noyau raspberrypi: [186164.314581] cfg80211: (2474000 KHz - 2494000 KHz à 20000 KHz), (N / A, 2000 mBm), (N / A)
29 mars 17:18:58 noyau raspberrypi: [186164.314592] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (N / A)
29 mars 17:18:58 noyau raspberrypi: [186164.314602] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 s)
29 mars 17:18:58 noyau raspberrypi: [186164.314611] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N / A, 2000 mBm), (0 s)
29 mars 17:18:58 noyau raspberrypi: [186164.314645] cfg80211: (5735000 KHz - 5835000 KHz à 80000 KHz), (N / A, 2000 mBm), (N / A)
29 mars 17:18:58 noyau raspberrypi: [186164.314654] cfg80211: (57240000 KHz - 63720000 KHz à 2160000 KHz), (N / A, 0 mBm), (N / A)

Merci pour l'offre, mais c'est maintenant entre les mains de Broadcom.

Une mise à jour de Broadcom s'il s'agit d'un bogue qui sera corrigé? J'ai maintenant une configuration de travail cron pour faire descendre et monter wlan0 quand il ne parvient pas à cingler.

mise à jour rapide de mon côté, je pourrais résoudre le problème semble être lié au pilote, j'ai installé Ubuntu MATE 16.04 avec le noyau 4.4.8 et je n'ai eu aucun problème avec le wifi depuis

Je veux dire qu'ils annoncent: "Ubuntu MATE 16.04 a également Bluetooth et Wifi pleinement fonctionnels sur le Raspberry Pi 3", ce qui semble vrai

peut-être que cela fonctionne aussi avec une nouvelle version de Debian, ce que je ne peux pas dire

@ juched78 Utilisez -vous un noyau 4.4? Sinon, lancez sudo rpi-update pour obtenir la dernière version 4.4.8 et voir si cela souffre du même problème.

Les pilotes Broadcom ont considérablement changé depuis la version 4.1, et notre arborescence 4.4 inclut des back-ports de certains correctifs qui sont entrés dans 4.5. Je ne suis au courant d'aucun bogue en suspens en dehors de l'échec du réveil du sommeil (la gestion de l'alimentation est toujours désactivée) - les canaux 12 et 13 sont utilisables là où cela est permis et le mode Ad Hoc ne plante pas - mais il peut toujours y avoir des problèmes cachés .

Oh, il y a encore un bug signalé dans la 4.4.8 - une utilisation apparemment intensive de hostapd peut conduire à un avertissement du noyau (voir https://github.com/raspberrypi/linux/issues/1375).

Je cours:
Linux XXX 4.4.8-v7 + # 880 SMP ven 22 avril 21:55:04 BST 2016 armv7l GNU / Linux

27 avril 2016 11:06:18
Copyright (c) 2012 Broadcom
version 9b52ab7b475f4a056658fd2d95d2440b32167390 (propre) (libération)

Avec mon Netgear R7000 exécutant Shibby Tomato, environ 2 jours dans le wifi tombe, et dans les journaux système, je vois:

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

Ensuite, il semble ne jamais se reconnecter ...

L'utilisation de sudo ifdown wlan0 suivi de sudo ifup wlan0 ramène ma connexion.

Je viens de passer à:
Linux JuchePi 4.4.8-v7 + # 881 SMP Sam 30 avril 12:16:50 BST 2016 armv7l GNU / Linux

Je ne sais pas ce qui est différent du 22 au 30. Je surveillerai la connexion.

Mon RPi 3 a également rencontré ce problème. J'ai reçu quelques messages du noyau différents. Principalement l'un de ceux ci-dessous.
Après cela, je peux faire fonctionner le WiFi, abaisser puis augmenter wlan0 n'aide pas.

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 est alimenté par l'adaptateur secteur d'origine pour la version 3. J'utilise la dernière OSMC:
$ uname -a
Linux osmc 4.4.8-3-osmc # 1 SMP PREEMPT dim 1 mai 18:57:43 UTC 2016 armv7l GNU / Linux

Surveillance toujours. Openhab s'est déconnecté après 3 jours de course, mais pour une raison quelconque, je pouvais toujours ssh dans le Pi, ce que je ne pouvais généralement pas. Le début de l'heure et le script wifi ont fonctionné pour arrêter et rétablir la connexion, puis il s'est reconnecté à mon organisation openhab. Impair. Continuera à regarder.

Je rencontre également le même problème - trace dmesg comme suit:

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)

Usage:

rp3 est utilisé comme routeur / point d'accès

La longueur de la connectivité semble aléatoire - j'ai eu jusqu'à deux semaines et aussi mauvaise que quelques minutes. Dernièrement, il sort toutes les 20 minutes environ. La désactivation et la sauvegarde de wlan0 ne résout pas le problème - un redémarrage complet est nécessaire.

Le problème semble être exacerbé lors de la diffusion de Netflix depuis mon AppleTV. Bien que ce ne soit pas le cas lorsque j'ai eu les deux semaines de disponibilité.

Je suis sur 4.4.10-v7 +

J'ai changé le canal de 13 à 6 pour vérifier si cela pouvait être le problème (il y avait des défauts sur les canaux hauts) et depuis lors, je n'ai pas eu de gel WiFi. Mais cela pourrait être une coïncidence ...

Changer les canaux des points d'accès n'a pas aidé. Le WiFi est toujours en panne. Ces dernières fois, j'ai dû redémarrer plusieurs fois de suite pour le faire fonctionner.

Je rencontre ce problème spécifiquement lorsque j'essaie de faire un transfert SFTP entre le rpi3 et mon téléphone Galaxy S5. Lorsque j'essaie d'effectuer le même transfert depuis mon ordinateur portable, tout se passe bien.

Exécution du dernier noyau à partir de rpi-update:

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

Message d'erreur de syslog:

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

Il semble que la seule solution après cette erreur soit un redémarrage.

J'ai fait déposer le mien sur le réseau deux fois la semaine dernière. La première fois que j'étais pressé, je l'ai simplement débranché et redémarré. Quelques jours plus tard, cela s'est produit à nouveau, redémarré à nouveau, puis exécuté des mises à jour complètes du système (y compris le micrologiciel) et surveillera. Installez-le sans moniteur à proximité, donc obtenir des détails sur l'erreur nécessite plus d'efforts :)

Même problème ici. Il se fige toujours lors du transfert de gros fichiers par sftp. Il suffit de redémarrer pour résoudre

Ce problème peut être lié à https://github.com/raspberrypi/linux/issues/1313

Broadcom dit que # 1313 n'est pas un problème, et le dernier noyau n'affiche plus ces messages.

J'ai été incapable de reproduire ce problème. Quelqu'un a-t-il pu capturer une trace de paquet au moment de l'échec?

Si quelqu'un a le temps de faire plus de tests avec un module de pilote activé pour le débogage, ce serait très apprécié:

1) Exécutez sudo rpi-update et redémarrez. Il s'agit de mettre votre noyau au même niveau que le mien afin que le module soit compatible.

2) Téléchargez et installez le module de pilote mis à jour:

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

Redémarrez pour activer les nouveaux modules.

3) Utilisez votre Pi comme d'habitude, puis si votre WiFi se bloque, exécutez:

dmesg > wifi_freeze.txt

et téléchargez-le sur votre site de collage préféré (ou créez un Gist). Un ou deux journaux devraient suffire.

Pour restaurer la version d'origine du module:

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

Merci d'avance.

Attendez un moment pendant que nous vérifions que la sortie de débogage est vraiment activée.

Vous devrez également activer une fonction de débogage sur le pilote:

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

J'ai modifié les instructions ci-dessus.

Après un redémarrage, votre sortie dmesg devrait inclure quelque chose comme ceci:

[   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 après avoir exécuté vos instructions je n'ai plus de wifi ...

root @ pi3b : / home / pi # dmesg | grep brcmf
[15.582665] brcmfmac: symbole inconnu brcmu_dbg_hex_dump (err 0)
[15.613709] brcmfmac: symbole inconnu brcmu_dbg_hex_dump (err 0)

Essaye ça:

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

Et redémarrez.

wlan0 ne s'associe pas.
wireless.txt
(dans l'un des nombreux redémarrages, j'ai vu une association pendant quelques minutes, je ne l'ai pas (encore) attrapée dans dmesg)

Il semble que le problème ait pu être résolu pour moi en passant de 4.4.11-v7 + à 4.4.15-v7 +

J'ai essayé de recréer les problèmes que j'avais avec les transferts SFTP à partir d'un téléphone Android, mais je ne vois aucun problème pour le moment.

@pelwell après une longue attente, wlan0 a réussi à s'associer; ajouté dmesg au journal précédent:
wireless.txt
en attente maintenant de gel ou de perte d'association
j'espère que c'est utile

@pelwell a rapidement perdu à nouveau la connexion; ajouté dmesg à:
wireless.txt

Merci. C'était lent pour moi la première fois. J'ai été occupé à obtenir un Raspbian propre et à appliquer les correctifs pour essayer de reproduire le problème - je continuerai quand même.

@pelwell
wireless.txt
et réassocié à nouveau: ajout de dmesg à nouveau
veux-tu que je continue?

@pelwell : une nouvelle association perdue
wireless_associationloss.txt

@pelwell
il s'allume / s'éteint irrégulièrement
wireless_associationloss.txt

Je pense que vous feriez mieux de revenir maintenant avant que ma boîte de réception ne déborde.

D'accord; Je reviendrai à mon dongle MT7601U à 3 €. ;)

Merci pour votre aide jusqu'à maintenant,

Je viens de trouver ce problème, puis-je confirmer qu'il est similaire à ce que je vois? J'ai configuré un RPi 3 comme point d'accès et de temps en temps je suis incapable de me connecter. Je suis capable de ssh via la connexion filaire et je vois que wlan0 est toujours en place avec la bonne adresse IP, mais la seule façon de faire fonctionner le point d'accès à nouveau est de redémarrer. Je vois des traces de pile comme celle-ci dans /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 ]---

Mon noyau est 4.4.13-v7 + et je viens de lancer rpi-update pour la première fois donc je ne sais pas encore si cela aidera.

Je me demande si cela pourrait être lié, ou peut-être un problème distinct
https://www.youtube.com/watch?v=_D_fi_ck9Vo

Mon RPI3 a fonctionné sans aucun problème via WiFi jusqu'à ce que je le mette à niveau vers le dernier udev ...

Maintenant, ça ne se connecte plus ...

J'ai également installé des modules patchés de Pelwell mais nous n'avons pas réussi: simplement ça ne se connecte pas ...

Faites-moi savoir si je peux vous aider,

Mon meilleur,
Mimmo

@ dh-connect votre problème a-t-il été résolu? Si tel est le cas, veuillez fermer ce problème. Merci.

Je travaille avec lan depuis, je n'ai pas essayé le wlan

Salut,

J'ai ce qui semble être le même problème avec mon rpi 3. Je suis revenu à l'utilisation du dongle USB wifi officiel RPI qui est solide comme le roc, mais le wifi intégré meurt après ~ 20 heures de connectivité avec ce type de messages dans syslog

brcmfmac: brcmf_cfg80211_reg_notifier: pas un code ISO3166
cfg80211: Domaine réglementaire mondial mis à jour:
cfg80211: région maître DFS: non définie

c'est sur le dernier raspbian, le dernier firmware

Est-il possible de rouvrir ce numéro?
Pourquoi a-t-il été fermé?

Je travaille avec lan depuis, je n'ai pas essayé le wlan
dh-connect fermé il y a 13 jours

Ce n'est pas une solution qui vaut la peine de clore le problème ...

J'ai toujours le problème et je peux reproduire le bogue.

Ma partie pertinente de dmesg est:

[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

Je rencontre le même problème que @jrmhaig et mis à niveau maintenant

$ 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

Configuration hostapd avec un pont.

/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

Pour les personnes ayant des problèmes de WiFi, Cypress (anciennement Broadcom) nous a fourni des modules de débogage pour aider à diagnostiquer les problèmes. Les modules étant spécifiques à la version du noyau, vous devrez d'abord mettre à jour (ou éventuellement revenir) à une version de micrologiciel spécifique:

sudo rpi-update b0ef6e25679d3612a980708cf4c3907ce6e13e84
sudo shutdown -r now

Vous pouvez maintenant télécharger et installer les modules de débogage:

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

La commande finale exécutera le script d'installation, qui copie les modules d'origine d'un côté avant de les remplacer par les versions de débogage. L'exécution de la commande à nouveau reviendra aux versions d'origine.

Après l'installation, redémarrez votre Pi 3 - maintenant dmesg | grep brcmfmac affichera un message de diagnostic comme celui-ci:

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

Lorsque vous rencontrez un problème, utilisez dmesg > wifidbg.txt pour capturer le suivi dans un fichier, ainsi que tous les autres messages du noyau, puis téléchargez le fichier quelque part (gist, pastebin, dropbox, etc.) et publiez un lien vers celui-ci avec une description de ce que vous faisiez lorsque l'erreur s'est produite.

veuillez rafraîchir ma mémoire: quelle commande utiliser pour revenir au firnmware stable
si je décide d'arrêter le débogage?

sudo apt-get update
sudo apt-get upgrade

devrait faire l'affaire. Et sudo ./brcmdbg pour simplement revenir aux pilotes non débogués.

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

Débogage commencé; il fallait environ 5 ou 6 essais pour s'associer; je ne sais pas pourquoi la dernière tentative a échoué; va le laisser fonctionner jusqu'à ce que je vois la perte d'association et vider un nouveau dmesg alors. Un comportement d'association incohérent était mon problème avant d'arrêter d'utiliser le wifi à bord, donc cela pourrait être sur place. Veuillez me faire savoir si des activités supplémentaires pourraient être utiles.

https://gist.github.com/BenoitSvB/bf8acdbb7b664df90e885603bb4774ce#file -201609081628_wifidbg-txt
Ne rien faire d'autre qu'attendre; voit-on ici plusieurs pertes / récupérations d'association?

Merci pour ça. Hmm - ces journaux ne sont pas très informatifs, mais voyons ce que Cypress revient avec.

https://gist.github.com/BenoitSvB/98db53ff884e7b1a57bf1475d6106c56
Perte inexpliquée et rétablissement de l'association; assez longtemps pour voir dans l'icône systray.
Le point d'accès est Linksys wrt160n avec le micrologiciel: DD-WRT v24-sp2 (08/07/10) std.
Je suppose que je peux arrêter le débogage pour l'instant et revenir à mon dongle MT7601U à 3 €, mais faites-moi savoir si je peux être d'une aide supplémentaire.

@pelwell Je n'ai vu aucune restauration de firmware après sudo apt-get update && sudo apt-get upgrade et sudo rpi-update donne
*** Votre firmware est déjà à jour; Je suppose que j'ai besoin d'exécuter rpi-update avec un hachage git spécifique pour revenir au firmware stable. Savez-vous quel hash?

L' historique des validations dans le référentiel

sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab

@pelwell :
root @ pi3b : / home / pi # sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab
** Mise à jour du firmware Raspberry Pi par Hexxeh, amélioré par AndrewS et Dom* * Effectuer une mise à jour automatique
** Redémarrage après la mise à jour* * Mise à jour du firmware Raspberry Pi par Hexxeh, amélioré par AndrewS et Dom
Hachage git non valide spécifié

Ah, le micrologiciel Hexxeh rpi a différents ID de validation - essayez 569e6611ac20c735647eb0e550484a73935a672d.

Je me demande si https://github.com/raspberrypi/linux/issues/1552 / # 1444 pourrait également être lié à ce problème.

J'ai récemment déployé une configuration 40xRPI3 qui fait des trucs bluetooth, nous devions obtenir des interfaces wifi usb sinon le wlan se figerait constamment .. Nous utilisons maintenant le périphérique bl interne et le module wifi interne est mis sur la liste noire dans modprobe.d.

Il pourrait peut-être être utile de faire hcitool name 11:11:11:11:11:11 et de voir si cela génère également des entrées de journal intéressantes. Je viens de suivre ce problème, je n'ai pas eu le temps de configurer mon environnement de laboratoire pour tester quoi que ce soit moi-même. Nous avons eu quelques gels de wifi sans BT activé mais la combinaison wifi + bt peut plus ou moins toujours tuer le wifi dans un laps de temps très court .. C'était toujours reproductible sur n'importe quel nombre de nos rpi

@pelwell
D'ACCORD; uname -a donne Linux pi3b.thuis 4.4.13-v7 + # 894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU / Linux
Juste pour information: où trouverait-on le hachage git pour la version actuelle du firmware stable?

@thomasf
bien que j'aie Bluetooth, je n'en ai aucune utilité pour le moment.hcitool name 11: 11: 11: 11: 11: 11 ne renvoie rien; ce qui est, je suppose, à prévoir car je ne suis connecté à aucun appareil. Je devrais peut-être m'acheter un appareil audio BT pour jouer avec.

Définissez stable.

Le hachage que je vous ai (enfin) donné concerne la version du firmware du 20 juin, que vous obtiendrez si vous exécutez:

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

Je ne connais pas un seul endroit contenant le hachage de la version "stable" la plus récente, mais en passant par RPI-Distro comme je l'ai fait, puis en faisant des références croisées avec le repo Hexxeh, vous pouvez obtenir des hachages de mise à jour rpi pour n'importe quelle version vous aimez. Si vous considérez que la version 2016-05-23 est stable parce qu'elle faisait partie de la dernière version complète de Raspbian, vous voulez le hachage 3b98f7433649e13cf08f54f509d11491c99c4c0b qui se traduit par un hachage de mise à jour rpi de 2b9c0bfacfc11ee8bb9b309dc9cdb8368288bb9b309cdb8368.

@BenoitSvB Le simple fait d' exécuter cette commande hcitool à partir d'un nouveau démarrage sans toucher hci0 avec aucun autre logiciel fait que le wifi commence à se comporter mal dans nos tests, je ne sais pas si ça compte s'il y a d'autres périphériques Bluetooth mais c'est le plus petit exemple reproductible Je peux penser à déclencher les problèmes de gel du wifi.

J'ai également testé le dongle bt externe + le wifi interne mais le wifi interne se bloque parfois même lorsque le pilote bcm bt interne n'est pas chargé. La "solution" (comme dans la solution rapide) pour nous était d'utiliser des adaptateurs wifi USB, qui s'est avérée stable dans nos tests et notre utilisation en production.

Je soupçonne toujours # 1313 d'être lié.

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

J'ai également testé un dongle bt externe + wifi interne mais le
le wifi se bloque parfois même lorsque le pilote bcm bt interne n'est pas
chargé. La "solution" (comme dans la solution rapide) pour nous était d'utiliser le wifi USB
adaptateurs, qui a été prouvé stable dans nos tests et notre utilisation en production.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245649229,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFyzObJxRjzQ-uMUlfe8hjRasrfq3nkwks5qoDLXgaJpZM4HupC5.

@pelwell
stable serait dans ce cas le firmware publié par la Fondation avec sa dernière image publiée et mis à jour par "sudo apt-get update && sudo apt-get upgrade" uniquement, donc sans invocation de rpi-update (avec ou sans git spécifique hash, qui est destiné, comme je l'ai compris, pour la mise à niveau vers un firmware plus récent à des fins spécifiques uniquement).
Ce qui m'amène à la question: puis-je lire le hachage de mon firmware opérationnel avant de charger un nouveau firmware pour le test, pour faciliter une restauration après le test car je ne me fierais pas à la conduite de la référence croisée que vous avez mentionnée ...

Peut-être que - cat /boot/.firmware_revision est écrit par rpi-update, mais
sans l'essayer, je ne pourrais pas vous dire si les versions de Raspbian écrivent aussi
il.

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

Mais j'ai trouvé avec:

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

que je veux en effet:

• firmware à partir de 390f53ed0fd79df274bdcc81d99e09fa262f03ab

Je comprends le crossref de
https://github.com/RPi-Distro/firmware/commits/debian?author=popcornmix à
https://github.com/Hexxeh/rpi-firmware/commits/master est fait avec soin
comparer les dates et les descriptions des commits.

J'ai appris quelque chose; thnx :)

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

Peut-être que - cat /boot/.firmware_revision est écrit par rpi-update, mais
sans l'essayer, je ne pourrais pas vous dire si les versions de Raspbian écrivent aussi
il.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245693018,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFyzOQ_pfODaEmuBGR6pQVXs2W6LggW8ks5qoFO2gaJpZM4HupC5
.

@BenoitSvB : Vos traces semblent montrer un type de problème différent - le micrologiciel ne donne aucun indice sur la raison pour laquelle vous êtes déconnecté. Vous pourriez obtenir d'autres indices d'un renifleur de paquets tel que WaveShark.

@mathieugouin @ dh-connect @ juched78 @maciex @duncanmcdowell : J'ai un ingénieur Cypress qui souhaite en savoir plus sur vos problèmes; si vous m'envoyez un e-mail - phil at raspberrypi dot org - je peux vous mettre en contact avec lui. Si vous voulez accélérer les choses, installez les modules de débogage comme indiqué ci-dessus et enregistrez la sortie de dmesg lorsque les choses tournent mal.

@pelwell Google n'a pas retourné beaucoup de choses sur le «renifleur de paquets Waveshark» mais je suppose que vous vouliez dire WireShark. Le fait que la liste noire de brcmutil & brcmfmac lors de l'utilisation d'un dongle MT7601U fait disparaître le comportement erratique de connexion / déconnexion, combiné avec les fréquentes occurrences de `` hors-ordre '' (voir # 1313, maintenant masqué mais non résolu) me fait suspecter un Broadcom / Cause matérielle Cypress.
Wireshark pourrait être utile, mais j'aurais besoin d'aide pour configurer / mener un effort matériel de débogage sérieux.

Oui, je voulais dire Wirehark.

Vous pouvez utiliser l'utilitaire dumpcap (qui fait partie du package tshark en mode texte) pour enregistrer toutes les activités dans un fichier, puis le tuer lorsque le journal dmesg contient un message suspect. Quelque chose comme ça:

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

Notez que bien que "grep --max-count 1" soit censé s'arrêter après une correspondance, il semble nécessiter une ligne d'entrée supplémentaire pour l'arrêter, mais cela ne devrait pas être un problème en pratique.

Si votre fichier de capture devient trop volumineux, vous pouvez demander à dumpcap d'utiliser un enregistrement à durée fixe en utilisant l'option "-b durée: 60 " (pendant une minute). Il est possible que le redémarrage de la capture comme celui-ci puisse se produire à un mauvais moment et perdre les paquets intéressants, mais c'est peu probable. Vous pouvez toujours le rendre moins probable en augmentant la durée.

@BenoitSvB Il y a un fil de discussion ici qui suggère de désactiver l'itinérance dans le pilote WiFi Pi3 pour éviter les problèmes de connectivité. L'itinérance permet à un appareil de se déplacer automatiquement entre des points d'accès avec le même SSID, mais cela sera probablement moins utile sur un appareil statique tel qu'un Pi3, et il y a une suggestion que cela peut éventuellement conduire à une perte totale de connectivité.

Pouvez-vous essayer d'activer le paramètre de module roamoff ? Vous devez créer create /etc/modprobe.d/brcmfmac.conf contenant les éléments suivants:

options brcmfmac roamoff=1

@pelwell : désactiver l'itinérance n'est pas la solution; mais ça me fait jouer avec différents canaux et un deuxième point d'accès. J'ai découvert que l'adaptateur wifi embarqué n'a des problèmes qu'avec certains canaux (par exemple 1, 5) et uniquement sur le Linksys WRT160N avec le firmware DD-WRT. Curieusement, aucun de mes autres clients wifi n'a partagé ce problème: ils se connecteront sans problème sur tous les canaux proposés sur les deux points d'accès. Bon pour moi, j'ai une solution de contournement stable (ne pas utiliser de canaux à bord du wifi a des problèmes avec) mais aucune clarté en la matière.
Voulez-vous que je fasse des tests spécifiques?
Au fait, devons-nous définir le paramètre
options brcmfmac debug = 1
dans le fichier /etc/modprobe.d/brcmfmac.conf en utilisant les pilotes de test spéciaux?
Et connaissez-vous un moyen de mesurer la disponibilité d'une association wifi: alors je pourrais tester plus systématiquement tous les canaux pendant des périodes plus longues sans faire de gigantesques fichiers de capture.

On m'a assuré que le débogage demandé est activé par défaut dans les pilotes de débogage (il a le même effet que options bcrmfmac debug=0x100000 ), mais n'hésitez pas à expérimenter avec différentes valeurs.

Je ne connais aucun moyen de mesurer le temps de disponibilité d'une association, à part des sondages fréquents et l'espoir de repérer un changement.

Un employé de Cypress est au courant de ce fil, mais envoyez-moi un e-mail (phil at raspberrypi dot org) si vous êtes heureux d'être contacté directement.

Bonjour,

Y a-t-il des progrès sur cette question? Je peux me connecter à mon réseau Wi-Fi ouvert, et après un temps aléatoire, je l'ai dans mes journaux:

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

Et puis je ne peux pas cingler le routeur.

Après un ifdown wlan0 && ifup wlan0 cela fonctionne à nouveau, jusqu'au prochain wlan0: carrier lost .

La gestion de l'alimentation est désactivée, le Bluetooth est désactivé, l'itinérance est désactivée (comme vous l'avez suggéré) et ma version est Linux pi3 4.4.17-v7+ .

cela arrivait toujours lorsque pont eth0 avec wlan0 ， j'ai eu le même problème que https://github.com/raspberrypi/linux/issues/1375

J'ai exactement le même problème de décrochage du WiFi embarqué Pi3 après une période aléatoire. ifup le fait fonctionner à nouveau sans problème.

Après de nombreuses recherches, j'ai trouvé que c'était dû à trois points d'accès (BSSID) avec un SSID (1 chacun sur les canaux 1, 6 et 11). Cette configuration prend en charge l'itinérance transparente et fonctionne parfaitement avec tous les autres clients WLAN.

L'activation du débogage / de la journalisation avec le pilote standard semble montrer qu'à un moment donné, le Pi décide de se désauthentifier et même de mettre en liste noire l'un des BSSID. La raison n'est pas claire, mais semble être une décision prise à l'extrémité Pi.

Quand j'ai exactement la même configuration sur le Pi mais avec un seul BSSID pour le SSID, Pi peut s'accrocher pendant des jours sans accroc.

Malheureusement, la désactivation de l'itinérance selon le lien de pelwell (http://projectable.me/optimize-my-pi-wi-fi/) n'est pas vraiment faisable, avoir un seul BSSID par SSID n'est pas une option, et je plutôt ne pas avoir à compter sur un script qui envoie un ping à un hôte et exécute ensuite ifdown / ifup.

Une enquête plus approfondie est-elle en cours pour prendre en charge plusieurs BSSID par SSID, ou puis-je faire quelque chose spécifiquement pour soutenir l'enquête?

Merci!

J'ai ce problème et mon réseau est similaire à celui de @TheOriginalMrWolf .
J'ai une station de base Apple et un aéroport express dans une configuration maillée utilisant WDS.

J'ai aussi ce problème. Si je copie des fichiers sur un partage samba, la connexion wifi est perdue (raspberry 3, nouveau raspbian installé).
Syslog:
brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012

Je reçois exactement le même problème lorsque je joue de la musique avec upnp (gmediarender).

J'ai le même problème lors du démarrage des appels vocaux sur wechat, avec le rpi comme AP utilisant hostapd. Je reçois un tas de spam comme celui-ci:

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

Avec des traces comme celle-ci:

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

La trace ressemble étrangement à celle de

Je viens de faire recommencer et j'ai fait du débogage. J'ai reçu des messages différents cette fois, qui semblent intéressants (il semble que ce soient les mêmes messages que @maciex a reçu une fois):

[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. Il semble que tout le système se fige lorsque cela se produit. L'exécution de while sleep 1; do date; done dans une boucle entraîne un espace lorsque le gel se produit. Je me demande si cela signifie que brcmf_proto_bcdc_msg renvoyant -110 (timeout) n'est qu'un symptôme du vrai problème - il enregistre juste là où nous gèlons.
2. J'ai mesuré (avec vcgencmd ) la température et les tensions au moment du gel. Rien à signaler là-bas, pour autant que je sache.
3. Mon système est un AP avec transfert vers un modem ZTE 4G via USB (c'est-à-dire. client -> wlan0 -> rpi -> usb0 -> 4g . Il semble que usb0 soit toujours capable d'accéder à Internet lorsque le gel du wifi se produit.

Re: les commentaires ci-dessus, cela se produit en mode de partage NAT pour moi avec roamoff=1 . Aucun de ceux-ci n'a résolu ou atténué le problème pour moi.

Après avoir désactivé WPA (en utilisant create_ap -w 2 dans mon cas pour activer uniquement WPA2), le problème semble résolu. Je ne sais pas pourquoi.

Je suis également confronté aux problèmes signalés ici. Dans mon cas, cela se produit chaque fois que j'accède à des fichiers (généralement mp3) via Samba à partir du gestionnaire de fichiers et du lecteur Samsung + ES.

Mon Raspberry Pi3 est connecté en wifi à mon AP. Par conséquent, toute la communication avec elle est pensée par réseau wifi. Il n'a ni moniteur, ni clavier, ni souris.

Je peux facilement reproduire l'erreur, donc si quelqu'un veut que je produise des fichiers journaux, dites-moi comment je pourrais vous aider.

Ci-dessous mes entrées syslog.

27 décembre 16:11:50 noyau raspberrypi: [560.902063] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
27 déc 16:11:52 noyau raspberrypi: [562.928930] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec l'état -110
27 déc 16:11:54 noyau raspberrypi: [564.926659] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec état -110
27 déc 16:11:54 noyau raspberrypi: [564.926820] brcmfmac: brcmf_cfg80211_get_station: échec de GET STA INFO, -52
27 déc 16:11:56 noyau raspberrypi: [566.924560] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec état -110
27 déc 16:11:58 noyau raspberrypi: [568.922555] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec l'état -110
27 déc 16:11:58 noyau raspberrypi: [568.928073] brcmfmac: brcmf_cfg80211_get_station: échec de GET STA INFO, -52
27 décembre 16:12:00 noyau raspberrypi: [570.920675] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec l'état -110
27 décembre 16:12:02 noyau raspberrypi: [572.918980] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec l'état -110
27 déc 16:12:02 noyau raspberrypi: [572.924580] brcmfmac: brcmf_cfg80211_get_station: échec de GET STA INFO, -52
27 décembre 16:12:04 noyau raspberrypi: [574.917259] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec l'état -110
27 décembre 16:12:06 noyau raspberrypi: [576.915703] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec l'état -110
27 déc 16:12:06 noyau raspberrypi: [576.921498] brcmfmac: brcmf_cfg80211_get_station: échec de GET STA INFO, -52
27 déc 16:12:06 raspberrypi ifplugd (wlan0) [1149]: Utilisation du mode de détection: IFF_RUNNING

@rcassaniga
J'ai également eu le même problème avec la configuration identique.

Solution après des heures de débogage:
Désactivez IPv6 sur la framboise dans /etc/modprobe.d/ipv6.conf:
alias net-pf-10 désactivé
alias ipv6 désactivé
option ipv6 disable_ipv6 = 1

Il s'agit uniquement d'une solution de contournement si vous n'utilisez pas ipv6 dans votre réseau.

Merci @ varl0g tu es mon héros! :)
Il semble que cette solution de contournement fonctionne pour moi, je ne peux plus reproduire le problème.

@ varl0g : Il

Merci et bonne année 2017.

J'ai essayé d'éteindre ipv6. Cela n'a pas fait de différence. J'ai essayé de désactiver le mode d'économie d'énergie. Toujours aucune différence. Cependant, lorsque je règle le canal de mon AP sur 6 (au lieu de 11), mon Raspberry Pi est en service depuis 2 jours sans aucun problème!

Je voudrais confirmer que la solution de contournement avec la désactivation d'IPv6 ne fonctionne pas.
Malheureusement, j'ai le même problème avec mon routeur RPi3 et Apple Airport Extreme.

@rajid , @ dh-connect
Étonnamment, cela a également résolu mon problème lorsque j'ai changé le canal wifi de mon AP à 6 au lieu d'automatique, merci @rajid

J'ai aussi ce bogue - brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
Où réparer ????
j'essaye le noyau 4.9, le noyau 4.4.41 - tous ont ce bogue. Alimentation 2.4a.

Je dois révoquer mon commentaire précédent concernant le canal 6. Apparemment, c'était une coïncidence si mon RPI3 avait un WiFi stable pendant 6 jours.

Je me demande simplement si quelqu'un a eu de la chance avec ce problème. J'ai essayé de désactiver la gestion de l'alimentation, le Bluetooth et le changement de canal. Rien jusqu'à présent n'a fonctionné. J'utilise Octoprint avec une webcam attachée. Cela semble arriver assez souvent, et je remarque que cela arrive beaucoup plus fréquemment lorsque plusieurs connexions http sont établies.
Erreur syslog avant le mode d'économie d'énergie:
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
Erreur syslog après le mode d'économie d'énergie:
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 !!!
J'utilise actuellement Linux octopi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

J'ai finalement obtenu que mon RaspPi 3 soit stable sur mon wifi en changeant le canal 2.4Ghz de mon wifi en "6". J'ai oublié ce que c'était avant, je pense, mais je ne suis pas sûr. Cela n'a pas bien fonctionné et j'ai trouvé une page Web qui disait que c'était un problème mais 6 fonctionne bien. C'est beaucoup mieux depuis que j'ai basculé le wifi de ma maison sur le canal 6.

/ raj

Le 3 mars 2017, à 20h39, Daniel < [email protected] [email protected] > a écrit:

Je me demande simplement si quelqu'un a eu de la chance avec ce problème. J'ai essayé de désactiver la gestion de l'alimentation, le Bluetooth et le changement de canal. Rien jusqu'à présent n'a fonctionné. J'utilise Octoprint avec une webcam attachée. Cela semble arriver assez souvent, et je remarque que cela arrive beaucoup plus fréquemment lorsque plusieurs connexions http sont établies.
Erreur syslog avant le mode d'économie d'énergie:
brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
Erreur syslog après le mode d'économie d'énergie:
noyau octopi: [10317.342360] brcmfmac: brcmf_sdio_bus_txdata: hors bus-> txq !!! noyau octopi: [10317.342593] brcmfmac: brcmf_sdio_bus_txdata: hors bus-> txq !!! noyau octopi: [10327.358384] brcmfmac: brcmf_sdio_bus_txdata: hors bus-> txq !!!
J'utilise actuellement Linux octopi 4.1.19-v7 + # 858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU / Linux

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, visualisez-le sur GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-284126948 , ou désactivez le fil 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

le canal 6, largeur de canal 20 MHz, semble stable depuis des semaines maintenant.

J'avais observé le même problème que celui signalé pour la première fois par @ dh-connect, c'est-à-dire que je voyais l'erreur -52 lignes de journal. La désactivation de l'économie d'énergie pour l'interface wifi n'a pas aidé. La désactivation d'ipv6 comme suggéré par @ varl0g a résolu mes problèmes. Le Wifi est maintenant stable pendant des jours et des jours alors qu'il tombait en panne quelques minutes après le démarrage.

Je n'ai pas eu de chance sur le canal 6 ou 7. n'a confirmé personne d'autre sur ces canaux.
J'ai essayé de faire clignoter mon sd avec une nouvelle image et maintenant mes contrôleurs wifi ne reçoivent pas de baux DHCP appropriés. Ils démarrent avec les ips locaux 169.254.xx.xx, pas le sous-réseau de mon serveur DHCP.

Décidé de simplement l'essuyer et d'installer le plus récent raspbian et d'installer octoprint à partir de la source. jusqu'à présent, aucun problème.

D'après ce que je peux dire, c'est un problème dans le logiciel du pilote de brcm80211 sdio.c lui-même.
La chaîne 0x40012 est vraiment 0x00040012, qui, lorsqu'elle est interprétée à l'aide des masques et des codes d' ici ~ ligne 55, peut être considérée comme une chaîne de boîte aux lettres indiquant un changement de contrôle de flux vers DEVREADY. Ce qui est étrange, c'est que la chaîne n'est jamais interprétée comme telle, et atteint donc la section rétrocompatible du pilote ~ ligne 1127 du fichier sdio.c dans la source brcm80211 / brcmfmac ici .

Je n'ai pas une grande expérience avec le pilote lui-même, ni la capacité de recompiler et de tester (je n'ai qu'un seul rpi3, et je préfère ne pas gâcher l'environnement dans lequel il vit actuellement. De plus, je ' Je ne suis pas familiarisé avec la recompilation / la mise à jour des pilotes Linux ..) donc je ne suis pas tout à fait sûr, mais il semble que deux messages HMB soient envoyés dos à dos si rapidement, le pilote n'a pas assez de temps pour les interpréter tous les deux .

Pour ceux qui se demandent, j'exécute actuellement octoprint (construit manuellement) sur mon rpi3 sans fil (duh ..) avec l'écran tactile capacitif adafruit pitft2.8 "et le noyau personnalisé d'adafruit (v 4.4.27-v7 +) et dupliquer le problème lorsque essayer d'accéder au flux vidéo (Logitech C270) sur mon Samsung Galaxy S7 via PrintDroid pro ou via Chrome. Le verrouillage se produit sans échec à chaque fois que cela est effectué et ne se produit que sur le sans fil. J'ai mis à niveau l'alimentation, désactivé ipv6 et gestion de l'alimentation, en vain.

@TGYK Pouvez-vous consulter le problème référencé - cela vous semble-t-il le même? Quels messages recevez-vous dans dmesg? kevent est tombé?

@TGYK. Vous avez un lien vers la page originale de Broadcom github - pouvez-vous donner une indication sur l'endroit où les problèmes apparaissent dans l'arborescence du noyau Raspberry Pi ici? Peu difficile de savoir à quelles lignes de code vous faites référence.

sdio.c est ici dans l'arborescence 4.9 https://github.com/raspberrypi/linux/tree/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac.

@ JamesH65 Dans la page github que vous avez liée, la ligne à laquelle je fais référence se situe vers 1140-1147. En ce qui concerne l'erreur dmesg, le message est le même problème que ci-dessus:
"Contenu de données de boîte aux lettres inconnu: 0x40012", suivi d'erreurs escan (-52).

Le même problème que votre sujet référencé ne se produit pas, car je ne relie en aucun cas mes interfaces sans fil et filaires. Pour autant que je sache, mon problème, et celui de ce fil, concerne uniquement l'interface sans fil.

Merci pour l'information. Le problème éventuellement lié est, je crois, similaire en ce sens qu'il s'agit d'un problème avec le pilote Wifi qui peut éventuellement recevoir un message étrange causant plus de bizarrerie plus tard dans la pile, mais je suis toujours en train de creuser.

J'ai le même problème avec un raspberry pi Zero W avec un symptôme similaire à @TGYK. Dans mon cas, j'exécute mpd sur le zéro et le contrôle via un client Android sur un Samsung Galaxy S5. Sans faute, si je mets le téléphone en veille pendant que l'application du contrôleur est en cours d'exécution (c'est-à-dire sans revenir à l'écran d'accueil au préalable), le wifi du zéro se rompt avec le message "Contenu de données de boîte aux lettres inconnu". Si je laisse simplement l'appareil inactif ou si je fais attention de toujours fermer l'application avant de laisser mon téléphone s'endormir, il reste indéfiniment allumé.

J'ai eu ce problème sur Raspian et maintenant OSMC.

Généralement intermittent, mais il est intéressant de noter que l'accès à l'interface Web Kodi à partir de mon S7 déclenchera toujours ce problème. Faire la même chose avec l'iPhone de ma femme fonctionne parfaitement et n'a jamais déclenché le problème.

@daedalia : J'ai un problème très similaire avec un Samsung Galaxy Tab S. Cependant, je n'ai pas accès à un appareil iPhone / iPad pour confirmer ...

Mon appareil Samsung plante le wifi lors de la tentative d'accès à l'interface Web tvheadend.

Cela ne se produit pas lors de l'accès à partir d'un navigateur Firefox à partir d'un PC Windows.

Heureux d'avoir trouvé ce fil, je pensais être le seul. J'ai les mêmes problèmes que les affiches ci-dessus, le wifi tombe sur mon pi3 / osmc lors de l'accès à partir d'un Samsung Galaxy Tab A. Fonctionne bien s'il est accédé à partir d'une tablette Nexus 7, d'un téléphone OnePlus ou d'un ordinateur portable Acer, seul le Samsung pose des problèmes. Facilement reproductible. Semble être le pilote wifi Samsung n'aime pas le wifi pi3 intégré? L'ajout d'un dongle wifi tp-link au pi3 est une solution de contournement pour moi.

@philborman Je suis curieux, utilisez-vous le même navigateur mobile sur le Samsung que sur le Nexus?

Les deux exécutent Chrome, mais ce n'est pas seulement un problème de navigateur. Si j'utilise Yatse pour
contrôler kodi cela fonctionne bien à partir du nexus / mobile / ordinateur portable mais pi3 WiFi tombe
si j'essaye la même chose du samsung. Idem si je ssh in, plante avec Samsung
et pas les autres. Avec ssh, je peux faire un peu, mais tous les transferts de fichiers ou
même la modification d'un fichier texte entraînera la déconnexion du wifi.

Le mercredi 12 avril 2017, 19:03 Mathieu Gouin, [email protected] a écrit:

@philborman https://github.com/philborman Je suis curieux, utilisez-vous le
même navigateur mobile sur le Samsung vs le Nexus?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-293643847 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ALmHOdtJ9AQtpfU7tmeVouI-a4STg2WMks5rvQPJgaJpZM4HupC5
.

Est-ce que quelqu'un qui commente ici a la possibilité de construire un noyau avec un correctif que j'ai qui pourrait aider à cela? Ceux-ci sont basés sur 4.9 mais pourraient fonctionner correctement sur 4.4. Attention, ce ne sont que des tests ...

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

Bonjour,

J'ai le même problème décrit ici avec l'un de mes 2 Pi3. Le wifi perd la connexion après un certain temps, peut durer entre 30 minutes et quelques heures. J'ai essayé absolument tout ce qui est suggéré ici, y compris le changement de canaux wifi sur l'AP, etc. sans succès. Ce qui est extrêmement étrange, c'est que sur mon 2ème Pi3 (rev 1.2 aussi, exactement le même), et avec la même carte SD / installation (Raspbian) que j'échange entre les deux, le Wifi est solide pendant des jours et des jours ...

C'est vraiment étrange. Les deux Pi3 sont mis à jour avec rpi-update, le noyau 4.9 et le firmware # 991, mais c'était déjà la même chose avec les versions précédentes du noyau / firmware.

Si vous faites une mise à jour rpi, vous obtiendrez les correctifs ci-dessus tels qu'acceptés par les développeurs du noyau - c'est pour le pilote smsc9x et le pilote brcmfmac, depuis hier soir. Pouvez-vous essayer ça? Si cela échoue toujours, pouvez-vous faire «dmesg» et voir s'il y a quelque chose de bizarre dans le syslog? Bien que, mon soupçon soit peut-être un défaut HW apparent car la puce sans fil se réchauffe étant donné qu'un autre Pi fonctionne bien avec la même carte.

Merci. Je l'ai fait sur le tableau suspect, le wifi s'est déconnecté après quelques minutes.
dmesg donne que:
''
[266.654964] brcmfmac: brcmf_sdio_bus_sleep: erreur lors de la modification de l'état de veille du bus -110
[266.655033] brcmfmac: brcmf_sdio_txfail: erreur sdio, commande d'abandon et fin du cadre
[266.659215] brcmfmac: brcmf_sdiod_regrw_helper: échec de l'écriture des données F1 @ 0x1000d , erreur: -110
[266.663346] brcmfmac: brcmf_sdiod_regrw_helper: impossible de lire les données F1 @ 0x1001a , erreur: -110
[266.667472] brcmfmac: brcmf_sdiod_regrw_helper: échec de lecture des données F1 @ 0x10019 , erreur: -110
[266.671608] brcmfmac: brcmf_sdiod_regrw_helper: impossible de lire les données F1 @ 0x1001a , erreur: -110
[266.675736] brcmfmac: brcmf_sdiod_regrw_helper: échec de lecture des données F1 @ 0x10019 , erreur: -110
[266.679866] brcmfmac: brcmf_sdiod_regrw_helper: impossible de lire les données F1 @ 0x1001a , erreur: -110
[266.683992] brcmfmac: brcmf_sdiod_regrw_helper: échec de lecture des données F1 @ 0x10019 , erreur: -110
[269.655049] brcmfmac: brcmf_sdio_bus_sleep: erreur lors de la modification de l'état de veille du bus -110
[272.069378] net_ratelimit: 35 rappels supprimés

......... alors cette "boucle" continue de remplir le journal dmesg plusieurs fois par minute.

Edit: j'ai touché tous les composants de la planche, ils sont tout sauf chauds, je dirais environ 30 °, juste un peu plus chaud que la peau de mes doigts.

Hmm, le truc SDIO est l'interface entre le Pi et la puce sans fil - il expire (-110). Cela ressemble à un problème matériel - à mesure que la puce chauffe, il y a peut-être un mauvais joint de soudure sur les lignes d'interface sdio quelque part, ce qui signifie que les communications se déconnectent.

Ping @ Roger-Thornton - Roger, pouvons-nous faire quelque chose pour tester cela?

@Crrispy Pouvez-vous vérifier que votre Pi n'est pas sous-alimenté - que rapporte vcgencmd get_throttled ?

@pelwell : après une perte de wifi, j'ai vérifié et étranglé = 0x0

Je ne pense pas que ce soit un défaut matériel, un simple redémarrage résout toujours instantanément le problème.

@ JamesH65 Je ne pense pas que cela ressemble à un problème de fabrication de matériel car les lignes fonctionnent toutes comme elles le devraient. S'il y a d'autres indices sur des problèmes matériels, je peux jeter un œil au tableau.

Cela ne semble pas être le même problème que le mien. Je n'ai qu'un seul pi3 et c'est
le wifi est solide jusqu'à ce que je me connecte à partir d'une tablette Samsung. Se connecter avec
rien d'autre et c'est bien. Ne semble pas être sous tension ou surchauffé
lié car c'est absolument bien pendant des jours jusqu'à ce que je me connecte du mauvais
tablette et il tombe.

Je suppose que c'est lié au pilote ou au firmware, quelque chose que le Samsung
le pilote envoie que le pi3 n'aime pas.

Le jeudi 27 avril 2017, 22:01 Crrispy, [email protected] a écrit:

@pelwell https://github.com/pelwell : après une perte de wifi, j'ai vérifié et
étranglé = 0x0

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297823068 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5
.

Il y a eu quelques correctifs au réseautage dans le dernier raspbian -
à quand remonte la dernière fois

sudo apt-get mise à jour
sudo apt-get dist-upgrade

?
Cela pourrait valoir la peine d'essayer pour voir si cela corrige les choses.

Le 28 avril 2017 à 14h38, philborman [email protected] a écrit:

Cela ne semble pas être le même problème que le mien. Je n'ai qu'un seul pi3 et c'est
le wifi est solide jusqu'à ce que je me connecte à partir d'une tablette Samsung. Se connecter avec
rien d'autre et c'est bien. Ne semble pas être sous tension ou surchauffé
lié car c'est absolument bien pendant des jours jusqu'à ce que je me connecte du mauvais
tablette et il tombe.

Je suppose que c'est lié au pilote ou au firmware, quelque chose que le Samsung
le pilote envoie que le pi3 n'aime pas.

Le jeudi 27 avril 2017, 22:01 Crrispy, [email protected] a écrit:

@pelwell https://github.com/pelwell : après une perte de wifi, j'ai vérifié,
et
étranglé = 0x0

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
ou couper le fil
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHag08r5c96nB39R3F-mFW772qBbGks5r0evJgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

J'ai le même problème avec le raspbery pi zéro W. Après un certain temps, je ne suis pas en mesure d'y accéder. J'ai tout essayé. Un fait amusant est que ... lorsque j'ai connecté rpi à mon téléviseur pour faire un dépannage après que je ne puisse pas y accéder ... cela fonctionnait à toute épreuve pendant 18h. Ensuite, j'ai changé HDMI pour un autre appareil et après un certain temps, quand je voulais ssh en pi, j'ai obtenu de belles informations "pas de route vers l'hôte". Lorsque j'ai rebranché le câble HDMI, j'ai pu envoyer une requête ping à la passerelle. Aucune erreur dans les journaux, iwconfig semble correct. systemctl redémarrer le réseau a aidé.

Comme ci-dessus, essayez la dernière version de Raspbian et signalez-la si vous voyez toujours
le problème.

Le 28 avril 2017 à 19h30, frankja2 [email protected] a écrit:

J'ai le même problème avec raspbery pi zero W.Après un certain temps, je ne suis pas
capable de s'y connecter. J'ai tout essayé. Un fait drôle est ... quand je me suis connecté
rpi sur mon téléviseur pour effectuer un dépannage après que je ne puisse pas ssh à
ça ... ça a fonctionné pendant 18h solide comme le roc. Ensuite, j'ai changé HDMI pour un autre
appareil et après un certain temps quand je voulais ssh à pi je suis devenu magnifique "non
route vers l'hôte "info. Lorsque j'ai rebranché le câble HDMI, j'ai pu envoyer un ping
passerelle. systemctl redémarrer le réseau a aidé.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Je suis peut-être le seul à avoir assez de tête pour que ce soit le problème, mais j'ai découvert que mon wpa_supplicant.conf avait le code de pays mal défini (il manquait qu'il s'agissait d'un élément de configuration distinct des autres options de localisation). Je ne dirai pas que le problème a complètement disparu, mais une fois que j'ai résolu cela, il a cessé de perdre sa connexion réseau de la manière «à chaque fois que je me connecte depuis mon Samsung» avant.

Juste mis à jour vers la dernière version (apt-get dist-upgrade) et ça a l'air plein d'espoir.
Ma précédente mise à jour remonte à environ 2 semaines, juste avant que je signale le
problèmes initiaux. Fonctionne bien pendant les dernières heures, pas de wifi
abandons du tout. Merci beaucoup!

Le 28/04/17 15:53, James Hughes a écrit:

Il y a eu quelques correctifs au réseautage dans le dernier raspbian -
à quand remonte la dernière fois

sudo apt-get mise à jour
sudo apt-get dist-upgrade

?
Cela pourrait valoir la peine d'essayer pour voir si cela corrige les choses.

Le 28 avril 2017 à 14h38, philborman [email protected] a écrit:

Cela ne semble pas être le même problème que le mien. Je n'ai qu'un seul pi3 et
ses
le wifi est solide jusqu'à ce que je me connecte à partir d'une tablette Samsung. Se connecter avec
rien d'autre et c'est bien. Ne semble pas être sous tension ou surchauffé
lié car c'est absolument bien pendant des jours jusqu'à ce que je me connecte du mauvais
tablette et il tombe.

Je suppose que c'est lié au pilote ou au firmware, quelque chose que le Samsung
le pilote envoie que le pi3 n'aime pas.

Le jeudi 27 avril 2017, 22:01 Crrispy, [email protected] a écrit:

@pelwell https://github.com/pelwell : après une perte de wifi, j'ai vérifié,
et
étranglé = 0x0

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub

< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
ou couper le fil
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub

https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
ou couper le fil

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

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298003537 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ALmHORKJxKdws0fMKU5tpfoJHJSah0Ffks5r0e9FgaJpZM4HupC5 .

C'est corrigé pour moi sur la dernière version.

La plupart des autres «correctifs» semblent manquer le point où mon système fonctionnait
parfaitement avec tout sauf une tablette (Samsung), il semble donc que le
le problème était que le samsung envoyait quelque chose au pilote / micrologiciel wifi pi3
ne pouvait pas faire face.

Si mon code de pays était mal défini, pourquoi seul Samsung
problèmes. Les autres tablettes / téléphones / ordinateurs portables se connectent tous correctement.

Quoi qu'il en soit, c'est corrigé maintenant - au moins, il n'est pas tombé en panne depuis quelques
heures. Plus de temps nous le dira ...

Le 28/04/17 21:09, rraszews a écrit:
>

Je suis peut-être le seul à avoir assez d'os pour que ce soit le problème, mais
J'ai découvert que mon wpa_supplicant.conf avait le code de pays défini
faux (il a manqué qu'il s'agissait d'un élément de configuration distinct de l'autre
options de localisation). Je ne dirai pas que le problème a disparu
entièrement, mais une fois que j'ai corrigé cela, il a cessé de perdre son réseau
connexion de la manière «à chaque fois que je me connecte depuis mon Samsung»
était avant.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298082370 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ALmHOWtM-_MXCz5RoQd8XShI4Mk-4LAyks5r0jlUgaJpZM4HupC5 .

Dans mon cas, cela dure environ 19h. Après ça, je ne pouvais plus ssh ...

Quelle est la différence entre rpi-update et dist-upgrade?

Parce qu'après la mise à jour rpi, j'avais 4.9.25+ # 995, puis j'ai fait une mise à niveau dist et le noyau est revenu à 4.9.24+ # 993. Quoi qu'il en soit pour moi le problème n'est toujours pas résolu. Ce que j'ai fait cette fois, c'est que j'ai utilisé un autre rpi0w et un autre PSU :) La dernière étape est d'utiliser une autre carte SD.

Ok, merci pour l'information.

Je vais avoir besoin de plus d'informations pour essayer de répliquer. Votre configuration, quoi
vous vous êtes connecté et le type de trafic réseau en cours, tous les journaux dmesg
ou d'autres messages d'erreur une fois que le sh cesse de fonctionner.

Merci.

Le 29 avril 2017 à 16h16, franko [email protected] a écrit:

Dans mon cas, cela dure environ 19h. Après cela, je pourrais plus ssh ...

Quelle est la différence entre rpi-update et dist-upgrade?

Parce qu'après la mise à jour rpi, j'avais 4.9.25+ # 995
https://github.com/raspberrypi/linux/pull/995 puis j'ai fait
dist-upgrade et le noyau sont revenus à 4.9.24+ # 993
https://github.com/raspberrypi/linux/pull/993 . Quoi qu'il en soit pour moi le problème est
toujours pas fixé.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298175041 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHQR8cadrEhb55YJj5PV6PP_odmJmks5r01RJgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Bonjour,

J'ai mis le Pi3 dans un boîtier avec un ventilateur assez puissant et la température dans la pièce est actuellement de 19 ° C, donc cela ne peut pas être un problème de chaleur. Échangé l'alimentation pour une autre (5V 3A aussi). Utilisé une autre carte SD, dist-upgrade puis rpi-update.
Hier, il a duré plusieurs heures, j'espérais qu'il était réparé mais après 3-4 heures, il s'est déconnecté (ping -t fonctionnant depuis ma machine à vent).
Essayé à nouveau ce matin, wifi en panne après moins de 20 minutes :-(
Toujours l'erreur -110 du pilote wifi sur sdio (voir ci-dessus), qui se répète en boucle jusqu'au redémarrage.
Et mon autre Pi3 connecté depuis 3-4 jours maintenant, pas de problème.
Cela peut donc ressembler à une défaillance matérielle. Mais .. pourquoi n'échoue-t-il jamais au démarrage et fonctionne-t-il toujours après un redémarrage? Vraiment déroutant.
Pourquoi essaie-t-il de changer "l'état de veille du bus" puisque la gestion de l'alimentation est désactivée pour wlan0? (désolé si la question est stupide).

vient de faire apt-get update; apt-get dist-upgrade . Malheureusement, aucun changement pour moi. D'après mon observation, le problème concerne le pontage wlan0 demandant s'il pourrait être lié au mode promiscuous. Avoir fatigué rpi-update aussi pour vérifier 4.9.25

en fait, c'est encore pire qu'avant car la connexion se perd maintenant généralement en quelques minutes et je peux voir les journaux habituels

[  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

"Parce qu'après la mise à jour rpi, j'avais 4.9.25+ # 995 et ensuite j'ai fait une mise à jour dist et le noyau est revenu à 4.9.24+ # 993."

C'est étrange. J'ai fait la mise à jour dist, je suis allé à 4.9.24+ # 993 et ​​quand je fais une mise à jour rpi en ce moment, il dit que j'ai déjà le dernier firmware et qu'il n'a rien à faire ... pourquoi ne pas mettre à jour vers 4.9.25 / # 995?

En fait, je dois dire que l'utilisation de brcmfmac/wlan0 bridged semble fonctionner plus stable qu'avec wlan0 pur (le tout avec hostapd)

Alors, pouvez-vous donner une description complète et précise de votre configuration, ainsi que
types d'appareils connectés et tous les messages d'erreur dmesg que vous pourriez recevoir
lorsque le sans fil échoue.

J'ai vraiment besoin d'un moyen de reproduire le problème qui ne prend pas des heures, donc
toute information fournie pouvant aider à atteindre cet objectif est acceptée avec gratitude.

Le 1er mai 2017 à 17h27, Szymon Stasik [email protected] a écrit:

En fait, je dois dire que l'utilisation de brcmfmac / wlan0 bridged semble fonctionner plus
stable qu'avec pure wlan0 (tout avec hostapd)

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Je ne sais pas si cela est spécifiquement lié à cet aspect du problème, mais IIRC j'ai pu reproduire entièrement une façon de supprimer le wifi en utilisant une commande hcitool .. Peut-être que ce n'est plus possible, c'était il y a un an maintenant et nous sommes allés avec le wifi usb pour résoudre le problème qui a fonctionné pour un tas de rpis ...

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

@thomasf Quelle était la configuration de votre système (périphérique autonome, point d'accès, point d'accès ponté, etc.) et sur quelle machine exécutez-vous la commande hcitool? Un test rapide sur un appareil connecté à un autre Pi via sans fil n'a montré aucun problème.

@ JamesH65 Nous avons traversé de nombreux scénarios et le problème était reproductible dans n'importe quelle configuration.

Lorsque la commande hcitool était exécutée sur un rpi, elle perdait généralement la connexion réseau (wifi) en quelques secondes. IIRC était plus facile à reproduire s'il y avait du trafic réseau sur l'appareil (comme un transfert de fichier).

En regardant rapidement notre système de provisionnement final, le wpa_supplicant.conf était le dernier que nous avons utilisé .. Je pense qu'il n'a pas l'air si différent de celui qui a causé des problèmes avec l'interface wifi interne, je suis sûr que nous avons commencé à utiliser un seul point d'accès tout en continuant à rencontrer des problèmes.

(SSID et clés expurgés):

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

Je viens de trouver un script appelé troublemaker.sh dans le référentiel d'approvisionnement maintenant ..

C'est très piraté, je pense que je l'ai prévu pour fonctionner au démarrage ~ comme une fois toutes les quelques minutes environ ~~ (modifier: probablement juste une fois car il fait une boucle par lui-même) sur un tas de rpi pour provoquer des problèmes et obtenir des journaux enregistré..

Cela a été principalement utilisé avant que je ne comprenne plus les problèmes. Je pense que les temps de ping et la perte de paquets augmentaient pendant une période avant que le wifi ne soit totalement déconnecté.

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

L'exécution du script de fauteur de troubles sur le dernier Raspbian stable (noyau 4.9) ne montre aucune erreur, ce qui est bon, mais mauvais pour essayer de répliquer les erreurs!

@ciekawy Avec le recul, vous semblez être en mesure de reproduire facilement un problème que nous ne pouvons pas faire ici. Pouvez-vous me donner une idée de votre configuration exacte, afin que je puisse enquêter. Il vaut également la peine de saisir la toute dernière mise à jour rpi car il y a eu des correctifs pour USB qui peuvent ou non avoir de la pertinence (si vous utilisez Ethernet). J'aurai besoin de connaître la topologie de votre réseau, comment le Pi est configuré, ce qui semble être à l'origine du problème. Rien? Vraiment!

@ JamesH65 , Ma configuration actuelle est:

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

aussi comme pour 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

Il convient de mentionner que ce RPI fonctionnait de manière stable pendant des jours (bien que des transferts plus durables de 10 Mbps aient également pu causer des problèmes) lorsque les rôles ont été commutés et que wlan0 brcmfmac a été utilisé pour se connecter à Internet et que l'AP local fonctionnait sur wlan2 ath9k. J'ai changé de configuration car je dois utiliser une meilleure antenne connectée à wlan2 pour l'accès Internet.

Mon récent rpi-updated était le 1er mai

J'ai exactement le même problème dans rpi3 en utilisant Archlinux-ARM.

Après quelques heures d'exécution de create_ap, il cesse de fonctionner avec les msgs dmesg déjà signalés par d'autres:
[11418.347554] brcmfmac: send_key_to_dongle: erreur wsec_key (-110)

Parfois, cela fonctionne pendant 1 jour sans problème, et parfois cela fonctionne pendant des minutes avant que le problème ne se produise.

Alarme Linux 4.9.25-2-ARCH # 1 SMP Ven 5 mai 00:46:52 UTC 2017 armv7l GNU / Linux

Même problème sur Pi Zero W, Raspbian Lite actuel. Après un certain temps (varie de quelques minutes à quelques heures), les émissions 'dmesg'
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
À partir de ce moment, la connexion wifi a disparu et ne peut être redémarrée que par rmmod'ing et modprob'ing brcmfmac.

J'ai désactivé la gestion de l'alimentation: aucun changement.
J'ai tout mis à jour via apt-get upgrade / dist-upgrade: aucun changement
J'ai mis à jour des trucs via rpi-update: aucun changement

brcmfmac est bogue à coup sûr. Je soulevais le même problème avec dmesg msg "brcmfmac: brcmf_sdio_hostmail: Contenu inconnu des données de boîte aux lettres: 0x40012" et parfois des messages différents aussi, comme indiqué dans mon message ci-dessus.

J'utilise un adaptateur wifi usb tp-link et mon application fonctionne correctement maintenant.

J'espère que Broadcom pourra corriger les bogues de brcmfmac.

Une solution de contournement?

Comme je l'ai mentionné au début de cette conversation, j'ai changé mon routeur Wifi pour utiliser le canal 6 au lieu de 11 (qu'il utilisait auparavant), et mon rPi est en hausse depuis lors (de retour en janvier jusqu'à maintenant) sans problème à tout.

Cela pourrait-il être lié à cette note du module du noyau:

Cette génération de puces contient un support réglementaire supplémentaire indépendant du pilote. Les appareils utilisent un seul domaine réglementaire mondial, avec les canaux 12-14 (bande 2,4 GHz) et les canaux 52-64 et 100-140 (bande 5 GHz) limités au fonctionnement passif. La transmission sur ces canaux est supprimée jusqu'à ce qu'un autre trafic approprié soit observé sur ces canaux. Dans le pilote, nous utilisons le code de pays fictif «X2» pour représenter ce domaine réglementaire mondial. Il n'y a actuellement aucune interface pour configurer un domaine différent. Le pilote lit le code de pays SROM à partir de la puce et le remet au mac80211 comme indice réglementaire, mais cette information n'est pas utilisée par le pilote.
(à partir d'ici: https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211)

Je suppose que cela signifie que même un code de pays "DE" (qui devrait autoriser les canaux wifi plus élevés) n'a aucun effet? Mais je ne suis pas sûr que cela puisse avoir un effet similaire au problème Unknown mailbox data content: 0x40012 ...

Au moins pour moi, ce n'est pas une solution de contournement - passage du canal 11 au canal 6 aujourd'hui, 2 heures plus tard: Unknown mailbox data content: 0x40012

J'ai eu ce problème jusqu'à ce que j'augmente la force du signal par un prolongateur de portée.
Pourriez-vous tester si la connexion est plus stable en déplaçant le Pi vers un endroit avec un meilleur signal?

Peut-être est-ce dû à une puissance supplémentaire nécessaire pour fonctionner avec une puissance de signal médiocre.

Même problème que Crrispy.

Pour ceux qui travaillent autour de cela avec un adaptateur USB WiFi (le changement de canal, etc. ne fonctionnait pas non plus pour moi), Edimax EW-7811Un a fonctionné immédiatement lorsque je l'ai branché sur mon câble USB OTG sur RPI Zero W. Je n'ai pas à faire de configuration ou d'ifconfig - c'était sur le réseau tout de suite! Hier, j'ai flambé avec le TP-Link Archer T1U AC450 pendant quelques heures.

@ b3nj1 - désolé d'intervenir, mais je dois demander --- pourquoi utiliser un wifi externe avec un Zero W? Bon, vous savez ce que signifie le «w». lol :)

J'ai choisi la même solution - acheté un adaptateur USB avec antenne externe et chipset mt7601 (environ 5 Eur) pour mon Zero W, fonctionne parfaitement. J'aurais dû acheter le non-W en premier lieu ... ce problème existe depuis plus d'un an et aucun correctif en vue.

@blacktigersoftware - c'est étrange, n'est-ce pas !? Le Zero W WiFi fonctionne très bien. Le Bluetooth Zero W fonctionne très bien. Mais, si j'utilise les deux en même temps, le système devient insupportablement lent et finalement inaccessible via le wifi.

J'ai jeté un coup d'œil au problème maibox décrit ci-dessus. Google montre que cela semble se produire un peu (et au moins une référence à une plate-forme non Pi). Le code du pilote détecte qu'un message provenant de la boîte aux lettres (je suppose une connexion au micrologiciel HW) a des bits définis dans ce qu'il ne devrait pas avoir. Cependant, il n'imprime que les messages - ne fait aucune récupération ou retour d'erreur. Étant donné que cela semble être une valeur renvoyée par le micrologiciel, je n'y ai pas accès pour voir ce qui se passe, et la fiche technique sur la puce est totalement inutile. Je pense donc que ceux-ci doivent être poussés vers Broadcom / Cypress / linux-wireless pour enquête.

Il convient également de noter que nous semblons disposer du dernier micrologiciel HW selon https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm. Les fichiers ont des différences de longueur d'un ou deux octets, mais c'est tout.

Le problème est que l'erreur de boîte aux lettres est suivie par d'autres erreurs (-52, -110, etc.), et ne redémarre que le système pour le remettre en marche.

-110 est une erreur de temporisation, indiquant que quelque chose d'autre meurt et ne répond pas. -52 est un échange invalide, qui va dans le même sens. Je soupçonne qu'au moment où l'erreur de boîte aux lettres s'est produite, le micrologiciel de la puce n'est pas en bon état, donc ces autres erreurs continuent.

Est-ce que quiconque peut reproduire le problème est capable de construire le dernier noyau de développement Pi (4.11, disponible sur notre github) et de voir si l'erreur de boîte aux lettres se produit toujours. Avant de commencer à pousser en amont, j'aimerais savoir que cela se produit toujours sur le dernier noyau, et que je n'ai pas été en mesure de le répliquer.

Je peux confirmer que le problème se produit dans: Alarme Linux 4.9.25-2-ARCH # 1 SMP Ven 5 mai 00:46:52 UTC 2017 armv7l GNU / Linux

Je n'ai pas testé dans le noyau 4.11

Le pilote utilisé dans mes tests: brcmfmac: Version du firmware = wl0: 15 décembre 2015 18:10:45 version 7.45.41.23 (r606571) FWID 01-cc4eda9c

@ b3nj1 - wow, merci pour le heads-up

Tout le monde - cela ne se produit-il que lorsque le GPU est allumé?

Le GPU est toujours activé (dans une certaine mesure), dans tous les modèles de Pi.

Voulez-vous dire lorsque Bluetooth est activé?

@ JamesH65 - Je vais essayer 4.11. Dois-je simplement cloner / construire selon ce qui suit? Lors du clonage selon ces instructions, je suis sur la branche rpi-4.9.y. Dois-je commander rpi-4.11.y à la place ou autre chose?

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

Merci d'avance

Extrayez la branche rpi-4.11.y, puis reconstruisez en suivant les instructions que vous
ont lié à.

Le 25 mai 2017 à 05h02, b3nj1 [email protected] a écrit:

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

• Je vais essayer 4.11. Dois-je simplement cloner / construire selon ce qui suit?
  Lors du clonage selon, je suis sur la branche rpi-4.9.y. Dois-je payer
  rpi-4.11.y à la place ou autre chose?

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

Merci d'avance

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Juste pour répéter certaines informations que j'ai fournies ailleurs, j'ai testé la connexion sans fil dans des conditions de faible puissance. Je l'ai réduit au point que les périphériques USB tombent, mais je n'ai vu aucun problème de connexion sans fil. Bien que ce soit la preuve que ce n'est pas un problème d'alimentation, cela vaut la peine de le noter.

J'ai trouvé comment reproduire cela en exécutant sudo memtester 256M 1 via SSH en utilisant mon téléphone; le wifi meurt dès que memtester commence à être inondé de ces caractères "chargement":

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

Chose étrange, le wifi ne se bloque que lorsque je fais cela sur mon téléphone. J'ai essayé mon PC, un autre pi et mon routeur sans succès.

@ JamesH65 - Mise à jour 2: j'ai pu démarrer avec 4.11 (j'ai mal configuré le noyau la première fois).
Linux rpiz 4.11.2+ #2 Thu May 25 21:19:11 PDT 2017 armv6l GNU/Linux

Malheureusement, le système est toujours sensible à l'orge lorsque je martèle BT.

Lorsque je rebranche le WiFi USB externe et que je connecte l'adresse de cet adaptateur, tout va bien à nouveau.

• Benjamin

Nouveau noyau construit et installé à partir de la branche rpi-4.11.y en suivant les instructions ici: 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

Malheureusement, le wifi se bloque toujours avec la même erreur:
brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Si vous vous console lorsque le wifi s'éteint, vous pouvez le redémarrer. Je teste un script bash en ce moment pour voir si cela aide. Je vais l'exécuter dans cron. Ici, c'est si quelqu'un est intéressé.

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

J'exécute ceci depuis un jour et jusqu'à présent, je n'ai pas remarqué ma baisse de wifi.

@ JR1994
Ça marche toujours?
À quelle fréquence l'exécutez-vous?
Chaque minute ?

Je vais l'essayer dans certains de mes raspberrys, j'en ai plusieurs qui redémarrent à chaque fois qu'il ne peut pas cingler le routeur

Merci d'avance

Jusqu'ici tout va bien. Je vérifie toutes les 2 min.

Notez que la dernière révision du firmware de brcmfmac est trop ancienne:

brcmfmac: Version du micrologiciel = wl0: 15 décembre 2015 18:10:45 version 7.45.41.23 (r606571) FWID 01-cc4eda9c

@semeion Je ne sais pas quel firmware vous utilisez - l'actuel devrait être "Version: 7.45.41.26 CRC: 5932ca06 Date: Ven 2016-05-27 00:15:32 PDT Ver Ucode: 1043.2060 FWID: 01-df77e4a7". C'est effectivement le même que celui du référentiel linux-firmware, bien que nous obtenions le nôtre directement de Brcm.

@ JamesH65 Ce message a été renvoyé dans 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

Mais en utilisant vcgencmd version il montre:

$ /opt/vc/bin/vcgencmd version

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

Ce n'est pas le firmware de la puce Wifi, c'est le firmware SoC, qui obtient
mis à jour assez fréquemment.

Vous ne savez toujours pas pourquoi votre système pense avoir cet ancien micrologiciel. Tu
avoir un firmware SoC très récent, donc vous avez probablement effectué une mise à niveau apt-get
récemment?

Le 5 juin 2017 à 17h55, Alexandre Bolelli [email protected] a écrit:

@ 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=
Ce message a été renvoyé dans dmesg. Mais en utilisant la version vcgencmd, il montre:
`$ / opt / vc / bin / vcgencmd version
Version du firmware

30 mai 2017 15:23:29
Copyright (c) 2012 Broadcom
version b8cdd5ae76f39d9f353dfa8fb48bf7e33b74903c (propre) (libération) `

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

@ JamesH65 Comme je l'ai dit ci-dessus,

Aucune idée de la raison pour laquelle cet ancien firmware est vieux dans mon système. Peut-être que cela peut être la raison de ce bug. Qu'est-ce que tu penses?

Quoi qu'il en soit, le bogue se produit avec raspbian, non? Le bug a été signalé en mars 2016? C'est vieux.

PS. L'anglais n'est pas ma langue maternelle, désolé pour une erreur / faute d'orthographe.

OK, je n'avais pas réalisé que vous utilisiez ARCH. On dirait qu'ils ne fournissent pas
un blob de firmware récent pour la puce Wifi. Vous pouvez le mettre à jour manuellement, il
pourrait résoudre votre problème, peut-être pas - je pense qu'il y a probablement
bogues sans fil, et il n'y a aucune garantie que vous êtes celui que vous voyez
une personne voit sur Raspbian.

Vous devez signaler le micrologiciel obsolète aux responsables de l'archive, et
peut-être aussi le bogue sans fil, car cela pourrait être dû à la distribution Arch.

Notez qu'en général, nous ne prenons pas en charge les autres distributions, notre distribution maison est
Raspbian, donc pour enquêter sur un problème, nous devons être en mesure de le répliquer sur
cette.

Le 5 juin 2017 à 23h13, Alexandre Bolelli [email protected] a écrit:

@ JamesH65 https://github.com/jamesh65 Comme je l'ai dit ci-dessus, j'utilise
Archlinux-ARM, c'est une distribution de version roulante, et oui mon système est mis à jour
avec pacman -Syu (pacman -Syu est l'équivalent d'apt-get upgrade / update).

Aucune idée de la raison pour laquelle cet ancien firmware est vieux dans mon système. Peut-être que ça peut être
la raison de ce bug. Qu'est-ce que tu penses?

Quoi qu'il en soit, le bogue se produit avec raspbian, non? Le bogue a été signalé dans
Mars 2016? C'est vieux.

PS. L'anglais n'est pas ma langue maternelle, désolé pour une erreur / faute d'orthographe.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306325452 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHaL4XsN5drPggS8eJDZWme4LyKXWks5sBH2CgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

@ jamesH65 Oui, en effet. Je vais essayer de demander dans # archlinux-arm pourquoi ce firmware est vieux. Quoi qu'il en soit, je suivrai ce problème et chercherai une solution. Je rapporterai ici toute information découverte.

Merci d'avance.

@ JamesH65 Je suis capable de le répliquer de manière cohérente sur mon Raspbian (RPi 3). S'il y a quelque chose que je peux faire pour vous aider, faites-le moi savoir!

Quelle est votre configuration? Comment reproduisez-vous le problème?

Le 6 juin 2017 à 14h17, Dan [email protected] a écrit:

@ JamesH65 https://github.com/jamesh65 Je suis capable de le reproduire
systématiquement sur mon Raspbian (RPi 3). S'il y a quelque chose que je peux faire pour aider
avec ça, faites le moi savoir!

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306483030 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHWyW5cQuS47k3xTmi3UX-QW7ffEYks5sBVF5gaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Jetez un œil dans les commentaires précédents, j'ai expliqué comment le reproduire il n'y a pas longtemps.
Le Pi fonctionne avec Raspbian complet avec un écran de 3,5 "sur le dessus en utilisant l'alimentation officielle. Rien d'extraordinaire, tout est mis à jour avec rpi-update et apt upgrade.

Après quelques jours, le wifi interne cesse de fonctionner avec le message suivant dans 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

Je lance hostapd sur cette interface et j'ai une autre interface wifi USB attachée au Pi. Mes informations système:

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

Ouais, et quand vous montrez que (-110) vous devez redémarrer le système pour qu'il fonctionne à nouveau ...

C'est bien de savoir que cela arrive aussi dans Raspbian, le bogue est indépendant de la distribution. C'est la même chose à Archlinux.

Cependant, depuis que j'ai déplacé mon wifi du canal 11 au canal 6 à la place, je n'ai pas vu le problème depuis. Je vois, d'après mes réponses précédentes sur ce fil, que cela fait depuis le 7 janvier lorsque j'ai fait le changement sur le canal 6. J'utilise actuellement deux RaspPI Zero W et un RaspPi 3, le tout sans problème. Les deux RaspPi W utilisent DietPi.

J'ai également ce problème sur mon Raspberry Pi 3. J'ai déjà essayé différents canaux wifi.
J'ai observé que si je connectais également le port LAN, le wifi est stable comme l'enfer. Dès que je débranche le port LAN, le wifi continue de chuter tout le temps.

C'est vraiment bizarre ......!

Le 15 juin 2017 à 23h02, macmeck [email protected] a écrit:

J'ai également ce problème sur mon Raspberry Pi 3. J'ai essayé différents canaux wifi
déjà.
J'ai observé que si je connectais également le port LAN, le wifi est stable comme l'enfer.
Dès que je débranche le port LAN, le wifi continue de chuter tout le temps.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-308878043 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHbUKBO9mG3xpKHFK977h4hrFUhrGks5sEantgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

J'ai le
"brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012"
question ainsi dans mon rpi3. ma solution de contournement la plus fiable pour éviter cette erreur a été
"Wondershaper 9000 9000"
J'espère que la cause profonde est déterminée.

J'ai exactement le même problème. Mon pi3 présente les symptômes suivants lorsqu'il est connecté au WIFI UNIQUEMENT:

1. Le wifi SORTANT fonctionne très bien. Je peux me connecter à Internet et télécharger des fichiers sans problème sur mon pi3.
2. Échec de TOUTES les connexions wifi ENTRANTES. Pings timeout, port 80 http accède timeout, ssh échoue, tout échoue INBOUND SEULEMENT.
   REMARQUE:
3. Une fois qu'Ethernet est connecté au pi3, le wifi fonctionne mieux mais il laisse toujours tomber des paquets.
4. Une fois Ethernet à nouveau supprimé, le wifi échoue complètement à toutes les connexions entrantes.
5. Une fois qu'Ethernet est à nouveau connecté au pi3, le wifi fonctionne MIEUX et autorise certains paquets entrants. mais il en laisse encore tomber beaucoup.

Veuillez corriger cela!

J'ai remarqué ce qui suit sur ifconfig:

Paquets RX: 1613 erreurs: 0 abandonné: 1074 dépassements: 0 trame: 0
Paquets TX erreurs: 0 abandonnés: 0 dépassements: 0 porteuse: 0
c ollisions: 0 t xqueuelen: 1000

Donc, fondamentalement, le côté RX du WIFI du pi3 laisse tomber des paquets comme un fou. Pas étonnant qu'il ne réponde pas aux connexions entrantes. TX fonctionne très bien!

Depuis que j'ai configuré ce script, je n'ai eu aucun problème avec le wifi sur mon
RPI3s.

Le mercredi 21 juin 2017 à 04:26, Edward Kang [email protected]
a écrit:

J'ai remarqué ce qui suit sur ifconfig:

Paquets RX: 1613 erreurs: 0 abandonné: 1074 dépassements: 0 trame: 0
Paquets TX erreurs: 0 abandonnés: 0 dépassements: 0 porteuse: 0
c ollisions: 0 t xqueuelen: 1000

Donc, fondamentalement, le côté RX du WIFI du pi3 laisse tomber des paquets comme un fou.
Pas étonnant qu'il ne réponde pas aux connexions entrantes.

VEUILLEZ RÉPARER CECI !!

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310049620 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFHmIH6kkxraxahE22_PpstdDkqW8Pgqks5sGP3ggaJpZM4HupC5
.

C'est très bien de dire «s'il vous plaît, corrigez ça», mais des problèmes comme celui-ci sont des salauds à trouver. Il a fallu un mois pour trouver une erreur dans les pilotes smsc / brcmfmac lors du pontage, et j'ai eu la chance de la trouver, et je soupçonne que celle-ci est plus rare et plus difficile à trouver. Si quelqu'un peut trouver un scénario de test réplicable qui montre rapidement l'erreur, ce serait d'une grande aide. Certaines personnes semblent avoir l'erreur kevent fréquemment, je l'obtiens très rarement.

En ce qui concerne le problème des paquets abandonnés, il est à l'étude lorsque j'ai des lacunes dans le calendrier. Dans le cas ci-dessus, vous semblez laisser tomber presque tous les paquets, ce qui est le plus étrange, et n'est généralement pas vu par la majorité des gens. Cela se produit-il avec tous les appareils connectés au Pi? Ou juste un en particulier.

désolé, James!

Je ne suis pas sûr de ce que vous entendez par tous les appareils connectés au Pi. Les paquets abandonnés proviennent de l'exécution de ifconfig directement sur le pi. Le pi est connecté via wifi à un routeur. Lorsque le pi est connecté uniquement au réseau wifi, il reçoit et abandonne constamment des paquets.

@ JamesH65 Eh bien, je suis d'accord avec vous, c'est difficile à résoudre ... Mais en utilisant Arch Linux-ARM, en installant le paquet "create_ap" et en l'activant (pacman -S create_ap; systemctl start / enable create_ap), vous pouvez obtenir le - 110 et le "Contenu inconnu des données de la boîte aux lettres: 0x40012" en quelques minutes de fonctionnement ... Il suffit de connecter votre smartphone et / ou un téléviseur intelligent dessus parfois et l'erreur viendra.

Nous ne prenons pas en charge Arch, Raspbian est notre système d'exploitation pris en charge et c'est celui que je
doivent pouvoir résoudre le problème dans. Je n'ai aucune idée de la version de
noyau ou les pilotes utilisés par ARCH, ils peuvent être très différents du
ceux dans Raspbian.

Les gens voient-ils toujours le problème en utilisant le Pi comme point d'accès?
Vous utilisez le pontage? IPv4 ou IPv6? C'est le genre d'informations (pas
exclusif bien sûr, autant d'informations que possible sont nécessaires) requis
pour reproduire les problèmes.

Notez que Broadcom a été informé de l'erreur de boîte aux lettres (c'est leur puce
et chauffeur bien sûr), mais les choses ont tendance à évoluer lentement avec eux.

Le 21 juin 2017 à 18h27, Alexandre Bolelli [email protected]
a écrit:

@ 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=
Eh bien, je suis d'accord avec vous, c'est difficile à résoudre ... Mais en utilisant Arch Linux-ARM,
installer le package "create_ap" et l'activer (pacman -S create_ap;
systemctl / startenable create_ap), vous pouvez obtenir l'erreur -110 et le
"Contenu de données de boîte aux lettres inconnu: 0x40012" en quelques minutes de fonctionnement ... Juste
connectez votre smartphone et / ou une smart TV parfois dessus et l'erreur
viendra.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

J'utilise IPv4 statique sur certains appareils et j'ai le même problème que le
d'autres utilisant dhcp

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

Nous ne prenons pas en charge Arch, Raspbian est notre système d'exploitation pris en charge et c'est celui que je
doivent pouvoir résoudre le problème dans. Je n'ai aucune idée de la version de
noyau ou les pilotes utilisés par ARCH, ils peuvent être très différents du
ceux dans Raspbian.

Les gens voient-ils toujours le problème en utilisant le Pi comme point d'accès?
Vous utilisez le pontage? IPv4 ou IPv6? C'est le genre d'informations (pas
exclusif bien sûr, autant d'informations que possible sont nécessaires) requis
pour reproduire les problèmes.

Notez que Broadcom a été informé de l'erreur de boîte aux lettres (c'est leur puce
et chauffeur bien sûr), mais les choses ont tendance à évoluer lentement avec eux.

Le 21 juin 2017 à 18h27, Alexandre Bolelli [email protected]
a écrit:

@ JamesH65
3A__github.com_jamesh65 & d = DwMFaQ & c = DpyQ_ftY536pf7wCBQXXU58xADDRY77THQz
Ju1OmzOo & r = w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m =
BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w & s = o90aBGb27vZvog3BdioLSa2_
MEySix0ymtnTgiNb87c & e =>
Eh bien, je suis d'accord avec vous, c'est difficile à résoudre ... Mais en utilisant Arch Linux-ARM,
installer le package "create_ap" et l'activer (pacman -S create_ap;
systemctl / startenable create_ap), vous pouvez obtenir l'erreur -110 et le
"Contenu de données de boîte aux lettres inconnu: 0x40012" en quelques minutes de fonctionnement ...
Juste
connectez votre smartphone et / ou une smart TV parfois dessus et l'erreur
viendra.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310294786 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ACeQBFj8ICNkDl7xYwYJcD6TK-k6_4K5ks5sGhJ1gaJpZM4HupC5
.

Une chose à noter est que le wifi fonctionnait parfaitement pour moi depuis le moment où j'ai eu mon pi3 l'année dernière jusqu'à il y a environ 3 mois lorsque le wifi a cessé de fonctionner.

De toute évidence, il doit y avoir eu une sorte de changement dans le logiciel à cette époque qui a empêché le wifi de fonctionner.

Si votre wifi a complètement cessé de fonctionner, cela indique un problème de votre côté (qui peut être aggravé par un problème logiciel bien sûr), car pour tout le monde, le Wifi fonctionne généralement (bien que je vois des paquets perdus).

BTW mon rpi3 est une toute nouvelle marque au Royaume-Uni.

Je me bats aussi depuis quelques mois. Parfois, cela dure quelques minutes. Parfois des semaines. Le dénominateur commun lorsque je perds une connexion est que je vois les appels pour réinitialiser le domaine réglementaire mondial CRDA immédiatement avant qu'il ne perde la connexion. A chaque fois. Point d'accès AC Ubiquiti, canal 11, largeur de canal HT40 (seule chose qui pourrait être spéciale).

28 juin 14:19:31 noyau raspberrypi: [980.387378] cfg80211: domaine de réglementation mondial mis à jour:
28 juin 14:19:31 noyau raspberrypi: [980.387387] cfg80211: région maître DFS: non définie
28 juin 14:19:31 noyau raspberrypi: [980.387396] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 juin 14:19:31 noyau raspberrypi: [980.387411] cfg80211: (2402000 KHz - 2472000 KHz à 40000 KHz), (N / A, 2000 mBm), (N / A)
28 juin 14:19:31 noyau raspberrypi: [980.387426] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N / A, 2000 mBm), (N / A)
28 juin 14:19:31 noyau raspberrypi: [980.387439] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N / A, 2000 mBm), (N / A)
28 juin 14:19:31 noyau raspberrypi: [980.387453] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (N / A)
28 juin 14:19:31 noyau raspberrypi: [980.387468] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 s)
28 juin 14:19:31 noyau raspberrypi: [980.387481] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N / A, 2000 mBm), (0 s)
28 juin 14:19:31 noyau raspberrypi: [980.387493] cfg80211: (5735000 KHz - 5835000 KHz à 80000 KHz), (N / A, 2000 mBm), (N / A)
28 juin 14:19:31 noyau raspberrypi: [980.387505] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 0 mBm), (N / A)
28 juin 14:19:32 noyau raspberrypi: [981.262521] cfg80211: domaine de réglementation changé en pays: États-Unis
28 juin 14:19:32 noyau raspberrypi: [981.262536] cfg80211: Région maître DFS: FCC
28 juin 14:19:32 noyau raspberrypi: [981.262540] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 juin 14:19:32 noyau raspberrypi: [981.262549] cfg80211: (2402000 KHz - 2472000 KHz à 40000 KHz), (N / A, 3000 mBm), (N / A)
28 juin 14:19:32 noyau raspberrypi: [981.262557] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2300 mBm), (N / A)
28 juin 14:19:32 noyau raspberrypi: [981.262565] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2300 mBm), (0 s)
28 juin 14:19:32 noyau raspberrypi: [981.262571] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N / A, 2300 mBm), (0 s)
28 juin 14:19:32 noyau raspberrypi: [981.262578] cfg80211: (5735000 KHz - 5835000 KHz à 80000 KHz), (N / A, 3000 mBm), (N / A)
28 juin 14:19:32 noyau raspberrypi: [981.262584] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 4000 mBm), (N / A)

Désolé de jeter de l'essence sur le feu, mais j'ai aussi un problème similaire sur le Pi Zero W, je pense.

Lors du basculement de wlan0 entre le mode point d'accès (lors de l'utilisation de hostapd) et le mode de connexion normal (c'est-à-dire la connexion à un routeur), wlan0 perdra parfois la capacité de s'associer à un point d'accès.

Il restera bloqué dans cet état:

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

et rien de moins qu'un redémarrage ne le résoudra. Je remarque dans dmesg les erreurs suivantes lorsque cela se produit:

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

Ce qui m'inquiète, c'est que c'est complètement arbitraire et aléatoire. Je peux parfois basculer entre les deux modes pendant un certain temps avant que le problème ne survienne. Mais c'est finalement le cas.

FWIW Je pense que le rechargement du module du noyau wifi (en faisant "modprobe -r -v brcmfmac && modprobe brcmfmac") l'a corrigé donc je devrai juste créer un script qui le fait chaque fois que mon Pi a des problèmes de wifi.

Cette chose est étrange. J'ai eu ce type de problèmes sur Raspberry pi zéro et zéro W, mais ils ont complètement disparu lorsque j'ai changé de chaîne (comme indiqué précédemment dans ce fil).

De plus, ces derniers temps, j'utilise le système d'exploitation DietPi et je n'ai eu aucun problème. Vous pouvez essayer cela.

J'aurais vraiment aimé me pencher sur le problème, après l'avoir vu auparavant, mais je ne peux tout simplement pas le faire se produire ces jours-ci! :(

/ raj
(envoyé depuis l'iPhone)

Le 5 juillet 2017, à 9 h 01, timdonovanuk [email protected] a écrit:

FWIW Je pense que le rechargement du module du noyau wifi (en faisant "modprobe -r -v brcmfmac && modprobe brcmfmac") l'a corrigé donc je devrai juste créer un script qui le fait chaque fois que mon Pi a des problèmes de wifi.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

Plus il y a de gens qui peuvent regarder, mieux c'est, je suis limité dans le temps
Je peux dépenser là-dessus pour le moment en raison d'autres projets. Un problème majeur
est un mécanisme solide pour le reproduire.

Le 5 juillet 2017 à 17h10, rajid [email protected] a écrit:

Cette chose est étrange. J'ai eu ce type de problèmes sur Raspberry pi
zéro et zéro W, mais ils ont complètement disparu lorsque j'ai changé de chaîne (comme
discuté plus tôt dans ce fil).

De plus, récemment, j'utilise le système d'exploitation DietPi et je n'ai eu aucun problème à
tout. Vous pouvez essayer cela.

J'aurais vraiment aimé me pencher sur le problème, après l'avoir vu auparavant, mais je
ne peut tout simplement pas que cela se produise ces jours-ci! :(

/ raj
(envoyé depuis l'iPhone)

Le 5 juillet 2017 à 9h01, timdonovanuk [email protected]
a écrit:

FWIW Je pense recharger le module du noyau wifi (en faisant "modprobe -r -v
brcmfmac && modprobe brcmfmac ") l'a corrigé donc je devrai juste créer un
script qui fait cela chaque fois que mon Pi a des problèmes de wifi.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

@timdonovanuk pourrait être sympa de partager votre script avec nous, je cherche une solution de contournement. Peut-être un script de surveillance fonctionnant comme le service systemd ... Que pensez-vous?

Existe-t-il un moyen pour moi de déclencher manuellement la mise à jour du domaine réglementaire? Comme je l'ai dit, cela semble être assez cohérent pour moi chaque fois que cela fonctionne, la connexion tombe. Je serais intéressé de l'exécuter manuellement plusieurs fois pour voir si je peux reproduire de manière fiable pour vous.

@rajid , par hasard courez-vous à une largeur de canal de 40? Et vous souvenez-vous si vous voyiez des mises à jour réglementaires mondiales similaires avant les baisses? Curieux de savoir s'il y a peut-être une combinaison autour du canal 11 et de la largeur de canal extra large ... et quel type de routeur / AP utilisez-vous? Je cherche juste un point commun, puisque je le vois également sur le canal 11, comme d'autres ... Mon AP est un Ubiquiti.

La solution de contournement pour passer du canal automatique sur Apple Extreme au canal 6 n'a pas fonctionné pour moi. J'utiliserai LAN pendant les vacances.

Edit: Maintenant, je perds la connexion même avec LAN, il y a plus quelque chose de plus ici, est-ce un problème de chaleur en utilisant le boîtier officiel (pas de ventilateur)?

Bonjour,
Je suis confronté à un problème très similaire sur un Raspberry Pi Zero W.

J'ai développé une API fonctionnant avec Node.JS sur le Pi et intégrée aux GPIO.
Le Pi est connecté à mon LAN via Wifi. Tout fonctionne très bien lorsque les clients PC appellent l'API. Cependant, dès que j'interroge mon API avec un appareil Android, le Pi plante. Ces plantages se produisent au hasard: parfois, l'API peut être appelée plusieurs fois par les appareils Android et soudainement le crash se produit.
Ce que je veux dire par crash est une perte de ping, mais Pi est toujours opérationnel.

L'appel de la même API via des PC ne déclenche jamais de plantage.

J'ai essayé de changer de canal Wifi mais je n'ai pas obtenu de meilleurs résultats.

Si je peux exécuter quelque chose pour aider au diagnostic / solution, n'hésitez pas à demander!

Quelque chose dans ce post d'aide sur le forum?

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

Le 11 juillet 2017 à 16h22, matthiasbou [email protected] a écrit:

Bonjour,
Je suis confronté à un problème très similaire sur un Raspberry Pi Zero W.

J'ai développé une API fonctionnant avec Node.JS sur le Pi et intégré
avec les GPIO.
Le Pi est connecté à mon LAN via Wifi. Tout fonctionne très bien lorsque le PC
les clients appellent l'API. Cependant, dès que j'interroge mon API avec un Android
appareil, le Pi plante. Ces plantages se produisent au hasard: parfois l'API peut
être appelé plusieurs fois par les appareils Android et soudainement le crash se produit.
L'appel de la même API via des PC ne déclenche jamais de plantage.

J'ai essayé de changer de canal Wifi mais je n'ai pas obtenu de meilleurs résultats.

Si je peux exécuter quelque chose pour aider au diagnostic / solution, n'hésitez pas à demander!

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314479400 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHYDohQoNRBDcX4oG49rK9e6kwpjjks5sM5MpgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

@matthiasbou

Intéressant ce que vous avez dit, mon pilote Broadcom renvoie l'erreur -110 (parfois une autre erreur) et plante exactement au moment où je connecte mon smartphone Motorola X2 (Android). Mais aussi la même erreur se produit lors de la connexion de ma SmartTV. Quoi qu'il en soit, je peux confirmer que le crash se produit au moment où la connexion est établie.

Mon pays est défini correctement, ipv6 désactiver et roamoff = 1, j'utilise le canal 6, le problème persiste. le mode d'économie d'énergie wifi et le bluetooth sont désactivés par défaut dans ma distribution.

@ JamesH65 : J'ai essayé la solution intéressante

Le Wifi se connecte, mais dès que je commence à "jouer" avec un appareil Android faisant des appels API sur le Pi Zero W, au bout d'un moment, il plante.

Pourquoi la désactivation d'IPv6 devrait-elle résoudre le problème du Wifi? Y a-t-il une explication raisonnable pour laquelle IPv6 est impliqué, qui est reproductible? La seule chose à laquelle je peux penser est qu'IPv6 peut avoir une légère charge de multidiffusion supplémentaire en raison des RA.

Pour ce que cela vaut, j'utilise deux Pi Zero W en tant que ponts IPv6 entre wlan0 intégré et eth0 externe, avec IPv4 bloqué. wlan0 est en mode AP et a le serveur ISC dHCPv4 en cours d'exécution. J'y connecte diverses tablettes et smartphones Android. Je n'ai remarqué aucun problème jusqu'à présent, mais peut-être que je dois les laisser fonctionner pendant de plus longues périodes. J'utilise le canal 6.

Désolé, j'utilise une boîte Apple Airport, et il n'y a pas de paramètre ou de mention de "largeur de canal". J'ai simplement défini le canal 6 pour le réseau 2,3 ​​GHz. J'utilise maintenant DietPi sur mes petits systèmes RaspPi Zero W. Les autres RaspPi que j'ai ont été configurés il y a longtemps avec Edimax USB et n'ont jamais eu de problèmes. Je crois que la seule fois où j'ai vu des problèmes, c'était avec Raspbian sur le système Zero W. Je vais devoir le charger à nouveau et voir si je peux le reproduire.

/ raj

Le 5 juillet 2017 à 15h19, Michael Hallock < [email protected] [email protected] > a écrit:

Existe-t-il un moyen pour moi de déclencher manuellement la mise à jour du domaine réglementaire? Comme je l'ai dit, cela semble être assez cohérent pour moi chaque fois que cela fonctionne, la connexion tombe. Je serais intéressé de l'exécuter manuellement plusieurs fois pour voir si je peux reproduire de manière fiable pour vous.

@rajid https://github.com/rajid , par hasard courez-vous à la largeur de canal 40? Et vous souvenez-vous si vous voyiez des mises à jour réglementaires mondiales similaires avant les baisses? Curieux de savoir s'il y a peut-être une combinaison autour du canal 11 et de la largeur de canal extra large ... et quel type de routeur / AP utilisez-vous? Je cherche juste un point commun, puisque je le vois également sur le canal 11, comme d'autres ... Mon AP est un Ubiquiti.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, visualisez-le sur GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-313242611 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AFAlZVdfvh5QzIlsZYtt9sjWJpXol5QzIlsZYtt9sjWJpXol5QzIlsZYtt9sjWJpXol5cm

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

J'ai juste effectué plus de tests et changé de routeur auquel le Pi se connecte.
Jusqu'à présent, tout fonctionne lorsque le Pi est sur cet autre routeur Wifi (pas de changement côté appareil Android):
Configuration du routeur de travail :
Canal 6
WPA-PSK
Bande passante 20Mhz

Configuration du routeur non fonctionnelle (perte de Wifi après un certain accès depuis Android Wifi):
Netgear WNR1000v2
Canal 6
WPA2-PSK [AES]
Fragmentation Longueur 2346
Seuil CTS / RTS 2347

Je vais passer le routeur de travail à WPA2-PSK pour voir si le problème peut ensuite être reproduit.

@TheDiveO En ce qui concerne IPv6, le pilote a différents chemins de code pour ipv6, tout comme le noyau. Il peut y avoir un bogue dans l'un de ces chemins qui n'est pas dans ipv6, ou, comme ISTR d'un bogue il y a quelque temps, quelque chose exécute un codepath ipv6 alors qu'il devrait exécuter un codepath ipv4 ou vica versa. La pile entière est assez alambiquée.

nouveau comportement. Changer les paramètres régionaux et faire la mise à niveau et la mise à jour apt-get a maintenant le comportement suivant lorsque mon pi3 est connecté via WIFI:

maintenant, les périphériques en dehors du LAN local peuvent se connecter à PI via TCP / IP.

PI refuse toujours toutes les connexions (TCP / IP) sur le LAN uniquement.

PI peut toujours accéder à Internet extérieur via WIFI.

ça ne fait rien. Rien n'a changé. C'est exactement le même comportement qu'avant. Pi3 wifi supprime tous les paquets sur le LAN local.

Juste pour suivre un peu ... J'ai démarré un nouvel AP (Linksys E4200 V2), que j'avais traîné. Je l'ai configuré sur le canal 11 pour 2,4 GHz, configuré WPA2 Personal, un BSSID et un mot de passe. Ensuite, configuré cela sur mon raspberry pi zéro w. Il s'est très bien connecté. J'ai ensuite déplacé cet AP dans la même pièce où se trouve mon AP de maison normal (qui est sur le canal 6). Mon RaspPi a alors obtenu ASSOC-REJECT status_code = 16. Le fait de remettre l'AP dans mon bureau a de nouveau permis à l'associé de RaspPi de très bien.

Donc, il semble que dans mon cas, au moins, le canal 11 pose un problème si AP est dans l'autre pièce. Je suppose que cela indique probablement un problème d'interférence.

Je publierai également ici une page Web que j'ai trouvée qui indique tous les status_codes et codes d'échec:

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

Cela montre que mon "status_code = 16" est causé par un timeout, donc l'un des systèmes ne reçoit tout simplement pas les paquets en temps opportun.

J'ai juste pensé que je jetterais cette information là-bas au cas où cela aiderait quelqu'un.

Quand j'allume les lumières de ma cuisine, ma connexion wifi sur le
salon ... je ne sais pas pourquoi mais quand vous avez parlé d'interférence, je pense
je ne suis pas fou

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

Juste pour faire un petit suivi ... j'ai démarré un nouvel AP (Linksys E4200 V2),
que j'avais traîner. Je l'ai installé sur le canal 11 pour 2.4Ghz, configuré
WPA2 Personal, un BSSID et un mot de passe. Puis configuré ceci sur ma framboise
pi zéro w. Il s'est très bien connecté. J'ai ensuite déplacé cet AP dans la même pièce
où se trouve mon AP domestique normal (qui est sur le canal 6). Mon RaspPi alors
obtenu ASSOC-REJECT status_code = 16. Déplacer le point d'accès dans mon bureau une fois
encore une fois fait l'associé RaspPi très bien.

Donc, il semble que dans mon cas, au moins, le canal 11 pose un problème si AP est
dans l'autre pièce. Je suppose que cela indique probablement une interférence
problème.

Je publierai également ici une page Web que j'ai trouvée qui raconte ce que tous les
status_codes et codes d'échec sont:

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

Cela montre que mon "status_code = 16" est dû à un délai d'expiration, donc l'un des
les systèmes ne reçoivent tout simplement pas les paquets en temps opportun.

Je pensais juste que je jetterais ces informations là-bas au cas où cela aiderait
n'importe qui.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314872003 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ACeQBJdfk2zp1sReVVs1wvrilKHXNm53ks5sNR42gaJpZM4HupC5
.

Il existe un très bon programme WiFi Analyzer pour Android, qui montre quels points d'accès sont autour de vous, ainsi que leurs informations détaillées. (J'aimerais que quelque chose comme ça existe pour iPhone / iPad, mais Apple ...)

@ JamesH65 vous pilote de couche liaison de données (couche 3) dérange la couche réseau 3. «Mess» n'est probablement pas non plus un mot approprié pour cette situation ...

Je ne dis pas ça en fait. Je ne suis pas un expert des réseaux Linux
pile, mais je me souviens certainement avoir vu des éléments spécifiques à IPv6 dans
un chauffeur quelque part.

Tout le contenu est dans l'arborescence du noyau, vous êtes invités à jeter un coup d'œil
vous-même pour mettre votre esprit au repos.

Le 13 juillet 2017 à 08h58, TheDiveO [email protected] a écrit:

@ JamesH65 https://github.com/jamesh65 vous me mettez vraiment mal à l'aise
disant qu'un pilote de couche de liaison de données (couche 3) dérange
la couche réseau 3. "Mess" n'est probablement pas un mot approprié pour cela
situation soit ...

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315002002 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHUSoqqxnhaw4k2ECkzGC9CDkIlhYks5sNc4ngaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

@TheDiveO James fait référence à des choses comme le déchargement de la somme de contrôle matérielle.
SMSC95xx par exemple ne peut prendre en charge que le déchargement de la somme de contrôle IPv4 car IPv6 nécessite une somme de contrôle de 0x0000 remplacée par 0xFFFF. Voir https://github.com/torvalds/linux/commit/fe0cd8ca1b82983db24b173bb8518ea646c02d25. Par conséquent, IPv6 et IPv4 suivront des chemins de code différents. Rien de douteux là-bas, mais inhérent à la pile réseau où le matériel ne peut pas couvrir toutes les situations.

Je suis presque sûr que ce bogue est dans le pilote Broadcom, pas dans le noyau.

Presque certainement. Le pilote Brcm est cependant un gros morceau de code, et des bogues
comme ça ne sont pas faciles à déboguer, surtout lorsque vous ne pouvez pas les répliquer ...

Le 13 juillet 2017 à 13h04, Alexandre Bolelli [email protected]
a écrit:

Je suis presque sûr que ce bogue est dans le pilote Broadcom, pas dans le noyau.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315058283 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHbr5SiWPKvQZOY7rN8IbyIIscNfVks5sNgexgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Plus je lutte avec cela, plus je commence à me demander si cela est lié à l'incapacité d'Ubuntu / Debians à connecter wlan0 et eth0 au même sous-réseau sans configuration étendue. Je vais examiner cela davantage et voir si tel est le problème.

@ JamesH65 serait-il utile que moi (ou quelqu'un d'autre) mette en place zéro w ou rpi 3 pour vous dans un environnement où cela est facilement reproductible et vous donne un accès ssh pour que vous puissiez déboguer? (J'aurais besoin d'acheter zéro w supplémentaire pour cela).

Probablement pas mais merci pour l'offre. J'ai tendance à exécuter des modifications personnalisées
pilote et noyau, avec des modifications apportées plusieurs fois par jour. Faisant cela
à distance n'est pas possible. Les mécanismes permettant de reproduire de manière fiable le problème sont
vraiment ce qu'il faut.

Le 13 juillet 2017 à 13h57, Tuomas Airaksinen [email protected]
a écrit:

@ JamesH65 https://github.com/jamesh65 cela aiderait-il si moi (ou quelqu'un
else) mettrait en place zéro w ou rpi 3 pour vous dans un environnement où c'est
facilement reproductible et vous donner un accès ssh pour que vous puissiez déboguer? (JE
aurait besoin d'acheter zéro w supplémentaire pour cela).

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315069935 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHeQ1RECH-uIIHWPX6ItvRdVbZG_Xks5sNhRWgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

James,
Si je fais cette simple boucle d'interrogation, je vois rapidement le réseau wifi embarqué se dégrader en un état inutilisable. Lorsque j'éteins le wifi embarqué et que j'utilise un wifi USB, cela fonctionne. Je ne me souviens pas s'il est sensible à la présence ou à l'absence de l'appareil BT, et je ne peux pas facilement le vérifier pendant quelques jours. J'ai limité à 10 minutes pour pouvoir revenir dans le pi zéro w après l'expérience.

bash# ((t= date +% s +600)); while [ date +% s -lt $t ] ; do hcitool name <BTMAC>; done
J'espère que cela pourra aider,
Benjamin

Cette copie de code a perdu mes tiques arrière. Les échapper ...

((t = `date +% s` + 600)); while [`date +% s` -lt $ t]; do hcitool name "insert BT MAC"; terminé

OMG. Je pense que c'est réglé. Le Wi-Fi est activé lorsque l'Ethernet est débranché. Incroyable.

J'ai supprimé toute mention de eth0 de mon fichier / etc / network / interfaces, remplacé allow-hotplug par auto, puis forcé la mise hors tension sans fil sur wlan0 et wlan1.

mon fichier / etc / network / interfaces:

auto lo
bouclage iface lo inet

mise hors tension sans fil
auto wlan0
iface wlan0 inet manuel
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

mise hors tension sans fil
auto wlan1
iface wlan1 inet manuel
wpa-conf / etc / wpa_supplicant / wpa_supplicant.conf`

Puis j'ai rincé arp:

ip -s -s neigh flush all

Puis j'ai redémarré:

sudo reboot now

Et maintenant, mon wifi fonctionne. Incroyable. Merci à tous ceux qui ont commenté ce fil.

Votre problème de configuration particulier peut être résolu, le bogue dans le pilote Broadcom est toujours présent.

OK, nous avons examiné cela. Mon premier problème était que lors de la connexion SSH à mon appareil de test, la session se bloquait à moins que le câble Ethernet ne soit également inséré. Il s'avère que l'ARP est géré par l'une ou l'autre interface, donc lorsque l'Ethernet était connecté, il l'utilisait. Le fait de ne pas être connecté signifiait qu'il était géré par le Wifi et rencontrait un problème. Ce problème pourrait être résolu en désactivant QoS / ToS dans SSH (voir ici https://expresshosting.net/ssh-hanging-authentication/), ce qui implique à son tour que le pilote Broadcom Wifi est très mécontent du TOS (type de service) / champ DSCP en cours de définition. Cela a déjà été vu dans NTP (numéro 1519). Je soupçonne que cela pourrait être une cause des problèmes de Wifi liés à ce problème et je vais fouiller dans le pilote Brcm aujourd'hui pour voir si je peux trouver quelque chose.

Rapport intérimaire. Nous constatons certainement des problèmes avec certaines valeurs de paquets TOS, entraînant la suppression silencieuse des paquets, provoquant des verrouillages SSH. Rien d'évident encore dans le code impénétrable du pilote, que TBH ne devrait pas toucher à cette partie du paquet de toute façon, mais il se passe clairement quelque chose. Cela a-t-il quelque chose à voir avec les gels généraux de WLAN signalés ici? Je ne sais pas encore.

J'ai des problèmes similaires sur un Pi Zero W avec jessie raspbian et le noyau 4.9.35+
J'ai le même problème mentionné par JamesH65 avec SSH et ntpd (TOS). Le correctif de https://expresshosting.net/ssh-hanging-authentication/ a fonctionné pour sshd. J'ai également des problèmes de déconnexion wlan0, mais avec des messages de journal un peu moins détaillés. Il semble superficiellement que le transporteur est perdu et wpa_supplicant échoue parfois à renégocier. Le seul moyen de sortir de cela est d'émettre ifdown wlan0, attendez, ifup wlan0 pour moi, puis wlan0 recommence à fonctionner. Heureux de fournir des journaux si quelqu'un en a besoin. Dites-moi simplement lequel.

Rapport intérimaire. Je voulais prendre quelques notes avant qu'elles ne soient oubliées. Nous avons déterminé que c'est la réponse du pi connecté sans fil qui disparaît lors de l'accès via SSH à partir d'un autre appareil. Si cette réponse a le champ TOS défini, le paquet est abandonné en silence - ne revient jamais au demandeur. Nous pouvons reproduire cela en utilisant netcat. Une simple commande net cat du Pi sans fil avec le jeu d'indicateurs TOS ne semble pas sortir de l'appareil.
Donc, sur le PI sans fil, essayez d'envoyer un paquet UDP à un autre appareil ...
nc -T 0x10 -usept
Le périphérique ne semble pas recevoir le paquet (comme indiqué en exécutant tcpdump sur la destination)
nc -T 0x00 -usept
accédera au système distant.
Nous n'avons essayé cela que sur le réseau sans fil ici au bureau. Je dois configurer un autre réseau Wifi pour voir s'il s'agit d'un routeur ou d'un problème dans le pilote.

Correction mineure de la commande netcat ci-dessus
nc -T 0x10 -u <dest_ip> 7
Le port UDP 7 a été choisi car il s'agit du service d'écho. Peu importe que cela ne fonctionne pas sur la machine distante, bien que cela conduise à la réponse ICMP inaccessible appropriée, ce qui est un indicateur utile que l'extrémité distante a reçu le message.

Commencer à penser que le problème SSH / ToS n'est en fait pas lié. J'ai tracé les paquets jusqu'au niveau HW et peu importe que les indicateurs TOS soient définis ou non, les paquets semblent descendre jusqu'au micrologiciel (ou au moins à la fonction brcmf_sdiod_send_pkt qui a dépassé toute gestion de priorité dans le pilote linux). Ce qui indique que les problèmes sont soit dans le micrologiciel de la puce (source fermée), soit en fait liés au routeur - c'est-à-dire que le routeur sans fil que j'utilise ne laisse pas passer les indicateurs TOS qui sont non-zéro (ou peut-être> 0x04). Je vais essayer un autre routeur sans fil demain pour essayer de le confirmer.

Y a-t-il une chance de localiser le service responsable du développement du module brcmfmac afin que quelqu'un puisse suivre ce fil ou au moins répondre si un correctif pour ces bogues sera publié?

Nous sommes déjà en contact via la liste de diffusion linux-wireless.

Le 19 juillet 2017 à 19h06, "Alexandre Bolelli" [email protected] a écrit:

Y a-t-il une chance de localiser le département responsable de
le module brcmfmac pour que quelqu'un puisse suivre ce fil ou au moins
répondre si un correctif pour ces bogues sera publié?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316469790 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHYtYvpxdKd3SBBynOnlDN-ZXiWs_ks5sPkW9gaJpZM4HupC5
.

Nous sommes déjà en contact via la liste de diffusion linux-wireless.

... et des itinéraires plus directs. Le problème a toujours été celui de la reproductibilité - une fois que nous avons un moyen de démontrer clairement le problème, nous pouvons le présenter à Broadcom / Cypress et le résoudre. Je n'ai jamais été en mesure de voir le problème en utilisant NTP, mais James a eu un échec avec SSH, donc je suis optimiste que nous arriverons à la cause racine.

@pelwell +1 pour le terme "_ échec réussi" _ :)

J'ai un correctif hacky pour le problème de verrouillage SSH. Cela semble être un problème dans le micrologiciel. Voici quelques détails.

»
Nous avons étudié un problème sur le Raspberry Pi, où SSH et
Les sessions NTP échouent lorsque l'indicateur TOS est défini dans l'en-tête IPv4.

Voici un extrait de ce qu'est TOS:

TOS est 0x08 ou 0x10. Un seul des 4 bits peut être défini à la fois.
0x10 - minimiser le retard
0x08 - maximiser le débit
0x04 - maximiser la fiabilité
0x02 - minimise le coût monétaire.
Techniquement, TOS a été remplacé par DSCP, mais est toujours pris en charge.

Nous pourrions essayer de recréer ce problème avec DSCP si vraiment nécessaire, mais ce n'est pas le cas
semblent pertinents.

Des détails sur le problème SSH et une solution de contournement peuvent être trouvés ici https://expresshosting.net/ssh-hanging-authentication/

Cependant, il s'agit clairement d'un problème quelque part dans les communications
pile, c'est donc ce que nous avons étudié.

Nous avons pu reproduire un exemple simple en utilisant netcat. tout d'abord,
connecter un Pi sans fil à un AP (PiA), avec un autre appareil connecté
soit sans fil ou via Ethernet sur le même réseau (PiB).

Sur l'exécution PiB

sudo tcpdump -n 'udp port 7' -v -i wlan0 <<<< ou eth0 selon la connexion

Sur PiA,

nc -T 0x10 -usept

Cela envoie un paquet UDP au port 7, avec l'indicateur TOS défini sur 0x10.

Cela n'arrivera PAS (ou sera parfois très retardé - 10 secondes)

Envoi de TOS en tant que 0

nc -T 0x0 -usept

Arrivera. 0x02 et 0x04 arriveront également, 0x8 et 0x10 ne le seront pas.

L'instrumentation du pilote brcmfmac montre que le paquet avec le TOS
flag = 0x10 est correctement envoyé dans la pile vers le matériel, mais alors le
le paquet disparaît.

Nous avons pu faire passer le paquet en piratant le code BCDC,
dans la fonction bcdc.c! brcmf_proto_bcdc_hdrpush, la priorité du
le paquet est également poussé dans l'en-tête bcdc. En définissant ceci sur un
valeur constante (qui pourrait être n'importe quoi de 0 à 7), le paquet est
transmis. Il semble donc qu'une valeur constante pour la priorité bcdc
fonctionne, mais en le définissant sur la priorité déterminée par le
Les choses de priorité skb échouent SI le TOS est 0x08 ou 0x10. Donc, il semble
être une combinaison de paquets avec des priorités variables qui provoque
les valeurs de priorité plus élevée échouent, pas la valeur elle-même.

Puisque la priorité d'en-tête BCDC est destinée au micrologiciel,
semblerait être un problème dans le firmware lui-même, pas dans le Linux
chauffeur.

Voici une différence du changement qui semble empêcher le problème de se produire.

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 Super. Puisque je ne m'attends pas à un correctif du micrologiciel bientôt, pourriez-vous s'il vous plaît copier ceci sur linux-wireless?

Je vais attendre quelques informations de Broadcom / Cypress, car je suis
pas sûr que ce hack soit sûr en toutes circonstances. Je leur ai envoyé un e-mail. Une fois que
Je reçois des commentaires, j'enverrai un correctif à linux-wireless.

Le 20 juillet 2017 à 12 h 41, Stefan Wahren [email protected] a écrit:

@ JamesH65 https://github.com/jamesh65 Génial. Puisque je ne m'attends pas à un
bientôt le correctif du firmware, pourriez-vous s'il vous plaît copier ceci sur linux-wireless?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316678154 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHY3DlxTr9mehRDlxBK3NWbjowxxyks5sPzzqgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Certains résultats de tests ne semblent indiquer aucun effet néfaste de ce piratage. Je viens de transférer des données dans les deux sens, 500 Mo vers le Wireless Pi, 3,4 Go envoyés. Les paquets RX 56 ont chuté à partir de 794730, aucun paquet TX a chuté de 2813930. Les performances semblent parfaites pour une connexion à 11 Mbit / s. Cela semble donc acceptable, mais ce hack désactive en fait quelque chose qui devrait probablement être activé, donc pas une solution à long terme.

@lategoodbye J'ai réfléchi à l'idée de pousser cela vers linux-wireless. Étant donné que ce piratage n'est vraiment pertinent / testé que pour la puce particulière du Pi (BCM43438?), Et que le code du pilote est pour plusieurs modèles de puces, le correctif devrait déterminer le type de puce utilisé avant d'effectuer le changement, et je soupçonne que linux-wireless ne serait pas satisfait de ce genre de changement et que je ne pourrais pas le tester de toute façon. Je vais certainement le publier sur notre repo (à moins qu'un correctif de firmware ne soit à venir, j'en doute dans un calendrier raisonnable). Je ne sais pas comment le pousser vers linux-sans fil, voire pas du tout.

@moonman
Pensez-vous que cela pourrait être poussé vers ARCH linux-raspberrypi?

@ JamesH65 Bien sûr, votre hack ne convient pas à tous les modèles de puces. Mais ce n'est pas votre travail de trouver une solution pour tous. Je pense qu'une simple copie de votre long commentaire ci-dessus (y compris le hack) serait suffisante. Mon intention était d'informer les autres développeurs de noyau non Broadcom du problème. Je ne m'attendais pas à ce que vous envoyiez un correctif approprié pour ce problème, seulement un rapport de bogue.

Je suggère que nous l'introduisions dans notre dépôt pour faire des tests sérieux - commencez par rpi-4.12.y qui est utilisé par les versions de pointe de LibreElec tous les soirs.

Une pensée - pourriez-vous rendre le patch plus sélectif dans son filtrage prioritaire et toujours résoudre le problème?

Je prépare juste un PR pour que cela aille au repo Pi.

En ce qui concerne la vérification sélective, j'ai essayé de détecter simplement la priorité
6 (celui qui est transmis dans la pile - il est traduit du TOS
valeur à quelque chose de plus spécifique à la pile Linux), et en définissant cela sur 0 et
cela a semblé fonctionner, mais je soupçonne que c'est une combinaison de
priorités différentes plutôt que spécifiquement 6 qui cause le problème. nous
sachez également qu'un TOS de 0x08 a également des problèmes, et c'est-à-dire IIRC,
converti en 2 au moment où il arrive à ce point. Nous pourrions simplement dire, si
son 6 ou 2, puis mettez-le à zéro, mais je ne suis toujours pas sûr que cela attraperait
tout ce qui peut causer des problèmes. Puisque la valeur est de toute façon 0-7, je suppose,
pour ce hack, il est préférable de simplement mettre à 0 dans tous les cas. Nous savons que
fonctionne, ce n'est peut-être pas optimal bien sûr, mais je pense que tous les paquets
traverser. Notez que ce paramètre n'affecte PAS la valeur TOS dans le
Paquet IPv4 - cela reste le même, c'est juste ce système d'envoi du
priorité à la puce et comment elle la gère ensuite qui semble floconneuse.

Le 21 juillet 2017 à 09h35, Phil Elwell [email protected] a écrit:

Une pensée - pourriez-vous rendre le patch plus sélectif dans sa priorité
filtrage et avez toujours résoudre le problème?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

J'ai eu un contact avec Cypress, qui va essayer de l'obtenir
regarda dès que possible.

Le 21 juillet 2017 à 10h11, James Hughes [email protected] a écrit:

Je prépare juste un PR pour que cela aille au repo Pi.

En ce qui concerne la vérification sélective, j'ai essayé de détecter simplement
priorité 6 (celle qui est transmise à la pile - elle est traduite de
la valeur TOS à quelque chose de plus spécifique à la pile Linux), et en définissant cela sur
0 et cela semble fonctionner, mais je soupçonne que c'est une combinaison
priorités différentes plutôt que spécifiquement 6 qui cause le problème.
Nous savons également qu'un TOS de 0x08 a également des problèmes, c'est-à-dire IIRC,
converti en 2 au moment où il arrive à ce point. Nous pourrions simplement dire, si
son 6 ou 2, puis mettez-le à zéro, mais je ne suis toujours pas sûr que cela attraperait
tout ce qui peut causer des problèmes. Puisque la valeur est de toute façon 0-7, je suppose,
pour ce hack, il est préférable de simplement mettre à 0 dans tous les cas. Nous savons que
fonctionne, ce n'est peut-être pas optimal bien sûr, mais je pense que tous les paquets
traverser. Notez que ce paramètre n'affecte PAS la valeur TOS dans le
Paquet IPv4 - cela reste le même, c'est juste ce système d'envoi du
priorité à la puce qui semble floconneuse et comment elle la gère ensuite
semble floconneux.

Le 21 juillet 2017 à 09h35, Phil Elwell [email protected] a écrit:

Une pensée - pourriez-vous rendre le patch plus sélectif dans sa priorité
filtrage et avez toujours résoudre le problème?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Nous savons également qu'un TOS de 0x08 a également des problèmes, et c'est-à-dire, IIRC, converti en 2 au moment où il arrive à ce point.

Correct. TOS 0x08 (maximiser le débit) mappé à 2. Ce sont des valeurs TC_PRIO_xxx de http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/pkt_sched.h#L19. 6 = INTERACTIF, 2 = VRAC.

Les tests précédents avec soit la définition d'IPQoS sur 8 dans sshd_config, soit avec netcat utilisant TOS 8 entraînaient des pertes de paquets.
Ni 0x02 ni 0x04 n'ont causé de problèmes, mais un pilote wifi ne peut pas faire grand-chose par rapport à la différence de coût (il n'y en a pas) ou à la fiabilité, il les ignore donc probablement.
edit En fait, la table de mappage sur http://elixir.free-electrons.com/linux/latest/source/net/ipv4/route.c#L177 prenant tos>>1 définit TOS 0x02 et 0x04 sur TC_PRIO_BESTEFFORT = 0 de toute façon, ce qui explique pourquoi ils n'ont aucun problème.

Juste un petit rapport. Cypress a été en mesure de reproduire le problème et est
vérifier le firmware si à la recherche d'espoir. Réponse très agréable et rapide
des gars là-bas.

Le 21 juillet 2017 à 11h07, 6by9 [email protected] a écrit:

Nous savons également qu'un TOS de 0x08 a également des problèmes, c'est-à-dire IIRC,
converti en 2 au moment où il arrive à ce point.

Correct. TOS 0x08 (maximiser le débit) mappé à 2. Ils sont TC_PRIO_xxx
valeurs de http://elixir.free-electrons.com/linux/latest/source/
inclure / uapi / linux / pkt_sched.h # L19. 6 = INTERACTIF, 2 = VRAC.

Tests précédents en définissant IPQoS sur 8 dans sshd_config ou avec
netcat utilisant TOS 8 a entraîné des paquets perdus.
Ni 0x02 ni 0x04 n'ont causé de problèmes, mais il y a peu de pilote wifi
peut faire sur la différence de coût (il n'y en a pas) ou la fiabilité est probablement
les ignorant (je n'ai pas vérifié).

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316962443 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHXTmjzqVW0o4T9IIoYFPprKvEvS7ks5sQHhXgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Une manière plus simple de reproduire - utilisez le ping! (J'avais oublié que ping / ICMP était supérieur à IP - idiot moi)

ping -Q 0x10 <dest ip addr> sur le Pi3
et exécutez tcpdump -n -v -i wlan0 'icmp' sur la destination.
Résultats en> 90% de perte de paquets sur -Q 0x10 ou -Q 0x08. Cela commence souvent bien avec 4 paquets séquentiels, mais devient ensuite très intermittent.
C'est un peu plus utile que netcat car (a) il continue de se répéter, et (b) il vous indique quand il obtient une réponse.

Il existe une solution de contournement ici: https://github.com/raspberrypi/linux/pull/2126
Si vous voulez le tester avec le noyau 4.9, utilisez rpi-update.
Puis remplacez:
modules / 4.9.39 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko avec ceci
modules / 4.9.39-v7 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko avec ceci

EDIT: Le dernier noyau de mise à jour rpi inclut désormais le correctif, le téléchargement des modules n'est donc plus nécessaire.

Je ne sais pas si c'est lié. La connexion sur le Broadcom embarqué sur mon Pi Zero W tombe toutes les 2 heures lorsqu'une deuxième interface wlan1 est active avec un dongle rt8192eu / 8192eu. Cela ne semble pas être un problème d'alimentation car il est très cyclique, j'ai un pastebin des déconnexions à https://pastebin.com/5hMQHWeW

Lorsque cela est en cours, wpa_supplicant renonce parfois à essayer sans raison évidente autre que l'échec de l'authentification et le seul moyen de rétablir la connectivité sur wlan0 est d'émettre ifdown / ifup qui fonctionne alors à 100%.

Maintenant, je ne sais pas si ce sont les problèmes liés au module de noyau Broadcom qui causent des problèmes, ou si c'est le buggy 8192eu ou les deux. Heureux de fournir plus de lignes de journaux si nécessaire ou de publier dans un fil différent, mais quelqu'un sur #raspbian m'a suggéré d'ajouter ceci ici.

Si vous pouvez confirmer que vcgencmd get_throttled renvoie 0x0 après une déconnexion, cela éliminera un problème d'alimentation.

Cela se produit généralement lorsque je dors / pas avec le Pi et que je découvre rétrospectivement que je ne peux plus me connecter (alors je me connectais via le deuxième AP et réinitialiser wlan0). Cependant, puisque le dongle 8192eu est maintenant débranché, il n'y a pas eu d'événement. Je peux brancher le deuxième dongle avec le module buggy, mais combien de temps après la déconnexion dois-je vérifier vcgencmd get_throttled?

Tant que vous n'avez pas redémarré, les bits supérieurs vous diront s'il y a déjà eu un événement de sous-tension.

Je l'ai juste couru. Certainement pas redémarré depuis la dernière déconnexion. Peut confirmer les retours de vcgencmd get_throttled:
étranglé = 0x0

Malheureusement, get_throttled ne fonctionnera pas sur un Pi0 / Pi0w (n'a pas de circuit de détection de sous-tension).

Pour une raison quelconque, copier et coller le diff de JamesH65 n'a pas fonctionné pour moi. Fabriqué un fichier de correctif qui devrait s'appliquer immédiatement, les gens supposés pourraient trouver cela utile: https://github.com/bortek/EZ-WifiBroadcast/blob/master/kernel/linux-4.9.28-brcmfmac-tos.patch

Le nom de fichier indique 4.9.28, mais devrait s'appliquer au moins jusqu'à 4.9.35 (et probablement aussi les plus récents).

Copiez ce fichier dans le répertoire racine de l'arborescence du noyau et appliquez avec patch -p1 < linux-4.9.28-brcmfmac-tos.patch

Informations supplémentaires (mais étranges):

Si le Pi Zero W est connecté à wlan0, mais sinon sans rien faire (script cron vérifiant sntp toutes les 15 minutes au maximum), il y a des déconnexions très fréquentes, quelque chose de l'ordre de 1 à 10 / heure durant au plus une seconde chacune.

Si j'avais quelque chose utilisant la connexion, par exemple, au ralenti sur IRC (plusieurs grands canaux), la connexion ne perd pas une seule fois pendant tout le temps, c'est le cas.

Il s'avère que charger les modules du noyau 4.9.39 sur 4.9.35 n'était pas une bonne idée.

Autre rapport de bogue du forum, une erreur de boîte aux lettres semble courante.

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

Le dernier noyau de mise à jour rpi inclut désormais le correctif prioritaire BCDC.

Cypress (anciennement Broadcom) nous a donné de nouvelles versions des firmwares WiFi et Bluetooth à tester. Vous pouvez télécharger une pré-version ici . Après avoir téléchargé sur votre Pi, exécutez:

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

Cela va extraire puis installer le nouveau firmware (les anciennes versions seront d'abord sauvegardées).

Pour revenir au firmware d'origine (ce que je vous recommande de faire avant d'installer une version appropriée):

./brcmfw -u

Ce qui a changé:

1. CVE-2017-9417: correction du problème «Broadpwn»
2. Ajoutez la chaîne «CY» dans la chaîne de version.
3. Correction de blocage du numéro de séquence AMPDU (correctif potentiel pour ce problème)
4. Mise à niveau de la version CLM
5. CVE-2017-0572: correction de corruption de mémoire

Juste une remarque: j'ai désactivé le wifi interne sur mon premier Pi Zero W et suis passé à un dongle wifi USB, tous les problèmes ont disparu. Il y a quelques jours, j'ai installé un autre Pi Zero W pour contrôler mon imprimante 3D (en utilisant OctoPi). J'ai été un peu surpris de voir que le wifi interne semble fonctionner parfaitement - mais après quelques tests, je peux confirmer que le wifi se brise dès que je me connecte à partir de mon téléphone Android LG G4 (navigateur Chrome). Quand j'y pense, je suppose que le comportement sur le premier Pi était assez similaire ...
La connexion depuis mon PC n'entraîne pas de tels effets.

Veuillez essayer le nouveau micrologiciel et rapporter vos résultats.

j'ai installé le micrologiciel de prévisualisation. J'obtiens toujours l'erreur «noyau raspberrypi: brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu:», suivie d'une panne de wifi.

Quel est votre cas d'utilisation?

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

essayer la configuration de travail publiée là-bas. Je mettrai à jour.

Veuillez fournir la version de votre noyau, un résumé des appareils connectés et le temps nécessaire pour que l'erreur apparaisse.

L'erreur de la boîte aux lettres est toujours sous enquête, je ne m'attends pas à cela
firmware pour le réparer. Il y a plus de débogage dans ce firmware pour aider à suivre
il vers le bas cependant. Si vous activez le débogage du pilote (désolé, sur mobile et
ne pas avoir de détails sur la façon de faire cela) et voir l'erreur, puis vider le
déboguer et publier les détails ici lorsque vous obtenez l'erreur de boîte aux lettres serait
utile.

Le 13 août 2017 à 21h40, "Stefan Wahren" [email protected] a écrit:

Veuillez fournir la version de votre noyau, un résumé des appareils connectés et
il faut longtemps pour que l'erreur apparaisse.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322062745 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHRwsQyHa-QqOP7ntTqgCfWlgXpEqks5sX1DlgaJpZM4HupC5
.

Le débogage est désactivé par défaut et nécessite une reconstruction de module pour l'activer (peut-être devrions-nous changer cela pendant ces investigations). Les modifications requises sont l'ajout de BRCMDBG=y à .config suivi d'une reconstruction, puis de brcmfmac.debug=0x???????? à /boot/cmdline.txt , où ???????? est un nombre hexadécimal comprenant valeurs de bits documentées ici: https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h#L22

J'ai essayé le firmware de test posté par pelwell, le problème persiste. La connexion se fige toutes les 1 à 2 heures. Lorsque la connexion a été interrompue et que j'ai essayé de cingler ( ping 8.8.8.8 ), cela fonctionne à nouveau _briefly_ jusqu'au 8e ping. Le comportement de ping est cohérent à travers les blocages. Working-> freeze-> ping 8.8.8.8-> working -> 8th ping -> gèle Après cela, je dois redémarrer mon Raspberry Pi. Je ne sais pas si ça aide.

Noyau:
Linux raspberrypi 4.9.41-v7 + # 1023 SMP Mar 8 août 16:00:15 BST 2017 armv7l GNU / Linux

Micrologiciel:
BT: test_170808
Poubelle WiFi: test_170808
Txt WiFi: test_170808

Quelque chose de pertinent dans dmesg quand cela se produit?

Le 14 août 2017 à 13h16, "GIlang Charismadiptya" [email protected]
a écrit:

J'ai essayé le firmware de test posté par pelwell, le problème persiste.
La connexion se fige toutes les 1 à 2 heures. Quand la connexion est tombée et que je
essayé de cingler (ping 8.8.8.8), il fonctionne à nouveau brièvement jusqu'au 8
ping. Après cela, je dois redémarrer mon Raspberry Pi.

Noyau:
Linux raspberrypi 4.9.41-v7 + # 1023
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1023&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=AKaU_LFRmDMObaVb2VxPhT3pS6_Sd6Qnrtg_9TSH5pc&s=OFVHPpEIYXIdyZoaKEmVcXWxHk2O53Mv7nB_Kp-jNnI&e=
SMP mar 8 août 16:00:15 BST 2017 armv7l GNU / Linux

Micrologiciel:
BT: test_170808
Poubelle WiFi: test_170808
Txt WiFi: test_170808

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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=
.

Non, rien d'intéressant. Peut-être parce que je n'ai pas reconstruit le module avec la prise en charge du débogage. Comment faire? ou allez-vous fournir le module compilé? Merci.

Vous trouverez ci-dessous les journaux 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
`

Voir l'article de Phil ci-dessus pour plus de détails sur le module de débogage. Nous sommes particulièrement
intéressé par la trace de débogage lorsque l'erreur de boîte aux lettres se produit.

Le 14 août 2017 à 17h52, "GIlang Charismadiptya" [email protected]
a écrit:

Non, rien d'intéressant. Peut-être parce que je n'ai pas reconstruit le module avec
prise en charge du débogage. Comment faire? ou allez-vous fournir le module compilé?
Merci.

Attaché ci-dessous le journal dmesg:

` pi @ raspberrypi : ~ $ sudo dmesg

[4.654722] brcmfmac: Version du micrologiciel = wl0: 7 août 2017 00:46:29 version
7.45.41.46 (r666254 CY) FWID 01-f8a78378
[5.752968] smsc95xx 1-1.1: 1.0 eth0: le matériel ne peut pas utiliser à distance
Réveillez-vous
[5.753285] IPv6: ADDRCONF (NETDEV_UP): eth0: le lien n'est pas prêt
[6.206530] IPv6: ADDRCONF (NETDEV_UP): wlan0: le lien n'est pas prêt
[6.206577] brcmfmac: gestion de l'alimentation désactivée
[7.088933] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: le lien est prêt
[7.340040] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: le lien est prêt
[7.340841] smsc95xx 1-1.1: 1.0 eth0: liaison, 100 Mbps, duplex intégral, lpa
0xCDE1
[7.431235] Ajout d'un swap 102396k sur / var / swap. Priorité: -1 étendues: 4
sur: 217088k SSFS
[10.182342] IPv6: ADDRCONF (NETDEV_UP): wlan0: le lien n'est pas prêt
[10.182357] brcmfmac: gestion de l'alimentation désactivée
[10.872838] IPv6: ADDRCONF (NETDEV_UP): wlan0: le lien n'est pas prêt
[10.872903] brcmfmac: gestion de l'alimentation désactivée
[11.594201] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: le lien est prêt
[14.128592] ip_tables: (C) 2000-2006 Netfilter Core Team
[14.172268] nf_conntrack version 0.5.0 (15360 compartiments, 61440 max)
[54.604680] aléatoire: crng init done

pi @ raspberrypi : ~ $ sudo dmesg -l err
[4.501055] raspberrypi-touchscreen 3f700000.dsi.0: micrologiciel Atmel inconnu
révision: 0xfa
»

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322228992 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHXuy3Eo5PqPAP8FfSFiYWMUQL7fAks5sYG1HgaJpZM4HupC5
.

Le dernier noyau rpi-update active BRCMDBG qui devrait autoriser l'option de ligne de commande brcmfmac.debug=0x???????? suggérée par @pelwell plus tôt.

Errrr ..... mon Pi3 qui était solide comme le roc avec le wifi le perd maintenant aussi depuis que je suis passé à la dernière raspbian il y a quelques jours :-(

Quels sont les symptômes? Je ne m'attendrais pas à une régression dans le firmware, ou
en effet le pilote lui-même.

Le 24 août 2017 à 20h07, Crrispy [email protected] a écrit:

Errrr ..... mon Pi3 qui était solide comme le roc avec le wifi le perd maintenant aussi depuis que je
mis à jour vers le dernier raspbian il y a quelques jours :-(

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-324728431 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHUxvLV3OzKGpcmEMGEoSad_piujBks5sbcoHgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

@Crrispy
Essaye ça:
J'ai supprimé toute mention de eth0 de mon fichier / etc / network / interfaces, remplacé allow-hotplug par auto, puis forcé la mise hors tension sans fil sur wlan0 et wlan1.

mon fichier / 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`

Puis j'ai rincé arp:

ip -s -s hennissez de tout rincer

Puis j'ai redémarré:

sudo redémarrer maintenant

Je suis presque sûr que je rencontre ce bogue régulièrement. Exécution de hostapd, utilisation du wifi Broadcom interne pour héberger un point d'accès et routage des clients qui s'y connectent via un dongle wifi USB qui sert de client sans fil. Plusieurs appareils sont connectés, mais dès que je porte le Pi hors de portée des appareils connectés, le crash du wlan semble se produire. Comme pour les autres, seul le périphérique wlan Broadcom interne tombe en panne: Ethernet et l'autre wlan ne sont pas affectés. J'obtiens également l'erreur "boîte aux lettres" dans le journal système:

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

(plus de détails sur le journal sur https://pastebin.com/NPB00ZEq)

J'avais remarqué que la sortie d'iwconfig ne montre plus la valeur Tx_Power lorsque le périphérique wlan est dans son état d'échec, donc je l'ai utilisé pour script un redémarrage automatique comme solution de contournement.

Je viens de mettre à jour la dernière mise à jour rpi, d'installer les pilotes wifi de test référencés ci-dessus et d'ajouter l'indicateur de débogage à mon cmdline.txt, en utilisant la valeur hexadécimale pour BRCMF_TRACE_VAL: bcrmfmac.debug=0x00000002

Si vous pouvez régulièrement obtenir l'erreur de boîte aux lettres, nous vous serions reconnaissants des résultats du pilote de débogage. Lorsque vous obtenez l'erreur de boîte aux lettres, veuillez faire quelque chose comme ceci pour obtenir les analyses médico-légales et publier les résultats ici, je peux les transmettre à Cypress qui étudie le problème.

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

Eh bien, ce qui était un problème facilement reproduit que je ne suis plus en mesure de dupliquer, depuis l'exécution de rpi-update. Je pourrais peut-être y arriver en rétrogradant à une nouvelle installation de la version Raspbian du 21 juin 2017, si cela pouvait être utile.

@ JamesH65
Géré pour capturer les analyses judiciaires que vous aviez demandées (après l'erreur de boîte aux lettres), mais pour être clair, c'est après la rétrogradation vers le noyau inclus dans la version de Raspbian du 21 juin. Cela a peut-être déjà été résolu, car je n'ai pas encore dupliqué le problème après avoir installé le micrologiciel de test publié par @pelwell il y a environ deux semaines et exécuté rpi-update.

Voici un lien vers la criminalistique:
https://pastebin.com/VVqVQ8FW

J'espère que c'est utile ...

Donc, avec l'ancien firmware, je soupçonne. Nous espérons obtenir la criminalistique pour
le nouveau firmware qui contient des messages supplémentaires (apparemment) destinés à suivre
dans le problème de la boîte aux lettres. Cela me fait penser que Cypress semble toujours penser
problème de boîte aux lettres sera là, même après les autres correctifs. Transmettra les données de toute façon au cas où cela aiderait.

Bon à savoir que les erreurs sont beaucoup plus difficiles à reproduire!

Le 29 août 2017 à 15h51, randyoo [email protected] a écrit:

@ 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=
Vous avez réussi à capturer les analyses judiciaires que vous aviez demandées, mais pour être clair,
c'est après la mise à niveau vers le noyau inclus dans le 21 juin Raspbian
construire. Cela a peut-être déjà été résolu, car je ne peux pas
dupliquez le problème après l'installation du micrologiciel de test publié par @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=
il y a environ deux semaines.

Voici un lien vers la criminalistique:
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=

J'espère que c'est utile ...

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Cela me fait penser que Cypress semble toujours penser
problème de boîte aux lettres sera là, même après les autres correctifs.

Oui, c'est aussi ce que je comprends.

@randyoo Merci pour les commentaires positifs.

@ JamesH65
D'accord, c'est arrivé à nouveau, cette fois sur le dernier firmware de mise à jour rpi, et en utilisant le firmware de test posté par @pelwell . Malheureusement, la sortie d'investigation semble identique à celle du post précédent. (Je ne sais pas pourquoi je ne reçois pas d'informations différentes / plus détaillées dans le vidage d'investigation, car le débogage est activé dans mon cmdline.txt, comme dans mon précédent post)

J'ai également vidé le contenu des autres éléments / sys / kernel / debug. Le voici: https://pastebin.com/pdFUPBxN

Lors du dernier gel du wlan, la trace du journal du noyau semble être plus détaillée. Voir le lien:
https://pastebin.com/KTxbgpYV

J'espère que cela pourra aider.

Y avait-il plus de détails dans la criminalistique du firmware? Je pense que c'est le
bit Cypress sont vraiment intéressés par le moment où l'erreur de boîte aux lettres se produit.

Le 31 août 2017 à 21h56, randyoo [email protected] a écrit:

Lors du dernier gel du wlan, la trace du journal du noyau semble être plus détaillée.
Voir le lien:
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=

J'espère que cela pourra aider.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Bon, désolé. Géré pour obtenir une capture de la criminalistique, et oui, il semble y avoir beaucoup plus de détails là-bas:
https://pastebin.com/qypfAfAp

Comme le fait d'avoir parfois de nouveaux cas m'aide, je l'obtiens aussi de temps en temps:

pi @ jempi : ~ $ grep "brcmf_sdio_hostmail: Contenu de données de boîte aux lettres inconnu: 0x40012" / var / log / syslog
14 août 22:16:23 noyau jempi: [501.247242] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
17 août 20:26:20 noyau jempi: [509.684277] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
24 août 23:57:37 noyau jempi: [573.652189] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
29 août 23:50:16 noyau jempi: [5052.517999] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
30 août 00:02:18 noyau jempi: [170.978988] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
30 août 23:58:03 noyau jempi: [8254.502431] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
2 septembre 00:33:28 noyau jempi: [5979.773944] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012

J'utilise le wifi interne (wlan0) comme AP et j'ai branché un dongle (wlan1) pour me connecter à mon routeur:
pi @ jempi : ~ $ ifconfig wlan0
Encapsulation de lien wlan0: Ethernet HWaddr b8: 27: eb: cf: db: b8
adr inet Bcast: 10.3.141.255 Masque: 255.255.255.0
inet6 addr: fe80 :: 6b56: 4657: 75cd: a501 / 64 Portée: Lien
UP BROADCAST RUNNING MULTICAST MTU: 1500 Métrique: 1
Paquets RX erreurs: 0 abandonnés: 0 dépassements: 0 trame: 0
Paquets TX erreurs: 0 abandonnés: 0 dépassements: 0 porteuse: 0
c ollisions: 0 t xqueuelen: 1000
Octets RX : 0 (0,0 B) Octets TX : 5492 (5,3 Kio)

pi @ jempi : ~ $ ifconfig wlan1
Encapsulation de lien wlan1: Ethernet HWaddr 00: 60: b3: db: 8a: 4a
adr inet Bcast: 192.168.1.255 Masque: 255.255.255.0
inet6 addr: fe80 :: 260: b3ff: fedb: 8a4a / 64 Portée: Lien
UP BROADCAST RUNNING MULTICAST MTU: 1500 Métrique: 1
Paquets RX erreurs: 0 abandonné: 2 dépassements: 0 trame: 0
Paquets TX erreurs: 0 abandonnés: 0 dépassements: 0 porteuse: 0
c ollisions: 0 t xqueuelen: 1000
Octets RX Octets TX

J'avais le noyau 4.9.35-v7 + et je l'ai mis à jour hier à 4.9.46-v7 + (avec rpi-update) mais ne m'aide pas. Entrée de syslog en cas d'échec:

2 septembre 00:33:28 noyau jempi: [5979.773944] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
2 septembre 00:34:00 noyau jempi: [6011.624839] brcmfmac: brcmf_netdev_wait_pend8021x: expiration du délai d'attente pour aucun paquet 802.1x en attente
2 septembre 00:34:02 noyau jempi: [6014.184823] brcmfmac: send_key_to_dongle: erreur wsec_key (-110)
2 septembre 00:34:05 noyau jempi: [6016.744833] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON a échoué -110
2 septembre 00:34:06 noyau jempi: [6017.704831] brcmfmac: brcmf_netdev_wait_pend8021x: expiration du délai d'attente pour aucun paquet 802.1x en attente
2 septembre 00:34:08 noyau jempi: [6020.264850] brcmfmac: send_key_to_dongle: erreur wsec_key (-110)
2 septembre 00:34:11 noyau jempi: [6022.824903] brcmfmac: brcmf_cfg80211_change_station: Échec de la configuration de l'autorisation SCB (de-), -110

Redémarrez l'interface wlan0 avec sudo ifconfig wlan0 vers le bas puis vers le haut n'a pas aidé.

@bulrog Veuillez également fournir les
Quel pilote utilise wlan1? Ce problème se produit-il toujours avec un dongle débranché?

Quelques captures de criminalistique supplémentaires:
https://pastebin.com/vqh3UcF3

Au cas où cela aiderait Cypress à regarder dans la bonne zone: j'ai rencontré ce problème de nombreuses fois maintenant, et il semble se manifester chaque fois qu'un appareil tente de se connecter. Cela s'est produit plusieurs fois après avoir atteint la portée du point d'accès ou lorsqu'un appareil endormi est réveillé.

J'ai gardé cette configuration assez longtemps pour capturer des analyses médico-légales, et s'il y a plus de détails que je peux fournir, je serais heureux de le faire, mais les plantages de wlan se produisent maintenant si fréquemment que cela rend mon appareil inutile. J'ai l'intention d'utiliser un autre dongle wifi USB pour remplacer la radio interne, afin d'atteindre la fiabilité.

J'ai transmis vos dernières analyses médico-légales à Cypress - merci d'avoir pris le temps.

Je voulais juste intervenir. J'ai exactement le même problème sur trois RPI3 exécutant le dernier firmware. J'utilise Octopi sur les trois et j'y accède via Printoid.

bcrmfmac.debug devrait être brcmfmac.debug (merci d'avoir repéré @MilhouseVH)
Je vais modifier les messages précédents.

bcrmfmac.debug devrait être brcmfmac.debug (merci d'avoir repéré @MilhouseVH)
Je vais modifier les messages précédents.

Sur cette base, j'ai supposé que les analyses médico-légales que j'avais capturées n'étaient pas complètes.

J'ai répété la capture d'investigation, elle peut être consultée à l'URL suivante:
https://pastebin.com/ha5rd7SW

De plus, mon fichier /var/log/kern.log a une taille de près de 200 Mo, la plupart se composant d'entrées très similaires. J'ai localisé l'erreur de boîte aux lettres à 00:53:19 et j'ai coupé quelques secondes avant et après l'erreur. J'espère que cela aide, voyez-le ici:
https://pastebin.com/JcE0zstS

donc je pense avoir trouvé le même problème, voir https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=192735

je peux le reproduire dans les 5 minutes. Vous avez besoin d'un trafic élevé sur le wifi (interface Web de la caméra) et d'un signal wifi très faible. J'ai pi zéro et c'est suffisant pour mettre vos doigts / mains autour de l'antenne embarquée pour obtenir le signal presque à zéro (mon routeur affiche un signal de 15 à 20%). Après environ 1 minute dans cet état, le wifi plante

@lategoodbye après une semaine, j'ai allumé mon pi et aucun problème tant que rien n'utilisait l'AP et après un certain temps, j'ai eu un problème lors de la connexion de mon téléphone à wlan0. Je lance la commande et le résultat peut être trouvé ici: https://pastebin.com/77tGfRcU

pour wlan1, j'ai utilisé un assez vieux dongle. Je ne me souviens pas du pilote que j'ai dû installer pour le faire fonctionner, mais voici ce que lsusb donne pour le matériel que j'utilise:

Bus 001 Périphérique 005: ID 0 cde: 0008 Adaptateur sans fil Z-Com XG-703A 802.11g [Intersil ISL3887]

Je ne sais pas si cela aide mais voici mon expérience:

J'ai acheté un Pi3 et l'ai testé pendant quelques jours avec le wifi interne (non loin de l'AP), et cela semblait fonctionner plutôt bien (je ne m'attendais pas à des débits élevés, il fallait juste que ce soit utile pour un shell distant via ssh ).

Après l'avoir mis dans un boîtier en aluminium, cela semblait toujours correct, mais le wifi a continué à devenir inutilisable au hasard. Jusqu'à quelques minutes sans ping. Il y avait encore des occasions où cela fonctionnait très bien pendant quelques secondes, mais il passait à nouveau à l'expérience «une frappe par seconde» ou cessait de fonctionner complètement.

Il semble qu'il n'y ait pas de connexion "lente mais utilisable" possible seulement une "très bonne" ou une "inutilisable". Cela peut être dû à un bogue dans le firmware. Je n'en ai aucune idée et franchement j'ai perdu patience et j'utilise à la place une toute petite clé USB qui fonctionne à 100% de manière stable.

Quelqu'un a-t-il trouvé une solution de contournement pour détecter le problème (en mode AP) et réinitialiser par programme le périphérique WLAN?

Pas ce que j'ai vu, le redémarrage de l'interface n'a pas aidé. Pour moi, le confinement était d'acheter un périphérique USB wifi externe et cela fonctionne comme un charme mais c'est dommage car maintenant j'ai éteint le wifi du pi (soupir!)

Voulez-vous dire le problème de la boîte aux lettres? Cela fait toujours l'objet d'une enquête chez Cypress.

Le 21 septembre 2017 à 08h38, "morel jerome" [email protected] a écrit:

Pas ce que j'ai vu, le redémarrage de l'interface n'a pas aidé. Pour moi le confinement
était d'acheter un périphérique USB wifi externe et cela fonctionne comme un charme mais c'est
dommage car maintenant j'ai éteint le wifi du pi (soupir!)

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur 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 couper le fil
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=
.

Oui, le problème de la boîte aux lettres. J'espère que cela sera corrigé, mais comme confinement, j'ai dû passer à un périphérique externe.

D'ACCORD. Nous sommes à la merci de Cypress sur celui-ci - c'est un problème de firmware, et ils sont les seuls à avoir accès. Je vais continuer à leur rappeler ..... nous pourrions avoir besoin de plus de criminalistique, mais publierons ici si c'est le cas.

mon wlan se déconnecte et se reconnecte après quelques secondes d'inactivité (je suppose que c'est une économie d'énergie, même si je l'ai désactivé avec iw, ou peut-être des interférences). Je ne sais pas s'il s'agit du même problème que celui discuté ici (car il se reconnecte immédiatement).

Si je me connecte avec ssh -o ServerAliveInterval 5 ... il ne se déconnecte plus.

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

@asssaf ,
Pas le problème, s'il se reconnectait, ce ne serait généralement qu'un problème de latence, mais lors de l'exécution sans tête sur WiFi (l'une des principales fonctionnalités potentielles du PiZero-W) lorsque le WiFi tombe et ne se reconnecte pas automatiquement, le système s'est écrasé à toutes fins pratiques.

Même si j'ai HDMI, souris et clavier sous de lourdes charges réseau comme avec Motioneye, parfois la seule façon de récupérer est de redémarrer.

J'ai répété l'installation et la configuration de Motioneye sur un Pi2 avec un dongle WiPi USB WiFi et jusqu'à présent, cela fonctionnait parfaitement avec des charges qui ont tué de manière fiable le PiZero-W en quelques heures. Pour moi, cela semble confirmer que c'est un problème de puce / pilote WiFi et non un problème avec Raspbian-stretch.

@ PeterTheMaster1 @randyoo @joshfria

OK, message pour quiconque voit régulièrement le problème de la boîte aux lettres et pourrait tester quelque chose pour moi.

Nous avons un micrologiciel de diagnostic de Cypress, qui peut aider à localiser le problème. Si quelqu'un avec le problème de la boîte aux lettres est prêt à exécuter ce micrologiciel, et lorsque le problème de la boîte aux lettres se produit, vider les analyses et publier les résultats ici, cela sera d'une grande aide. Attention, ce firmware ne doit pas être utilisé pour autre chose que pour ce test car il sera "non optimal"! Veuillez commenter ici si vous êtes capable de faire le test, et je prendrai contact avec le firmware et les instructions

@iurly : j'ai écrit un script qui détecterait le problème, puis redémarrer, car le fait de descendre et de monter l'interface

@ JamesH65 : Je serais ravi d'aider, comme avant. S'agit-il d'une nouvelle version du micrologiciel de diagnostic? J'ai publié une capture d'investigation il y a 3 semaines (sur cette page de problème) en utilisant le micrologiciel de diagnostic / débogage publié plus tôt sur cette page.

Oui, nouveau firmware de Cypress à partir du lundi 25 septembre.
diagnostics dedans. Les analyses médico-légales précédentes que vous avez fournies se sont réduites
le problème, ils ont besoin d'un peu plus de détails cependant. Je fais tourner une machine
pour 24 heures jusqu'à présent sans erreur de boîte aux lettres, donc actuellement impossible de le répliquer
moi même.

Pouvez-vous m'envoyer un email sur James. [email protected] et je peux vous fournir le firmware. Je ne veux pas le faire connaître plus globalement car c'est vraiment juste à des fins de test.

Le 27 septembre 2017 à 14h48, randyoo [email protected] a écrit:

@iurly https://github.com/iurly : j'ai écrit un script qui détecterait
le problème, puis redémarrez, depuis que l'interface vers le bas et vers le haut
n'a pas aidé ... Mais alors il redémarrait si souvent que je ne pouvais obtenir qu'un
appareil utile en le sortant du mode AP (et en attribuant des tâches AP à mon
Clé USB)

@ JamesH65 https://github.com/jamesh65 : Je serais heureux de vous aider, car
avant. S'agit-il d'une nouvelle version du micrologiciel de diagnostic? J'ai posté un
capture médico-légale il y a 3 semaines (sur cette page de problème) à l'aide de
firmware de diagnostic / débogage posté plus tôt sur cette page.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332526471 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHW_vEVuxFD-9RuxE003QZc_2NoFaks5smlIjgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

@ JamesH65 Si vous avez la gentillesse de fournir un lien vers le nouveau micrologiciel, je peux l'installer et essayer de capturer à nouveau le forensics, comme vous l'avez demandé.

Malheureusement, fournir un lien ici signifie qu'il est accessible au public, et
comme il s'agit vraiment d'un firmware de test, je préférerais qu'il ne s'échappe pas
le sauvage. D'où la demande à faire par e-mail. Si cela pose un problème, je téléchargerai
il quelque part et peut publier un lien.

Le 27 septembre 2017 à 15h56, randyoo [email protected] a écrit:

@ JamesH65 https://github.com/jamesh65 Si vous auriez la gentillesse de
fournir un lien vers le nouveau firmware, je peux l'installer et essayer de capturer
la criminalistique à nouveau, comme vous l'aviez demandé.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332548884 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHbVhHD2rk_hp3kG51WBY0R0IQzL3ks5smmIbgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

@ JamesH65 Je sais que je gèle régulièrement la carte sans fil interne du RPI3 en mode AP, donc je serais plus que disposé à aider, mais je ne suis pas tout à fait sûr que ce soit le problème de la boîte aux lettres ou autre. J'ai en fait cherché dans mes journaux un tel message mais je ne l'ai pas trouvé.

J'exécute le firmware livré avec le noyau 4.4.50 (et je ne peux pas vraiment mettre à niveau vers la dernière version 4.9 à cause d'une régression, voir # 2197), cette version afficherait-elle ce message ou a-t-elle été ajoutée ultérieurement?

Merci!

@iurly vous avez dit une chose juste, le problème de plantage dans les pilotes Broadcom se produit en mode AP, et je ne sais pas si cela est lié à l'erreur de boîte aux lettres. il semble qu'il y ait plus d'un bogue ici, c'est peut-être un bogue matériel dû au temps où le problème existe et qu'aucune solution n'a été trouvée.

Ce qui me dérange vraiment, c'est l'absence de solution de contournement, à moins de redémarrer tout le système.
Je veux dire, il n'y a même pas un moyen de réinitialiser le périphérique et de redémarrer hostapd?!?

@iurly vous avez dit une chose juste, le problème de plantage dans les pilotes Broadcom se produit en mode AP, et je ne sais pas si cela est lié à l'erreur de boîte aux lettres. il semble qu'il y ait plus d'un bogue ici, c'est peut-être un bogue matériel dû au temps où le problème existe et qu'aucune solution n'a été trouvée.

Juste pour info, j'ai aussi des problèmes en mode client / station. Exécution du maître LEDE, noyau 4.9 et utilisant le firmware 7.45.41.46.

@ JamesH65
Comprenez le désir d'empêcher la publication du micrologiciel de test. Le courrier électronique serait bien, mais je ne veux pas publier mon adresse ici non plus, et je ne vois pas de moyen d'envoyer des messages sur github.

Utilisez mon adresse pi ci-dessus pour m'envoyer un e-mail et je vous enverrai le firmware.

Ré. Mode Ap
Il y a eu quelques correctifs depuis la version 4.4, il vaut donc la peine d'essayer la dernière version
pour voir si ce problème persiste.

Ah, lorsque vous modifiez un commentaire, aucune mise à jour par e-mail n'est envoyée, et j'ai modifié mon e-mail Pi à l'entrée ci-dessus, vous n'avez donc peut-être pas été mis à jour. Utilisez le site Web github pour voir où vous devez m'envoyer un e-mail.

@ JamesH65 Vous a envoyé un e-mail. Heureux d'apprendre que la précédente capture médico-légale a contribué à le réduire, au moins ... Il semble que beaucoup de gens seront heureux lorsque ce problème sera résolu.

@ JamesH65
Voici une capture médico-légale à partir du firmware que vous avez envoyé par e-mail: https://pastebin.com/zdB36ttj
J'espère que ça aide.

Génial, passera à Cypress. Merci d'avoir fait ça.

J'ai un pi dans une configuration en ce moment où il semble que je puisse le reproduire à volonté. Si collecter plus de criminalistique est utile, faites-le moi savoir. L'erreur de boîte aux lettres est tout ce que je peux voir dans les journaux.

Après avoir remplacé la microSD dans ma Zero W, elle a été connectée pendant 7 jours sans problème. Je ne pense pas qu'il ait jamais survécu aussi longtemps. Cela semble étrange qu'une carte SD puisse influencer le WiFi, mais comme ils sont tous les deux connectés au bus SDIO, il est possible que l'un influence l'autre.

La carte que j'utilisais auparavant était une Transcend classe 4 de 8 Go (probablement bon marché) fournie avec ma carte UDOO Quad. En ce moment, c'est un Samsung EVO 32 Go. Les personnes qui rencontrent des problèmes peuvent vouloir essayer si l'utilisation d'une autre carte peut aider.

@stintel Intéressant, mais peut-être était-ce un problème de configuration du logiciel sur l'autre microSD, ou même une microSD endommagée.

Cela pourrait-il être lié au pouvoir? Peut-être que la carte bon marché a momentanément consommé trop d'énergie du bus?

J'ai chargé le firmware publié par Pelwell et j'ai vu une énorme amélioration. Avant, un SSH sur mon Pi 0W était comme appeler un terminal avec un modem à 2400 bauds et une ligne téléphonique de merde. Maintenant, je peux exécuter X à distance et cela fonctionne très bien.

Merci!

J'ai le même problème. En transférant une énorme quantité de noms de fichiers (sync-over-ftp) de raspberryPi3-internal-wifi vers Galaxy S5, le wifi cesse de fonctionner. mais parfois ça marche ...

J'ai eu le même problème de message de boîte aux lettres avec mon RPi3 WiFi AP, mais j'ai trouvé une solution dans ce forum , et cela a fonctionné pour moi. La solution était de modifier les paramètres suivants dans /etc/hostapd/hostapd.conf

wpa = 3 changé en wpa = 2auth_algs = 3 changé en auth_algs = 1

Je l'ai testé pendant 1 semaine et il ne montre plus les problèmes de boîte aux lettres.

Je ne sais pas si cela fonctionnerait pour vous tous, mais vous pouvez l'essayer et poster ici si cela fonctionne.

Voici le hostapd de travail, 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

Une mise à jour sur ce problème? Ou existe-t-il une solution de contournement connue?

Vous rencontrez toujours cela sur un Pi Zero W récemment acheté avec les derniers stretch-lite et rpi-update d'hier.

En utilisant le RPi pour diffuser un flux de caméra via RTSP (udp), je peux voir que la connexion se détériore considérablement juste avant que la connexion WiFi ne se coupe, après cela, la connexion WiFi ne se rétablit jamais et je dois redémarrer le Pi0W.

A dmesg > dmesg.log ne montre que:

brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Si je rapproche le Pi0W de mon point d'accès, le problème ne se produit pas.

Je n'utilise pas le Pi0W comme point d'accès, c'est juste un client. J'ai essayé différentes sources d'alimentation.

Nous attendons actuellement Cypress, les fournisseurs de la puce sans fil,
pour faire progresser la question. Je vais leur cingler, encore une fois.

Le 25 octobre 2017 à 14h02, Matthias Urhahn [email protected]
a écrit:

Une mise à jour sur ce problème? Ou existe-t-il une solution de contournement connue?

Toujours en train de rencontrer cela sur un Pi Zero W récemment acheté avec le dernier
stretch-lite et rpi-update d'hier.

En utilisant le RPi pour diffuser un flux de caméra via RTSP (udp), je peux voir le
la connexion se détériore considérablement juste avant la coupure de la connexion WiFi,
après cela, la connexion WiFi ne se rétablit jamais et je dois redémarrer le
Pi0W.

Un dmesg> dmesg.log affiche uniquement:

brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012

Si je rapproche le Pi0W de mon point d'accès, le problème ne se produit pas.

Je n'utilise pas le Pi0W comme point d'accès, c'est juste un client. j'ai essayé
différentes sources d'énergie.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-339322153 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHRlPhJBGXc3JFWbpw_Tf4_EKmgAeks5svzFQgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Eh bien ... j'ai mis à niveau vers le dernier noyau / firmware (apt-get upgrade puis rpi-update), et maintenant, même mon Pi3 qui avait un wifi solide le perd également après quelques heures !! Je sais, si ce n'est pas cassé, ne le répare pas ... je n'aurais pas dû le mettre à niveau, mais puisque je fais des tests de temps en temps dans mon 2ème Pi3 avec la même carte SD ...

FWIW, je peux également reproduire ce problème à volonté. J'ai créé un message de forum sur Raspberry Pi qui explique le problème:

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

REMARQUE: je n'utilise pas le Pi comme point d'accès. Je peux aider avec la criminalistique ou tester un firmware expérimental, etc. si cela aide.

Même problème ici. J'ai configuré ownCloud et je peux transférer des fichiers depuis mon ordinateur portable sans aucun problème.
Mais dès que je transfère des fichiers avec mon Samsung Galaxy S7, le wifi se casse et
raspberrypi kernel: [ 962.273390] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012 :
apparaît.

Mon routeur est une FRITZ! Box 7490.

Merci @srinathava pour le post qui décrit bien mon problème!

Les personnes qui ont testé avec le firmware de test peuvent-elles essayer ce qui suit - plus d'informations de débogage requises par Cypress.

1. en faisant insmod, ajoutez "debug = 0x100000"
2. une fois que le problème se produit, enregistrez la sortie "dmesg"

Merci.

Encore une demande d'aide sur celui-ci.

Les personnes qui ont testé avec le firmware de test (voir ci-dessus) peuvent-elles essayer ce qui suit - plus d'informations de débogage requises par Cypress.

en faisant insmod, ajoutez "debug = 0x100000"
une fois que le problème se produit, enregistrez la sortie "dmesg" - c'est le bit qui nous intéresse.

Merci.

@ JamesH65 Juste pour vous faire savoir, j'essaie maintenant de collecter les informations, mais le problème ne s'est pas encore manifesté. J'ai seulement apporté quelques petites modifications au fichier /etc/hostapd/hostapd.conf, mais ces modifications peuvent avoir résolu ce problème par inadvertance. Si le problème ne se présente pas dans quelques jours, j'annulerai ces modifications pour tenter de répliquer le problème et collecter les données de débogage.

Merci pour l'aide à ce sujet.

Il serait intéressant de voir les modifications que vous avez apportées à hostapd si, en effet, cela permet de contourner le problème.

Après 4 jours de stabilité, j'ai annulé mes modifications dans le fichier /etc/hostapd/hostapd.conf, et après seulement quelques heures, le problème est réapparu. Voici la sortie de dmesg:

[86340.811305] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
[86374.278317] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86376.838299] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86376.838314] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[86379.398310] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86381.958740] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86381.958754] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[86384.518337] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86384.518353] brcmfmac: brcmf_cfg80211_get_tx_power: error (-110)
[86387.078328] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86389.638353] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[86389.638366] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110

J'exécute un progiciel appelé

Quoi qu'il en soit, en commentant cette ligne dans /etc/hostapd.conf: et en le remplaçant par ceci: J'ai eu un fonctionnement stable pendant 4 jours consécutifs, alors que ça plantait en quelques heures, voire parfois même quelques minutes!

J'espère que tout cela aide.

Toutes mes excuses si je publie au mauvais endroit, je rencontre un comportement étrange avec le wlan interne RPi3 (broadcom) lors de l'envoi de paquets UDP Unicast sous raspbian.
J'envoie un petit paquet de données 2kb une fois par seconde, à l'extrémité du récepteur, cela est bloqué toutes les 120 secondes pendant environ 3-4 secondes. Ce test fonctionne comme une horloge, et je peux reproduire avec iperf en faisant ce qui suit

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

Ubuntu PC connecté en tant que client WiFi à RPi3 (IP 192.168.1.22 comme ci-dessus)

iperf -u -s -i 1

Garanti un blocage toutes les 120 secondes. Intéressant, cela ne semble pas se produire avec TCP
Enfin, après avoir téléchargé et examiné le code du pilote (sans rien comprendre), j'ai remarqué une mention suspecte de

définir BRCMF_SCAN_PASSIVE_TIME 120

Qui est ensuite utilisé dans le code du pilote

cela pourrait-il être lié, je suis à bout de souffle en essayant de résoudre?
Merci

J'ai mis ce qui suit dans /etc/rc.local et le mien semble fonctionner beaucoup mieux:

Iwconfig wlan0 hors tension

PI zéro w

Sean

Le 19 décembre 2017, à 3 h 42, LeeMooreImperas [email protected] a écrit:

Toutes mes excuses si je publie au mauvais endroit, je rencontre un comportement étrange avec le wlan interne RPi3 (broadcom) lors de l'envoi de paquets UDP Unicast sous raspbian.
J'envoie un petit paquet de données 2kb une fois par seconde, à l'extrémité du récepteur, cela est bloqué toutes les 120 secondes pendant environ 3-4 secondes. Ce test fonctionne comme une horloge, et je peux reproduire avec iperf en faisant ce qui suit

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

Ubuntu PC connecté en tant que client WiFi à RPi3 (IP 192.168.1.22 comme ci-dessus)

iperf -u -s -i 1

Garanti un blocage toutes les 120 secondes. Intéressant, cela ne semble pas se produire avec TCP
Enfin, après avoir téléchargé et examiné le code du pilote (sans rien comprendre), j'ai remarqué une mention suspecte de

définir BRCMF_SCAN_PASSIVE_TIME 120

Qui est ensuite utilisé dans le code du pilote

cela pourrait-il être lié, je suis à bout de souffle en essayant de résoudre?
Merci

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

Salut Sean
Merci pour la mise en garde, malheureusement, cela n'est pas accepté par l'appareil Broadcom, je reçois

Error for wireless request "Set Power Management" (8B2C) 
    Set failed on device wlan0; Invalid argument

Cependant, j'utilise la commande suivante dans ma configuration pour atteindre le même objectif
$ iw dev wlan0 set power_save off
cela est accepté et si je demande les paramètres
$ iwconfig wlan0
Je vois
Power Management:off

Donc, à peu près sûr que l'économie d'énergie est désactivée, mais ne résout pas ce problème
Merci

@LeeMooreImperas Je suggère d'ouvrir un problème séparé pour cela et de fournir au moins la version du noyau et la version du micrologiciel Wifi.

J'ai commenté ce fil il y a longtemps mais j'ai dû arrêter de le regarder car je n'étais plus capable de le reproduire. Eh bien, j'ai de nouvelles données et je trouve cela très intéressant.

J'ai deux Raspberry Pi; un B + V1.2 et un Raspberry PI (C) 2011 d'origine.

Si j'exécute "4.1.19+ # 858 Tue Mar 15 15:52:03 GMT 2016" sur le RaspPi B +, la puce WiFi Edimax présentera le problème que d'autres ont vu.

Si j'exécute "4.9.27+ # 1 Thu May 11 17:40:53 UTC 2017" sur le même RaspPi B +, la même puce WiFi Edimax ne montrera pas le problème.

Je me demande maintenant s'il s'agit plus d'une incompatibilité avec le matériel et je me souviens également qu'avec des cartes RaspPi beaucoup plus anciennes, le WiFi USB avait besoin d'un câble spécial afin d'augmenter la puissance + 5V car l'alimentation provenant de la carte n'était pas. t assez pour le conduire. Je vais remettre les cartes SD en place pour qu'elles présentent le problème, puis voir si ce type de câble aide.

Ok, je pense que j'avais cela incorrect.

L'exécution de 4.9.27+ sur l'ancien RaspPi présentera le problème. Vérification maintenant.

Ok, c'est définitif et très intéressant.

En utilisant une carte Raspberry Pi originale (vers 2011) et sous Linux 4.9.27+ (de "uname -a"), je peux reproduire le problème de la puce Edimax USB WiFi perdant la connexion WiFi, et donc l'adresse IP, à chaque fois , en quelques minutes.

En utilisant la même carte Raspberry Pi d'origine et la même version de Linux, mais le SEUL changement de simplement utiliser un câble USB qui me permet d'augmenter le + 5V au WiFi USB à partir d'une source secondaire, le système est stable.

Donc, il semble certainement y avoir un problème avec la carte WiFi USB Edimax qui ne reçoit pas assez de puissance dans cette configuration. Cela n'aide évidemment pas ceux qui utilisent un Raspberry Pi avec WiFi intégré, mais dans ces cas, je me demande si un problème similaire se produit et si le passage à un adaptateur USB qui produit plus d'amplis peut montrer une différence?

Il est possible que l'adaptateur secteur vers USB qui alimente le Pi ne donne pas un 5V propre dans certains cas.
Étant donné que le courant alternatif doit être régulé, puis lissé avant qu'il ne devienne 5V, vous obtenez toujours un peu d'ondulation dans le DC en sortie.
Le 5V d'un ordinateur portable ou d'un PC est plus susceptible d'être sans ondulation qu'un chargeur secteur vers USB bon marché

Il serait intéressant de mettre un oscilloscope sur l'alimentation de la puce wifi dans différentes conditions pour voir à quoi ressemble l'ondulation en cas de panne / non-panne

Veuillez garder ce problème aux problèmes avec la puce sans fil ONBOARD Brcm sur le Pi3 - si vous avez des problèmes avec d'autres appareils, veuillez utiliser le forum pour obtenir des conseils. C'est simplement pour que les informations que nous devons transmettre à Cypress ne soient pas trop confuses.

@ JamesH65
@lategoodbye

Salut James, Stefan,
Donc, les messages contradictoires ici, le problème que j'ai enregistré était directement lié au RPi3 BRCM WiFi.
Donc, cela devrait-il aller dans un autre fil (comme suggéré par lategoodbye)?
J'aurais pensé que ce fil concerne spécifiquement mon problème?

Je suis heureux de déplacer le problème

Merci

@LeeMooreImperas Bien que votre problème concerne le sans fil intégré, le vôtre est une pause toutes les 2 minutes, ce problème décrit un échec complet du verrouillage sans fil qui se produit à des intervalles aléatoires, il semble donc que ce n'est pas lié. Cela pourrait donc valoir la peine de créer un autre problème. J'étais malheureusement un peu vague dans mon message précédent.

Ajout d'un autre "moi aussi" à ce sujet.
Matériel: Raspberyy Pi 3, modèle B.
Noyau: Linux raspberrypi 4.9.70-v7 +
Système d'exploitation: Raspbian GNU / Linux 9 (extensible)
Image chargée: 2017-11-29-raspbian-stretch.img
Image MD5:
SDCard: pas sûr du fabricant, il est livré avec le kit
Fichier d' interfaces :
hostapd.conf: hostapd.txt
sortie dmesg (pendant le travail): dmesg_20171230.txt

L'appareil est configuré comme point d'accès pour mon réseau sans fil. Mon routeur principal est un firmware Linksys EA6400 version 1.1.40 (build 184085). Le Linksys et le Pi offrent le même SSID sur différents canaux. Pi est connecté au routeur via une connexion filaire avec un commutateur non géré entre les deux.
La charge du système d'exploitation sur l'appareil est assez récente. J'avais une image RetroPie sur le système et j'ai rencontré les mêmes problèmes. J'ai rechargé sur Raspbian pour voir si cela fonctionnait mieux.
Je vois des abandons sporadiques du pont. Le principal symptôme est que le réseau sans fil fourni par le Pi semble s'isoler du réseau filaire. L'interface filaire continue de fonctionner normalement et je peux atteindre le Pi via SSH. Si j'exécute un tcpdump sur l'interface sans fil (wlan0), dans cet état, je peux toujours voir le trafic vers et depuis les périphériques connectés.
Le cycle de la connexion sans fil (ifdown; ifup) ne semble pas résoudre le problème. Je n'ai pas encore essayé de cycler l'interface du pont (br0). En général, j'ai redémarré l'appareil qui résout le problème.
Je ne suis pas sûr que ce soit lié; cependant, le problème semble apparaître lorsque j'essaie de contrôler mon ChromeCast 2 après qu'il a fonctionné pendant un certain temps. Par exemple, si je joue une émission via Netflix sur ChromeCast, puis que j'essaie de suspendre l'émission, le pont semble tomber à ce moment-là. Je n'ai pas encore pu attraper cela via tcpdump; mais, c'est une prochaine étape pour moi.
J'ai considéré que cela pourrait être un problème de chaleur; cependant, j'ai eu /opt/vc/bin/vcgencmd measure_temp cours d'exécution sur une boucle de 30 secondes pendant l'un des abandons et la température de mon processeur était de l'ordre de

Je suis heureux de capturer les journaux / pcaps au besoin pour aider à résoudre le problème davantage. Cependant, veuillez être explicite dans les instructions car j'ai pas mal de lacunes dans mes connaissances sur Linux.

EDIT: vient d'avoir un abandon et a fait un sudo ifdown br0 && sudo ifup br0 et il semble avoir recommencé à fonctionner. Je vais tester à nouveau lors de mon prochain abandon.

EDIT2: Voici un vidage dmesg avec la connexion a échoué. Le sudo ifdown br0 && sudo ifup br0 n'a pas semblé récupérer la connexion cette fois.
dmesg_20171220_failed.txt
Il semble particulièrement intéressant de noter l'erreur:
brcmfmac: brcmf_cfg80211_stop_ap: la configuration du mode INFRA a échoué -7

EDIT3: Ran à travers ce fil à propos d'un problème similaire qui renvoyait à ce fil. A exécuté la modification demandée dans le module brcmfmac pour activer le débogage. Avait le déclencheur d'échec et capturé la sortie dmesg:
dmesg_debug_failed.txt
De plus, j'ai également remarqué la mention d'un téléphone Samsung dans l'autre fil. Nous avons remarqué que les problèmes de pont avec mon Pi semblent tourner autour de mon Samsung Galaxy S7. Les appareils Apple de ma femme (iPhone et iPad) ne semblent pas déclencher le problème.

EDIT4: Ran a sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000 Suivi par dmesg à nouveau. Sortie ci-dessous:
dmesg_debug_failed_reset_driver.txt

Hmm, pas l'erreur de boîte aux lettres attendue. Je vais le transmettre aux développeurs de Cypress dans la nouvelle année.

Je ne sais pas si c'est le même problème, mais mon symptôme est intermittent sans fil RPi3 à bord; 10 secondes de bons pings, suivis de 20 à 30 secondes sans pings, et répéter pour toujours. Lorsqu'aucun ping, l'hôte distant reçoit les demandes d'écho ICMP et envoie les réponses d'écho ICMP. Le point d'accès renvoie l'hôte ICMP inaccessible à l'hôte distant.

Les conditions préalables sont à la fois Ethernet et sans fil. Les chances que cela se produise se sont grandement améliorées en redémarrant inutilement dhcpcd .

La solution de contournement consiste à définir l'interface réseau en mode promiscuité; sudo ifconfig wlan0 promisc . Le symptôme revient dans les dix secondes à une minute de sudo ifconfig wlan0 -promisc .

Plus d'informations disponibles si nécessaire, il suffit de demander.

@ Sylver-Dragon, pour moi, un tcpdump empêché le symptôme, et peut-être avez-vous trouvé la même chose; essayez le drapeau -p , qui désactive le mode promiscuité; il a laissé le symptôme continuer.

https://github.com/iiab/iiab/issues/638

@quozl J'ai essayé d'exécuter tcpdump à la fois sur l'interface sans fil et sur l'interface du pont et j'ai eu des blocages pendant son exécution. Je vais essayer le mode promiscuité et voir si cela fait une différence. Cependant, en fonction de la sortie de débogage du pilote d'interface sans fil, en particulier:
wl0: _wlc_bss_update_beacon: hors de mémoire, 0 octet malléable
Je suppose que c'est une sorte de fuite de ressources (mémoire?) De la part du pilote. Quand j'ai un peu plus de temps, je veux faire une capture de paquet et creuser le moment où il se verrouille. Je soupçonne que mon téléphone envoie une sorte de paquet ou une série de paquets impairs ou mal formés sur l'appareil qui déclenche le verrouillage. Si je peux capturer et isoler cela, cela devrait aider à informer le correctif.

Cela ressemble à une erreur différente du problème de boîte aux lettres que nous suivons actuellement. Ce qui est ennuyeux. Votre téléphone est-il un Samsung BTW? Le problème de la boîte aux lettres semble être déclenché plus souvent par les appareils SS. Si vous pouvez localiser ce qui cause les problèmes, ce serait très utile

Je chasse la même chose (?) Depuis des semaines maintenant. J'ai l'impression que j'ai dû lire tous les rapports sur ce sujet et des problèmes similaires. Alors, voici quelques informations de moi:

J'utilise le wifi interne d'un Raspberry Pi 3 comme point d'accès. J'utilise le noyau et les modules raspbian standard (version Linux 4.9.35-v7 + (dc4 @ dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) # 1014 SMP ven 30 juin à 14:47:43 BST 2017).

Le micrologiciel Wifi est: brcmfmac: Version du micrologiciel = wl0: 7 août 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378

Je suis à peu près certain que cette configuration matérielle fonctionnait auparavant, mais après quelques mises à jour (également du noyau), je crois que les choses ont mal tourné. La création de l'AP fonctionne bien, mais après l'avoir utilisée pendant un certain temps (30 minutes environ, pas la même chose à chaque fois que je pense), en utilisant un Chromecast, la connexion cesse de fonctionner. Il se peut (mais ici je ne suis pas sûr) que cela se produise le plus souvent lorsque je mets en pause / arrête le flux, mais rarement au milieu du visionnage. En cas d'échec, les connexions existantes sont abandonnées et les nouvelles tentatives de connexion ne sont acceptées par aucun client. Le rechargement de hostapd entraîne brcmf_cfg80211_stop_ap: setting INFRA mode failed -7 (impossible de définir le mode sur maître). Cela peut être corrigé temporairement en rechargeant le pilote: rmmod brcmfmac; modprobe brcmfmac . Les choses fonctionnent à nouveau comme prévu jusqu'à ce qu'elles échouent la prochaine fois. Alternativement, un redémarrage "corrige" le problème également.

La seule chose que j'obtiens dans l'état d'échec (avec le débogage activé) dans syslog est:

noyau: [3615.491795] brcmfmac: brcmf_netdev_wait_pend8021x: Expiration du délai d'attente pour aucun paquet 802.1x en attente
hostapd: wlan0: STA xx: xx: xx: xx: xx: xx IEEE 802.11: désauthentifié en raison d'une demande de désautorisation locale

Ce message d'erreur n'a pas de sens pour moi. Il expire en attendant «aucun paquet en attente»? En tous cas:

J'ai désactivé l'économie d'énergie:

iw wlan0 get power_save Power save: off

roam_off est défini sur 1 et le débogage est activé:

`systool -a -v -m brcmfmac
Module = "brcmfmac"

Les attributs:
coresize = "222874"
initsize = "0"
initstate = "live"
refcnt = "0"
srcversion = "10E8F4629D109E78E1F506C"
taint = ""
uevent =

Paramètres:
alternative_fw_path =
debug = "1048576"
roamoff = "1"
»

Je n'ai pas de téléphone Samsung, mais certains Android. Aucun de ceux-ci n'est connecté à ce point d'accès. Les seuls clients directs sont deux Chromecasts (une vidéo, une audio uniquement, plus une tablette Android). Tout le reste entre via l'interface filaire.

@knarrff
Veuillez rechercher sur cette page mon commentaire précédent d'il y a 3 semaines pour une bonne solution de contournement.

@ JamesH65
Je n'ai jamais eu d'acquittement de ta part. Avez-vous copié / relayé la sortie dmesg que j'ai partagée à partir de ce commentaire il y a 3 semaines aux gars de Cypress?

@randyoo : J'ai à la fois "rsn_pairwise = CCMP" et "wpa = 2" dans mon hostapd.conf. Cela n'aide pas dans mon cas. Entrées non secrètes de mon fichier:
»
interface = wlan0

pilote = 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
»

Il devient également clair que l'échec semble toujours se produire pour moi lorsque j'essaie de mettre en pause un flux netflix sur le Chromecast (ce qui ne signifie pas qu'il échoue toujours lorsque j'essaye cela, mais que chaque fois que cela échoue, c'est ce que je faisais. ). D'un autre côté, cela pourrait être un hareng rouge, car c'est ce que je fais presque tout le temps avec ce réseau wifi. Il se peut simplement que le problème se produise simplement lorsqu'un appareil tente de s'authentifier auprès du point d'accès (comme la tablette Android qui a probablement désactivé le wifi pendant le sommeil). Plus de tests montreront. J'essaierai sans Chromecast - juste le wifi régulier sur la tablette, y compris les cycles wifi-sommeil.

Il ne semble pas que mon problème soit le même que celui-ci, je vais donc passer en mode caché. Mon ifconfig wlan0 promisc a résolu pour n'aider personne d'autre, nous devons examiner un problème différent.

Je peux reproduire cela de manière fiable sans Netflix ou Chromecast en me connectant au réseau via la tablette Google, puis en laissant la tablette s'endormir, la reprendre (la tablette tente de se réassocier), et à ce moment-là, l'AP est "mort".

Sur une machine Linux, je les reçois dans syslog lorsque j'essaie d'associer (en utilisant les informations d'identification correctes):

»

[42231.476518] wlan7: envoyer l'authentification à b8: 27: eb: 33: 98: 14 (essayez 1/3)
[42231.583434] wlan7: envoyer l'authentification à b8: 27: eb: 33: 98: 14 (essayez 2/3)
[42231.694397] wlan7: envoyer l'authentification à b8: 27: eb: 33: 98: 14 (essayez 3/3)
[42231.799368] wlan7: l'authentification avec b8: 27: eb: 33: 98: 14 a expiré
[42236.585750] wlan7: authentifier avec b8: 27: eb: 33: 98: 14
[42236.598833] wlan7: envoyer l'authentification à b8: 27: eb: 33: 98: 14 (essayez 1/3)
[42236.602344] wlan7: authentifié
[42236.603480] wlan7: associer avec b8: 27: eb: 33: 98: 14 (essayez 1/3)
[42236.619322] wlan7: RX AssocResp de b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 aid = 1)
[42236.623181] wlan7: associé
[42236.623325] IPv6: ADDRCONF (NETDEV_CHANGE): wlan7: le lien est prêt
[42236.625464] wlan7: limitation de la puissance d'émission à 30 (30 - 0) dBm comme annoncé par b8: 27: eb: 33: 98: 14
[42239.730365] wlan7: désauthentifié de b8: 27: eb: 33: 98: 14 (raison: 2 = PREV_AUTH_NOT_VALID)
[42241.243434] wlan7: authentifier avec b8: 27: eb: 33: 98: 14
[42241.256326] wlan7: envoyer l'authentification à b8: 27: eb: 33: 98: 14 (essayez 1/3)
[42241.260724] wlan7: authentifié
[42241.263403] wlan7: associer avec b8: 27: eb: 33: 98: 14 (essayez 1/3)
[42241.279537] wlan7: RX AssocResp de b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 aid = 1)
[42241.282500] wlan7: associé
[42241.336166] wlan7: limitation de la puissance d'émission à 30 (30 - 0) dBm comme annoncé par b8: 27: eb: 33: 98: 14
[42244.392213] wlan7: désauthentifié de b8: 27: eb: 33: 98: 14 (raison: 2 = PREV_AUTH_NOT_VALID)
[42253.916626] wlan7: authentifier avec b8: 27: eb: 33: 98: 14
[42253.928966] wlan7: envoyer l'authentification à b8: 27: eb: 33: 98: 14 (essayez 1/3)
[42253.936020] wlan7: authentifié
[42253.939533] wlan7: associer avec b8: 27: eb: 33: 98: 14 (essayez 1/3)
[42253.943361] wlan7: RX AssocResp de b8: 27: eb: 33: 98: 14 (capab = état 0x411 = 0 aide = 2)
[42253.945415] wlan7: associé
[42254.035149] wlan7: limitation de la puissance d'émission à 30 (30 - 0) dBm comme annoncé par b8: 27: eb: 33: 98: 14
[42257.053762] wlan7: désauthentifié de b8: 27: eb: 33: 98: 14 (raison: 2 = PREV_AUTH_NOT_VALID)
»

b8: 27: eb: 33: 98: 14 est le RPI3 en question, sur lequel j'obtiens à nouveau les entrées dmesg:
brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets

Je ne comprends pas très bien pourquoi l'AP envoie PREV_AUTH_NOT_VALID alors que je suis apparemment associé. J'ai l'impression que l'authentification passe avant l'association. Il ne devrait pas y avoir de cas où je suis associé mais pas authentifié.

salut

J'utilise un Pi3 comme serveur multimédia, les communications se font via le WiFi intégré

Mise à jour de la mise à jour de Rasbian Stretch Lite 4.9 (maintenant)
Serveur multimédia Plex

Je suis en train...

noyau: [1958.899715] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012

dans dmesg et syslog lors de la connexion au Pi à l'aide du client BubbleUPnp sur un Samsung S5 SM_G900F Android 7.1.2, cela est à peu près garanti et nécessite un redémarrage pour que le PiWiFi redevienne utilisable.

Sur mon ancien Sony Xperia XP Android 6.0.1 exécutant à nouveau BubbleUPnp, cela fonctionne très bien jusqu'à présent. C'est ma solution. Cependant, si je peux être utile pour aller au fond des choses, je serai heureux de contribuer.

John

Cela fonctionne également sur l'iPad exécutant mConnectLite

@johnthesoftwareathome Veuillez écrire un e-mail à James Hughes de Raspberry Pi afin qu'il puisse vous envoyer un firmware de débogage Wifi.

Adresse e-mail publiée via la page de contact de Raspberry Pi fao James Hughes

OK, nous avons un nouveau firmware de débogage de Cypress avec lequel je voudrais que les gens testent - il contient plus de débogage, mais pas de correctifs, donc uniquement pour ceux qui sont heureux de tester. Si vous m'avez déjà envoyé votre adresse e-mail, indiquez ici que vous souhaitez faire des tests et je vous enverrai le firmware, ou contactez-moi via PM sur les forums Pi.

Pour sauver les gens qui cherchent comment installer / exécuter le nouveau firmware.

Copiez le fichier du micrologiciel de débogage dans:

/lib/firmware/brcm/

(Vous voudrez d'abord sauvegarder l'original)

Je pense que vous devez redémarrer à ce stade.

Maintenant, redémarrez le pilote Linux en mode débogage

sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000

Faites-le mal .. !!

Videz dmesg dans un fichier et publiez-le ici.

Pour ajouter à ce que dit James, vous préférerez peut-être éviter la séquence rmmod / modprobe en ajoutant brcmfmac.debug=0x100000 à /boot/cmdline.txt .

@ JamesH65 Je serais heureux d'aider à tester. Bien que je viens de m'inscrire au Forum Pi, je ne peux pas envoyer de messages. Utiliser le même nom d'utilisateur là-bas, si cela peut vous aider.

J'ai essayé le nouveau firmware de débogage hier et j'ai également ajouté brcmfmac.debug = 0x100000 à /boot/cmdline.txt.

Cependant, étrangement, je n'ai vu aucune sortie de débogage dans dmesg. Encore plus étrange, là où je pouvais reproduire de manière fiable le problème avant, cela fonctionnait toute la soirée, peu importe ce que je faisais. Je n'ai pas eu un seul problème, et tout ce que j'ai fait différemment, c'était d'utiliser le nouveau fichier de firmware (md5 sum ba679a85c1dc76e9775603af45440bc0) au lieu de l'ancien et d'ajouter l'entrée à /boot/cmdline.txt au lieu d'ajouter l'option à l'aide de modprobe. Je n'ai pas eu le temps hier de revenir à l'ancien firmware pour voir si cela revient aux anciens problèmes. Je ferai rapport une fois que je l'ai fait. En attendant: est-ce que tout ce qui a changé dans ce firmware est vraiment "plus de débogage"?

Je pensais que c'était juste du débogage, mais je reviendrai à Cypress aussi clairement
quelque chose d'autre a changé, espérons-le dans le bon sens!

Le 11 janvier 2018 à 06:48, Frank Löffler [email protected] a écrit:

J'ai essayé le nouveau firmware de débogage hier et j'ai également ajouté
brcmfmac.debug = 0x100000 à /boot/cmdline.txt.

Cependant, étrangement, je n'ai vu aucune sortie de débogage dans dmesg. Encore plus
étrangement, là où je pouvais reproduire de manière fiable le problème avant, cela fonctionnait
toute la soirée, peu importe ce que j'ai fait. Je n'ai pas eu un seul problème, et
tout ce que j'ai fait était d'utiliser le nouveau fichier du firmware (somme md5
ba679a85c1dc76e9775603af45440bc0). Je n'ai pas eu le temps hier de partir
retour à l'ancien firmware pour voir si cela revient aux anciens problèmes. Mauvais
rapporter une fois que je l'ai fait. En attendant: est-ce que tout cela a changé
firmware vraiment "plus de débogage"?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-356842102 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHam4jUgDCkSFxMXS-KW4axCLoPZhks5tJa6fgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Mon expérience était similaire à celle de @knarrf sauf que j'ai vu des messages de débogage dans dmesg.

Auparavant, mon Samsung S5 était inutilisable en tant que client plexserver, mais lorsque j'ai chargé le micrologiciel de débogage, il fonctionnait (avec, comme je l'ai dit les messages de débogage dans dmesg), je suis donc revenu à mon binaire d'origine (sauvegardé et vérifié) et cela fonctionne toujours. Je suis donc à nouveau en cours d'exécution avec le firmware de débogage (je n'ai pas essayé le mod cmdline.txt, juste le rmmod / modprobe) et j'ai écouté quelques heures de musique sans erreur. J'ai essayé d'activer la plupart des nombreux appareils WiFi que j'ai dispersés, sans aucun effet.

Je vais essayer ceci pendant quelques jours pour voir si quelque chose se passe, puis rechargez l'original et réessayez. Je n'ai peut-être pas éteint le Pi entre les redémarrages. Je m'assurerai de le faire lorsque je reviendrai pour voir si cela pourrait être une sorte de rétention de registre.

Ce soir, j'ai téléchargé un micrologiciel plus ancien (tiré d'une image d'installation raspian; plus d'informations sur les versions que j'utilise ci-dessous), et j'ai rechargé le module avec cela (et le débogage activé), j'ai même redémarré entre les deux. La sortie courte dans dmesg confirme que l'ancienne version est maintenant chargée. Et comme avec @johnthesoftwareathome , il a continué à fonctionner toute la soirée, malgré des choses qui auraient dû interrompre le wifi plusieurs fois dans le passé.

Donc, pour l'instant, ma tâche semble être de le ramener à «ne fonctionne pas» pour avoir une chance de découvrir ce qui se passe. Mon prochain essai, bien que ce ne soit plus aujourd'hui, sera de faire une réinitialisation matérielle (coupure de courant pendant un certain temps au lieu d'utiliser simplement la commande 'reboot'), et d'utiliser une toute nouvelle installation à partir d'une nouvelle image.

De plus, je ne peux malheureusement pas exclure la possibilité que l'image avec laquelle j'ai échoué soit encore une version différente, car j'ai oublié de faire une sauvegarde avant de l'écraser avec l'image de débogage. Peut-être que @johnthesoftwareathome pourrait publier l'image exacte qu'il utilise et avec laquelle il a / a des problèmes? D'un autre côté, à l'époque, je mettais uniquement à jour le firmware à l'aide des packages standard, et j'ai installé la version firmware-brcm80211 (1: 0.43 + rpi6). Bien que la dernière entrée du journal des modifications ne spécifie pas la version du micrologiciel, l'avant-dernière le fait: 7.45.41.26, qui est plus ancienne que celle de l'image. En supposant que le journal des modifications a été écrit correctement, ce serait une forte indication que le firmware n'a pas été remplacé depuis la création de l'image, et que celui que j'appelle «image» est celui que j'ai utilisé auparavant.

Informations sur mes deux fichiers de firmware (image: celui de l'image d'installation de raspbian, debug: celui que j'ai reçu directement de @ JamesH65 :

déboguer:
Version du micrologiciel = wl0: 23 octobre 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f
md5sum: ba679a85c1dc76e9775603af45440bc0
image:
Version du micrologiciel = wl0: 7 août 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
md5sum: 5f520a38ab4e943bfa1ba102f80fb2a0

@johnthesoftwareathome : à quoi ressemble la nouvelle sortie "debug"? Je n'obtiens toujours rien qui ressemble même à distance à un débogage étendu, quelle que soit la façon dont je charge le module. Je n'obtiens aucune entrée pendant le fonctionnement, et même après le démarrage, tous les looks quelque peu pertinents sont:

en tant que root: dmesg | grep brcm
[0.000000] Commande noyau ligne: 8250.nr_uarts = 0 bcm2708_fb.fbwidth = 640 = 480 bcm2708_fb.fbheight bcm2708_fb.fbdepth = 16 bcm2708_fb.fbswap = 1 vc_mem.mem_base = 0x3ea00000 vc_mem.mem_size = 0x3f000000 dwc_otg.lpm_enable = 0 console = ttyS0 , 115200 console = tty1 root = PARTUUID = f8e4f7c2-02 rootfstype = ext4 ascenseur = date limite fsck.repair = oui rootwait brcmfmac.debug = 0x100000
[3.500135] usbcore: nouveau pilote d'interface enregistré brcmfmac
[3.662113] brcmfmac: Version du micrologiciel = wl0: 7 août 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[3.774278] brcmfmac: gestion de l'alimentation désactivée
[4.711443] brcmfmac: gestion de l'alimentation désactivée

Petite mise à jour: en repensant à l' un de mes commentaires les plus anciens dans ce fil, je peux en fait confirmer que l'ancien firmware que j'ai utilisé aujourd'hui ('image') est celui avec lequel j'ai eu des problèmes jusqu'à ce que j'essaye la nouvelle image de débogage.

Maison vide, alors j'ai finalement écouté le dernier album de Bowie. Tout fonctionnait parfaitement (l'album pas si). Loin de chez moi jusqu'à demain, je vais ramasser ça alors.

Géré pour que le micrologiciel d'origine échoue comme avant mais pas de manière fiable entre son utilisation et le micrologiciel de débogage Actuellement, il suffit de redémarrer avec les éléments de débogage sans échec pour le moment.

J'ai mal compris ce que @knarrf voulait dire à propos de la sortie de débogage et j'ai supposé qu'il ne pouvait pas voir que le nouveau firmware était installé plutôt que de signifier qu'il s'attendait à une sorte de flux de débogage (que je ne peux pas voir non plus). Il a un point. En cas d'échec, verrons-nous quelque chose ou l'hex de débogage est-il incorrect?

De plus, l'un des échecs n'a pas été merdique immédiatement. Cela m'a permis de revenir en arrière avant d'avoir besoin d'un redémarrage. Syslog contient les éléments suivants.

13 janvier 08:34:48 noyau plexServer: [46.648630] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
13 janvier 08:35:14 noyau plexServer: [72.161473] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec l'état -110
13 janvier 08:35:14 noyau plexServer: [72.161484] brcmfmac: brcmf_cfg80211_get_channel: échec de chanspec (-110)

C'est un ensemble de messages d'erreur très familier, mais il est toujours utile de savoir que vous rencontrez le même problème qui semble maintenant être résolu.

Cypress prépare une nouvelle version du firmware pour nous - nous publierons ici quand quelque chose sera disponible pour le test. Merci à tous pour votre intérêt, votre temps et votre patience.

D'accord. Merci pour un pilote de travail.

Les choses ont peut-être évolué depuis.

https://tech4research.wordpress.com/2014/07/23/brcmfmac-debugging-and-appropriate-debug-values/

et j'apprécie que le commutateur de débogage pour le nouveau micrologiciel puisse être un ajout spécial, mais ces commutateurs semblent fonctionner à la fois pour le micrologiciel d'origine et de «débogage» et le flux de débogage attendu est émis.

Probablement déjà vu; mais TPLink affirme que les appareils Android utilisent des paquets MDNS lorsqu'ils se réveillent et tentent de se reconnecter avec Chromecast ou des appareils similaires.
En creusant dans un pcap que j'ai obtenu d'une déconnexion de mon propre appareil, je peux voir ~ 3 500 paquets MDNS arriver en plus de 2,25 secondes juste avant que ma connexion ne s'éteigne. Il semble correspondre à ce modèle et peut être lié.

Juste pour ajouter / confirmer quelques informations dans ce numéro:

• Définir l'interface wifi sur promiscuous ( ifconfig wlan0 promisc ) semble atténuer le problème
• Le problème semble être causé uniquement par mon téléphone Android 7.1.2 Galaxy S7 (que j'ai eu il y a une semaine et c'est là que les problèmes ont commencé)

J'exécute Debian Buster avec aarch64 sur mon Pi3 et j'exécute un serveur Nextcloud dessus. la suppression de fichiers plus volumineux à partir d'un ordinateur portable Linux ne pose aucun problème et Nextcloud ne se synchronise pas à partir de cet ordinateur portable, mais dès que je télécharge un lot de fichiers depuis le Galaxy, l'erreur Unknown mailbox data content: 0x40012 apparaîtra et la connectivité Wifi est perdu.

Le firmware brcmfmac que j'utilise est 7.45.41.26 (r640327) FWID 01-4527cfab

Malheureusement, je n'ai pas un ancien Android à tester.

J'ai tcpdumpé un téléchargement du Samsung vers le Pi3, mais le Wifi était en mode promiscuité et tout fonctionnait très bien. Si je trouve le temps, je vais jeter un œil au pcap et faire un rapport si je trouve quelque chose d'utile / intéressant.

PS: Cast (le principal contrevenant décrit dans l'article TPLink) n'est pas actif (ou du moins je ne le vois pas dans les paramètres de connectivité).

Salut tout le monde,

Je veux juste confirmer que la désactivation du mode PowerSafe et l'activation du mode promiscuis ont résolu le problème pour moi: pour la première fois, il a réussi à rester connecté pendant 24 heures.

sudo iw wlan0 mettre power_save off
sudo ifconfig wlan0 promisc

Merci,
Luc

Veuillez consulter ce message du forum pour plus de détails sur une nouvelle version du firmware Quiconque voit le problème de la boîte aux lettres, ou en fait des problèmes sans fil, devrait essayer cela pour voir si cela aide.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508

@ JamesH65
Bonjour James,
Pouvez-vous fournir des instructions d'installation, le fichier .bin dans l'archive est-il un exécutable auto-installable?
Merci
Lee

Instructions maintenant sur la page du forum lié.

Réenregistrement après avoir exécuté le nouveau micrologiciel pendant un peu plus d'une semaine. Jusqu'à présent, ça a été solide. J'ai réveillé à plusieurs reprises mon appareil Samsung après de longues périodes et l'interface sans fil de mon Pi a continué à fonctionner. Je crois que j'ai eu un cas où il a chuté temporairement puis récupéré; cependant, je n'ai pas pu reproduire cela. Dans l'ensemble, ça a l'air solide. Merci à la fois à James de s'en tenir à cela et à l'équipe de Cypress pour avoir corrigé celui-ci.

Merci pour le rapport.

Quelqu'un peut-il me dire si le correctif du firmware l'a déjà fait dans la distribution officielle de Raspbian afin qu'il puisse être installé via apt update ou si ce n'est pas encore le cas, m'informer après que cela ait été le cas?

Quelqu'un peut-il me dire si le correctif du micrologiciel l'a déjà fait dans la distribution officielle de Raspbian afin qu'il puisse être installé via apt update ou si ce n'est pas encore le cas, m'informer après que cela ait été le cas?

Oui. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508&start=25#p1270212
Certains problèmes ont été signalés sur Pi0W après une mise à jour générale, mais il n'est pas tout à fait clair s'il s'agit simplement d'un changement de firmware ou de quelque chose d'autre - https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=204882

J'ai mis à jour le firmware

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.bin
ba679a85c1dc76e9775603af45440bc0  /lib/firmware/brcm/brcmfmac43430-sdio.bin

mais ont toujours le même problème

$ 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

Ce qui suit n'évite pas non plus ce problème

sudo iw wlan0 set power_save off
sudo ifconfig wlan0 promisc

J'utilise le RPi3 comme point d'accès avec hostapd et dnsmasq .
Je peux toujours reproduire le problème lors du démarrage d'un téléchargement dans l'application Spotify sur mon téléphone Android.

Dois-je également mettre à jour le fichier suivant?

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.txt
9a88b55134d9f8f3ad2331b93f4b7b79  /lib/firmware/brcm/brcmfmac43430-sdio.txt

Sera-t-il utilisé par le conducteur ou peut-il être ignoré?

Éditer:
Oui. Le brcmfmac43430-sdio.txt est également requis.
Mais j'utilise les dernières meilleures versions de https://github.com/RPi-Distro/firmware-nonfree/tree/927fa8ebdf5bcfb90944465b40ec4981e01d6015/brcm

J'ai également mis à jour mon noyau 4.9.35-v7 + vers 4.14.18-v7 +.
Mais le problème existe toujours.

Rencontrez le même problème sur mon RPi3: le Wifi tombe après une certaine disponibilité (par exemple pendant la nuit) avec presque aucun trafic.
La sortie dmesg affiche uniquement:

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

J'ai essayé de recharger le pilote (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

Cela n'a pas fonctionné d'une manière ou d'une autre - pilote chargé mais non, je n'ai pas d'interface
Essayé à nouveau:

[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

.. et je suis à nouveau debout.

Pi3 exécute le noyau '4.14.24-v7 + # 1097' - le micrologiciel est le plus ancien du 7 août 2017 - même blob de micrologiciel qui fonctionne parfaitement (temps de fonctionnement> 2 mois) sur un noyau Pi Zero W exécutant le noyau '4.9.77+ # 1081'
Les deux Pis sont connectés au même routeur et à une pièce à part. Les deux sont connectés via WiFi uniquement.

Cela vaut probablement la peine d'utiliser le dernier micrologiciel de la version 4.14, car la version 4.14 comporte toutes les modifications nécessaires pour fonctionner avec ce micrologiciel.

:) Mis à jour à la dernière fw (23 octobre 2017 03:55:53 version 7.45.98.38) hier après la publication - semble fonctionner atm - voyons ce qui se passe ..

Il semble que raspbian soit revenu au package du firmware d'août 2017. Existe-t-il de nouvelles exigences pour le rpi 3B + sans fil?

Le dernier package de microprogramme de repo extensible de la Fondation

J'ai aussi ce problème avec le wifi en train de mourir.

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

C'est avec 4.14.27-v7 + et avec
/ sbin / iw dev wlan0 définit power_save off
/ sbin / ifconfig wlan0 promisc
dans /etc/rc.local.

mêmes messages d'erreur que @ flok99 - en utilisant le dernier firmware (rpi-update) sur Stretch.

OK, donc le bogue que nous pensions que Cypress avait corrigé est toujours là. Retour à
Cypress ça va. Il a fallu un an pour obtenir cette version. Retenir son souffle non
conseillé.

Vous devez toutefois confirmer la version, veuillez publier le contenu de

dmesg | grep brcmfmac

Le 18 mars 2018 à 01:44, Rebroad [email protected] a écrit:

mêmes messages d'erreur que @ flok99 https://github.com/flok99 - en utilisant le dernier
firmware (rpi-update) sur stretch.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373966343 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHY1Cmntz_kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

[4.112717] brcmfmac: signature F1 lue @ 0x18000000 = 0x15264345
[4.119827] brcmfmac: brcmf_fw_map_chip_to_name: utilisation
brcm / brcmfmac43455-sdio.bin pour puce 0x004345 (17221) rev 0x000006
[4.120314] usbcore: nouveau pilote d'interface enregistré brcmfmac
[4.440371] brcmfmac: brcmf_c_preinit_dcmds: Version du micrologiciel = wl0: février
27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[4.440958] brcmfmac: brcmf_c_preinit_dcmds: version CLM = API: 12.2
Données: 9.10.105 Compilateur: 1.29.4 Clm Import: 1.36.3 Création: 2018-03-09
18:56:28
[10.911757] brcmfmac: gestion de l'alimentation désactivée
[12.016088] brcmfmac: gestion de l'alimentation désactivée
[2074.090674] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
échec avec statut -5
[2074.090687] brcmfmac: brcmf_cfg80211_get_tx_power: erreur (-5)
[2074.090745] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[2074.090753] brcmfmac: brcmf_link_down: WLC_DISASSOC a échoué (-5)
[2074.610583] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[2074.611992] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[2074.613945] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[2074.613971] brcmfmac: brcmf_cfg80211_get_channel: échec de chanspec (-5)
[2074.729716] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[2074.729733] brcmfmac: brcmf_cfg80211_reg_notifier: indicatif de pays iovar
renvoyé err = -5
[2074.871693] usbcore: désenregistrement du pilote d'interface brcmfmac
[2074.929084] brcmfmac: signature F1 lue @ 0x18000000 = 0x15264345
[2074.936897] brcmfmac: brcmf_fw_map_chip_to_name: utilisation
brcm / brcmfmac43455-sdio.bin pour puce 0x004345 (17221) rev 0x000006
[2074.937139] usbcore: nouveau pilote d'interface enregistré brcmfmac
[2075.118180] brcmfmac: brcmf_c_preinit_dcmds: Version du micrologiciel = wl0: février
27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2075.118706] brcmfmac: brcmf_c_preinit_dcmds: version CLM = API: 12.2
Données: 9.10.105 Compilateur: 1.29.4 Clm Import: 1.36.3 Création: 2018-03-09
18:56:28
[2075.215365] brcmfmac: gestion de l'alimentation désactivée
[2075.263751] brcmfmac: gestion de l'alimentation désactivée
[2085.475001] brcmfmac: gestion de l'alimentation désactivée
[2124.380808] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[2124.381146] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[2124.381156] brcmfmac: brcmf_cfg80211_get_channel: échec de chanspec (-5)
[2124.622345] usbcore: désenregistrement du pilote d'interface brcmfmac
[2124.705432] brcmfmac: signature F1 lue @ 0x18000000 = 0x15264345
[2124.714194] brcmfmac: brcmf_fw_map_chip_to_name: utilisation
brcm / brcmfmac43455-sdio.bin pour puce 0x004345 (17221) rev 0x000006
[2124.716213] usbcore: nouveau pilote d'interface enregistré brcmfmac
[2124.929556] brcmfmac: brcmf_c_preinit_dcmds: Version du micrologiciel = wl0: février
27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2124.929993] brcmfmac: brcmf_c_preinit_dcmds: version CLM = API: 12.2
Données: 9.10.105 Compilateur: 1.29.4 Clm Import: 1.36.3 Création: 2018-03-09
18:56:28
[2125.105218] brcmfmac: gestion de l'alimentation désactivée
[2125.150290] brcmfmac: gestion de l'alimentation désactivée
[8237.434034] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu:
0x40012
[8239.890302] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[8239.890822] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[8239.890835] brcmfmac: brcmf_run_escan: erreur (-110)
[8239.890845] brcmfmac: brcmf_cfg80211_scan: erreur d'analyse (-110)
[8254.280425] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
échec avec statut -5
[8254.280438] brcmfmac: brcmf_cfg80211_get_tx_power: erreur (-5)
[8254.280491] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8254.280498] brcmfmac: brcmf_link_down: WLC_DISASSOC a échoué (-5)
[8254.800394] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8254.803873] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8254.808353] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8254.808370] brcmfmac: brcmf_cfg80211_get_channel: échec de chanspec (-5)
[8254.881402] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8254.881420] brcmfmac: brcmf_cfg80211_reg_notifier: indicatif de pays iovar
renvoyé err = -5
[8255.001550] usbcore: annulation du pilote d'interface brcmfmac
[8255.071184] brcmfmac: signature F1 lue @ 0x18000000 = 0x15264345
[8255.077098] brcmfmac: brcmf_fw_map_chip_to_name: utilisation
brcm / brcmfmac43455-sdio.bin pour puce 0x004345 (17221) rev 0x000006
[8255.077348] usbcore: nouveau pilote d'interface enregistré brcmfmac
[8257.730418] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[8257.751038] brcmfmac: brcmf_c_get_clm_name: récupération des informations de révision
a échoué (-110)
[8257.751049] brcmfmac: brcmf_c_process_clm_blob: obtenir le nom du fichier blob CLM
a échoué (-110)
[8257.751068] brcmfmac: brcmf_c_preinit_dcmds: télécharger le fichier blob CLM
échoué, -110
[8257.751076] brcmfmac: brcmf_bus_started: échec: -110
[8257.751114] brcmfmac: brcmf_sdio_firmware_callback: le dongle n'est pas
répondre
[8304.417684] usbcore: désenregistrement du pilote d'interface brcmfmac
[8304.486099] brcmfmac: signature F1 lue @ 0x18000000 = 0x15264345
[8304.493613] brcmfmac: brcmf_fw_map_chip_to_name: utilisation
brcm / brcmfmac43455-sdio.bin pour puce 0x004345 (17221) rev 0x000006
[8304.494078] usbcore: nouveau pilote d'interface enregistré brcmfmac
[8304.686761] brcmfmac: brcmf_c_preinit_dcmds: Version du micrologiciel = wl0: février
27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8304.687203] brcmfmac: brcmf_c_preinit_dcmds: version CLM = API: 12.2
Données: 9.10.105 Compilateur: 1.29.4 Clm Import: 1.36.3 Création: 2018-03-09
18:56:28
[8304.829994] brcmfmac: gestion de l'alimentation désactivée
[8304.907662] brcmfmac: gestion de l'alimentation désactivée
[8357.441791] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu:
0x40012
[8359.891146] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[8359.891655] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[8359.891668] brcmfmac: brcmf_run_escan: erreur (-110)
[8359.891677] brcmfmac: brcmf_cfg80211_scan: erreur d'analyse (-110)
[8371.731226] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[8371.731731] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[8371.731746] brcmfmac: brcmf_cfg80211_get_channel: échec de chanspec (-110)
[8373.941267] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
échoué avec état -5
[8373.941280] brcmfmac: brcmf_cfg80211_get_tx_power: erreur (-5)
[8373.941330] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8373.941338] brcmfmac: brcmf_link_down: WLC_DISASSOC a échoué (-5)
[8374.461245] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8374.461942] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8374.463553] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8374.463573] brcmfmac: brcmf_cfg80211_get_channel: échec de chanspec (-5)
[8374.564729] brcmfmac: brcmf_fil_cmd_data: le bus est en panne. nous n'avons rien
faire.
[8374.564750] brcmfmac: brcmf_cfg80211_reg_notifier: indicatif de pays iovar
renvoyé err = -5
[8374.702401] usbcore: désenregistrement du pilote d'interface brcmfmac
[8374.759839] brcmfmac: signature F1 lue @ 0x18000000 = 0x15264345
[8374.767561] brcmfmac: brcmf_fw_map_chip_to_name: utilisation
brcm / brcmfmac43455-sdio.bin pour puce 0x004345 (17221) rev 0x000006
[8374.771137] usbcore: nouveau pilote d'interface enregistré brcmfmac
[8377.411255] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[8377.431924] brcmfmac: brcmf_c_get_clm_name: récupération des informations de révision
a échoué (-110)
[8377.431934] brcmfmac: brcmf_c_process_clm_blob: obtenir le nom du fichier blob CLM
a échoué (-110)
[8377.431941] brcmfmac: brcmf_c_preinit_dcmds: télécharger le fichier blob CLM
échoué, -110
[8377.431949] brcmfmac: brcmf_bus_started: échec: -110
[8377.432003] brcmfmac: brcmf_sdio_firmware_callback: le dongle n'est pas
répondre
[8424.133114] usbcore: désenregistrement du pilote d'interface brcmfmac
[8424.229631] brcmfmac: signature F1 lue @ 0x18000000 = 0x15264345
[8424.237210] brcmfmac: brcmf_fw_map_chip_to_name: utilisation
brcm / brcmfmac43455-sdio.bin pour puce 0x004345 (17221) rev 0x000006
[8424.239352] usbcore: nouveau pilote d'interface enregistré brcmfmac
[8424.460736] brcmfmac: brcmf_c_preinit_dcmds: Version du micrologiciel = wl0: février
27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8424.461174] brcmfmac: brcmf_c_preinit_dcmds: version CLM = API: 12.2
Données: 9.10.105 Compilateur: 1.29.4 Clm Import: 1.36.3 Création: 2018-03-09
18:56:28
[8424.646993] brcmfmac: gestion de l'alimentation désactivée
[8424.708633] brcmfmac: gestion de l'alimentation désactivée

Le dim 18 mars 2018 à 11h30, James Hughes [email protected]
a écrit:

OK, donc le bogue que nous pensions que Cypress avait corrigé est toujours là. Retour à
Cypress ça va. Il a fallu un an pour obtenir cette version. Retenir son souffle non
conseillé.

Vous devez toutefois confirmer la version, veuillez publier le contenu de

dmesg | grep brcmfmac

Le 18 mars 2018 à 01:44, Rebroad [email protected] a écrit:

mêmes messages d'erreur que @ flok99 https://github.com/flok99 - en utilisant
dernier
firmware (rpi-update) sur stretch.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -373966343
,
ou couper le fil
kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5>
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373987387 ,
ou couper le fil
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 

On dirait que vous êtes sur le nouveau Pi3b + et non sur le Pi3 d'origine: alors peut-être que c'est différent?

Puce et firmware entièrement différents, bien que le pilote côté Linux soit le
même. (brcmfmac).

Le 19 mars 2018 à 16h26, macmpi [email protected] a écrit:

@ flok99 https://github.com/flok99

brcmfmac: brcmf_fw_map_chip_to_name: utilisation de brcm / brcmfmac43455-sdio.bin pour la puce
Version du micrologiciel = wl0: 27 février 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04

On dirait que vous êtes sur le nouveau Pi3b + et non sur le Pi3 d'origine: donc
peut-être une question différente?

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-374274045 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADqrHeP6-sc-P-OSggQFPrl3O8z_B2aRks5tf9wbgaJpZM4HupC5
.

-
James Hughes
Ingénieur logiciel principal,
Raspberry Pi (Trading) Ltd

Je pense qu'il est préférable d'avoir un autre fil pour les problèmes de Pi3B + et de se référer à celui-ci si nécessaire, sinon il sera très difficile à suivre. Pouvez @ flok99 s'il vous plaît créer un nouveau problème avec ses rapports, en vous assurant que le titre fait référence au 3b +. Je vais changer le titre de celui-ci pour refléter son pour Pi3B uniquement.

terminé

Quelqu'un qui s'est abonné à ce problème, exécutant le 3B (pas plus), voit-il toujours les problèmes avec le dernier firmware et le dernier noyau? Voudrait des rapports d'échec continu - les derniers articles sur le sujet ci-dessus semblent impliquer que les choses fonctionnent maintenant bien.

Mon 3B est en place depuis 44 jours avec ceci:

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

Aucun problème depuis.

Bonnes nouvelles. Sauf si j'entends le contraire, je fermerai probablement ce fil dans une semaine ou deux, bien qu'il puisse être rouvert à tout moment si les problèmes se reproduisent.

J'ai commencé à avoir ce problème il y a environ une semaine, sans en avoir entendu parler auparavant. J'utilise aussi le plus souvent le pi avec un téléphone Samsung comme routeur - le mien est un s4. J'écris ceci connecté directement au s4 avec USB, c'est-à-dire en utilisant rndis. Voici mes détails du démarrage d'aujourd'hui:
0 mis à jour, 0 nouvellement installé, 0 à supprimer et 0 non mis à niveau.
thenry @ pi3portable : ~ $ dmesg | grep brcmfmac
[9.965782] brcmfmac: signature F1 lue @ 0x18000000 = 0x1541a9a6
[9.972059] brcmfmac: brcmf_fw_map_chip_to_name: utilisation de brcm / brcmfmac43430-sdio.bin pour la puce 0x00a9a6 (43430) rev 0x000001
[9.972250] usbcore: nouveau pilote d'interface enregistré brcmfmac
[10.147562] brcmfmac: brcmf_c_preinit_dcmds: Version du micrologiciel = wl0: 7 août 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.148507] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Données: 7.11.15 Compilateur: 1.24.2 ClmImport: 1.24.1 Création: 2014-05-26 10:53:55 Inc Données: 9.10.41 Inc Compilateur: 1.29 .4 Inc ClmImport: 1.36.3 Création: 2017-08-07 00:37:47
[18.538641] brcmfmac: gestion de l'alimentation désactivée
[30.629545] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
[33.191450] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[33.194850] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[35.751496] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[35.754898] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[35.754906] brcmfmac: brcmf_pno_clean: code d'échec -110
[43.271438] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[43.274800] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[43.274807] brcmfmac: brcmf_do_escan: erreur (-110)
[43.274811] brcmfmac: brcmf_cfg80211_scan: erreur d'analyse (-110)
[7673.758073] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[7673.761437] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[7673.761454] brcmfmac: _brcmf_set_multicast_list: Échec de la configuration de mcast_list, -110
[7676.328075] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[7676.331449] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[7676.331466] brcmfmac: _brcmf_set_multicast_list: Échec de la définition de allmulti, -110
[7678.878084] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[7678.881460] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[7681.448101] brcmfmac: _brcmf_set_multicast_list: Échec de la configuration de BRCMF_C_SET_PROMISC, -110
[7689.118098] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec l'état -110
[7689.118241] brcmfmac: gestion de l'alimentation désactivée
[7691.678100] brcmfmac: brcmf_cfg80211_set_power_mgmt: erreur (-110)
[7694.238122] brcmfmac: _brcmf_set_multicast_list: Échec de la configuration de mcast_list, -110
[7696.798118] brcmfmac: _brcmf_set_multicast_list: échec de la définition de allmulti, -110
[7699.358158] brcmfmac: brcmf_do_escan: erreur (-110)
[7699.358167] brcmfmac: brcmf_cfg80211_scan: erreur d'analyse (-110)
[7701.918127] brcmfmac: _brcmf_set_multicast_list: Échec du paramètre BRCMF_C_SET_PROMISC, -110
[11406.881341] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg a échoué avec l'état -110
[11406.881352] brcmfmac: brcmf_cfg80211_reg_notifier: le code de pays iovar a renvoyé err = -110
[11579.921479] brcmfmac: _brcmf_set_multicast_list: Échec de la configuration de mcast_list, -110
[11582.491485] brcmfmac: _brcmf_set_multicast_list: échec de la configuration de allmulti, -110
[11587.611478] brcmfmac: _brcmf_set_multicast_list: Échec du paramètre BRCMF_C_SET_PROMISC, -110
thenry @ pi3portable : ~ $
thenry @ pi3portable : ~ $ uname -a
Linux pi3portable 4.14.27-v7 + # 1100 SMP ven 16 mars 13:51:48 GMT 2018 armv7l GNU / Linux
thenry @ pi3portable : ~ $
J'exécute ce noyau parce que je suis passé au flux suivant lorsque je testais le démarrage depuis USB, et je n'ai pas changé en arrière par la suite. Ensuite, j'ai reçu un avis concernant le nouveau noyau (4.14) et j'ai donc décidé d'essayer cela, il y a environ un mois. Tout s'est bien passé, aucun problème jusqu'à celui-ci. Le seul autre changement majeur est que je suis passé de NetworkManager à systemd-networkd il y a plusieurs jours, mais c'est après que ce problème se soit manifesté.
Cordialement,
Trevor Henry

Mise à jour:
Après avoir lu tous les articles connexes, j'ai trouvé le dernier firmware dans le post https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508
et cela a résolu mon problème.

version de test de brcmfmas43430-sdio.bin installée 250418

version 7.45.98.38 23 octobre 2017, version 7.45.41.46 remplacée le 7 août 2017

avant:

[10.368086] brcmfmac: signature F1 lue @ 0x18000000 = 0x1541a9a6
[10.376702] brcmfmac: brcmf_fw_map_chip_to_name: utilisation de brcm / brcmfmac43430-sdio.bin pour la puce 0x00a9a6 (43430) rev 0x000001
[10.377026] usbcore: nouveau pilote d'interface enregistré brcmfmac
[10.599523] brcmfmac: brcmf_c_preinit_dcmds: Version du micrologiciel = wl0: 7 août 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.600577] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Données: 7.11.15 Compilateur: 1.24.2 ClmImport: 1.24.1 Création: 2014-05-26 10:53:55 Inc Données: 9.10.41 Inc Compilateur: 1.29 .4 Inc ClmImport: 1.36.3 Création: 2017-08-07 00:37:47
[126.642710] brcmfmac: gestion de l'alimentation désactivée
[139.249230] brcmfmac: brcmf_sdio_hostmail: contenu de données de boîte aux lettres inconnu: 0x40012
[141.751545] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[141.754973] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[144.311482] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[144.314959] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[144.314975] brcmfmac: brcmf_pno_clean: code d'échec -110
[151.831564] brcmfmac: brcmf_sdio_bus_rxctl: reprise à l'expiration du délai
[151.835066] brcmfmac: brcmf_sdio_checkdied: interruption du micrologiciel dans le dongle
[151.835079] brcmfmac: brcmf_do_escan: erreur (-110)
[151.835084] brcmfmac: brcmf_cfg80211_scan: erreur d'analyse (-110)

après:

thenry @ pi3portable : ~ $ dmesg | grep brcm
[10.115833] brcmfmac: signature F1 lue @ 0x18000000 = 0x1541a9a6
[10.134926] brcmfmac: brcmf_fw_map_chip_to_name: utilisation de brcm / brcmfmac43430-sdio.bin pour la puce 0x00a9a6 (43430) rev 0x000001
[10.135115] usbcore: nouveau pilote d'interface enregistré brcmfmac
[10.367703] brcmfmac: brcmf_c_preinit_dcmds: Version du micrologiciel = wl0: 23 octobre 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[10.368419] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Données: 7.11.15 Compilateur: 1.24.2 ClmImport: 1.24.1 Création: 2014-05-26 10:53:55 Inc Données: 9.10.39 Inc Compilateur: 1.29 .4 Inc ClmImport: 1.36.3 Création: 2017-10-23 03:47:14
[18.045308] brcmfmac: gestion de l'alimentation désactivée
thenry @ pi3portable : ~ $

Il a continué à fonctionner à travers plusieurs bottes et je l'utilise maintenant, connecté par wifi au téléphone Samsung S4.
Merci pour votre aide, salutations, Trevor Henry.

Je pensais que le dernier firmware était déjà dans les dernières images, donc je me serais attendu à ce qu'une mise à niveau vers la version 4.14 aurait introduit le dernier firmware.

Oui - les images Raspbian actuelles ont le firmware 7.45.98.38 du 23 octobre 2017.

Salut, non, je n'ai pas construit le noyau, j'ai mis à niveau avec rpi-update, et comme vous pouvez le voir, il exécutait toujours le micrologiciel d'août 2017 après la mise à jour.

rpi-update ne met à niveau que le noyau, le firmware et un petit nombre d'utilitaires spécifiques à VideoCore. Pour tout mettre à jour, y compris le micrologiciel WiFi, vous devez utiliser apt-get upgrade / distupgrade.

Salut,
J'ai donc ce problème et c'est mieux avec le dernier FW, 7.45.98.38, qu'il ne l'était, mais j'ai toujours des problèmes.
Observations
Si je démarre la framboise sans rien faire, le WLAN se met en place comme il se doit.
Si j'essaie d'utiliser le clavier ou la souris Bluetooth avant que le WLAN ne soit activé, le problème persiste, je n'obtiens aucune connexion.
Si j'ai une connexion et que je désactive / active le réseau sans fil, le WLAN ne se connecte pas.
Si je laisse le WLAN allumé pendant la nuit, la connexion cesse de fonctionner.
J'ai trois configurations identiques et le comportement est le même sur toutes.
Je ne sais pas si cela compte mais nous utilisons WPA2 entreprise, PEAP et MSCHAPv2

Ces problèmes se produisent-ils uniquement lorsque les appareils BT sont connectés?

Oui! Bluetooth désactivé et claviers et souris USB connectés et le WLAN connecté plus rapidement que je n'ai jamais vu auparavant.

Encore quelques problèmes avec coexistent alors. Devra être signalé à Cypress, je suppose.

Juste pour vérifier, vous utilisez la dernière version de Raspbian? Ou quelque chose d'assez nouveau?

@pelwell ping

Description: Raspbian GNU / Linux 9.4 (extensible)
Avez-vous besoin de plus d'informations?

Il se bloque après:
14 mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected

voir le journal ci-dessous

14 mai 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.7887] périphérique (wlan0): état de l'interface du demandeur: déconnecté -> association
14 mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: Associé à 44: d9: e7: f7: d5: 34
14 mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-STARTED L'authentification EAP a démarré
14 mai 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.9263] périphérique (wlan0): état de l'interface du demandeur: association -> associée
14 mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor = 0 method = 25
14 mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
14 mai 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0716] appareil (wlan0): Activation: l'association (wifi) a pris trop de temps
14 mai 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0718] périphérique (wlan0): changement d'état: config -> need-auth (raison 'aucune') [50 60 0]
14 mai 15:44:24 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-DISCONNECTED bssid = 44: d9: e7: f7: d5: 34 reason = 3 local_generated = 1
14 mai 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0937] appareil (wlan0): Activation: (wifi) demande de nouveaux secrets
14 mai 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0959] sup-iface [0x1c438c0, wlan0]: connexion déconnectée (raison -3)

J'ai le même problème avec octoPi 0.14 (chaque paquet mis à jour, firmware rpi au plus tard, chaque plugin octoprint mis à jour).

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

avec cette configuration son 100% reproductible. Accédez au site Web d'octoprint sur le pi (premier accès après le démarrage) à partir de mon Samsung S4 Active (Android 5.0.1, en utilisant Chrome) ou de ma tablette Samsung 10 pouces avec également Android 5.xi guess et Chrome tue le wifi lorsque le la page est à moitié chargée.
Pas de câble connecté à mon Pi3, wifi sur le canal 11 avec wpa2.
J'ai essayé de désactiver la puissance wifi et de passer au canal wifi 6 sans aucune chance (conseils d'en haut) - mais j'avais le sentiment que c'était un peu mieux avec le canal 6.

Mais maintenant vient l'indice intéressant sur le bogue:
Je n'ai aucun problème lorsque j'ouvre le site octopi / octoprint (sur le pi) à partir de ma machine Windows 10 ou Ubuntu 16 (en utilisant chrome, connexion par câble au routeur). Je suppose que c'est maintenant un bug lié à Android, Samsung ou wifi. Et je pense avoir lu quelque chose sur les problèmes Android / RPI il y a quelque temps.

J'espère que cela t'aides. Si vous avez besoin d'un testeur pour une version, je l'essayerais.

Je pensais juste que je voudrais carillon ici et dire que nous avons également vu ce qui ressemble à des blocages de blocage liés au WiFi autour de ce pilote qui peuvent être liés à un autre SBC. Ce n'est pas spécifique à Raspberry PI.

Cela m'arrive aussi.

Installer

• Pi 3B 1.2 (a02082)
• Noyau:

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

Exécution de la version 9.4 de Raspbian:

pi<strong i="14">@raspberrypi</strong>:~ $ cat /etc/debian_version
9.4

Version du 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 gestion de l'alimentation est désactivée:

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

J'utilise le wifi intégré. Rien n'est connecté au port Ethernet.

Le système a été mis à jour en utilisant apt-get upgrade , apt-get dist-upgrade et rpi-update .

Ce que je vois

Une fois que le pi a été activé pendant environ une heure, il devient inaccessible depuis le réseau. Je ne peux pas atteindre le Pi depuis mon réseau local (ping et ssh ne fonctionnent pas).

Dans dmesg , je vois que j'obtiens:

brcmfmac: power management disabled
...
snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned

Mais pas d'erreurs.

Quelque chose d'intéressant

J'ai remarqué que lorsque cela se produit, si je me connecte directement au pi et que je ping mon ordinateur portable, les choses se remettent au travail. De plus, les temps de ping sont un peu bizarres - il semble qu'il faut un peu de temps pour que les choses se `` réchauffent '':

pi<strong i="40">@raspberrypi</strong>:~ $ ping 192.168.1.22
PING 192.168.1.22 (192.168.1.22) 56(84) bytes of data.
64 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=5024 ms
64 bytes from 192.168.1.22: icmp_seq=2 ttl=64 time=4010 ms
64 bytes from 192.168.1.22: icmp_seq=3 ttl=64 time=2971 ms
64 bytes from 192.168.1.22: icmp_seq=4 ttl=64 time=1932 ms
64 bytes from 192.168.1.22: icmp_seq=5 ttl=64 time=892 ms
64 bytes from 192.168.1.22: icmp_seq=6 ttl=64 time=5.63 ms
64 bytes from 192.168.1.22: icmp_seq=7 ttl=64 time=12.4 ms
64 bytes from 192.168.1.22: icmp_seq=8 ttl=64 time=5.59 ms
64 bytes from 192.168.1.22: icmp_seq=9 ttl=64 time=55.5 ms

Si quelqu'un a besoin de plus d'informations, je serai heureux de les fournir.

@bugok , est-ce que la configuration de l'interface réseau sur promiscuous atténue le problème pour vous? ( ifconfig wlan0 promisc ).

@quozl : Cela n'a pas aidé. Après un certain temps, le ping a commencé à échouer:

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

Rapporter: mon problème semble être résolu et ne semble pas lié au problème dans ce fil.

Détails ici , mais l'essentiel est que j'ai défini une adresse IP statique sur le Pi lui-même (en /etc/dhcpcd.conf ). Après avoir défini l'adresse IP statique dans le routeur, supprimé la configuration IP statique de /etc/dhcpcd.conf et redémarré - les choses semblent fonctionner.

Une mise à jour rapide: ce problème (erreur "Contenu de données de boîte aux lettres inconnu" accompagné d'un verrouillage sans fil complet) persiste, sur le dernier firmware avec toutes les mises à jour installées (dist-upgrade).

Changer une seule ligne dans le fichier hostapd.conf (selon mon commentaire précédent) élimine toujours le problème pour moi.

Utilisation de Rpi3B avec le noyau 4.14.52-v7 (raspberrypi-kernel 1.20180703-1) et (firmware-brcm80211 1: 20161130-3 + rpt4)
Je suis également toujours confronté au problème de blocage du wlan (90 appareils dont 2 par jour ont le problème). Dans certains cas, l'adaptateur est manquant et dans d'autres, il ne répond pas. Je n'utilise pas le Pi en mode AP, juste
J'ai essayé de le relier comme dans RPi-3B + mais sans succès.

J'ai actuellement créé une solution lorsqu'aucune connexion réseau n'est détectée, le pi redémarre. Cependant, ce n'est pas une solution appropriée et au moins j'essaye de recharger le pilote

Je voyais constamment ce même problème sur un Pi3 qui fonctionnait auparavant. Je me suis rendu compte que le seul changement que j'avais fait était de brancher un écran tactile LCD, puisant l'alimentation du Pi. Lorsque j'ai débranché l'écran tactile, le WiFi fonctionnait correctement. Cela semble donc certainement lié au pouvoir. Cela utilisait l'adaptateur secteur officiel Raspberry.

C'est un point de données très intéressant. Était-ce l'un de nos LCD?

@ JamesH65 J'ai également commencé à rencontrer des pannes de wifi et des pics de latence après avoir installé https://www.waveshare.com/wiki/5inch_HDMI_LCD , j'ai une caméra 3b + une rpi v2 et l'écran, connecté à un psu 3 ampères, n'obtenez aucun avertissement d'alimentation ...

Salut les gars, une mise à jour à ce sujet? J'essayais d'utiliser raspivid sur un zéro W avec un flux TCP et après quelques minutes, mon Wi-Fi est parti, je suppose que c'est le même problème.

Je n'ai pas eu le problème depuis au moins un an environ. Je commence à penser de plus en plus que cela peut être simplement lié au fait que la source d'alimentation USB ne fournit pas assez d'amplis, mais j'aimerais avoir la preuve que ce n'est pas le cas. À titre de test, essayez de brancher votre câble USB sur un adaptateur d'amplification plus élevée, surtout si vous pouvez facilement reproduire le problème.

Je suis sûr que ce n'est pas directement lié à l'ampli car je n'utilise qu'environ 2 ampères. principalement de vieux chargeurs Samsung. Cependant, il pourrait être ondulé ou quelque chose avec l'alimentation ou le matériel pi.Von meinem Samsung Gerät gesendet.

-------- Ursprüngliche Nachricht --------
Von: rajid [email protected]
Datum: 07.04.2019 02:15 (GMT + 01: 00)
Un: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , Commentaire [email protected]
Betreff: Re: [raspberrypi / linux] wlan se fige dans raspberry pi 3 / PiZeroW (pas
3B +) (# 1342)

Je n'ai pas eu le problème depuis au moins un an environ. Je commence à penser de plus en plus que cela peut être simplement lié au fait que la source d'alimentation USB ne fournit pas assez d'amplis, mais j'aimerais avoir la preuve que ce n'est pas le cas. À titre de test, essayez de brancher votre câble USB sur un adaptateur d'amplification plus élevée, surtout si vous pouvez facilement reproduire le problème.

—Vous recevez ceci parce que vous avez commenté. Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil.
{"api_version": "1.0", "publisher": {"api_key": "05dde50f1d1a384dd78767c55493e4bb", "name": "GitHub"}, "entity": {"external_key": "github / raspberrypi / linux", "title ":" raspberrypi / linux "," subtitle ":" Dépôt 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 ":" Ouvrir dans GitHub "," url ":" https://github.com/raspberrypi/linux "}}," updates ": {" snippets ": [{" icon ":" PERSON "," message ":" @rajid in # 1342: Je n'ai pas eu le problème depuis au moins un an. Je Je commence à penser de plus en plus que cela peut être simplement lié au fait que la source d'alimentation USB ne fournit pas assez d'amplis, mais j'aimerais avoir la preuve que ce n'est pas le cas. Pour tester, essayez de brancher votre câble USB sur un adaptateur d'ampli plus élevé, en particulier si vous pouvez facilement reproduire le problème. "}]," action ": {" name ":" Afficher le problème "," url ":" https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753 "}}}
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"name": "Afficher le problème"
},
"description": "Afficher ce problème sur GitHub",
"éditeur": {
"@type": "Organisation",
"name": "GitHub",
"url": " https://github.com "
}
}
]

J'ai toujours le problème, mais pas aussi souvent - peut-être jamais quelques semaines - et je ne peux plus le provoquer de manière fiable en me connectant à partir d'appareils Android Samsung.

J'alimente en fait le Pi zero w avec une alimentation USB 3A et un câble USB de 15 cm utilisé pour charger les batteries externes (pas de lignes de données, juste des lignes électriques)

Si j'utilise la connexion régulièrement (comme un utilisateur régulier), cela fonctionne bien, mais si je diffuse du MJPEG à 5 Mbps, il se bloque après quelques minutes, je vois une erreur de boîte aux lettres (ou similaire) sur journalct (je ne me souviens pas car je suis hors de la maison pendant une semaine), ssh s'arrête, pas de ping, le Wi-Fi tombe, iwconfig prend quelques secondes pour afficher les résultats et ils sont presque vides.

@vascojdb Si vous utilisez le Pi comme point d'accès (mode AP), cette solution de contournement (voir le texte en gras en bas) devrait résoudre votre problème.

Faites le nous savoir?

Non, ce n'est pas en mode AP, je suis connecté à mon réseau Wi-Fi 2,4 GHz domestique

Bonjour,

J'ai un problème de wifi pour synchroniser l'heure au démarrage avec le serveur NTP en utilisant LibreELEC sur RPI3B + depuis la version 9.0.0.
Après quelques discussions avec certains membres de l'équipe LE ( voir ici ), le problème a été corrigé suite à cette modification .

Mais il semble que cette solution de contournement a été annulée et le problème est toujours présent.
Est-il possible de le réparer à nouveau?

Personne pour répondre ou faire remonter ce problème?

Même problème. des nouvelles à ce sujet?

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)

J'ai essayé de désactiver la gestion de l'alimentation pour le moment. Est-ce un vieux bug réintroduit?

https://patchwork.kernel.org/patch/9948825/

Même problème. des nouvelles à ce sujet?

Ce message indique seulement que le firmware de la puce wifi s'est écrasé. Le noyau Linux ne peut rien faire à part la réinitialisation. Un rapport de bogue utile contient les informations suivantes:

Quel firmware wifi que vous utilisez?
Comment exploitez-vous le wifi (AP, client, ...)?
Pouvez-vous reproduire cela dans un temps défini?
Quels autres appareils wifi sont impliqués?

c'est dans mon dernier commentaire car il était reproductible à l'époque mais c'est un mauvais à reproduire et change avec les changements de logiciel quand il plante.

-------- Ursprüngliche Nachricht --------
Von: Stefan Wahren [email protected]
Datum: 01.05.2020 10:21 (GMT + 01: 00)
Un: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , Commentaire [email protected]
Betreff: Re: [raspberrypi / linux] wlan se fige dans raspberry pi 3 / PiZeroW (pas
3B +) (# 1342)

Même problème. des nouvelles à ce sujet?

Ce message indique seulement que le firmware de la puce wifi s'est écrasé. Le noyau Linux ne peut rien faire à part la réinitialisation. Un rapport de bogue utile contient les informations suivantes:
Quel firmware wifi que vous utilisez?
Comment exploitez-vous le wifi (AP, client, ...)?
Pouvez-vous reproduire cela dans un temps défini?
Quels autres appareils wifi sont impliqués?

—Vous recevez cet e-mail parce que vous avez commenté. Répondez directement à cet e-mail, affichez-le sur GitHub ou désabonnez-vous.
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"name": "Afficher le problème"
},
"description": "Afficher ce problème sur GitHub",
"éditeur": {
"@type": "Organisation",
"name": "GitHub",
"url": " https://github.com "
}
}
]

Même problème. des nouvelles à ce sujet?

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)

J'ai essayé de désactiver la gestion de l'alimentation pour le moment. Est-ce un vieux bug réintroduit?

https://patchwork.kernel.org/patch/9948825/

Pas de solution à proprement parler, mais j'ai exactement le même problème sur un Rpi4 avec le dernier firmware installé. Je l'ai restauré sur une image de carte SD que j'ai créée il y a quelques mois et le problème a disparu. Comme j'utilise hostapd, je pense que l'une de ces mises à niveau ou une combinaison de ces mises à niveau l'ont cassé pour moi:

$ apt list - évolutif
Liste ... Terminé
...
hostapd / stable 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u2 armhf [extensible à partir de: 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u1]
firmware-brcm80211 / testing 1: 20190114-1 + rpt6 all [extensible à partir de: 1: 20190114-1 + rpt4]
raspberrypi-kernel / testing 1.20200212-1 armhf [extensible à partir de: 1.20200114-1]
...

J'ai également essayé de désactiver la gestion de l'alimentation (et j'ai confirmé qu'elle était désactivée avec iwconfig), mais cela n'a eu aucun effet lors de l'exécution de hostapd. Je devrai renoncer aux mises à niveau du micrologiciel jusqu'à ce qu'elles soient corrigées, car nous en envoyons beaucoup et avons besoin de points d'accès stables pour nos clients.

Toute personne rencontrant des interruptions de micrologiciel, des délais d'expiration (-110), etc. - veuillez activer le débogage du micrologiciel afin que nous puissions collecter des données.

Ajoutez brcmfmac.debug=0x100000 à /boot/cmdline.txt, en le gardant dans une seule longue ligne, puis redémarrez. L'exécution de dmesg | grep brcmfmac devrait aboutir à une sortie comme celle-ci:

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

Alors continuez comme d'habitude. Lorsque le micrologiciel brcmfmac meurt, capturez la sortie de dmesg dans un fichier et attachez-le (ou un lien vers pastebin, etc.) ici.

Puisque l'échec déclenche d'autres messages du noyau, il y a un risque que la sortie utile soit perdue avant que vous ayez la chance de la capturer. Un moyen d'éviter cela est de laisser un shell enregistrant constamment les messages du noyau dans un fichier:

$ dmesg -w > kernel_log.txt &

Voir le même problème ici. Essayera le débogage mentionné ci-dessus.

Exécution de hostapd en mode AP, wireguard et frr. Utilisant également le chapeau cellulaire 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

Je suis également capable de recréer cela sur la branche 5.4. FWIW, je peux toujours déclencher manuellement ce bug en SCPing un gros fichier (> 400 Mo) sur mon Pi Zero W.

Si cela aide, ma version du noyau est à partir de ce 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 avec débogage:

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

Pendant le crash ci-dessus, j'ai exécuté un ifdown et ifup qui n'ont pas restauré le wifi. La seule solution est de redémarrer le pi, ou rmmod & modprobe brcmfmac.

Il convient de noter que cela se produit lorsque la gestion de l'alimentation est désactivée, car je l'ai dans mon fichier d'interface:

pre-up iwconfig wlan0 power off