EDIMAX EW-7811UN .... Das verwendet den RTL8188CUS-Chipsatz IIRC.

Wenn Sie noch keine haben, erstellen Sie /etc/modprobe.d/8192cu.conf mit Inhalt ....

Deaktivieren Sie die Energieverwaltung

Optionen 8192cu rtw_power_mgnt = 0 rtw_enusbss = 0

Das rpi3 verwendet tatsächlich den brcmfmac-Treiber für das eingebaute WLAN
Es gibt ein Problem, bei dem das Energiesparen / Verwalten deaktiviert werden muss

Ich denke, die neueren Raspian-Kernel haben dies bereits gepatcht, um das Energiesparen standardmäßig zu deaktivieren, aber ich denke, es befindet sich noch nicht in diesem 4.5-Zweig

Was ich im Moment mache (Gentoo-Installation), ist das Folgende beim Booten, um die Energieeinsparung auf der WLAN-Karte zu deaktivieren

iw wlan0 macht power_save aus

Das rpi3 verwendet tatsächlich den brcmfmac-Treiber für das eingebaute WLAN

Ja, ich weiß. Oh ich verstehe. Er benutzt den EDIMAX EW-7811UN Dongle nicht mehr. Er benutzte es mit RPi2.

Ja, ich benutze das USB-WLAN nicht mehr. Wie richte ich die Cmd-Leitung ein, um die Energieverwaltung auszuschalten?
crontab
@reboot iw wlan0 set power_save off

Ich bin mir nicht sicher für Raspian, da ich Gentoo benutze, wird es anders sein

Versuchen Sie Folgendes: https://gist.github.com/mkb/40bf48bc401ffa0cc4d3

Scheint zu funktionieren, seit ich das Powermanagement ausgeschaltet habe. Ich hatte keinen weiteren WLAN-Absturz.

Nur um es zu erwähnen, um das WLAN nach einem Absturz automatisch neu zu starten, hilft dies hier:
sudo cp /etc/wpa_supplicant/ifupdown.sh /etc/ifplugd/action.d/ifupdown

Übrigens, beim neuesten apt-get-Upgrade-Kernel ist die Energieverwaltung standardmäßig deaktiviert.
@ dh-connect funktioniert dies für Sie, wenn Sie Ihre aktuelle Problemumgehung entfernen?

Nach dem letzten Upgrade stürzt es immer noch ab. Jetzt erhalte ich diesen Fehler im Syslog:
brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!

Wenn Sie sagen, dass es abstürzt, gibt es andere Symptome als die Fehlermeldung?

Nein, nur die, die ich hier gepostet habe, aber sie steht oft im Protokoll

Das WLAN funktioniert nicht mehr. Ich kann immer noch damit arbeiten, aber um das WLAN wieder zum Laufen zu bringen, muss ich es neu starten

Danke - ich denke, "wlan hört auf zu arbeiten" zählt als Symptom.

Ich habe ein paar Dinge ausprobiert, aber wlan bricht immer noch zusammen

um die obige Frage zu beantworten, wenn ich die Konfiguration zurücknehme
kabelloses Ausschalten in / etc / network / interfaces
und neu starten
und überprüfen Sie die Einstellungen mit iwconfig
Die Energieverwaltung ist wieder eingeschaltet. Standardmäßig würde ich nicht sagen, dass dies diasled ist, sodass ich die Konfiguration verlassen werde

Ich habe das mit Kernel 4.1.19 und jetzt auch mit Kernel 4.1.20 versucht ... keine Änderung

wenn der wlan abgestürzt ist und ich versuche ihn mit ifdown und ifup wlan0 wieder einzuschalten bekomme ich folgendes:
Fehler bei drahtloser Anforderung "Set Power Management" (8B2C): SET auf Gerät wlan0 fehlgeschlagen; Ungültiger Austausch.

Ich habe auch noch ein paar Fehler im Syslog:

dhcpcd [532]: wlan0: xxx: Option 25 abgelaufen

21. März 17:29:35 Himbeerpi-Kernel: [6627.337503] brcmfmac: _brcmf_set_multicast_list: Das Festlegen von mcast_list ist fehlgeschlagen, -52
21. März 17:29:36 raspberrypi wpa_supplicant [6318]: Wpa_supplicant wurde erfolgreich initialisiert
21. März 17:29:36 raspberrypi dhcpcd [532]: wlan0: Träger verloren

21. März 17:29:43 Himbeerpi-Kernel: [6635.337616] brcmfmac: _brcmf_set_multicast_list: Das Festlegen von mcast_list ist fehlgeschlagen, -52

21. März 17:29:45 Himbeerpi-Kernel: [6637.337588] brcmfmac: brcmf_do_escan: Fehler (-52)
21. März 17:29:45 Himbeerpi-Kernel: [6637.337602] brcmfmac: brcmf_cfg80211_scan: Scanfehler (-52)

21. März 17:29:47 Himbeerpi-Kernel: [6639.337596] brcmfmac: _brcmf_set_multicast_list: Das Einstellen von allmulti ist fehlgeschlagen, -52
21. März 17:29:49 raspberrypi-Kernel: [6641.337632] brcmfmac: _brcmf_set_multicast_list: Das Einstellen von BRCMF_C_SET_PROMISC ist fehlgeschlagen, -52

Gibt es noch etwas, das ich versuchen könnte?

auch diese:

21. März 21:26:55 raspberrypi dhcpcd [526]: wlan0: xxx: Option 25 abgelaufen
21. März 21:28:54 Himbeerpi-Kernel: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
21. März 21:30:16 raspberrypi dhcpcd [526]: wlan0: xxx ist nicht erreichbar und läuft ab

Ich bin nicht überrascht, dass iwconfig der Meinung ist, dass auf dem Gerät die Energiesparfunktion aktiviert ist. Ich habe es im Treiber selbst blockiert. Entweder wird der Status in den höheren Ebenen gespeichert, oder es ist eine weitere Änderung erforderlich, um ihn korrekt zu melden. In beiden Fällen gibt es starke Beweise dafür, dass wir die stromsparenden Fehler vermieden haben, aber einige andere Probleme bleiben bestehen.

Haben Sie grobe Zahlen für die Zeit bis zum Ausfall und ungefähr, wie viele Daten möglicherweise übertragen wurden (von ifconfig)?

Ja, wenn nur der Webserver mit wenig Verkehr (weniger als 100 MB) ausgeführt wird, dauert es ein oder zwei Tage, wenn ich große Datendateien wie 1 GB wlan innerhalb von 1 Stunde abstürze

Was kann ich tun, um den Fehler zu finden?

Hier sind einige Fehler von Syslog:

29. März 14:20:56 raspberrypi dhcpcd [535]: wlan0: xxx: Option 25 abgelaufen
29. März 14:30:15 raspberrypi dhcpcd [535]: wlan0: xxx ist nicht erreichbar und läuft ab
29. März 17:18:42 Himbeerpi-Kernel: [186148.102420] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29. März 17:18:43 Himbeerpi-Kernel: [186149.101045] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29. März 17:18:43 Himbeerpi-Kernel: [186149.101145] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29. März 17:18:44 Himbeerpi-Kernel: [186150.101209] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29. März 17:18:50 raspberrypi wpa_supplicant [478]: wlan0: STRG-EVENT-DISCONNECTED bssid = xxx Grund = 3 lokal_generiert = 1
29. März 17:18:50 Himbeerpi-Kernel: [186156.181033] brcmfmac: brcmf_cfg80211_disconnect: Fehler (-52)
29. März 17:18:52 Himbeerpi-Kernel: [186158.181028] brcmfmac: send_key_to_dongle: wsec_key error (-52)
29. März 17:18:54 Himbeerpi-Kernel: [186160.181046] brcmfmac: send_key_to_dongle: wsec_key error (-52)
29. März 17:18:56 Himbeerpi-Kernel: [186162.181048] brcmfmac: send_key_to_dongle: wsec_key error (-52)
29. März 17:18:58 Himbeerpi-Kernel: [186164.181049] brcmfmac: send_key_to_dongle: wsec_key error (-52)
29. März 17:18:58 Himbeerpi-Kernel: [186164.185477] cfg80211: Aufruf von CRDA zur Aktualisierung der weltweiten Regulierungsdomäne
29. März 17:18:58 raspberrypi dhcpcd [535]: wlan0: Träger verloren
29. März 17:18:58 raspberrypi wpa_supplicant [7354]: Wpa_supplicant wurde erfolgreich initialisiert
29. März 17:18:58 Himbeerpi-Kernel: [186164.314511] brcmfmac: brcmf_cfg80211_reg_notifier: kein ISO3166-Code
29. März 17:18:58 Himbeerpi-Kernel: [186164.314541] cfg80211: Weltregulierungsdomäne aktualisiert:
29. März 17:18:58 Himbeerpi-Kernel: [186164.314548] cfg80211: DFS-Master-Region: nicht festgelegt
29. März 17:18:58 Himbeerpi-Kernel: [186164.314555] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
29. März 17:18:58 Himbeerpi-Kernel: [186164.314565] cfg80211: (2402000 kHz - 2472000 kHz bei 40000 kHz), (N / A, 2000 mBm), (N / A)
29. März 17:18:58 Himbeerpi-Kernel: [186164.314573] cfg80211: (2457000 kHz - 2482000 kHz bei 40000 kHz), (N / A, 2000 mBm), (N / A)
29. März 17:18:58 Himbeerpi-Kernel: [186164.314581] cfg80211: (2474000 kHz - 2494000 kHz bei 20000 kHz), (N / A, 2000 mBm), (N / A)
29. März 17:18:58 Himbeerpi-Kernel: [186164.314592] cfg80211: (5170000 kHz - 5250000 kHz bei 80000 kHz, 160000 kHz AUTO), (N / A, 2000 mBm), (N / A)
29. März 17:18:58 Himbeerpi-Kernel: [186164.314602] cfg80211: (5250000 KHz - 5330000 KHz bei 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 s)
29. März 17:18:58 Himbeerpi-Kernel: [186164.314611] cfg80211: (5490000 KHz - 5730000 KHz bei 160000 KHz), (N / A, 2000 mBm), (0 s)
29. März 17:18:58 Himbeerpi-Kernel: [186164.314645] cfg80211: (5735000 KHz - 5835000 KHz bei 80000 KHz), (N / A, 2000 mBm), (N / A)
29. März 17:18:58 Himbeerpi-Kernel: [186164.314654] cfg80211: (57240000 kHz - 63720000 kHz bei 2160000 kHz), (N / A, 0 mBm), (N / A)

Vielen Dank für das Angebot, aber das liegt jetzt in den Händen von Broadcom.

Gibt es ein Update von Broadcom, wenn dies ein Fehler ist, der behoben wird? Ich habe jetzt ein Cron-Job-Setup, um wlan0 herunterzufahren und hochzufahren, wenn es nicht pingt.

schnelles Update von meiner Seite, ich konnte das Problem beheben, scheint treiberbezogen zu sein, ich habe Ubuntu MATE 16.04 mit Kernel 4.4.8 installiert und hatte seitdem keine Probleme mit WLAN

Ich meine, sie werben ist: "Ubuntu MATE 16.04 hat auch voll funktionsfähiges Bluetooth und Wifi auf dem Raspberry Pi 3", was wahr scheint

Vielleicht funktioniert es auch mit einer neuen Debian-Version, die ich nicht sagen kann

@ juched78 Läufst du einen 4.4 Kernel? Wenn nicht, führen Sie bitte sudo rpi-update , um den neuesten 4.4.8-Build zu erhalten und festzustellen, ob das gleiche Problem vorliegt.

Die Broadcom-Treiber haben sich seit 4.1 erheblich geändert, und unser 4.4-Baum enthält Back-Ports einiger Fixes, die in 4.5 enthalten sind. Ich kenne keine ausstehenden Fehler, abgesehen davon, dass ich nicht aus dem Ruhezustand aufwache (die Energieverwaltung ist weiterhin deaktiviert). Die Kanäle 12 und 13 können verwendet werden, sofern dies zulässig ist, und der Ad-hoc-Modus stürzt nicht ab .

Oh, es gibt noch einen gemeldeten Fehler in 4.4.8 - anscheinend kann eine starke Verwendung von Hostapd zu einer Kernel-Warnung führen (siehe https://github.com/raspberrypi/linux/issues/1375).

Ich renne:
Linux XXX 4.4.8-v7 + # 880 SMP Fr 22. April 21:55:04 BST 2016 armv7l GNU / Linux

27. April 2016 11:06:18
Copyright (c) 2012 Broadcom
Version 9b52ab7b475f4a056658fd2d95d2440b32167390 (sauber) (Version)

Mit meinem Netgear R7000, auf dem Shibby Tomato ausgeführt wird, werden ungefähr 2 Tage im WLAN und in den Systemprotokollen angezeigt:

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

Dann scheint es nie wieder zu verbinden ...

Die Verwendung von sudo ifdown wlan0 gefolgt von sudo ifup wlan0 bringt meine Verbindung zurück.

Gerade aktualisiert auf:
Linux JuchePi 4.4.8-v7 + # 881 SMP Sa 30.04. 12:16:50 BST 2016 armv7l GNU / Linux

Ich bin mir nicht sicher, was sich vom 22. bis zum 30. unterscheidet. Ich werde die Verbindung überwachen.

Mein RPi 3 hat dieses Problem ebenfalls gelöst. Ich habe einige verschiedene Kernel-Nachrichten erhalten. Hauptsächlich eine davon unten.
Danach kann ich das WiFi zum Laufen bringen. Es hilft nicht, wlan0 herunter und dann hoch zu bringen.

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 wird vom Original-Netzteil für Version 3 mit Strom versorgt. Ich verwende das neueste OSMC:
$ uname -a
Linux osmc 4.4.8-3-osmc # 1 SMP PREEMPT So 1. Mai 18:57:43 UTC 2016 armv7l GNU / Linux

Immer noch überwachen. Ich hatte Openhab nach 3 Tagen offline gehen lassen, aber aus irgendeinem Grund konnte ich immer noch in den Pi ssh, was ich normalerweise nicht konnte. Die Spitze der Stunde und das WLAN-Skript wurden ausgeführt, um die Verbindung zu beenden und wiederherzustellen, und dann wurde die Verbindung zu meiner Openhab-Organisation wiederhergestellt. Seltsam. Ich werde weiter zuschauen.

Ich habe auch das gleiche Problem - dmesg trace wie folgt:

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)

Verwendung:

rp3 wird als Router / Access Point verwendet

Die Konnektivitätslänge scheint zufällig zu sein - ich hatte bis zu zwei Wochen und nur ein paar Minuten Zeit. In letzter Zeit geht es alle 20 Minuten oder so aus. Durch Herunterfahren und Sichern von wlan0 wird das Problem nicht behoben. Ein vollständiger Neustart ist erforderlich.

Das Problem scheint sich beim Streaming von Netflix von meinem AppleTV zu verschärfen. Dies war jedoch nicht der Fall, als ich zwei Wochen Betriebszeit hatte.

Ich bin auf 4.4.10-v7 +

Ich habe den Kanal von 13 auf 6 umgestellt, um zu prüfen, ob dies das Problem sein könnte (es gab einige Mängel bei den hohen Kanälen), und seitdem habe ich kein WLAN mehr. Aber das könnte ein Zufall sein ...

Das Ändern der Zugangspunktkanäle hat nicht geholfen. WiFi bricht immer noch. Die letzten Male musste ich einige Male hintereinander neu starten, damit es funktionierte.

Dieses Problem tritt speziell auf, wenn ich versuche, eine SFTP-Übertragung zwischen dem rpi3 und meinem Galaxy S5-Telefon durchzuführen. Wenn ich versuche, dieselbe Übertragung von meinem Laptop durchzuführen, läuft alles reibungslos.

Ausführen des neuesten Kernels von rpi-update:

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

Fehlermeldung von Syslog:

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

Es scheint, dass die einzige Lösung nach diesem Fehler ein Neustart ist.

Ich habe meine in der letzten Woche zweimal aus dem Netzwerk entfernen lassen. Zum ersten Mal war ich in Eile, also einfach ausgesteckt und neu gestartet. Wenige Tage später passierte es erneut, startete erneut und führte dann vollständige Systemupdates (einschließlich Firmware) aus und wird überwacht. Habe es ohne Monitor in der Nähe montiert, so dass es mehr Aufwand erfordert, Details über den Fehler zu erhalten :)

Selbes Problem hier. Es friert immer ein, wenn große Dateien per SFTP übertragen werden. Einfach neu starten, um zu lösen

Dieses Problem hängt möglicherweise mit https://github.com/raspberrypi/linux/issues/1313 zusammen

Broadcom sagt, dass # 1313 kein Problem ist und der neueste Kernel diese Nachrichten nicht mehr anzeigt.

Ich konnte dieses Problem nicht reproduzieren. Konnte jemand zum Zeitpunkt des Ausfalls eine Paketverfolgung erfassen?

Wenn jemand Zeit hat, weitere Tests mit einem debug-fähigen Treibermodul durchzuführen, wäre er sehr dankbar:

1) Führen Sie sudo rpi-update und starten Sie neu. Dies dient dazu, Ihren Kernel auf das gleiche Niveau wie meinen zu bringen, damit das Modul kompatibel ist.

2) Laden Sie das aktualisierte Treibermodul herunter und installieren Sie es:

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

Starten Sie neu, um die neuen Module zu aktivieren.

3) Verwenden Sie Ihren Pi wie gewohnt. Wenn Ihr WLAN einfriert, laufen Sie:

dmesg > wifi_freeze.txt

und laden Sie es auf Ihre bevorzugte Einfügeseite hoch (oder erstellen Sie eine Übersicht). Ein oder zwei Protokolle sollten ausreichend sein.

So stellen Sie die Originalversion des Moduls wieder her:

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

Danke im Voraus.

Warten Sie einen Moment, während wir überprüfen, ob die Debug-Ausgabe wirklich aktiviert ist.

Sie müssen auch eine Debug-Funktion für den Treiber aktivieren:

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

Ich habe die obigen Anweisungen geändert.

Nach einem Neustart sollte Ihre dmesg-Ausgabe Folgendes enthalten:

[   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 nach der Ausführung Ihrer Anweisungen habe ich kein WLAN mehr ...

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

Versuche dies:

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

Und neu starten.

wlan0 assoziiert nicht.
wireless.txt
(Bei einem von vielen Neustarts habe ich einige Minuten lang eine Assoziation gesehen, die ich (noch) nicht in dmesg abgefangen habe.)

Anscheinend wurde das Problem für mich durch ein Upgrade von 4.4.11-v7 + auf 4.4.15-v7 + behoben

Ich habe versucht, die Probleme, die ich mit SFTP-Übertragungen von einem Android-Telefon hatte, wiederherzustellen, sehe aber derzeit keine Probleme.

@pelwell nach langem Warten gelang es wlan0 zu assoziieren; dmesg an vorheriges Protokoll angehängt:
wireless.txt
Warten jetzt auf Einfrieren oder Assoziationsverlust
hoffe das ist hilfreichl

@pelwell verlor schnell wieder die Verbindung; Dmesg angehängt an:
wireless.txt

Dankeschön. Es war das erste Mal langsam für mich. Ich war damit beschäftigt, einen sauberen Raspbian zu bekommen und die Patches anzuwenden, um das Problem zu reproduzieren - ich werde trotzdem fortfahren.

@ Pelwell
wireless.txt
und wieder zugeordnet: dmesg wieder angehängt
willst du, dass ich weitermache?

@pelwell : wieder Assoziation verloren
wireless_associationloss.txt

@ Pelwell
es schaltet sich unregelmäßig ein / aus
wireless_associationloss.txt

Ich denke, Sie sollten jetzt zurückschalten, bevor mein Posteingang überläuft.

OK; Ich werde auf meinen 3 € MT7601U Dongle zurückgreifen. ;)

Vielen Dank für Ihre bisherige Hilfe,

Ich habe dieses Problem gerade gefunden. Kann ich bestätigen, dass es dem ähnlich ist, was ich sehe? Ich habe ein RPi 3 als Zugangspunkt eingerichtet und kann von Zeit zu Zeit keine Verbindung herstellen. Ich kann über die Kabelverbindung sshen und sehe, dass wlan0 immer noch die richtige IP-Adresse hat, aber der einzige Weg, um den Access Point wieder zum Laufen zu bringen, ist ein Neustart. Ich sehe solche Stapelspuren in /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 ]---

Mein Kernel ist 4.4.13-v7 + und ich habe gerade zum ersten Mal rpi-update ausgeführt, daher weiß ich noch nicht, ob das helfen wird.

Ich frage mich, ob dies damit zusammenhängt oder vielleicht ein separates Problem
https://www.youtube.com/watch?v=_D_fi_ck9Vo

Mein RPI3 funktionierte problemlos über WLAN, bis ich es auf das neueste udev ...

Jetzt verbindet es sich nicht mehr ...

Ich habe auch gepatchte Module von Pelwell installiert, aber wir haben keinen Erfolg: Einfach keine Verbindung ...

Lassen Sie mich wissen, ob ich helfen kann,

Mein Bestes,
Mimmo

@ dh-connect wurde Ihr Problem behoben? Wenn ja, schließen Sie dieses Problem. Vielen Dank.

Ich arbeite seitdem mit LAN, habe WLAN nicht ausprobiert

Hallo,

Ich habe das gleiche Problem mit meinem RPI 3. Ich habe wieder den offiziellen RPI-WLAN-USB-Dongle verwendet, der absolut stabil ist, aber das eingebaute WLAN stirbt nach ca. 20 Stunden Konnektivität mit dieser Art von Nachrichten im Syslog

brcmfmac: brcmf_cfg80211_reg_notifier: kein ISO3166-Code
cfg80211: Weltregulierungsdomäne aktualisiert:
cfg80211: DFS-Master-Region: nicht festgelegt

Dies ist auf der neuesten Raspbian, neuesten Firmware

Ist es möglich, dieses Problem erneut zu öffnen?
Warum war es geschlossen?

Ich arbeite seitdem mit LAN, habe WLAN nicht ausprobiert
dh-connect hat dies vor 13 Tagen geschlossen

Dies ist keine Lösung, die es wert ist, das Problem zu schließen ...

Ich habe immer noch das Problem und kann den Fehler reproduzieren.

Mein relevanter Teil von dmesg ist:

[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

Ich habe das gleiche Problem wie @jrmhaig und habe jetzt ein Upgrade

$ 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

Richten Sie hostapd mit einer Brücke ein.

/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

Für Menschen mit WiFi-Problemen hat Cypress (war Broadcom) uns Debug-Module zur Verfügung gestellt, um die Diagnose der Probleme zu erleichtern. Da Module kernelversionsspezifisch sind, müssen Sie zuerst auf eine bestimmte Firmware-Version aktualisieren (oder möglicherweise zurücksetzen):

sudo rpi-update b0ef6e25679d3612a980708cf4c3907ce6e13e84
sudo shutdown -r now

Jetzt können Sie die Debug-Module herunterladen und installieren:

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

Der letzte Befehl führt das Installationsskript aus, das die Originalmodule auf eine Seite kopiert, bevor sie durch die Debug-Versionen ersetzt werden. Wenn Sie den Befehl erneut ausführen, werden die ursprünglichen Versionen wiederhergestellt.

Starten Sie Ihren Pi 3 nach der Installation neu - jetzt zeigt dmesg | grep brcmfmac eine Diagnosemeldung wie folgt an:

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

Wenn Sie auf ein Problem stoßen, verwenden Sie dmesg > wifidbg.txt , um die Ablaufverfolgung zu einer Datei zusammen mit anderen Kernel-Nachrichten zu erfassen, laden Sie die Datei dann irgendwo hoch (Kern, Pastebin, Dropbox usw.) und veröffentlichen Sie einen Link dazu zusammen mit eine Beschreibung dessen, was Sie getan haben, als der Fehler aufgetreten ist.

Bitte aktualisieren Sie mein Gedächtnis: Welchen Befehl verwenden, um zu stabiler Firnmware zurückzukehren?
Wenn ich mich entscheide, das Debuggen zu beenden?

sudo apt-get update
sudo apt-get upgrade

sollte den Trick machen. Und sudo ./brcmdbg um einfach zu den Nicht-Debug-Treibern zurückzukehren.

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

Debugging gestartet; benötigt etwa 5 oder 6 Versuche zu assoziieren; Ich weiß nicht, warum alle bis auf den letzten Versuch fehlgeschlagen sind. Ich werde es laufen lassen, bis ich einen Assoziationsverlust sehe und dann ein neues Dmesg ausgeben werde. Inkonsistentes Assoziationsverhalten war mein Problem, bevor ich das Onboard-WLAN nicht mehr verwendete, sodass dies möglicherweise vor Ort war. Bitte lassen Sie mich wissen, ob zusätzliche Aktivitäten hilfreich sein könnten.

https://gist.github.com/BenoitSvB/bf8acdbb7b664df90e885603bb4774ce#file -201609081628_wifidbg-txt
Nichts tun als warten; sehen wir hier mehrere Assoziationsverluste / -rückforderungen?

Dank dafür. Hmm - diese Protokolle sind nicht sehr informativ, aber mal sehen, mit was Cypress zurückkommt.

https://gist.github.com/BenoitSvB/98db53ff884e7b1a57bf1475d6106c56
Unerklärlicher Verlust und Wiederherstellung der Assoziation; lang genug, um im Systray-Symbol zu sehen.
Accesspoint ist Linksys wrt160n mit Firmware: DD-WRT v24-sp2 (08/07/10) std.
Ich schätze, ich kann das Debuggen vorerst beenden und zu meinem 3 € MT7601U-Dongle zurückkehren, aber lassen Sie mich wissen, ob ich Ihnen weiterhelfen kann.

@pelwell Ich habe keine Firmware-Wiederherstellung nach dem Update von sudo apt-get und dem Upgrade von sudo apt-get und dem sudo rpi-update gesehen
*** Ihre Firmware ist bereits auf dem neuesten Stand. Ich denke, ich muss das RPI-Update mit einem bestimmten Git-Hash ausführen, um zur stabilen Firmware zurückzukehren. Weißt du welcher Hash?

Der Festschreibungsverlauf im RPI-Distro-Repo zeigt, dass Sie das Festschreiben 390f53ed0fd79df274bdcc81d99e09fa262f03ab vom Firmware-Repo aus ausführen möchten. Führen Sie also Folgendes aus:

sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab

@ Pelwell :
root @ pi3b : / home / pi # sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab
** Raspberry Pi Firmware-Updater von Hexxeh, erweitert von AndrewS und Dom* * Selbstaktualisierung durchführen
** Neustart nach dem Update* * Raspberry Pi Firmware-Updater von Hexxeh, erweitert von AndrewS und Dom
Ungültiger Git-Hash angegeben

Ah, die Hexxeh-RPI-Firmware hat unterschiedliche Commit-IDs - versuchen Sie es mit 569e6611ac20c735647eb0e550484a73935a672d.

Ich frage mich, ob https://github.com/raspberrypi/linux/issues/1552 / # 1444 auch mit diesem Problem zusammenhängen könnte.

Ich habe kürzlich ein 40xRPI3-Setup bereitgestellt, das einige Bluetooth-Funktionen ausführt. Wir mussten USB-WLAN-Schnittstellen einrichten, sonst würde WLAN ständig einfrieren. Wir verwenden jetzt das interne BL-Gerät und das interne WLAN-Modul ist in modprobe.d auf der schwarzen Liste.

Es könnte vielleicht nützlich sein, hcitool name 11:11:11:11:11:11 und zu prüfen, ob dadurch auch interessante Protokolleinträge generiert werden. Ich habe gerade dieses Problem verfolgt und hatte nicht die Zeit, meine Laborumgebung einzurichten, um selbst etwas zu testen. Wir hatten einige WLAN-Einfrierungen ohne BT aktiviert, aber die Kombination von WLAN + BT kann mehr oder weniger immer WLAN in sehr kurzer Zeit töten. Dies war immer über eine beliebige Anzahl unserer RPIs reproduzierbar

@ Pelwell
OK; uname -a gibt Linux pi3b.thuis 4.4.13-v7 + # 894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU / Linux
Nur zur Information: Wo würde jemand den Git-Hash für die aktuelle stabile Firmware-Version finden?

@ Thomasf
Obwohl ich Bluetooth aktiviert habe, kann ich es derzeit nicht verwenden. Der Name des Hcitools 11: 11: 11: 11: 11: 11 gibt nichts zurück. Das ist wohl zu erwarten, da ich mit keinem Gerät verbunden bin. Vielleicht sollte ich mir ein BT-Audiogerät kaufen, mit dem ich spielen kann.

Stabil definieren.

Der Hash, den ich Ihnen (endlich) gegeben habe, ist für die Firmware-Version vom 20. Juni, die Sie erhalten, wenn Sie Folgendes ausführen:

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

Mir ist kein einziger Ort bekannt, der den Hash der neuesten "stabilen" Version enthält, aber wenn Sie RPI-Distro durchgehen, wie ich es damals mit dem Hexxeh-Repo getan habe, können Sie RPI-Update-Hashes für jede Version erhalten du magst. Wenn Sie die Version 2016-05-23 als stabil betrachten, da sie Teil der letzten vollständigen Raspbian-Version war, möchten Sie den Hash 3b98f7433649e13cf08f54f509d11491c99c4c0b, der sich in einen RPI-Update-Hash von 2b9c0bfacfc11ee8bb9b30dc8cc übersetzt.

@BenoitSvB Wenn Sie diesen Befehl hcitool von einem Neustart aus ausführen, ohne hci0 mit einer anderen Software zu berühren, verhält sich das WLAN in unseren Tests schlecht. Ich weiß nicht, ob es wichtig ist, ob es andere Bluetooth-Geräte gibt, aber es ist das kleinste reproduzierbare Beispiel Ich kann mir vorstellen, die Probleme mit dem Einfrieren des WLANs auszulösen.

Ich habe auch externen BT-Dongle + internes WLAN getestet, aber das interne WLAN hängt manchmal, selbst wenn der interne BTM-BT-Treiber nicht geladen ist. Die "Lösung" (wie bei der schnellen Lösung) für uns war die Verwendung von USB-WLAN-Adaptern, die sich in unseren Tests und in der Produktion als stabil erwiesen haben.

Ich vermute immer noch # 1313 als verwandt.

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

Ich habe auch externen BT-Dongle + internes WLAN getestet, aber das interne
WiFi hängt manchmal, auch wenn der interne bcm bt-Treiber nicht ist
geladen. Die "Lösung" (wie in der Schnellreparatur) für uns war die Verwendung von USB-WLAN
Adapter, die sich in unseren Tests und im Produktionsbetrieb als stabil erwiesen haben.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245649229,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AFyzObJxRjzQ-uMUlfe8hjRasrfq3nkwks5qoDLXgaJpZM4HupC5.

@ Pelwell
stabil wäre in diesem Fall die Firmware, wie sie von der Foundation mit ihrem letzten veröffentlichten Image veröffentlicht und nur durch "sudo apt-get update && sudo apt-get upgrade" aktualisiert wurde, also ohne Aufruf von rpi-update (mit oder ohne ein bestimmtes git Hash, der meines Wissens nur für ein Upgrade auf neuere Firmware für bestimmte Zwecke gedacht ist).
Das bringt mich zu der Frage: Kann ich den Hash meiner betriebsbereiten Firmware lesen, bevor ich eine neue Firmware zum Testen lade, um eine Wiederherstellung nach dem Testen zu vereinfachen, da ich mir nicht trauen würde, den von Ihnen erwähnten Querverweis auszuführen ...

Vielleicht - cat /boot/.firmware_revision wird von rpi-update geschrieben, aber
Ohne es zu versuchen, konnte ich dir nicht sagen, ob die Raspbian-Veröffentlichungen auch schreiben
es.

boot / .firmware-revision ist eine rpi-update sache (
https://www.raspberrypi.org/forums/viewtopic.php?t=106073&p=732449#p731830)

Aber ich fand mit:

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

das will ich ja:

• Firmware ab 390f53ed0fd79df274bdcc81d99e09fa262f03ab

Ich verstehe das Crossref von
https://github.com/RPi-Distro/firmware/commits/debian?author=popcornmix to
https://github.com/Hexxeh/rpi-firmware/commits/master wird sorgfältig erstellt
Vergleichen von Daten und Beschreibungen von Commits.

Etwas gelernt; Danke :)

Op 8 sep. 2016 20.28 Uhr schreef "Phil Elwell" [email protected] :

Vielleicht - cat /boot/.firmware_revision wird von rpi-update geschrieben, aber
Ohne es zu versuchen, konnte ich dir nicht sagen, ob die Raspbian-Veröffentlichungen auch schreiben
es.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245693018,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AFyzOQ_pfODaEmuBGR6pQVXs2W6LggW8ks5qoFO2gaJpZM4HupC5
.

@BenoitSvB : Ihre Spuren scheinen ein anderes Problem

@mathieugouin @ dh-connect @ juched78 @maciex @duncanmcdowell : Ich habe einen Cypress-Ingenieur, der mehr über Ihre Probleme erfahren möchte . Wenn Sie mir eine E-Mail senden - Phil von raspberrypi dot org - kann ich Sie mit ihm in Verbindung setzen. Wenn Sie die Dinge beschleunigen möchten, installieren Sie die Debug-Module wie oben beschrieben und speichern Sie die Ausgabe von dmesg, wenn etwas schief geht.

@pelwell Google hat auf 'Packet Sniffer Waveshark' nicht viel Wesentliches zurückgegeben, aber ich denke, Sie meinten WireShark. Die Tatsache, dass die schwarze Liste von brcmutil & brcmfmac während der Verwendung eines MT7601U-Dongles das unregelmäßige Verbindungs- / Trennungsverhalten verschwinden lässt, kombiniert mit den häufigen 'außer Betrieb' auftretenden Ereignissen (siehe # 1313, jetzt versteckt, aber nicht gelöst), lässt mich einen Broadcom / vermuten Cypress Hardware Ursache.
Wireshark könnte hilfreich sein, aber ich würde Unterstützung benötigen, um einen ernsthaften Debugging-Hardware-Aufwand einzurichten / durchzuführen.

Ja, ich meinte Wireshark.

Sie können das Dienstprogramm dumpcap (Teil des tshark-Pakets im Textmodus) verwenden, um alle Aktivitäten in einer Datei aufzuzeichnen und diese dann zu beenden, wenn das dmesg-Protokoll eine verdächtige Nachricht enthält. Etwas wie das:

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

Beachten Sie, dass "grep --max-count 1" zwar nach einem Spiel beendet werden soll, jedoch eine weitere Eingabezeile erforderlich sein muss, damit es tatsächlich stoppt. In der Praxis sollte dies jedoch kein Problem sein.

Wenn Ihre Erfassungsdatei zu groß wird, können Sie dumpcap verwenden, um eine Aufzeichnung mit fester Dauer mit der Option "-b Dauer: 60 " (für eine Minute) zu verwenden. Es besteht die Möglichkeit, dass ein solcher Neustart der Erfassung zu einem schlechten Zeitpunkt erfolgt und die interessanten Pakete verloren gehen. Dies ist jedoch unwahrscheinlich. Sie können die Wahrscheinlichkeit immer verringern, indem Sie die Dauer verlängern.

@BenoitSvB Es ist ein Thread hier die Probleme zu vermeiden Konnektivität im Pi3 WiFi - Treiber als eine Möglichkeit , Roaming schlägt deaktivieren. Durch Roaming kann ein Gerät automatisch zwischen APs mit derselben SSID wechseln. Dies ist jedoch auf einem statischen Gerät wie einem Pi3 wahrscheinlich weniger nützlich, und es wird vermutet, dass dies letztendlich zu einem vollständigen Verbindungsverlust führen kann.

Könnten Sie versuchen, den Modulparameter roamoff aktivieren? Sie müssen create /etc/modprobe.d/brcmfmac.conf erstellen, das Folgendes enthält:

options brcmfmac roamoff=1

@pelwell : Das Deaktivieren des Roamings ist nicht die Lösung. aber es bringt mich dazu, mit verschiedenen Kanälen und einem zweiten Zugangspunkt zu spielen. Ich habe festgestellt, dass der integrierte WLAN-Adapter nur bei einigen Kanälen (z. B. 1, 5) und nur beim Linksys WRT160N mit DD-WRT-Firmware Probleme hat. Seltsamerweise teilte keiner meiner anderen WLAN-Clients dieses Problem: Sie stellen auf allen angebotenen Kanälen auf beiden Accesspoints problemlos eine Verbindung her. Gut für mich, ich habe eine stabile Problemumgehung (keine Verwendung von Kanälen an Bord von WLAN hat Probleme), aber keine Klarheit in der Sache.
Soll ich bestimmte Tests durchführen?
Übrigens müssen wir Parameter einstellen
options brcmfmac debug = 1
in der /etc/modprobe.d/brcmfmac.conf bei Verwendung der speziellen Testtreiber?
Und kennen Sie einen Weg, um die Verfügbarkeit einer WLAN-Verbindung zu messen: Dann könnte ich alle Kanäle systematischer über längere Zeiträume testen, ohne gigantische Erfassungsdateien zu erstellen.

Mir wurde versichert, dass das angeforderte Debugging in den Debug-Treibern standardmäßig aktiviert ist (es hat den gleichen Effekt wie options bcrmfmac debug=0x100000 ), aber Sie können gerne mit verschiedenen Werten experimentieren.

Mir ist keine Möglichkeit bekannt, die Verfügbarkeit eines Verbandes zu messen, außer häufig abzufragen und zu hoffen, eine Änderung zu erkennen.

Ein Cypress-Mitarbeiter kennt diesen Thread, aber schreiben Sie mir eine E-Mail (phil at raspberrypi dot org), wenn Sie gerne direkt kontaktiert werden.

Hallo,

Gibt es Fortschritte in diesem Bereich? Ich kann eine Verbindung zu meinem offenen Wi-Fi-Netzwerk herstellen und habe dies nach einer zufälligen Zeit in meinen Protokollen:

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

Und dann kann ich den Router nicht anpingen.

Nach einem ifdown wlan0 && ifup wlan0 funktioniert es wieder, bis zum nächsten wlan0: carrier lost .

Die Energieverwaltung ist deaktiviert, Bluetooth ist deaktiviert, Roaming ist deaktiviert (wie Sie vorgeschlagen haben) und meine Version ist Linux pi3 4.4.17-v7+ .

Es ist immer passiert, wenn Bridge Eth0 mit WLAN0 verbunden ist. Ich habe das gleiche Problem wie https://github.com/raspberrypi/linux/issues/1375

Ich habe genau das gleiche Problem mit Pi3 Onboard WiFi, das nach einer zufälligen Zeitspanne ausfällt. ifup bringt es wieder zum Laufen kein Problem.

Nach eingehender Untersuchung stellte ich fest, dass drei APs (BSSIDs) mit einer SSID (jeweils 1 auf Kanal 1, 6 und 11) vorhanden waren. Dieses Setup unterstützt nahtloses Roaming und funktioniert perfekt mit allen anderen WLAN-Clients.

Das Aktivieren des Debuggens / Protokollierens mit dem Standardtreiber scheint zu zeigen, dass der Pi irgendwann beschließt, eine der BSSIDs zu deaktivieren und sogar auf eine schwarze Liste zu setzen. Der Grund ist unklar, scheint aber eine Entscheidung zu sein, die am Ende des Pi getroffen wurde.

Wenn ich genau die gleiche Konfiguration auf dem Pi habe, aber nur eine BSSID für die SSID habe, kann Pi tagelang ohne Probleme durchhalten.

Leider ist das Deaktivieren des Roamings gemäß dem Pelwell-Link (http://projectable.me/optimize-my-pi-wi-fi/) nicht wirklich möglich, da nur eine BSSID pro SSID keine Option ist, und ich würde Sie müssen sich lieber nicht auf ein Skript verlassen, das einen Host anpingt und dann ifdown / ifup ausführt.

Werden weitere Untersuchungen zur Unterstützung mehrerer BSSIDs pro SSID durchgeführt, oder kann ich etwas spezielles tun, um die Untersuchung zu unterstützen?

Vielen Dank!

Ich habe dieses Problem und mein Netzwerk ähnelt dem von @TheOriginalMrWolf .
Ich habe eine Apple-Basisstation und einen Airport Express in einer Mesh-Konfiguration mit WDS.

Ich habe auch dieses Problem. Wenn ich Dateien auf eine Samba-Freigabe kopiere, geht die WLAN-Verbindung verloren (Himbeere 3, neu installiertes Raspbian).
Syslog:
brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012

Ich bekomme genau das gleiche Problem, wenn ich Musik mit upnp (gmediarender) spiele.

Ich habe das gleiche Problem beim Starten von Sprachanrufen über Wechat, wobei das RPI als AP Hostapd verwendet. Ich bekomme so eine Menge Spam:

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

Mit Spuren wie diesen:

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

Die Spur ähnelt verdächtig der von @jrmhaig .

Ich hatte dies gerade wieder passiert und habe einige Debugging durchgeführt. Diesmal habe ich verschiedene Nachrichten erhalten, die interessant erscheinen (anscheinend handelt es sich um dieselben Nachrichten, die @maciex einmal erhalten hat):

[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. Es sieht so aus, als ob das gesamte System einfriert, wenn dies passiert. Das Ausführen von while sleep 1; do date; done in einer Schleife führt zu einer Lücke, wenn das Einfrieren auftritt. Ich frage mich, ob dies bedeutet, dass brcmf_proto_bcdc_msg, das -110 (Timeout) zurückgibt, nur ein Symptom für das eigentliche Problem ist - es protokolliert nur, wo immer wir einfrieren.
2. Ich habe (mit vcgencmd ) die Temperatur und die Spannungen zum Zeitpunkt des Einfrierens gemessen. Soweit ich das beurteilen kann, gibt es dort nichts zu berichten.
3. Mein System ist ein AP mit Weiterleitung an ein ZTE 4G-Modem über USB (dh client -> wlan0 -> rpi -> usb0 -> 4g . Es scheint, dass usb0 immer noch auf das Internet zugreifen kann, wenn das WLAN einfriert.

Betreff: Die obigen Kommentare, dies geschieht im NAT-Freigabemodus für mich mit roamoff=1 . Keiner von beiden hat das Problem für mich behoben oder gemildert.

Nach dem Deaktivieren von WPA (in meinem Fall mit create_ap -w 2 , um nur WPA2 zu aktivieren) scheint das Problem behoben zu sein. Unklar warum.

Ich bin auch mit den hier gemeldeten Problemen konfrontiert. In meinem Fall geschieht dies immer dann, wenn ich über Samba über den Samsung + ES-Dateimanager und -Player auf Dateien (normalerweise MP3) zugreife.

Mein Himbeer-Pi3 ist über WLAN mit meinem AP verbunden. Daher wird die gesamte Kommunikation mit ihm als WLAN-Netzwerk angesehen. Es hat weder einen Monitor noch eine Tastatur oder eine Maus.

Ich kann den Fehler leicht reproduzieren. Wenn also jemand möchte, dass ich Protokolldateien erstelle, lassen Sie mich wissen, wie ich helfen kann.

Unter meinen Syslog-Einträgen.

27. Dezember 16:11:50 Himbeerpi-Kernel: [560.902063] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
27. Dezember 16:11:52 Himbeerpi-Kernel: [562.928930] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
27. Dezember 16:11:54 Himbeerpi-Kernel: [564.926659] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
27. Dezember 16:11:54 Himbeerpi-Kernel: [564.926820] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO fehlgeschlagen, -52
27. Dezember 16:11:56 Himbeerpi-Kernel: [566.924560] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
27. Dezember 16:11:58 Himbeerpi-Kernel: [568.922555] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
27. Dezember 16:11:58 Himbeerpi-Kernel: [568.928073] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO fehlgeschlagen, -52
27. Dezember 16:12:00 Himbeerpi-Kernel: [570.920675] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
27. Dezember 16:12:02 Himbeerpi-Kernel: [572.918980] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
27. Dezember 16:12:02 Himbeerpi-Kernel: [572.924580] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO fehlgeschlagen, -52
27. Dezember 16:12:04 Himbeerpi-Kernel: [574.917259] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
27. Dezember 16:12:06 Himbeerpi-Kernel: [576.915703] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
27. Dezember 16:12:06 Himbeerpi-Kernel: [576.921498] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO fehlgeschlagen, -52
27. Dezember 16:12:06 raspberrypi ifplugd (wlan0) [1149]: Erkennungsmodus verwenden: IFF_RUNNING

@rcassaniga
Ich hatte auch das gleiche Problem mit dem identischen Setup.

Lösung nach stundenlangem Debuggen:
Deaktivieren Sie IPv6 auf der Himbeere in /etc/modprobe.d/ipv6.conf:
Alias ​​net-pf-10 aus
alias ipv6 aus
Optionen ipv6 disable_ipv6 = 1

Dies ist nur eine Problemumgehung, wenn Sie IPv6 in Ihrem Netzwerk nicht verwenden.

Danke @ varl0g du bist mein Held! :) :)
Sieht so aus, als würde diese Problemumgehung für mich funktionieren. Ich kann das Problem nicht mehr reproduzieren.

@ varl0g : Die

Danke und ein frohes 2017.

Ich habe versucht, IPv6 auszuschalten. Das machte keinen Unterschied. Ich habe versucht, den Energiesparmodus auszuschalten. Immer noch kein Unterschied. Wenn ich jedoch den Kanal meines AP auf 6 (statt 11) stelle, ist mein Raspberry Pi seit 2 Tagen ohne Probleme aktiv!

Ich möchte bestätigen, dass die Problemumgehung beim Deaktivieren von IPv6 nicht funktioniert.
Leider habe ich das gleiche Problem mit meinem RPi3- und Apple Airport Extreme-Router.

@rajid , @ dh-connect
Überraschenderweise löste es auch mein Problem, als ich den WLAN-Kanal meines AP auf 6 anstatt auf automatisch geändert habe, danke @rajid

Ich habe auch diesen Fehler - brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
Wo beheben ????
Ich versuche 4.9 Kernel, 4.4.41 Kernel - alle haben diesen Fehler. Stromversorgung 2.4a.

Ich muss meinen vorherigen Kommentar zu Kanal 6 widerrufen. Anscheinend war es ein Zufall, dass mein RPI3 6 Tage lang über stabiles WLAN verfügte.

Ich frage mich nur, ob jemand mit diesem Problem Glück gehabt hat. Ich habe versucht, Energieverwaltung, Bluetooth und Kanalwechsel zu deaktivieren. Bisher hat nichts funktioniert. Ich verwende Octoprint mit einer angeschlossenen Webcam. Es scheint ziemlich oft zu passieren, und ich stelle fest, dass es viel häufiger passiert, wenn ich mehr als eine http-Verbindung hergestellt habe.
Syslog-Fehler vor dem Energiesparmodus:
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
Syslog-Fehler nach dem Energiesparmodus:
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 !!!
Ich verwende derzeit Linux octopi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

Ich habe endlich mein RaspPi 3 auf meinem WLAN stabil gemacht, indem ich den 2,4-GHz-Kanal meines WLANs auf "6" geändert habe. Ich habe vergessen, was es vorher war, 11 ich denke, aber ich bin nicht sicher. Das hat nicht gut funktioniert und ich habe eine Webseite gefunden, auf der stand, dass dies ein Problem war, aber 6 funktioniert einwandfrei. Es ist viel besser gewesen, seit ich mein Haus-WLAN auf Kanal 6 umgestellt habe.

/ raj

Am 3. März 2017 um 20:39 Uhr schrieb Daniel < [email protected] [email protected] >:

Ich frage mich nur, ob jemand mit diesem Problem Glück gehabt hat. Ich habe versucht, Energieverwaltung, Bluetooth und Kanalwechsel zu deaktivieren. Bisher hat nichts funktioniert. Ich verwende Octoprint mit einer angeschlossenen Webcam. Es scheint ziemlich oft zu passieren, und ich stelle fest, dass es viel häufiger passiert, wenn ich mehr als eine http-Verbindung hergestellt habe.
Syslog-Fehler vor dem Energiesparmodus:
brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
Syslog-Fehler nach dem Energiesparmodus:
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 !!!
Ich verwende derzeit Linux octopi 4.1.19-v7 + # 858 SMP Di Mar 15 15:56:00 GMT 2016 armv7l GNU / Linux

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-284126948 an oder schalten Sie den Thread https://github.com/notifications/unsubscribe-auth/AFAlZVD- stumm

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

Kanal 6, Kanalbreite 20 MHz, sieht seit Wochen stabil aus.

Ich hatte das gleiche Problem beobachtet, das gemeldet wurde, dh es wurde der Fehler -52 Protokollzeilen angezeigt. Das Ausschalten der Energieeinsparung für die WLAN-Schnittstelle hat nicht geholfen. Das Deaktivieren von ipv6, wie von @ varl0g vorgeschlagen, löste meine Probleme. Wifi ist jetzt tagelang stabil, während es früher Minuten nach dem Start ausfiel.

Ich habe auf Kanal 6 oder 7 kein Glück gehabt. Ich habe niemanden auf diesen Kanälen bestätigt.
Ich habe versucht, meine SD mit einem neuen Image zu flashen, und jetzt erhalten meine WLAN-Controller keine ordnungsgemäßen DHCP-Leases. Sie starten mit 169.254.xx.xx lokalen IPs, nicht mit dem Subnetz von meinem DHCP-Server.

Beschlossen, es einfach zu löschen und das neueste Raspbian zu installieren und Octoprint von der Quelle zu installieren. Bisher keine Probleme.

Soweit ich das beurteilen kann, ist dies ein Problem in der Treibersoftware von brcm80211 sdio.c.
Die Zeichenfolge 0x40012 ist wirklich 0x00040012, die bei Interpretation mit den Masken und Codes von hier ~ Zeile 55 als Postfachzeichenfolge angesehen werden kann, die eine Änderung der Flusssteuerung in DEVREADY anzeigt. Was seltsam ist, ist, dass die Zeichenfolge niemals als solche interpretiert wird und somit den abwärtskompatiblen Abschnitt der Treiberzeile 1127 der Datei sdio.c in der Quelle brcm80211 / brcmfmac hier trifft.

Ich habe weder großartige Erfahrungen mit dem Treiber selbst noch mit der Fähigkeit zum Neukompilieren und Testen (ich habe nur ein RPI3, und ich möchte die Umgebung, in der es derzeit lebt, lieber nicht durcheinander bringen. Ich bin nicht mit dem Neukompilieren / Aktualisieren von Linux-Treibern vertraut.) Ich bin also nicht gerade sicher, aber es scheint, dass zwei HMB-Nachrichten so schnell hintereinander gesendet werden, dass der Treiber nicht genug Zeit hat, beide zu interpretieren .

Für diejenigen, die sich fragen, verwende ich derzeit Octoprint (manuell erstellt) auf meinem RPI3 über WLAN (duh ..) mit dem kapazitiven Adafruit Pitft2.8 "-Touchscreen und dem benutzerdefinierten Kernel von Adafruit (v 4.4.27-v7 +) und dupliziere das Problem, wenn Ich versuche, über PrintDroid Pro oder Chrome auf den Videostream (Logitech C270) auf meinem Samsung Galaxy S7 zuzugreifen. Die Sperrung erfolgt jedes Mal ohne Fehler und nur über WLAN. Ich habe das Netzteil aktualisiert, IPv6 deaktiviert und Energieverwaltung, ohne Erfolg.

@TGYK Können Sie sich das Problem

@TGYK. Sie haben auf die ursprüngliche Broadcom-Github-Seite verlinkt. Können Sie hier einen Hinweis geben, wo die Probleme im Raspberry Pi-Kernelbaum auftreten? Es ist etwas schwierig festzustellen, auf welche Codezeilen Sie sich beziehen.

sdio.c befindet sich hier im 4.9-Baum https://github.com/raspberrypi/linux/tree/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac.

@ JamesH65 Auf der von Ihnen verlinkten Github-Seite liegt die Zeile, auf die ich mich beziehe, zwischen
"Unbekannter Postfachdateninhalt: 0x40012", gefolgt von Escan-Fehlern (-52).

Das gleiche Problem wie bei Ihrem referenzierten Thema tritt nicht auf, da ich meine drahtlosen und kabelgebundenen Schnittstellen in keiner Weise überbrücke. Soweit ich das beurteilen kann, betrifft mein Problem und das dieses Threads ausschließlich die drahtlose Schnittstelle.

Danke für die Auskunft. Das möglicherweise damit verbundene Problem ist meines Erachtens insofern ähnlich, als es ein Problem ist, bei dem der Wifi-Treiber möglicherweise eine seltsame Nachricht erhält, die später im Stapel mehr Seltsamkeit verursacht, aber ich grabe immer noch.

Ich habe das gleiche Problem mit einem Himbeer-Pi Zero W mit einem ähnlichen Symptom wie @TGYK. In meinem Fall starte ich mpd auf Null und steuere es über einen Android-Client auf einem Samsung Galaxy S5. Wenn ich das Telefon in den Standby-Modus versetze, während die Controller-App ausgeführt wird (dh ohne zuerst zum Startbildschirm zurückzukehren), wird das WLAN der Null mit der Meldung "Unbekannter Postfachdateninhalt" unterbrochen. Wenn ich das Gerät nur im Leerlauf lasse oder die App immer schließe, bevor ich mein Telefon in den Ruhezustand versetze, bleibt es unbegrenzt aktiv.

Ich hatte dieses Problem bei Raspian und jetzt bei OSMC.

Meistens zeitweise, aber interessanterweise wird der Zugriff auf die Kodi-Weboberfläche von meiner S7 aus immer dieses Problem auslösen. Dasselbe vom iPhone meiner Frau aus zu tun, funktioniert einwandfrei und hat das Problem nie ausgelöst.

@daedalia : Ich habe ein sehr ähnliches Problem mit einem Samsung Galaxy Tab S. Ich habe jedoch keinen Zugriff auf ein iPhone / iPad-Gerät, um zu bestätigen ...

Mein Samsung-Gerät stürzt beim Versuch, auf die tvheadend-Weboberfläche zuzugreifen, das WLAN ab.

Dies geschieht nicht, wenn über einen Firefox-Browser von einem Windows-PC aus darauf zugegriffen wird.

Ich bin froh, dass ich diesen Thread gefunden habe und dachte, ich wäre der einzige. Ich habe die gleichen Probleme wie auf den oben genannten Postern. Beim Zugriff auf ein Samsung Galaxy Tab A fällt auf meinem pi3 / osmc WLAN aus. Funktioniert einwandfrei, wenn auf das Nexus 7-Tablet, das OnePlus-Telefon oder den Acer-Laptop zugegriffen wird. Nur das Samsung gibt Probleme. Leicht wiederholbar. Scheint der Samsung WLAN-Treiber zu sein, der das eingebaute pi3-WLAN nicht mag? Das Hinzufügen eines TP-Link-WLAN-Dongles zum pi3 ist eine Problemumgehung für mich.

@philborman Ich bin neugierig, verwenden Sie den gleichen mobilen Browser auf dem Samsung vs dem Nexus?

Beide laufen mit Chrome, aber es ist nicht nur ein Browserproblem. Wenn ich Yatse dazu benutze
Steuerkodi es funktioniert gut vom Nexus / Handy / Laptop, aber pi3 WiFi fällt
wenn ich das gleiche aus dem samsung versuche. Das gleiche gilt, wenn ich ssh in, stürzt mit Samsung ab
und nicht die anderen. Mit ssh kann ich ein wenig machen, aber jede Datei überträgt oder
Selbst das Bearbeiten einer Textdatei führt dazu, dass das WLAN getrennt wird.

Am Mittwoch, den 12. April 2017 um 19:03 Uhr schrieb Mathieu Gouin, [email protected] :

@philborman https://github.com/philborman Ich bin neugierig, verwenden Sie die
gleicher mobiler Browser auf dem Samsung gegen das Nexus?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-293643847 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ALmHOdtJ9AQtpfU7tmeVouI-a4STg2WMks5rvQPJgaJpZM4HupC5
.

Hat jemand, der hier kommentiert, die Möglichkeit, einen Kernel mit einem Patch zu erstellen, der mir dabei helfen könnte? Diese basieren auf 4.9, funktionieren aber möglicherweise unter 4.4. Beachten Sie, dies sind nur 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);

Hallo,

Ich habe das gleiche Problem, das hier mit einem meiner 2 Pi3 beschrieben wurde. Wifi verliert nach einiger Zeit die Verbindung, kann zwischen 30 Minuten und einigen Stunden liegen. Ich habe absolut alles versucht, was hier vorgeschlagen wurde, einschließlich des Wechsels der WLAN-Kanäle auf dem AP usw., ohne Erfolg. Was äußerst seltsam ist, ist, dass auf meinem 2. Pi3 (auch Version 1.2, genau das gleiche) und mit der gleichen SD-Karte / Installation (Raspbian), die ich zwischen beiden austausche ,

Das ist wirklich seltsam. Beide Pi3 werden mit RPI-Update, Kernel 4.9 und Firmware # 991 aktualisiert, aber es war bereits das gleiche mit früheren Kernel / Firmware-Versionen.

Wenn Sie ein RPI-Update durchführen, erhalten Sie die oben genannten Patches, die von den Kernel-Entwicklern akzeptiert wurden - dies gilt für den smsc9x-Treiber und den brcmfmac-Treiber ab letzter Nacht. Könnten Sie das versuchen? Wenn dies immer noch fehlschlägt, können Sie dann 'dmesg' ausführen und prüfen, ob das Syslog etwas Seltsames enthält? Obwohl mein Verdacht vielleicht ein HW-Fehler ist, der offensichtlich wird, wenn sich der drahtlose Chip erwärmt, da ein anderer Pi mit derselben Karte einwandfrei funktioniert.

Vielen Dank. Ich habe das auf der verdächtigen Tafel gemacht, WLAN nach ein paar Minuten getrennt.
dmesg gibt das:
``
[266.654964] brcmfmac: brcmf_sdio_bus_sleep: Fehler beim Ändern des Busschlafzustands -110
[266.655033] brcmfmac: brcmf_sdio_txfail: sdio-Fehler, Befehl abbrechen und Frame beenden
[266.659215] brcmfmac: brcmf_sdiod_regrw_helper: Daten F1 @ 0x1000d konnten nicht geschrieben werden , err: -110
[266.663346] brcmfmac: brcmf_sdiod_regrw_helper: Daten F1 @ 0x1001a konnten nicht gelesen werden, err: -110
[266.667472] brcmfmac: brcmf_sdiod_regrw_helper: Daten F1 @ 0x10019 konnten nicht gelesen werden, err: -110
[266.671608] brcmfmac: brcmf_sdiod_regrw_helper: Daten F1 @ 0x1001a konnten nicht gelesen werden, err: -110
[266.675736] brcmfmac: brcmf_sdiod_regrw_helper: Daten F1 @ 0x10019 konnten nicht gelesen werden, err: -110
[266.679866] brcmfmac: brcmf_sdiod_regrw_helper: Daten F1 @ 0x1001a konnten nicht gelesen werden, err: -110
[266.683992] brcmfmac: brcmf_sdiod_regrw_helper: Daten F1 @ 0x10019 konnten nicht gelesen werden, err: -110
[269.655049] brcmfmac: brcmf_sdio_bus_sleep: Fehler beim Ändern des Busruhezustands -110
[272.069378] net_ratelimit: 35 Rückrufe unterdrückt

......... dann füllt diese "Schleife" das dmesg-Protokoll mehrmals pro Minute.

Bearbeiten: Ich habe alle Komponenten auf der Platine berührt, sie sind alles andere als heiß, ich würde sagen um 30 °, nur ein wenig wärmer als meine Fingerhaut.

Hmm, das SDIO-Zeug ist die Schnittstelle zwischen dem Pi und dem drahtlosen Chip - es läuft ab (-110). Dies sieht nach einem HW-Problem aus - während sich der Chip erwärmt, befindet sich möglicherweise irgendwo eine schlechte Lötstelle auf den SDIO-Schnittstellenleitungen, was bedeutet, dass die Kommunikation unterbrochen wird.

Ping @ Roger-Thornton - Roger, können wir etwas tun, um dies zu testen?

@Crrispy Kannst du überprüfen, ob dein Pi nicht vcgencmd get_throttled ?

@pelwell : Nach einem WLAN-Verlust habe ich überprüft und gedrosselt = 0x0

Ich denke nicht, dass es ein Hardwarefehler ist, ein einfacher Neustart löst das Problem immer sofort.

@ JamesH65 Ich denke nicht, dass dies wie ein Problem bei der Hardwareherstellung aussieht, da alle Leitungen so funktionieren, wie sie sein sollten. Wenn es andere Hinweise auf Hardwareprobleme gibt, kann ich einen Blick auf die Platine werfen.

Scheint nicht das gleiche Problem zu sein wie ich. Ich habe nur einen pi3 und es ist
WiFi ist absolut stabil, bis ich eine Verbindung von einem Samsung-Tablet herstelle. Verbinden mit
alles andere und es ist in Ordnung. Scheint nicht Strom oder Überhitzung zu sein
verwandt, da es tagelang absolut in Ordnung ist, bis ich mich vom Falschen verbinde
Tablette und es fällt um.

Ich vermute, es ist Treiber oder Firmware bezogen, etwas, das der Samsung
Treiber sendet, dass der pi3 nicht mag.

Am Do, 27. April 2017, 22:01 Uhr Crrispy, [email protected] schrieb:

@pelwell https://github.com/pelwell : Nach einem WLAN-Verlust habe ich überprüft, und
gedrosselt = 0x0

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297823068 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5
.

Im neuesten Raspbian wurden einige Korrekturen für das Networking vorgenommen -
Wann haben Sie das letzte Mal eine

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

?
Könnte einen Versuch wert sein, um zu sehen, ob es Dinge behebt.

Am 28. April 2017 um 14:38 schrieb philborman [email protected] :

Scheint nicht das gleiche Problem zu sein wie ich. Ich habe nur einen pi3 und es ist
WiFi ist absolut stabil, bis ich eine Verbindung von einem Samsung-Tablet herstelle. Verbinden mit
alles andere und es ist in Ordnung. Scheint nicht Strom oder Überhitzung zu sein
verwandt, da es tagelang absolut in Ordnung ist, bis ich mich vom Falschen verbinde
Tablette und es fällt um.

Ich vermute, es ist Treiber oder Firmware bezogen, etwas, das der Samsung
Treiber sendet, dass der pi3 nicht mag.

Am Do, 27. April 2017, 22:01 Uhr Crrispy, [email protected] schrieb:

@pelwell https://github.com/pelwell : Nach einem WLAN-Verlust habe ich überprüft,
und
gedrosselt = 0x0

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
oder schalten Sie den Thread stumm
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHag08r5c96nB39R3F-mFW772qBbGks5r0evJgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Ich habe das gleiche Problem mit Raspbery Pi Zero W. Nach einiger Zeit bin ich nicht in der Lage, es zu ssh. Ich habe alles versucht. Eine lustige Tatsache ist ... als ich rpi an meinen Fernseher angeschlossen habe, um Fehler zu beheben, nachdem ich nicht in der Lage bin, es zu ssh ... es funktionierte für 18 Stunden absolut solide. Dann habe ich hdmi auf ein anderes Gerät umgestellt und nach einiger Zeit, als ich ssh auf pi setzen wollte, bekam ich wunderschöne Informationen "Keine Route zum Hosting". Als ich das HDMI-Kabel wieder anschloss, konnte ich das Gateway anpingen. Kein Fehler in den Protokollen, iwconfig scheint in Ordnung zu sein. Systemctl Neustart Netzwerk geholfen.

Probieren Sie wie oben das neueste Raspbian aus und melden Sie sich zurück, wenn Sie es noch sehen
das Problem.

Am 28. April 2017 um 19:30 schrieb frankja2 [email protected] :

Ich habe das gleiche Problem mit Raspbery Pi Zero W. Nach einiger Zeit bin ich nicht
in der Lage, es zu ssh. Ich habe alles versucht. Eine lustige Tatsache ist ... als ich mich verbunden habe
rpi an meinen Fernseher, um Fehler zu beheben, nachdem ich nicht in der Lage bin, ssh zu
es ... es funktionierte für 18h steinhart. Dann habe ich HDMI gegen andere ausgetauscht
Gerät und nach einiger Zeit, als ich zu pi ssh wollte, wurde ich schön "nein
route to host "info. Als ich das HDMI-Kabel wieder anschloss, konnte ich pingen
Tor. Systemctl Neustart Netzwerk geholfen.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Ich bin vielleicht der einzige, der das Problem nicht lösen kann, aber ich habe festgestellt, dass in meiner wpa_supplicant.conf der Ländercode falsch eingestellt ist (es wurde übersehen, dass es sich um ein von den anderen Lokalisierungsoptionen getrenntes Konfigurationselement handelt). Ich werde nicht sagen, dass das Problem vollständig verschwunden ist, aber als ich das behoben habe, hat es aufgehört, seine Netzwerkverbindung so zu verlieren, wie es vorher war.

Gerade auf das neueste aktualisiert (apt-get dist-upgrade) und es sieht hoffnungsvoll aus.
Mein vorheriges Upgrade war vor ungefähr 2 Wochen, kurz bevor ich das gemeldet habe
anfängliche Probleme. Funktioniert gut für die letzten paar Stunden, kein WiFi
Aussetzer überhaupt. Danke vielmals!

Am 28.04.17 um 15:53 ​​schrieb James Hughes:

Im neuesten Raspbian wurden einige Korrekturen für das Networking vorgenommen -
Wann haben Sie das letzte Mal eine

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

?
Könnte einen Versuch wert sein, um zu sehen, ob es Dinge behebt.

Am 28. April 2017 um 14:38 schrieb philborman [email protected] :

Scheint nicht das gleiche Problem zu sein wie ich. Ich habe nur einen pi3 und
es ist
WiFi ist absolut stabil, bis ich eine Verbindung von einem Samsung-Tablet herstelle. Verbinden mit
alles andere und es ist in Ordnung. Scheint nicht Strom oder Überhitzung zu sein
verwandt, da es tagelang absolut in Ordnung ist, bis ich mich vom Falschen verbinde
Tablette und es fällt um.

Ich vermute, es ist Treiber oder Firmware bezogen, etwas, das der Samsung
Treiber sendet, dass der pi3 nicht mag.

Am Do, 27. April 2017, 22:01 Uhr Crrispy, [email protected] schrieb:

@pelwell https://github.com/pelwell : Nach einem WLAN-Verlust habe ich überprüft,
und
gedrosselt = 0x0

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an

< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
oder schalten Sie den Thread stumm
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an

https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
oder schalten Sie den Thread stumm

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

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298003537 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ALmHORKJxKdws0fMKU5tpfoJHJSah0Ffks5r0e9FgaJpZM4HupC5 .

Es ist für mich in der neuesten Version behoben.

Die meisten anderen "Korrekturen" scheinen den Punkt zu verfehlen, an dem mein System funktioniert hat
perfekt mit allem außer einem Tablet (Samsung) so scheint es das
problem war das samsung etwas den pi3 wifi treiber / firmware zu senden
konnte nicht damit umgehen.

Wenn mein Ländercode falsch eingestellt war, warum sollte nur das Samsung verursachen
Probleme. Andere Tablets / Telefone / Laptops lassen sich problemlos verbinden.

Wie auch immer, es ist jetzt behoben - zumindest ist es in den letzten paar Jahren nicht umgefallen
Std. Mehr Zeit wird es zeigen ...

Am 28/04/17 21:09 schrieb rraszews:
>

Ich bin vielleicht der einzige, der genug Kopf hat, um das Problem zu lösen, aber
Ich habe festgestellt, dass für meine wpa_supplicant.conf der Ländercode festgelegt wurde
falsch (Es wurde übersehen, dass es sich um ein vom anderen getrenntes Konfigurationselement handelt
Lokalisierungsoptionen). Ich werde nicht sagen, dass das Problem verschwunden ist
ganz, aber als ich das behoben hatte, hörte es auf, sein Netzwerk zu verlieren
Verbindung in der "jedes Mal, wenn ich von meinem Samsung aus verbinden" Weise es
war vorher.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298082370 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ALmHOWtM-_MXCz5RoQd8XShI4Mk-4LAyks5r0jlUgaJpZM4HupC5 .

In meinem Fall dauert es ungefähr 19 Stunden. Danach konnte ich nicht mehr ssh ...

Was ist der Unterschied zwischen RPI-Update und Dist-Upgrade?

Weil ich nach dem RPI-Update 4.9.25+ # 995 hatte und dann dist-upgrade und Kernel auf 4.9.24+ # 993 zurückgesetzt habe. Jedenfalls ist das Problem für mich immer noch nicht behoben. Dieses Mal habe ich ein anderes rpi0w und ein anderes Netzteil verwendet :) Der letzte Schritt ist die Verwendung einer anderen SD-Karte.

Ok danke für die Information.

Sie benötigen weitere Informationen, um zu versuchen, zu replizieren. Dein Setup, was
Sie haben eine Verbindung hergestellt und die Art des Netzwerkverkehrs läuft, alle dmesg-Protokolle
oder andere Fehlermeldungen, sobald der sh nicht mehr funktioniert.

Vielen Dank.

Am 29. April 2017 um 16:16 schrieb franko [email protected] :

In meinem Fall dauert es ungefähr 19 Stunden. Danach konnte ich nicht mehr ssh ...

Was ist der Unterschied zwischen RPI-Update und Dist-Upgrade?

Denn nach dem RPI-Update hatte ich 4.9.25+ # 995
https://github.com/raspberrypi/linux/pull/995 und dann habe ich gemacht
dist-upgrade und Kernel wurden auf 4.9.24+ # 993 zurückgesetzt
https://github.com/raspberrypi/linux/pull/993 . Jedenfalls ist für mich das Problem
immer noch nicht behoben.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298175041 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHQR8cadrEhb55YJj5PV6PP_odmJmks5r01RJgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Hallo,

Ich habe den Pi3 in ein Gehäuse mit einem ziemlich starken Lüfter gestellt und die Temperatur im Raum beträgt derzeit 19 ° C, sodass es kein Hitzeproblem sein kann. Tauschen Sie das Netzteil gegen ein anderes aus (5V 3A auch). Verwenden Sie eine andere SD-Karte, dist-Upgrade und dann RPI-Update.
Gestern war es mehrere Stunden lang in Betrieb, ich hoffte, dass es repariert wurde, aber nach 3-4 Stunden wurde die Verbindung getrennt (Ping-t lief von meiner Windoze-Maschine).
Heute Morgen erneut versucht, WLAN nach weniger als 20 Minuten ausgefallen :-(
Immer noch der -110-Fehler des WLAN-Treibers auf SDIO (siehe oben), der sich bis zum Neustart in einer Schleife wiederholt.
Und mein anderer Pi3 ist seit 3-4 Tagen verbunden, kein Problem.
Dies könnte also als Hardwarefehler aussehen. Aber .. warum scheitert es nie beim Booten und funktioniert immer nach einem Neustart? Wirklich rätselhaft.
Warum wird versucht, den "Bus-Ruhezustand" zu ändern, da die Energieverwaltung für wlan0 deaktiviert ist? (Entschuldigung, wenn die Frage dumm ist).

gerade gemacht apt-get update; apt-get dist-upgrade . Leider keine Änderungen für mich. Nach meiner Beobachtung bezieht sich das Problem auf die Überbrückung von wlan0 fragt sich, ob es mit dem Promiscuous-Modus zusammenhängen könnte. Habe auch rpi-update müde, um 4.9.25 zu überprüfen

Tatsächlich ist es sogar noch schlimmer als zuvor, da die Verbindung jetzt normalerweise in wenigen Minuten unterbrochen wird und ich die üblichen Protokolle sehen kann

[  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

"Weil ich nach dem RPI-Update 4.9.25+ # 995 hatte und dann dist-upgrade und Kernel auf 4.9.24+ # 993 zurückgesetzt habe."

Das ist seltsam. Ich habe das dist-Upgrade durchgeführt, bin zu 4.9.24+ # 993 gegangen und wenn ich gerade ein RPI-Update mache, heißt es, dass ich bereits die neueste Firmware habe und es nichts zu tun hat ... warum aktualisiert es nicht auf 4.9.25 / # 995?

Eigentlich muss man sagen, dass die Verwendung von brcmfmac/wlan0 Bridged stabiler zu funktionieren scheint als mit reinem wlan0 (alle mit Hostapd).

Können Sie also eine vollständige und genaue Beschreibung Ihres Setups zusammen mit geben?
Arten verbundener Geräte und eventuell erhaltene dmesg-Fehlermeldungen
wenn das WLAN ausfällt.

Ich brauche wirklich eine Möglichkeit, das Problem zu replizieren, die nicht Stunden dauert
Alle Informationen, die dazu beitragen können, werden dankbar angenommen.

Am 1. Mai 2017 um 17:27 schrieb Szymon Stasik [email protected] :

Eigentlich muss ich sagen, dass die Verwendung von brcmfmac / wlan0 Bridged mehr zu funktionieren scheint
stabiler als mit reinem wlan0 (alle mit hostapd)

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Ich weiß nicht, ob dies speziell mit diesem Aspekt des Problems zusammenhängt, aber IIRC Ich konnte einen Weg zum WLAN-Löschen mit einem hcitool-Befehl vollständig reproduzieren. Vielleicht ist es nicht mehr möglich, es war wie vor einem Jahr und jetzt Wir gingen mit USB WiFi, um das Problem zu lösen, das für eine Reihe von RPIs funktionierte ...

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

@thomasf Wie war Ihr System-Setup (Standalone-Gerät, Access Point, Bridged Access Point usw.) und auf welchem ​​Computer führen Sie den Befehl hcitool aus? Ein schneller Test auf einem Gerät, das über WLAN an einen anderen Pi angeschlossen war, ergab keine Probleme.

@ JamesH65 Wir haben viele Szenarien durchlaufen und das Problem war in jeder Konfiguration reproduzierbar.

Wenn der Befehl hcitool auf einem RPI ausgeführt wurde, verlor er normalerweise innerhalb von Sekunden die (WLAN-) Netzwerkverbindung. IIRC Es war einfacher zu reproduzieren, wenn auf dem Gerät Netzwerkverkehr vorhanden war (wie bei einer Dateiübertragung).

Bei einem kurzen Blick auf unser endgültiges Bereitstellungssystem war das folgende wpa_supplicant.conf das letzte, das wir verwendet haben. Ich denke, es sieht nicht allzu anders aus als das, das Probleme mit der internen WLAN-Schnittstelle verursacht hat. Ich bin mir sicher, dass Wir haben angefangen, nur einen einzigen AP zu verwenden, während wir immer noch Probleme hatten.

(SSIDs und Schlüssel redigiert):

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

Ich habe gerade ein Skript namens troublemaker.sh im Provisioning-Repo gefunden.

Es ist sehr hackig, ich denke, ich habe es so bereitgestellt, dass es beim Start ausgeführt wird ~ wie etwa alle paar Minuten ~~ (Bearbeiten: wahrscheinlich nur einmal, da es selbst eine Schleife ausführt) auf einer Reihe von RPIs, um Probleme zu provozieren und einige Protokolle zu erhalten Gerettet..

Dies wurde hauptsächlich verwendet, bevor ich mehr über die Probleme verstanden habe. Ich denke, dass die Ping-Zeiten und der Paketverlust für einen Zeitraum anstiegen, bevor das WLAN vollständig getrennt wurde.

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

Das Ausführen des Unruhestifter-Skripts auf dem neuesten stabilen Raspbian (4.9-Kernel) zeigt keine Fehler an. Dies ist gut, aber schlecht, wenn versucht wird, Fehler zu replizieren!

@ciekawy Rückblickend scheinen Sie in der Lage zu sein, ein Problem, das wir hier nicht

@ JamesH65 , Mein aktuelles Setup ist:

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

auch wie bei 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

Es ist erwähnenswert, dass dieses RPI tagelang stabil lief (obwohl länger anhaltende 10-Mbit / s-Übertragungen auch einige Probleme verursachen konnten), als die Rollen gewechselt wurden und wlan0 brcmfmac verwendet wurde, um eine Verbindung zum Internet herzustellen, und der lokale AP auf wlan2 ath9k lief. Ich habe die Konfiguration geändert, da ich für den Internetzugang eine bessere Antenne verwenden muss, die mit wlan2 verbunden ist.

Mein letztes rpi-updated war am 1. Mai

Ich habe genau das gleiche Problem in rpi3 mit Archlinux-ARM.

Nach einigen Stunden, in denen create_ap ausgeführt wird, funktioniert es nicht mehr mit den dmesg-Nachrichten, die bereits von anderen gemeldet wurden:
[11418.347554] brcmfmac: send_key_to_dongle: wsec_key error (-110)

Manchmal funktioniert es 1 Tag ohne Probleme und manchmal Minuten, bevor das Problem auftritt.

Linux-Alarm 4.9.25-2-ARCH # 1 SMP Fr 5. Mai 00:46:52 UTC 2017 armv7l GNU / Linux

Gleiches Problem bei Pi Zero W, dem aktuellen Raspbian Lite. Nach einiger Zeit (unterscheidet sich von Minuten bis Stunden) wird "dmesg" angezeigt
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
Ab diesem Zeitpunkt ist die WLAN-Verbindung unterbrochen und kann nur durch rmmod'ing und modprob'ing brcmfmac neu gestartet werden.

Ich habe die Energieverwaltung deaktiviert: keine Änderung.
Ich habe alles über apt-get upgrade / dist-upgrade aktualisiert: keine Änderung
Ich habe Sachen per RPI-Update aktualisiert: keine Änderung

brcmfmac ist sicher fehlerhaft. Ich hatte das gleiche Problem mit der dmesg-Nachricht "brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012" und manchmal auch mit anderen Nachrichten, wie in meinem obigen Beitrag angegeben.

Ich verwende einen TP-Link-USB-WLAN-Adapter und meine Anwendung funktioniert jetzt einwandfrei.

Ich hoffe, Broadcom kann die Fehler in brcmfmac beheben.

Irgendeine Problemumgehung?

Wie ich bereits zu Beginn dieses Gesprächs erwähnt habe, habe ich meinen WLAN-Router so geändert, dass er Kanal 6 anstelle von 11 verwendet (den er zuvor verwendet hat), und mein rPi ist seitdem (von Januar bis heute) ohne Probleme aktiv alle.

Könnte dies mit diesem Kernelmodul zusammenhängen? Hinweis:

Diese Generation von Chips enthält unabhängig vom Fahrer zusätzliche behördliche Unterstützung. Die Geräte verwenden eine einzige weltweite Regelungsdomäne, wobei die Kanäle 12-14 (2,4-GHz-Band) und die Kanäle 52-64 und 100-140 (5-GHz-Band) auf den passiven Betrieb beschränkt sind. Die Übertragung auf diesen Kanälen wird unterdrückt, bis angemessener anderer Verkehr auf diesen Kanälen beobachtet wird. Innerhalb des Treibers verwenden wir den fiktiven Ländercode „X2“, um diese weltweite Regulierungsdomäne darzustellen. Derzeit gibt es keine Schnittstelle zum Konfigurieren einer anderen Domäne. Der Treiber liest den SROM-Ländercode vom Chip und übergibt ihn als regulatorischen Hinweis an mac80211. Diese Informationen werden jedoch ansonsten vom Treiber nicht verwendet.
(von hier: https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211)

Ich denke, dies bedeutet, dass sogar ein Ländercode "DE" (der die höheren WLAN-Kanäle zulassen sollte) keine Auswirkung hat? Ich bin mir jedoch nicht sicher, ob dies einen ähnlichen Effekt haben könnte wie das Problem Unknown mailbox data content: 0x40012 ...

Zumindest für mich ist es keine Problemumgehung - heute, 2 Stunden später, von Kanal 11 auf Kanal 6 umgestellt: Unknown mailbox data content: 0x40012

Ich hatte dieses Problem, bis ich die Signalstärke durch einen Range Extender erhöhte.
Könnten Sie testen, ob die Verbindung stabiler ist, indem Sie den Pi an einen Punkt mit besserem Signal bewegen?

Möglicherweise liegt dies an der zusätzlichen Leistung, die für den Betrieb bei schlechter Signalstärke erforderlich ist.

Gleiches Problem wie Crrispy.

Für diejenigen, die dies mit einem USB-WLAN-Adapter umgehen (Kanalwechsel usw. funktionierte auch bei mir nicht), funktionierte Edimax EW-7811Un sofort, als ich es an RPI Zero W an mein OTG-USB-Kabel anschloss. Sie müssen keine Konfiguration oder ifconfig vornehmen - es war sofort im Netzwerk! Gestern habe ich ein paar Stunden mit dem TP-Link Archer T1U AC450 herumgespielt.

@ b3nj1 - Entschuldigung, aber ich muss fragen --- warum ein externes WLAN mit einem Zero W verwenden? Richtig, Sie wissen, was das "w" bedeutet. lol :)

Ich entschied mich für die gleiche Lösung - kaufte einen USB-Adapter mit externer Antenne und mt7601-Chipsatz (ca. 5 Euro) für meinen Zero W, funktioniert einwandfrei. Sollte das Non-W überhaupt gekauft haben ... dieses Problem besteht seit mehr als einem Jahr und es ist keine Lösung in Sicht.

@blacktigersoftware - es ist seltsam, nicht

Ich habe einen kurzen Blick auf das oben beschriebene Maibox-Problem geworfen. Google zeigt, dass dies ein gutes Stück passiert (und mindestens ein Hinweis auf eine Nicht-Pi-Plattform). Der Treibercode erkennt, dass für eine Nachricht, die von der Mailbox zurückkommt (ich nehme eine Verbindung zur HW-Firmware an), einige Bits gesetzt sind, die sie nicht haben sollte. Es werden jedoch nur die Nachrichten gedruckt - keine Wiederherstellung oder Fehlerrückgabe. Da dies ein Wert zu sein scheint, der von der Firmware zurückgegeben wird, habe ich keinen Zugriff darauf, um tatsächlich zu sehen, was vor sich geht, und das Datenblatt auf dem Chip ist überhaupt nicht hilfreich. Daher denke ich, dass diese zur Untersuchung an Broadcom / Cypress / Linux-Wireless weitergeleitet werden müssen.

Erwähnenswert ist auch, dass wir anscheinend die neueste HW-Firmware gemäß https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm haben. Dateien haben ein oder zwei Byte Längenunterschiede, aber das war's.

Das Problem ist, dass auf den Postfachfehler weitere Fehler folgen (-52, -110 usw.) und nur das System neu gestartet wird, damit das WLAN wieder funktioniert.

-110 ist ein Timeout-Fehler, der darauf hinweist, dass etwas anderes stirbt und nicht reagiert. -52 ist ein ungültiger Austausch, der in die gleiche Richtung verläuft. Ich vermute, dass die Firmware auf dem Chip zu dem Zeitpunkt, zu dem der Postfachfehler aufgetreten ist, nicht mehr in Ordnung ist, sodass diese anderen Fehler weiterhin auftreten.

Ist jemand, der das Problem replizieren kann, in der Lage, den neuesten Pi-Dev-Kernel (4.11, erhältlich von unserem Github) zu erstellen und zu prüfen, ob der Postfachfehler weiterhin auftritt? Bevor ich anfange, Upstream zu pushen, möchte ich wissen, dass dies immer noch auf dem neuesten Kernel geschieht und ich es nicht replizieren konnte.

Ich kann bestätigen, dass das Problem auftritt in: Linux-Alarm 4.9.25-2-ARCH # 1 SMP Fr 5. Mai 00:46:52 UTC 2017 armv7l GNU / Linux

Ich habe nicht in Kernel 4.11 getestet

Der in meinen Tests verwendete Treiber: brcmfmac: Firmware-Version = wl0: 15. Dezember 2015 18:10:45 Version 7.45.41.23 (r606571) FWID 01-cc4eda9c

@ b3nj1 - wow, danke für das Heads-up

Alle - passiert das nur, wenn die GPU eingeschaltet ist?

Die GPU ist in allen Pi-Modellen immer (bis zu einem gewissen Grad) eingeschaltet.

Meinst du, wenn Bluetooth eingeschaltet ist?

@ JamesH65 - Ich werde 4.11 versuchen. Klone / baue ich nur wie folgt? Wenn ich nach diesen Anweisungen klone, bin ich auf dem Zweig rpi-4.9.y. Sollte ich stattdessen rpi-4.11.y oder etwas anderes auschecken?

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

Danke im Voraus

Überprüfen Sie den Zweig rpi-4.11.y und erstellen Sie ihn anhand der Anweisungen neu
habe verlinkt mit.

Am 25. Mai 2017 um 05:02 schrieb b3nj1 [email protected] :

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

• Ich werde 4.11 ausprobieren. Klone / baue ich nur wie folgt?
  Beim Klonen bin ich auf dem Zweig rpi-4.9.y. Soll ich auschecken?
  rpi-4.11.y stattdessen oder etwas anderes?

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

Danke im Voraus

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Um einige Informationen zu wiederholen, die ich an anderer Stelle bereitgestellt habe, habe ich die drahtlose Verbindung unter Bedingungen mit geringem Stromverbrauch getestet. Ich habe es so weit gebracht, dass USB-Geräte ausfallen, aber keine Probleme mit drahtlosen Verbindungen festgestellt. Das ist zwar ein Beweis dafür, dass es sich nicht um ein Stromproblem handelt, aber es ist erwähnenswert.

Ich habe zufällig herausgefunden, wie ich dies reproduzieren kann, indem ich sudo memtester 256M 1 über SSH mit meinem Telefon ausgeführt habe. Das WLAN stirbt, sobald memtester mit diesen "Lade" -Zeichen überflutet wird:

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

Seltsame Sache, WiFi hängt nur, während ich das auf meinem Handy mache. Ich habe meinen PC, einen anderen Pi und meinen Router ohne Glück ausprobiert.

@ JamesH65 - Update 2: Ich konnte mit 4.11 booten (ich habe den Kernel beim ersten Mal falsch konfiguriert).
Linux rpiz 4.11.2+ #2 Thu May 25 21:19:11 PDT 2017 armv6l GNU/Linux

Leider reagiert das System immer noch auf Gerste, wenn ich auf BT hämmere.

Wenn ich das externe USB-WLAN wieder anschließe und die Adresse des Adapters anschließe, ist alles wieder in Ordnung.

• Benjamin

Neuer Kernel, erstellt und installiert von Zweig rpi-4.11.y gemäß den Anweisungen hier: 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

Leider hängt WLAN immer noch mit dem gleichen Fehler:
brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Wenn Sie sich trösten, wenn das WLAN ausgeht, können Sie es neu starten. Ich teste gerade ein Bash-Skript, um zu sehen, ob dies hilft. Ich werde es in cron laufen lassen. Hier ist es, wenn jemand interessiert ist.

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

Ich habe dies für einen Tag ausgeführt und bis jetzt habe ich nicht bemerkt, dass mein WLAN abfällt.

@ JR1994
Funktioniert es noch
Wie oft lässt du es laufen?
Jede Minute ?

Ich werde es in einigen meiner Himbeeren versuchen, ich habe mehrere, die ich jedes Mal neu starte, wenn es den Router nicht pingen kann

Danke im Voraus

So weit, ist es gut. Ich überprüfe alle 2 Minuten.

Beachten Sie, dass die letzte Firmware-Version für brcmfmac zu alt ist:

brcmfmac: Firmware-Version = wl0: 15. Dezember 2015, 18:10:45 Uhr Version 7.45.41.23 (r606571) FWID 01-cc4eda9c

@semeion Nicht sicher, welche Firmware Sie verwenden - die aktuelle sollte "Version: 7.45.41.26 CRC: 5932ca06 Datum: Fr 2016-05-27 00:15:32 PDT Ucode Ver: 1043.2060 FWID: 01-df77e4a7" sein. Dies ist praktisch das gleiche wie im Linux-Firmware-Repo, obwohl wir unsere direkt von Brcm erhalten.

@ JamesH65 Diese Nachricht wurde in dmesg zurückgegeben.

$ 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

Aber mit vcgencmd version es:

$ /opt/vc/bin/vcgencmd version

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

Das ist nicht die Wifi-Chip-Firmware, sondern die SoC-Firmware
ziemlich häufig aktualisiert.

Ich bin mir immer noch nicht sicher, warum Ihr System denkt, dass es diese alte Firmware hat. Sie
Ich habe die neueste SoC-Firmware, also haben Sie vermutlich ein Apt-Get-Upgrade durchgeführt
vor kurzem?

Am 5. Juni 2017 um 17:55 schrieb Alexandre Bolelli [email protected] :

@ JamesH65
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jamesh65&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=W4TAJLAOB4LK3uzOCSYuvCg12E0PPs2YnLK7F3dSY6o&s=M_TSF6XbiHCAZO2_1FYozegsNPyrTwcm6HGX8iccJsg&e=
Diese Nachricht wurde in dmesg zurückgegeben. Aber mit der vcgencmd-Version zeigt es:
`$ / opt / vc / bin / vcgencmd Version
Firmware Version

30. Mai 2017 15:23:29
Copyright (c) 2012 Broadcom
Version b8cdd5ae76f39d9f353dfa8fb48bf7e33b74903c (sauber) (Version) `

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

@ JamesH65 Wie ich oben sagte, ich benutze Archlinux-ARM, es ist eine Rolling Release Distribution, und ja, mein System wird mit pacman -Syu aktualisiert (pacman -Syu ist ein passendes Upgrade / Update-Äquivalent).

Keine Ahnung, warum diese alte Firmware in meinem System alt ist. Vielleicht kann es der Grund für diesen Fehler sein. Was denkst du?

Wie auch immer, der Fehler passiert mit Raspbian, oder? Der Fehler wurde im März 2016 gemeldet? Es ist alt.

PS. Englisch ist nicht meine Muttersprache, entschuldigen Sie einige Fehler / Rechtschreibfehler.

OK, ich hatte nicht bemerkt, dass Sie ARCH verwenden. Klingt so, als würden sie nicht liefern
Ein neuer Firmware-Blob für den Wifi-Chip. Sie können es manuell aktualisieren
könnte Ihr Problem beheben, es könnte nicht - ich denke, es gibt wahrscheinlich mehrere
Wireless-Fehler, und es gibt keine Garantie dafür, dass Sie einen sehen, den Sie sehen
Ein Volk sieht auf Raspbian.

Sie sollten die veraltete Firmware den Arch-Betreuern melden und
Vielleicht auch der drahtlose Fehler, da dies möglicherweise an der Arch-Distribution liegt.

Beachten Sie, dass wir im Allgemeinen keine anderen Distributionen unterstützen, sondern unsere interne Distribution
Raspbian, um ein Problem zu untersuchen, müssen wir es replizieren können
Das.

Am 5. Juni 2017 um 23:13 schrieb Alexandre Bolelli [email protected] :

@ JamesH65 https://github.com/jamesh65 Wie ich oben sagte, benutze ich
Archlinux-ARM, es ist Rolling Release Distribution, und ja, mein System ist aktualisiert
mit pacman -Syu (pacman -Syu ist ein passendes Upgrade / Update-Äquivalent).

Keine Ahnung, warum diese alte Firmware in meinem System alt ist. Vielleicht kann es sein
der Grund für diesen Fehler. Was denkst du?

Wie auch immer, der Fehler passiert mit Raspbian, oder? Der Fehler wurde in gemeldet
März 2016? Es ist alt.

PS. Englisch ist nicht meine Muttersprache, entschuldigen Sie einige Fehler / Rechtschreibfehler.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306325452 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHaL4XsN5drPggS8eJDZWme4LyKXWks5sBH2CgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

@ JamesH65 Ja in der Tat. Ich werde versuchen, in # archlinux-arm zu fragen, warum diese Firmware alt ist. Wie auch immer, ich werde diesem Problem folgen und nach einer Lösung suchen. Ich werde hier alle entdeckten Informationen melden.

Danke im Voraus.

@ JamesH65 Ich kann es konsistent auf meinem Raspbian (RPi 3) replizieren. Wenn ich etwas tun kann, um Ihnen dabei zu helfen, lassen Sie es mich wissen!

Was ist dein Setup? Wie replizieren Sie das Problem?

Am 6. Juni 2017 um 14:17 schrieb Dan [email protected] :

@ JamesH65 https://github.com/jamesh65 Ich kann es replizieren
konsequent auf meinem Raspbian (RPi 3). Wenn ich etwas tun kann, um zu helfen
Lass es mich wissen!

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306483030 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHWyW5cQuS47k3xTmi3UX-QW7ffEYks5sBVF5gaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Werfen Sie einen Blick in die vorherigen Kommentare, ich habe vor nicht allzu langer Zeit erklärt, wie man es reproduziert.
Der Pi läuft voll mit Raspbian mit einem 3,5-Zoll-Bildschirm über dem offiziellen Netzteil. Nichts Besonderes, alles wird mit RPI-Update und passendem Upgrade auf dem neuesten Stand gehalten.

Nach einigen Tagen funktioniert das interne WLAN nicht mehr mit der folgenden Meldung in 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

Ich starte hostapd auf dieser Schnittstelle und habe eine andere USB-WLAN-Schnittstelle an den Pi angeschlossen. Meine Systeminformationen:

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

Ja, und wenn Sie zeigen, dass (-110) Sie das System neu starten müssen, damit es wieder funktioniert ...

Gut zu wissen, dass es auch in Raspbian passiert, der Fehler ist distro-unabhängig. Passiert dasselbe in Archlinux.

Da ich jedoch mein WLAN von Kanal 11 auf Kanal 6 verschoben habe, habe ich das Problem seitdem nicht mehr gesehen. Aus meinen vorherigen Antworten zu diesem Thread geht hervor, dass ich seit dem 7. Januar auf Kanal 6 umgestellt habe. Derzeit verwende ich zwei RaspPI Zero Ws und ein RaspPi 3, alle ohne Probleme. Auf den beiden RaspPi W wird DietPi ausgeführt.

Ich habe dieses Problem auch auf meinem Raspberry Pi 3. Ich habe bereits verschiedene WLAN-Kanäle ausprobiert.
Ich habe festgestellt, dass WLAN verdammt stabil ist, wenn ich auch den LAN-Port anschließe. Sobald ich den LAN-Anschluss abziehe, fällt das WLAN ständig aus.

Das ist wirklich komisch ......!

Am 15. Juni 2017 um 23:02 schrieb macmeck [email protected] :

Ich habe dieses Problem auch auf meinem Raspberry Pi 3. Ich habe verschiedene WLAN-Kanäle ausprobiert
bereits.
Ich habe festgestellt, dass WLAN verdammt stabil ist, wenn ich auch den LAN-Port anschließe.
Sobald ich den LAN-Anschluss abziehe, fällt das WLAN ständig aus.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-308878043 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHbUKBO9mG3xpKHFK977h4hrFUhrGks5sEantgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

ich habe
"brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012"
Problem auch in meinem rpi3. Meine zuverlässigste Problemumgehung, um diesen Fehler zu verhindern, war
"Wondershaper 9000 9000"
Ich hoffe, die Grundursache ist bestimmt.

Ich habe genau das gleiche Problem. Mein pi3 hat die folgenden Symptome, wenn er NUR mit WIFI verbunden ist:

1. OUTGOING WiFi funktioniert super. Ich kann ohne Probleme eine Verbindung zum Internet herstellen und Dateien auf meinen pi3 herunterladen.
2. Alle eingehenden WLAN-Verbindungen schlagen fehl. Pings-Timeout, Port 80 http greift auf Timeout zu, ssh schlägt fehl, alles schlägt NUR INBOUND fehl.
   HINWEIS:
3. Sobald Ethernet mit dem pi3 verbunden ist, funktioniert das WLAN BESSER, aber es werden immer noch Pakete verworfen.
4. Sobald Ethernet wieder entfernt wird, schlägt WLAN alle eingehenden Verbindungen vollständig fehl.
5. Sobald das Ethernet wieder mit dem pi3 verbunden ist, funktioniert das WLAN BESSER und lässt einige eingehende Pakete zu. aber es lässt immer noch viele von ihnen fallen.

Bitte beheben Sie dies!

Ich habe folgendes auf ifconfig bemerkt:

RX-Pakete: 1613 Fehler: 0 verworfen: 1074 Überläufe: 0 Frame: 0
TX- Pakete: 146 Fehler: 0 verworfen: 0 Überläufe: 0 Träger: 0
Kollisionen: 0 t xqueuelen: 1000

Im Grunde genommen wirft die RX-Seite des WIFI des pi3 Pakete wie verrückt ab. Kein Wunder, dass es nicht auf eingehende Verbindungen reagiert. TX funktioniert gut!

Seit ich dieses Skript eingerichtet habe, hatte ich keine Probleme mit WLAN auf beiden
RPI3s.

Am Mittwoch, 21. Juni 2017, um 04:26 Uhr, Edward Kang [email protected]
schrieb:

Ich habe folgendes auf ifconfig bemerkt:

RX-Pakete: 1613 Fehler: 0 verworfen: 1074 Überläufe: 0 Frame: 0
TX- Pakete: 146 Fehler: 0 verworfen: 0 Überläufe: 0 Träger: 0
Kollisionen: 0 t xqueuelen: 1000

Im Grunde genommen wirft die RX-Seite des WIFI des pi3 Pakete wie verrückt ab.
Kein Wunder, dass es nicht auf eingehende Verbindungen reagiert.

BITTE BEHEBEN SIE DIESES !!

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310049620 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AFHmIH6kkxraxahE22_PpstdDkqW8Pgqks5sGP3ggaJpZM4HupC5
.

Es ist alles sehr gut zu sagen "Bitte beheben Sie dies", aber Probleme wie diese sind absolute Bastarde zu finden. Es hat einen Monat gedauert, bis beim Überbrücken ein Fehler in den smsc / brcmfmac-Treibern gefunden wurde, und ich hatte das Glück, ihn zu finden, und ich vermute, dass dieser seltener und schwieriger zu finden ist. Wenn jemand einen replizierbaren Testfall findet, der den Fehler schnell anzeigt, wäre dies eine große Hilfe. Einige Leute scheinen den Kevent-Fehler häufig zu bekommen, ich bekomme ihn sehr selten.

Das Problem mit verworfenen Paketen wird geprüft, wenn ich Lücken im Zeitplan habe. Im obigen Fall scheinen Sie fast alle Pakete zu verwerfen, was am seltsamsten ist und normalerweise von der Mehrheit der Menschen nicht gesehen wird. Geschieht dies bei allen an den Pi angeschlossenen Geräten? Oder nur eine im Besonderen.

Entschuldigung, James!

Ich bin mir nicht sicher, was Sie unter allen an den Pi angeschlossenen Geräten verstehen. Die verworfenen Pakete stammen von der Ausführung von ifconfig direkt auf dem pi. Der Pi ist über WLAN mit einem Router verbunden. Wenn der pi nur mit dem WLAN-Netzwerk verbunden ist, empfängt und verwirft er ständig Pakete.

@ JamesH65 Nun, ich stimme Ihnen zu, es ist schwer zu lösen ... Aber wenn Sie Arch Linux-ARM verwenden, das Paket "create_ap" installieren und aktivieren (pacman -S create_ap; systemctl start / enable create_ap), können Sie das - 110 Fehler und der "Unbekannte Postfachdateninhalt: 0x40012" in wenigen Minuten ... Schließen Sie einfach manchmal Ihr Smartphone und / oder ein Smart-TV-Gerät an, und der Fehler wird auftreten.

Wir unterstützen Arch nicht, Raspbian ist unser unterstütztes Betriebssystem und das ist das, was ich habe
müssen in der Lage sein, das Problem in zu beheben. Ich habe keine Ahnung, welche Version der
Kernel oder Treiber, die ARCH verwendet, können sich stark von den unterscheiden
diejenigen in Raspbian.

Sehen die Leute das Problem immer noch, wenn sie den Pi als Zugangspunkt verwenden?
Überbrückung verwenden? IPv4 oder IPv6? Dies ist die Art von Informationen (nicht
Ausschließlich natürlich sind so viele Informationen wie möglich erforderlich
Probleme zu replizieren.

Beachten Sie, dass Broadcom über den Postfachfehler informiert wurde (es ist ihr Chip
und Fahrer natürlich), aber die Dinge bewegen sich langsam mit ihnen.

Am 21. Juni 2017 um 18:27 Uhr, Alexandre Bolelli [email protected]
schrieb:

@ 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=
Nun, ich stimme Ihnen zu, es ist schwer zu lösen ... Aber mit Arch Linux-ARM,
"create_ap" -Paket installieren und aktivieren (pacman -S create_ap;
systemctl / startable create_ap) erhalten Sie den Fehler -110 und den
"Unbekannter Postfachdateninhalt: 0x40012" in wenigen Minuten ... Nur
Verbinden Sie manchmal Ihr Smartphone und / oder einen Smart-TV damit und den Fehler
wird kommen.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Ich benutze statische IPv4 auf einigen Geräten und habe das gleiche Problem wie die
andere verwenden dhcp

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

Wir unterstützen Arch nicht, Raspbian ist unser unterstütztes Betriebssystem und das ist das, was ich habe
müssen in der Lage sein, das Problem in zu beheben. Ich habe keine Ahnung, welche Version der
Kernel oder Treiber, die ARCH verwendet, können sich stark von den unterscheiden
diejenigen in Raspbian.

Sehen die Leute das Problem immer noch, wenn sie den Pi als Zugangspunkt verwenden?
Überbrückung verwenden? IPv4 oder IPv6? Dies ist die Art von Informationen (nicht
Ausschließlich natürlich sind so viele Informationen wie möglich erforderlich
Probleme zu replizieren.

Beachten Sie, dass Broadcom über den Postfachfehler informiert wurde (es ist ihr Chip
und Fahrer natürlich), aber die Dinge bewegen sich langsam mit ihnen.

Am 21. Juni 2017 um 18:27 Uhr, Alexandre Bolelli [email protected]
schrieb:

@ JamesH65
3A__github.com_jamesh65 & d = DwMFaQ & c = DpyQ_ftY536pf7wCBQXXU58xADDRY77THQz
Ju1OmzOo & r = w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m =
BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w & s = o90aBGb27vZvog3BdioLSa2_
MEySix0ymtnTgiNb87c & e =>
Nun, ich stimme Ihnen zu, es ist schwer zu lösen ... Aber mit Arch Linux-ARM,
"create_ap" -Paket installieren und aktivieren (pacman -S create_ap;
systemctl / startable create_ap) erhalten Sie den Fehler -110 und den
"Unbekannter Postfachdateninhalt: 0x40012" in wenigen Minuten ...
Gerade
Verbinden Sie manchmal Ihr Smartphone und / oder einen Smart-TV damit und den Fehler
wird kommen.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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 =>,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310294786 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ACeQBFj8ICNkDl7xYwYJcD6TK-k6_4K5ks5sGhJ1gaJpZM4HupC5
.

Eine Sache zu beachten ist, dass das WiFi perfekt für mich funktionierte, von dem Zeitpunkt, als ich mein pi3 letztes Jahr bekam, bis vor ungefähr 3 Monaten, als das WiFi nicht mehr funktionierte.

Offensichtlich muss es zu dieser Zeit eine Art Änderung an der Software gegeben haben, die dazu führte, dass das WLAN nicht mehr funktionierte.

Wenn Ihr WLAN nicht mehr vollständig funktioniert, weist dies auf ein Problem an Ihrem Ende hin (das natürlich durch ein Softwareproblem verstärkt werden kann), da WLAN für alle anderen im Allgemeinen funktioniert (obwohl ich verworfene Pakete sehe).

Übrigens ist mein RPI3 brandneu in Großbritannien.

Ich kämpfe auch seit ein paar Monaten dagegen. Manchmal dauert es Minuten. Manchmal Wochen. Der gemeinsame Nenner beim Verlust einer Verbindung ist, dass die Aufrufe zum Zurücksetzen der CRDA-Weltregulierungsdomäne unmittelbar vor dem Verbindungsverlust angezeigt werden. Jedes Mal. Ubiquiti AC Access Point, Kanal 11, Kanalbreite HT40 (nur das Besondere).

28. Juni 14:19:31 Himbeerpi-Kernel: [980.387378] cfg80211: Weltregulierungsdomäne aktualisiert:
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387387] cfg80211: DFS-Master-Region: nicht festgelegt
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387396] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387411] cfg80211: (2402000 kHz - 2472000 kHz bei 40000 kHz), (N / A, 2000 mBm), (N / A)
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387426] cfg80211: (2457000 KHz - 2482000 KHz bei 20000 KHz, 92000 KHz AUTO), (N / A, 2000 mBm), (N / A)
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387439] cfg80211: (2474000 KHz - 2494000 KHz bei 20000 KHz), (N / A, 2000 mBm), (N / A)
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387453] cfg80211: (5170000 kHz - 5250000 kHz bei 80000 kHz, 160000 kHz AUTO), (N / A, 2000 mBm), (N / A)
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387468] cfg80211: (5250000 KHz - 5330000 KHz bei 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 s)
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387481] cfg80211: (5490000 kHz - 5730000 kHz bei 160000 kHz), (N / A, 2000 mBm), (0 s)
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387493] cfg80211: (5735000 KHz - 5835000 KHz bei 80000 KHz), (N / A, 2000 mBm), (N / A)
28. Juni 14:19:31 Himbeerpi-Kernel: [980.387505] cfg80211: (57240000 KHz - 63720000 KHz bei 2160000 KHz), (N / A, 0 mBm), (N / A)
28. Juni 14:19:32 Himbeerpi-Kernel: [981.262521] cfg80211: Die regulatorische Domäne wurde in Land: USA geändert
28. Juni 14:19:32 Himbeerpi-Kernel: [981.262536] cfg80211: DFS-Master-Region: FCC
28. Juni 14:19:32 Himbeerpi-Kernel: [981.262540] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28. Juni 14:19:32 Himbeerpi-Kernel: [981.262549] cfg80211: (2402000 kHz - 2472000 kHz bei 40000 kHz), (N / A, 3000 mBm), (N / A)
28. Juni 14:19:32 Himbeerpi-Kernel: [981.262557] cfg80211: (5170000 kHz - 5250000 kHz bei 80000 kHz, 160000 kHz AUTO), (N / A, 2300 mBm), (N / A)
28. Juni 14:19:32 Himbeerpi-Kernel: [981.262565] cfg80211: (5250000 KHz - 5330000 KHz bei 80000 KHz, 160000 KHz AUTO), (N / A, 2300 mBm), (0 s)
28. Juni 14:19:32 Himbeerpi-Kernel: [981.262571] cfg80211: (5490000 KHz - 5730000 KHz bei 160000 KHz), (N / A, 2300 mBm), (0 s)
28. Juni 14:19:32 Himbeerpi-Kernel: [981.262578] cfg80211: (5735000 KHz - 5835000 KHz bei 80000 KHz), (N / A, 3000 mBm), (N / A)
28. Juni 14:19:32 Himbeerpi-Kernel: [981.262584] cfg80211: (57240000 KHz - 63720000 KHz bei 2160000 KHz), (N / A, 4000 mBm), (N / A)

Es tut mir leid, Kraftstoff ins Feuer zu werfen, aber ich denke, ich habe auch ein ähnliches Problem mit dem Pi Zero W.

Beim Umschalten von wlan0 zwischen dem Access Point-Modus (bei Verwendung von hostapd) und dem normalen Verbindungsmodus (dh dem Herstellen einer Verbindung zu einem Router) verliert wlan0 manchmal die Fähigkeit, sich einem Access Point zuzuordnen.

Es wird in diesem Zustand stecken bleiben:

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

und nichts weniger als ein Neustart wird es beheben. Ich bemerke in dmesg die folgenden Fehler, wenn dies passiert:

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

Was mich beunruhigt, ist völlig willkürlich und zufällig. Ich kann manchmal eine Weile zwischen den beiden Modi wechseln, bevor das Problem auftritt. Aber es tut es schließlich.

FWIW Ich denke, das Neuladen des WLAN-Kernel-Moduls (durch Ausführen von "modprobe -r -v brcmfmac && modprobe brcmfmac") hat es behoben, sodass ich nur ein Skript erstellen muss, das dies tut, wenn mein Pi WLAN-Probleme hat.

Diesmal ist die Sache seltsam. Ich hatte diese Art von Problemen mit Raspberry pi zero & zero W, aber sie verschwanden vollständig, als ich die Kanäle wechselte (wie weiter oben in diesem Thread beschrieben).

Außerdem habe ich in letzter Zeit das DietPi-Betriebssystem verwendet und hatte überhaupt keine Probleme. Vielleicht möchten Sie das versuchen.

Ich hatte mich wirklich gerne mit dem Problem befasst, nachdem ich es schon einmal gesehen hatte, aber ich kann es heutzutage einfach nicht mehr zustande bringen! :(

/ raj
(vom iPhone gesendet)

Am 5. Juli 2017, um 9:01 Uhr, schrieb timdonovanuk [email protected] :

FWIW Ich denke, das Neuladen des WLAN-Kernel-Moduls (durch Ausführen von "modprobe -r -v brcmfmac && modprobe brcmfmac") hat es behoben, sodass ich nur ein Skript erstellen muss, das dies tut, wenn mein Pi WLAN-Probleme hat.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Je mehr Leute sich darum kümmern können, desto besser ist meine Zeit begrenzt
Ich kann im Moment aufgrund anderer Projekte dafür ausgeben. Ein großes Problem
ist ein solider Mechanismus, um es zu replizieren.

Am 5. Juli 2017 um 17:10 schrieb rajid [email protected] :

Diesmal ist die Sache seltsam. Ich hatte diese Art von Problemen auf Raspberry Pi
Null & Null W, aber sie gingen komplett weg, als ich die Kanäle wechselte (as
weiter oben in diesem Thread besprochen).

Außerdem habe ich in letzter Zeit das DietPi-Betriebssystem verwendet und hatte keine Probleme damit
alle. Vielleicht möchten Sie das versuchen.

Ich hatte mich wirklich gerne mit dem Problem befasst, nachdem ich es schon einmal gesehen hatte, aber ich
kann es heutzutage einfach nicht mehr schaffen! :(

/ raj
(vom iPhone gesendet)

Am 5. Juli 2017, um 9:01 Uhr, timdonovanuk [email protected]
schrieb:

FWIW Ich denke, das Wifi-Kernel-Modul wird neu geladen (indem "modprobe -r -v" ausgeführt wird
brcmfmac && modprobe brcmfmac ") hat das Problem behoben, sodass ich nur eine erstellen muss
Skript, das dies tut, wenn mein Pi WLAN-Probleme hat.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

@ Timdonovanuk könnte nett sein, teilen Sie Ihr Skript mit uns, ich suche nach einer Problemumgehung. Vielleicht läuft ein Überwachungsskript wie systemd service ... Was denkst du?

Gibt es eine Möglichkeit für mich, das Update der Regulierungsdomäne manuell auszulösen? Wie gesagt, es scheint für mich ziemlich konsistent zu sein, wenn das läuft, die Verbindung wird unterbrochen. Es würde mich interessieren, es einige Male manuell auszuführen, um zu sehen, ob ich es für Sie zuverlässig reproduzieren kann.

@rajid ,

Problemumgehung für den Wechsel vom automatischen Kanal auf Apple Extreme zu Kanal 6 hat bei mir nicht funktioniert. Ich werde LAN im Urlaub nutzen.

Bearbeiten: Jetzt verliere ich die Verbindung sogar mit LAN, es gibt meistens etwas mehr hier, ist es ein Hitzeproblem mit dem offiziellen Fall (kein Lüfter)?

Hallo,
Ich habe ein sehr ähnliches Problem mit einem Raspberry Pi Zero W.

Ich habe eine API entwickelt, die mit Node.JS auf dem Pi ausgeführt und in GPIOs integriert wird.
Der Pi ist über WLAN mit meinem LAN verbunden. Alles funktioniert gut, wenn PC-Clients die API aufrufen. Sobald ich jedoch meine API mit einem Android-Gerät abfrage, stürzt der Pi ab. Diese Abstürze treten zufällig auf: Manchmal kann die API von Android-Geräten mehrmals aufgerufen werden, und plötzlich tritt der Absturz auf.
Was ich unter Absturz verstehe, ist ein Ping-Verlust, aber Pi ist noch in Betrieb.

Das Aufrufen derselben API über PCs löst niemals einen Absturz aus.

Ich habe versucht, den Wifi-Kanal zu wechseln, aber keine besseren Ergebnisse erzielt.

Wenn ich irgendetwas ausführen kann, um bei der Diagnose / Lösung zu helfen, können Sie mich gerne fragen!

Irgendwas in diesem Forum Beitrag Hilfe?

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

Am 11. Juli 2017 um 16:22 schrieb matthiasbou [email protected] :

Hallo,
Ich habe ein sehr ähnliches Problem mit einem Raspberry Pi Zero W.

Ich habe eine API entwickelt, die mit Node.JS auf dem Pi ausgeführt und integriert wird
mit GPIOs.
Der Pi ist über WLAN mit meinem LAN verbunden. Beim PC funktioniert alles super
Clients rufen die API auf. Sobald ich jedoch meine API mit einem Android abfrage
Gerät stürzt der Pi ab. Diese Abstürze passieren zufällig: Manchmal kann API
von Android-Geräten mehrmals aufgerufen werden und plötzlich passiert der Absturz.
Das Aufrufen derselben API über PCs löst niemals einen Absturz aus.

Ich habe versucht, den Wifi-Kanal zu wechseln, aber keine besseren Ergebnisse erzielt.

Wenn ich irgendetwas ausführen kann, um bei der Diagnose / Lösung zu helfen, können Sie mich gerne fragen!

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314479400 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHYDohQoNRBDcX4oG49rK9e6kwpjjks5sM5MpgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

@matthiasbou

Interessanterweise gibt mein Broadcom-Treiber den Fehler -110 (manchmal ein weiterer Fehler) zurück und stürzt genau in dem Moment ab, in dem ich mein Motorola X2 (Android) -Smartphone anschließe. Der gleiche Fehler tritt aber auch beim Anschließen meines SmartTV auf. Auf jeden Fall kann ich bestätigen, dass der Absturz zum Zeitpunkt des Verbindungsaufbaus auftritt.

Mein Land ist richtig eingestellt, IPv6 deaktiviert und Roamoff = 1, ich benutze Kanal 6, das Problem tritt immer noch auf. WiFi-Energiesparmodus und Bluetooth ist in meiner Distribution standardmäßig deaktiviert.

@ JamesH65 : Ich habe die interessante Lösung ausprobiert, das richtige Land einzustellen (was nicht der Fall war), IPV6 zu deaktivieren und Roaming zu betreiben, aber immer noch das gleiche Problem zu haben :(

Wifi stellt eine Verbindung her, aber sobald ich anfange, mit einem Android-Gerät zu "spielen", das einige API-Aufrufe auf dem Pi Zero W ausführt, stürzt es nach einer Weile ab.

Warum sollte das Deaktivieren von IPv6 das Wifi-Problem beheben? Gibt es eine vernünftige Erklärung, warum IPv6 beteiligt ist, die reproduzierbar ist? Das einzige, was ich mir vorstellen kann, ist, dass IPv6 aufgrund von RAs eine geringfügige zusätzliche Multicast-Last aufweist.

Für das, was es wert ist, verwende ich zwei Pi Zero Ws als IPv6-Brücken zwischen integriertem wlan0 und externem eth0, wobei IPv4 blockiert ist. wlan0 befindet sich im AP-Modus und der ISC-dHCPv4-Server wird ausgeführt. Ich verbinde verschiedene Android-Tablets und Smartphones damit. Ich habe bisher keine Probleme bemerkt, aber vielleicht muss ich sie für längere Zeit laufen lassen. Ich benutze Kanal 6.

Entschuldigung, ich verwende eine Apple Airport-Box und es gibt keine Einstellung oder Erwähnung von "Kanalbreite". Ich habe einfach Kanal 6 für das 2,3-GHz-Netz eingestellt. Ich verwende jetzt DietPi auf meinen kleinen RaspPi Zero W-Systemen. Die anderen RaspPi, die ich habe, wurden vor langer Zeit mit Edimax USB eingerichtet und hatten nie Probleme. Ich glaube, das einzige Mal, dass ich Probleme sah, war mit Raspbian auf dem Zero W-System. Ich muss das wieder laden und sehen, ob ich es reproduzieren kann.

/ raj

Am 5. Juli 2017, um 15:19 Uhr, schrieb Michael Hallock < [email protected] [email protected] >:

Gibt es eine Möglichkeit für mich, das Update der Regulierungsdomäne manuell auszulösen? Wie gesagt, es scheint für mich ziemlich konsistent zu sein, wenn das läuft, die Verbindung wird unterbrochen. Es würde mich interessieren, es einige Male manuell auszuführen, um zu sehen, ob ich es für Sie zuverlässig reproduzieren kann.

@rajid https://github.com/rajid , laufen Sie zufällig mit der Kanalbreite 40? Und erinnerst du dich, wenn du vor dem Fall ähnliche Aktualisierungen der weltweiten Vorschriften gesehen hast? Neugierig, ob es dort vielleicht eine Kombination um Kanal 11 und die extra breite Kanalbreite gibt ... und welche Art von Router / AP verwenden Sie? Ich suche nur nach Gemeinsamkeiten, da ich dies ebenso wie andere auf Kanal 11 sehe ... Mein AP ist ein Ubiquiti.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, sehen Sie sie auf GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-313242611 an oder schalten Sie den Thread https://github.com/notifications/unsubscribe-auth/AFAlZVdfvh5QzIlsZYtt9sjpJs5pjqX5qjqX5JvX5qjqXJqX5qjqXJqX5qjqX5 .

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

Ich habe gerade weitere Tests durchgeführt und den Router geändert, mit dem der Pi verbunden ist.
Bis jetzt funktioniert alles, wenn sich der Pi auf diesem anderen WLAN-Router befindet (keine Änderung auf der Seite des Android-Geräts):
Funktionierende Routerkonfiguration :
Kanal 6
WPA PSK
Bandbreite 20Mhz

Nicht funktionierende Routerkonfiguration (Wifi-Verlust nach einigen Zugriffen von Android Wifi):
Netgear WNR1000v2
Kanal 6
WPA2-PSK [AES]
Fragmentierungslänge 2346
CTS / RTS-Schwellenwert 2347

Ich werde den funktionierenden Router auf WPA2-PSK umstellen, um zu sehen, ob das Problem dann reproduziert werden kann.

@TheDiveO In Bezug auf IPv6 hat der Treiber unterschiedliche Codepfade für IPv6, ebenso wie der Kernel. Es kann einen Fehler in einem dieser Pfade geben, der nicht in ipv6 enthalten ist, oder als ISTR aufgrund eines Fehlers vor einiger Zeit wird ein IPv6-Codepfad ausgeführt, wenn ein IPv4-Codepfad ausgeführt werden soll, oder umgekehrt. Der ganze Stapel ist ziemlich verworren.

neues Verhalten. Das Ändern des Gebietsschemas und das Ausführen von apt-get-Upgrades und -Updates hat jetzt das folgende Verhalten, wenn mein pi3 über WIFI verbunden ist:

Jetzt können Geräte außerhalb des lokalen LAN über TCP / IP eine Verbindung zu PI herstellen.

PI lehnt weiterhin alle Verbindungen (TCP / IP) nur im LAN ab.

PI kann weiterhin über WIFI auf das externe Internet zugreifen.

keine Ursache. Nichts hat sich verändert. Dies ist genau das gleiche Verhalten wie zuvor. Pi3 WiFi verwirft alle Pakete im lokalen LAN.

Nur um ein wenig nachzufolgen ... Ich habe einen neuen AP (Linksys E4200 V2) gestartet, den ich herumliegen hatte. Ich habe es auf Kanal 11 für 2,4 GHz eingerichtet, WPA2 Personal konfiguriert, eine BSSID und ein Passwort. Dann konfigurierte dies auf meinem Himbeer-Pi Null w. Es hat sich gut verbunden. Ich habe diesen AP dann in denselben Raum verschoben, in dem sich mein normaler Haus-AP befindet (der sich auf Kanal 6 befindet). Mein RaspPi hat dann ASSOC-REJECT status_code = 16 erhalten. Als ich den AP wieder in mein Büro zurückbrachte, war der RaspPi-Mitarbeiter in Ordnung.

Es scheint also, dass zumindest in meinem Fall Kanal 11 ein Problem ist, wenn sich der AP im anderen Raum befindet. Ich vermute, dies deutet wahrscheinlich auf ein Interferenzproblem hin.

Ich werde hier auch eine Webseite veröffentlichen, auf der alle Statuscodes und Fehlercodes aufgeführt sind:

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

Dies zeigt, dass mein "status_code = 16" durch eine Zeitüberschreitung verursacht wird, sodass eines der Systeme Pakete einfach nicht rechtzeitig empfängt.

Ich dachte nur, ich würde diese Informationen rauswerfen, falls sie jemandem helfen.

Wenn ich das Licht in meiner Küche einschalte, wird meine WLAN-Verbindung auf der Küche unterbrochen
Wohnzimmer ... ich weiß nicht warum, aber wenn Sie über Störungen gesprochen haben, denke ich
ich bin nicht verrückt

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

Nur um ein wenig nachzufolgen ... Ich habe einen neuen AP (Linksys E4200 V2) gestartet.
was ich herumliegen hatte. Ich habe es auf Kanal 11 für 2,4 GHz eingerichtet, konfiguriert
WPA2 Personal, eine BSSID und ein Passwort. Dann konfigurierte dies auf meiner Himbeere
pi null w. Es hat sich gut verbunden. Ich habe diesen AP dann in den gleichen Raum verlegt
wo sich mein normaler Haus-AP befindet (der sich auf Kanal 6 befindet). Mein RaspPi dann
habe ASSOC-REJECT status_code = 16. Einmal den AP zurück in mein Büro bringen
wieder machte der RaspPi-Mitarbeiter ganz gut.

Es scheint also, dass in meinem Fall zumindest Kanal 11 ein Problem ist, wenn AP dies ist
in dem anderen Raum. Ich vermute, dies deutet wahrscheinlich auf eine Störung hin
Problem.

Ich werde hier auch eine Webseite posten, die ich gefunden habe und die alles erzählt
Statuscodes und Fehlercodes sind:

https://supportforums.cisco.com/document/141136/80211-
Assoziationsstatus-80211-Deauth-Ursachencodes

Dies zeigt, dass mein "status_code = 16" durch eine Zeitüberschreitung verursacht wird, also eine der
Systems empfängt Pakete einfach nicht rechtzeitig.

Ich dachte nur, ich würde diese Informationen rauswerfen, falls es hilft
jemand.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314872003 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ACeQBJdfk2zp1sReVVs1wvrilKHXNm53ks5sNR42gaJpZM4HupC5
.

Es gibt ein wirklich schönes WiFi Analyzer-Programm für Android, das zeigt, welche APs sich in Ihrer Nähe befinden, zusammen mit ihren detaillierten Informationen. (Ich wünschte, so etwas gäbe es für iPhone / iPad, aber Apple ...)

@ JamesH65 Sie machen es mir wirklich Datenverbindungsschichttreiber (Schicht 3) mit der Netzwerkschicht 3 herumspielt. "Chaos" ist wahrscheinlich auch kein passendes Wort für diese Situation ...

Das sage ich eigentlich nicht. Ich bin kein Experte für Linux-Netzwerke
Stapel, aber ich scheine mich sicher zu erinnern, einige IPv6-spezifische Sachen in gesehen zu haben
irgendwo ein Fahrer.

Das Zeug ist alles im Kernelbaum, Sie können gerne einen Blick darauf werfen
sich selbst, um Ihren Geist zur Ruhe zu bringen.

Am 13. Juli 2017 um 08:58 schrieb TheDiveO [email protected] :

@ JamesH65 https://github.com/jamesh65 Du machst mich wirklich unruhig
sagen, dass ein Datenverbindungsschichttreiber (Schicht 3) damit herumspielt
die Netzwerkschicht 3. "Mess" ist wahrscheinlich kein passendes Wort dafür
Situation entweder ...

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315002002 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHUSoqqxnhaw4k2ECkzGC9CDkIlhYks5sNc4ngaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

@TheDiveO James bezieht sich auf Dinge wie Hardware-Prüfsummen-Offload.
SMSC95xx kann beispielsweise nur das IPv4-Prüfsummen-Offload unterstützen, da IPv6 erfordert, dass 0xFFFF durch eine Prüfsumme von 0x0000 ersetzt wird. Siehe https://github.com/torvalds/linux/commit/fe0cd8ca1b82983db24b173bb8518ea646c02d25. Daher folgen IPv6 und IPv4 unterschiedlichen Codepfaden. Nichts zweifelhaftes, aber inhärent im Netzwerkstapel, wo die Hardware nicht alle Situationen abdecken kann.

Ich bin mir ziemlich sicher, dass dieser Fehler im Broadcom-Treiber und nicht im Kernel liegt.

Fast sicher. Der Brcm-Treiber ist jedoch ein großer Teil des Codes und Fehler
solche sind nicht einfach zu debuggen. Besonders wenn Sie sie nicht replizieren können ...

Am 13. Juli 2017 um 13:04 Uhr, Alexandre Bolelli [email protected]
schrieb:

Ich bin mir ziemlich sicher, dass dieser Fehler im Broadcom-Treiber und nicht im Kernel liegt.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315058283 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHbr5SiWPKvQZOY7rN8IbyIIscNfVks5sNgexgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Je mehr ich damit zu kämpfen habe, desto mehr frage ich mich, ob dies mit der Unfähigkeit von Ubuntu / Debians zusammenhängt, wlan0 und eth0 ohne umfangreiche Konfiguration mit demselben Subnetz zu verbinden. Ich werde dies genauer untersuchen und herausfinden, ob dies das Problem ist.

@ JamesH65 würde es helfen, wenn ich (oder jemand anderes) in einer Umgebung, in der dies leicht reproduzierbar ist, null w oder rpi 3 für Sie einrichten und Ihnen dort SSH-Zugriff zum Debuggen gewähren würde? (Ich müsste dafür extra null w kaufen).

Wahrscheinlich nicht, aber danke für das Angebot. Ich neige dazu, benutzerdefinierte Änderungen an der
Treiber und Kernel, mit Änderungen, die mehrmals am Tag vorgenommen werden. Das machen
Remote ist nicht machbar. Mechanismen zur zuverlässigen Reproduktion des Problems sind
wirklich was benötigt wird.

Am 13. Juli 2017 um 13:57 Uhr, Tuomas Airaksinen [email protected]
schrieb:

@ JamesH65 https://github.com/jamesh65 würde es helfen, wenn ich (oder jemand
sonst) würde in einer Umgebung, in der dies der Fall ist, null w oder rpi 3 für Sie einrichten
leicht reproduzierbar und geben Ihnen dort SSH-Zugriff zum Debuggen? (ICH
müsste dafür extra null w kaufen).

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315069935 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHeQ1RECH-uIIHWPX6ItvRdVbZG_Xks5sNhRWgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

James,
Wenn ich diese einfache Abfrageschleife durchführe, sehe ich schnell, dass sich das integrierte WLAN-Netzwerk in einen unbrauchbaren Zustand verschlechtert. Wenn ich das integrierte WLAN ausschalte und ein USB-WLAN verwende, funktioniert es find. Ich erinnere mich nicht, ob es empfindlich auf das Vorhandensein oder Nichtvorhandensein des BT-Geräts reagiert, und kann dies einige Tage lang nicht einfach überprüfen. Ich habe mich auf 10 Minuten begrenzt, damit ich nach dem Experiment wieder in den Nullpunkt zurückkehren kann.

bash# ((t= Datum +% s +600)); while [ Datum +% s -lt $t ] ; do hcitool name <BTMAC>; done
Hoffentlich hilft das,
Benjamin

Dieser Code-Snip hat meine Rücken-Ticks verloren. Flucht vor ihnen ...

((t = "Datum +% s" + 600)); während [`Datum +% s` -lt $ t]; hcitool name "BT MAC einfügen"; erledigt

OH MEIN GOTT. Ich denke es ist behoben. Wifi ist aktiv, wenn das Ethernet nicht angeschlossen ist. Nicht zu fassen.

Ich habe alle Erwähnungen von eth0 aus meiner Datei / etc / network / interfaces entfernt, allow-hotplug durch auto ersetzt und dann das drahtlose Ausschalten von wlan0 und wlan1 erzwungen.

meine / etc / network / interfaces-Datei:

auto lo
iface lo inet loopback

kabelloses Ausschalten
auto wlan0
iface wlan0 inet Handbuch
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

kabelloses Ausschalten
auto wlan1
iface wlan1 inet Handbuch
wpa-conf / etc / wpa_supplicant / wpa_supplicant.conf`

Dann habe ich arp gespült:

ip -s -s neigh flush all

Dann habe ich neu gestartet:

sudo reboot now

Und jetzt funktioniert mein WiFi. Nicht zu fassen. Vielen Dank an alle, die diesen Thread kommentiert haben.

Ihr spezielles Konfigurationsproblem wurde möglicherweise behoben. Der Fehler im Broadcom-Treiber ist weiterhin vorhanden.

OK, wir haben uns das angeschaut. Mein erstes Problem war, dass beim Einrichten von SSH in mein Testgerät die Sitzung blockiert wurde, es sei denn, das Ethernet-Kabel wurde ebenfalls eingesteckt. Es stellt sich heraus, dass ARP von beiden Schnittstellen verwaltet wird. Als das Ethernet verbunden war, wurde es verwendet. Wenn es nicht angeschlossen war, bedeutete dies, dass es vom WLAN verwaltet wurde und auf ein Problem stieß. Dieses Problem könnte behoben werden, indem QoS / ToS in SSH deaktiviert wird (siehe hier https://expresshosting.net/ssh-hanging-authentication/), was wiederum impliziert, dass der Broadcom Wifi-Treiber mit den Nutzungsbedingungen (Typ von) sehr unzufrieden ist Service) / DSCP-Feld wird gesetzt. Dies wurde bereits in NTP (Ausgabe Nr. 1519) gesehen. Ich vermute, dass dies eine Ursache für die Wifi-Probleme sein könnte, die mit diesem Problem zusammenhängen, und werde heute den Brcm-Treiber durchsuchen, um zu sehen, ob ich etwas finden kann.

Zwischenbericht. Wir sehen definitiv Probleme mit bestimmten TOS-Paketwerten, die dazu führen, dass Pakete stillschweigend verworfen werden und SSH-Abstürze auftreten. Noch nichts Offensichtliches im undurchdringlichen Treibercode, der TBH sollte diesen Teil des Pakets sowieso nicht berühren, aber es ist eindeutig etwas los. Hat dies etwas mit den hier gemeldeten allgemeinen WLAN-Einfrierungen zu tun? Weiß noch nicht.

Ich habe ähnliche Probleme auf einem Pi Zero W mit Raspbian Jessie und Kernel 4.9.35+
Ich habe das gleiche von JamesH65 erwähnte Problem mit SSH und ntpd (TOS). Fix von https://expresshosting.net/ssh-hanging-authentication/ funktionierte für sshd. Ich habe auch die Probleme mit der Trennung von wlan0, aber mit etwas weniger ausführlichen Protokollmeldungen. Oberflächlich betrachtet sieht es nur so aus, als wäre der Träger verloren, und wpa_supplicant kann manchmal nicht neu verhandeln. Der einzige Ausweg besteht darin, ifdown wlan0 auszugeben, zu warten, ifup wlan0 für mich, dann beginnt wlan0 wieder zu arbeiten. Gerne liefern Protokolle, wenn jemand sie benötigt. Sag mir einfach welche.

Zwischenbericht. Wollte ein paar Notizen machen, bevor sie vergessen werden. Wir haben festgestellt, dass beim Zugriff über SSH von einem anderen Gerät aus die Antwort des drahtlos verbundenen pi fehlt. Wenn für diese Antwort das TOS-Feld festgelegt ist, wird das Paket stillschweigend verworfen - es wird nie wieder an den Anforderer zurückgegeben. Wir können dies mit netcat replizieren. Ein einfacher net cat-Befehl vom drahtlosen Pi mit gesetzten TOS-Flags scheint es nicht aus dem Gerät zu schaffen.
Versuchen Sie also auf dem drahtlosen PI, ein UDP-Paket an ein anderes Gerät zu senden ...
nc -T 0x10 -u7
Das Gerät scheint das Paket nicht zu empfangen (wie durch Ausführen von tcpdump auf dem Ziel gezeigt).
nc -T 0x00 -u7
wird zum entfernten System gelangen.
Wir haben dies nur über das drahtlose Netzwerk hier im Büro versucht. Ich muss ein anderes Wifi-Netzwerk einrichten, um festzustellen, ob es sich um einen Router oder ein Problem im Treiber handelt.

Kleinere Korrektur des obigen Befehls netcat
nc -T 0x10 -u <dest_ip> 7
UDP-Port 7 wurde ausgewählt, da es sich um den Echodienst handelt. Es spielt keine Rolle, dass dies nicht auf dem Remote-Computer ausgeführt wird, obwohl dies zu einer entsprechenden nicht erreichbaren ICMP-Antwort führt. Dies ist eine nützliche Meldung, dass das Remote-Ende die Nachricht erhalten hat.

Ich fange an zu glauben, dass das SSH / ToS-Problem eigentlich nichts damit zu tun hat. Ich habe Pakete bis zur HW-Ebene zurückverfolgt, und es spielt keine Rolle, ob die TOS-Flags gesetzt sind oder nicht. Die Pakete scheinen es bis zur Firmware (oder zumindest der Funktion brcmf_sdiod_send_pkt) zu schaffen, die keine Priorität mehr hat der Linux-Treiber). Was darauf hinweist, dass die Probleme entweder in der Firmware auf dem Chip (Closed Source) oder tatsächlich im Zusammenhang mit dem Router liegen - dh der von mir verwendete WLAN-Router lässt keine TOS-Flags durch, die nicht Null sind (oder möglicherweise> 0x04). Ich werde morgen einen anderen WLAN-Router ausprobieren, um dies zu bestätigen.

Gibt es eine Möglichkeit, die für die Entwicklung des brcmfmac-Moduls zuständige Abteilung zu finden, damit jemand diesem Thread folgen oder zumindest antworten kann, wenn ein Fix für diese Fehler veröffentlicht wird?

Wir sind bereits über die Linux-Wireless-Mailingliste in Kontakt.

Am 19. Juli 2017 um 19:06 Uhr schrieb "Alexandre Bolelli" [email protected] :

Gibt es eine Chance, die für die Entwicklung zuständige Abteilung zu finden?
das brcmfmac-Modul, damit jemand diesem Thread folgen kann oder zumindest
Antwort, wenn ein Fix für diese Fehler veröffentlicht wird?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316469790 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHYtYvpxdKd3SBBynOnlDN-ZXiWs_ks5sPkW9gaJpZM4HupC5
.

Wir sind bereits über die Linux-Wireless-Mailingliste in Kontakt.

... und direktere Routen. Das Problem war schon immer die Reproduzierbarkeit. Sobald wir das Problem klar demonstrieren können, können wir es Broadcom / Cypress präsentieren und beheben. Ich konnte das Problem mit NTP nie erkennen, aber James hatte einen erfolgreichen Fehler mit SSH, daher bin ich optimistisch, dass wir zur eigentlichen Ursache gelangen.

@pelwell +1 für den Begriff "_erfolgreicher Fehler" _ :)

Ich habe eine hackige Lösung für das SSH-Sperrproblem. Es scheint ein Problem in der Firmware zu sein. Hier sind einige Details.

`
Wir haben ein Problem auf dem Raspberry Pi untersucht, bei dem SSH und
NTP-Sitzungen schlagen fehl, wenn das TOS-Flag im IPv4-Header gesetzt ist.

Hier ist ein Auszug aus den Nutzungsbedingungen:

TOS ist 0x08 oder 0x10. Es darf jeweils nur eines der 4 Bits gesetzt werden.
0x10 - Verzögerung minimieren
0x08 - Maximieren Sie den Durchsatz
0x04 - Maximale Zuverlässigkeit
0x02 - Geldkosten minimieren.
Technisch gesehen wurde TOS von DSCP abgelöst, wird aber weiterhin unterstützt.

Wir könnten versuchen, dieses Problem mit DSCP neu zu erstellen, wenn dies wirklich erforderlich ist, aber dies ist nicht der Fall
scheinen relevant zu sein.

Details zum SSH-Problem und eine Problemumgehung finden Sie hier https://expresshosting.net/ssh-hanging-authentication/

Dies ist jedoch eindeutig irgendwo in der Kommunikation ein Problem
Stack, das haben wir also untersucht.

Wir konnten ein einfaches Beispiel mit netcat replizieren. Zuerst,
Verbinden Sie einen Pi drahtlos mit einem AP (PiA), wobei ein anderes Gerät angeschlossen ist
entweder drahtlos oder über Ethernet an dasselbe Netzwerk (PiB).

Auf PiB laufen

sudo tcpdump -n 'udp port 7' -v -i wlan0 <<<< oder eth0 je nach verbindung

Auf PiA,

nc -T 0x10 -u7

Dies sendet ein UDP-Paket an Port 7, wobei das TOS-Flag auf 0x10 gesetzt ist.

Dies wird NICHT eintreffen (oder manchmal sehr stark verzögert sein - 10 Sekunden)

Senden der Nutzungsbedingungen als 0

nc -T 0x0 -u7

Wird ankommen. 0x02 und 0x04 werden ebenfalls ankommen, 0x8 und 0x10 nicht.

Die Instrumentierung des brcmfmac-Treibers zeigt, dass das Paket mit den TOS übereinstimmt
flag = 0x10 wird korrekt über den Stack an die HW gesendet, aber dann die
Paket geht verloren.

Wir konnten das Paket durch Hacken des BCDC-Codes durchbringen.
in der Funktion bcdc.c! brcmf_proto_bcdc_hdrpush die Priorität der
Das Paket wird auch in den bcdc-Header verschoben. Indem Sie dies auf a setzen
konstanter Wert (der zwischen 0 und 7 liegen kann), das Paket ist
übertragen. Es scheint also ein konstanter Wert für die bcdc-Priorität zu sein
funktioniert, aber es wird auf die Priorität gesetzt, die vom eingehenden bestimmt wird
Dinge mit SKB-Priorität schlagen fehl, wenn die Nutzungsbedingungen 0x08 oder 0x10 sind. So scheint es
eine Kombination von Paketen mit unterschiedlichen Prioritäten sein, die verursacht
Werte mit höherer Priorität schlagen fehl, nicht der Wert selbst.

Da die BCDC-Header-Priorität für die Firmware bestimmt ist, ist dies
scheint ein Problem in der Firmware selbst zu sein, nicht in Linux
Treiber.

Hier ist ein Unterschied zu der Änderung, die das Problem zu stoppen scheint.

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 Großartig. Könnten Sie dies bitte auf Linux-Wireless kopieren, da ich keine baldige Firmware-Korrektur erwarte?

Ich werde auf einige Informationen von Broadcom / Cypress warten, da ich es bin
Ich bin mir nicht sicher, ob dieser Hack unter allen Umständen sicher ist. Ich habe sie per E-Mail gesendet. Einmal
Ich bekomme ein Feedback, ich werde einen Patch an Linux-Wireless senden.

Am 20. Juli 2017 um 12:41 schrieb Stefan Wahren [email protected] :

@ JamesH65 https://github.com/jamesh65 Großartig. Da erwarte ich keine
Bald Firmware-Fix, könnten Sie dies bitte auf Linux-Wireless kopieren?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316678154 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHY3DlxTr9mehRDlxBK3NWbjowxxyks5sPzzqgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Einige Testergebnisse scheinen keine negativen Auswirkungen dieses Hacks anzuzeigen. Ich habe gerade Daten hin und her übertragen, 500 MB an den Wireless Pi, 3,4 GB wurden gesendet. Die Empfangspakete 56 wurden von 794730 verworfen, keine TX-Pakete wurden von 2813930 verworfen. Die Leistung scheint für eine 11-Mbit / s-Verbindung genau richtig zu sein. Sieht also akzeptabel aus, aber dieser Hack deaktiviert tatsächlich etwas, das wahrscheinlich aktiviert werden sollte, also keine langfristige Lösung.

@lategoodbye Ich habe darüber

@ Moonman
Denken Sie, dies könnte auf ARCH Linux-Himbeerpi übertragen werden?

@ JamesH65 Sicher, dein Hack ist nicht für alle

Ich schlage vor, wir nehmen es in unser Repo auf, um einige ernsthafte Tests durchzuführen - beginnen Sie mit rpi-4.12.y, das von nächtlichen hochmodernen LibreElec-Builds verwendet wird.

Ein Gedanke: Könnten Sie den Patch in seiner Prioritätsfilterung selektiver gestalten und das Problem dennoch beheben?

Ich bereite gerade eine PR dafür vor, damit das Pi-Repo geht.

In Bezug auf die selektive Überprüfung habe ich versucht, einfach die Priorität zu ermitteln
6 (derjenige, der den Stapel weitergegeben wird - er wird aus den Nutzungsbedingungen übersetzt
Wert auf etwas mehr Linux-Stack-spezifisch), und setzen Sie das auf 0 und
das schien zu funktionieren, aber mein Verdacht ist, dass es eine Kombination von ist
andere Prioritäten als speziell 6, die das Problem verursachen. Wir
wissen auch, dass eine TOS von 0x08 auch Probleme hat, und das ist, IIRC,
Bis zu diesem Punkt in 2 konvertiert. Wir könnten einfach sagen, ob
es ist 6 oder 2, dann setze es auf Null, aber ich bin mir immer noch nicht sicher, ob das fangen würde
alles, was Probleme verursachen kann. Da der Wert sowieso 0-7 ist, denke ich,
Für diesen Hack ist es in allen Fällen besser, nur auf 0 zu setzen. Wir wissen das
funktioniert, es mag natürlich nicht optimal sein, aber ich denke, dass alle Pakete würden
durchkommen. Beachten Sie, dass diese Einstellung den TOS-Wert in der NICHT beeinflusst
IPv4-Paket - das bleibt gleich, es ist nur dieses System zum Senden des
Priorität für den Chip und wie er dann damit umgeht, der schuppig erscheint.

Am 21. Juli 2017 um 09:35 schrieb Phil Elwell [email protected] :

Ein Gedanke: Könnten Sie den Patch in seiner Priorität selektiver gestalten?
Filtern und noch das Problem behoben haben?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Ich hatte Kontakt zu Cypress, die versuchen werden, dies zu erreichen
sah so schnell wie möglich an.

Am 21. Juli 2017 um 10:11 schrieb James Hughes [email protected] :

Ich bereite gerade eine PR dafür vor, damit das Pi-Repo geht.

In Bezug auf die selektive Überprüfung habe ich versucht, einfach zu erkennen
Priorität 6 (diejenige, die über den Stapel weitergegeben wird - es wird übersetzt von
den TOS-Wert auf etwas Linux-Stack-spezifischeres) und das Setzen auf
0 und das schien zu funktionieren, aber mein Verdacht ist, dass es eine Kombination ist
von unterschiedlichen Prioritäten anstatt speziell 6, die das Problem verursacht.
Wir wissen auch, dass eine TOS von 0x08 ebenfalls Probleme hat, und das heißt, IIRC,
Bis zu diesem Punkt in 2 konvertiert. Wir könnten einfach sagen, ob
es ist 6 oder 2, dann setze es auf Null, aber ich bin mir immer noch nicht sicher, ob das fangen würde
alles, was Probleme verursachen kann. Da der Wert sowieso 0-7 ist, denke ich,
Für diesen Hack ist es in allen Fällen besser, nur auf 0 zu setzen. Wir wissen das
funktioniert, es mag natürlich nicht optimal sein, aber ich denke, dass alle Pakete würden
durchkommen. Beachten Sie, dass diese Einstellung den TOS-Wert in der NICHT beeinflusst
IPv4-Paket - das bleibt gleich, es ist nur dieses System zum Senden des
Priorität für den Chip, der schuppig erscheint und wie er dann damit umgeht
erscheint schuppig.

Am 21. Juli 2017 um 09:35 schrieb Phil Elwell [email protected] :

Ein Gedanke: Könnten Sie den Patch in seiner Priorität selektiver gestalten?
Filtern und noch das Problem behoben haben?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Wir wissen auch, dass ein TOS von 0x08 ebenfalls Probleme hat, und das heißt, IIRC, das zu diesem Zeitpunkt in 2 konvertiert wird.

Richtig. TOS 0x08 (Durchsatz maximieren) ist 2 zugeordnet. Dies sind TC_PRIO_xxx -Werte von http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/pkt_sched.h#L19. 6 = INTERAKTIV, 2 = BULK.

Frühere Tests mit IPQoS auf 8 in sshd_config oder mit Netcat unter Verwendung von TOS 8 führten zu verworfenen Paketen.
Weder 0x02 noch 0x04 haben Probleme verursacht, aber es gibt wenig, was ein WLAN-Treiber über Kostenunterschiede (es gibt keine) oder Zuverlässigkeit tun kann, sodass er diese wahrscheinlich ignoriert.
Bearbeiten Tatsächlich setzt die Zuordnungstabelle unter http://elixir.free-electrons.com/linux/latest/source/net/ipv4/route.c#L177 unter Verwendung von tos>>1 die TOS 0x02 und 0x04 auf TC_PRIO_BESTEFFORT = 0 sowieso, was erklärt, warum sie keine Probleme haben.

Nur ein kurzer Bericht. Cypress konnte das Problem replizieren und ist es auch
Überprüfen Sie die Firmware so hoffnungsvoll. Sehr erfreuliche und schnelle Antwort
von den Jungs dort.

Am 21. Juli 2017 um 11:07 schrieb 6by9 [email protected] :

Wir wissen auch, dass eine TOS von 0x08 ebenfalls Probleme hat, und das heißt, IIRC,
Bis zu diesem Punkt in 2 konvertiert.

Richtig. TOS 0x08 (Durchsatz maximieren) ist auf 2 abgebildet. Sie sind TC_PRIO_xxx
Werte von http://elixir.free-electrons.com/linux/latest/source/
include / uapi / linux / pkt_sched.h # L19. 6 = INTERAKTIV, 2 = BULK.

Vorherige Tests mit der Einstellung von IPQoS auf 8 in sshd_config oder mit
Netcat mit TOS 8 führte zu verworfenen Paketen.
Weder 0x02 noch 0x04 haben Probleme verursacht, aber es gibt kaum einen WLAN-Treiber
kann über Kostenunterschied (es gibt keine) oder Zuverlässigkeit tun, so ist wahrscheinlich
ignoriere sie (ich habe nicht überprüft).

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316962443 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHXTmjzqVW0o4T9IIoYFPprKvEvS7ks5sQHhXgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Einfachere Art der Reproduktion - verwenden Sie Ping! (Ich hatte vergessen, dass Ping / ICMP über IP lag - dumm von mir)

ping -Q 0x10 <dest ip addr> auf dem Pi3
und führen Sie tcpdump -n -v -i wlan0 'icmp' am Ziel aus.
Führt zu einem Paketverlust von> 90% bei -Q 0x10 oder -Q 0x08. Es wird oft mit 4 aufeinanderfolgenden Paketen in Ordnung gestartet, geht dann aber sehr sporadisch.
Es ist etwas nützlicher als Netcat, da (a) es sich immer wieder wiederholt und (b) es Ihnen sagt, wann es eine Antwort erhält.

Hier gibt es eine Problemumgehung: https://github.com/raspberrypi/linux/pull/2126
Wenn Sie es mit dem 4.9-Kernel testen möchten, verwenden Sie rpi-update.
Dann ersetzen:
Module / 4.9.39 + / Kernel / Treiber / Net / Wireless / Broadcom / brcm80211 / brcmfmac / brcmfmac.ko mit diesem
Module / 4.9.39-v7 + / Kernel / Treiber / Net / Wireless / Broadcom / brcm80211 / brcmfmac / brcmfmac.ko mit diesem

BEARBEITEN: Der neueste RPI-Update-Kernel enthält jetzt den Patch, sodass das Herunterladen der Module nicht mehr erforderlich ist.

Nicht sicher, ob verwandt. Die Verbindung über die integrierte Broadcom auf meinem Pi Zero W wird alle 2 Stunden unterbrochen, wenn eine zweite Schnittstelle wlan1 mit einem rt8192eu / 8192eu-Dongle ausgestattet ist. Es scheint kein Stromproblem zu sein, da es sehr zyklisch ist. Ich habe einen Pastebin der Trennungen unter https://pastebin.com/5hMQHWeW

Wenn dies andauert, gibt wpa_supplicant es manchmal auf, es ohne ersichtlichen Grund zu versuchen, außer wenn die Authentifizierung fehlschlägt. Die einzige Möglichkeit, die Konnektivität auf wlan0 wiederherzustellen, besteht darin, ifdown / ifup auszugeben, das dann zu 100% funktioniert.

Jetzt weiß ich nicht, ob dies die damit verbundenen Probleme mit dem Broadcom-Kernelmodul sind, die Probleme verursachen, oder ob es sich um den fehlerhaften 8192eu oder beides handelt. Gerne stellen wir bei Bedarf weitere Protokollzeilen zur Verfügung oder veröffentlichen sie in einem anderen Thread, aber jemand auf #raspbian hat vorgeschlagen, dies hier hinzuzufügen.

Wenn Sie bestätigen können, dass vcgencmd get_throttled 0x0 nach einer Unterbrechung vcgencmd get_throttled zurückgibt, wird ein Stromversorgungsproblem ausgeschlossen.

Normalerweise passiert es, wenn ich schlafe / nicht mit dem Pi und im Nachhinein herausfinde, wenn ich keine Verbindung mehr herstellen kann (dann habe ich mich über den zweiten AP verbunden und wlan0 zurückgesetzt). Da der 8192eu-Dongle jetzt nicht angeschlossen ist, gab es noch kein Ereignis. Ich kann den zweiten Dongle mit dem Buggy-Modul anschließen, aber wie schnell nach dem Trennen muss ich vcgencmd get_throttled überprüfen?

Solange Sie nicht neu gestartet haben, zeigen die oberen Bits an, ob jemals ein Unterspannungsereignis aufgetreten ist.

Lief es einfach. Auf keinen Fall seit dem letzten Trennen neu gestartet. Kann die Rückgabe von vcgencmd get_throttled bestätigen:
gedrosselt = 0x0

Leider funktioniert get_throttled auf einem Pi0 / Pi0w nicht (hat keine Unterspannungserkennungsschaltung).

Aus irgendeinem Grund hat das Kopieren und Einfügen des Diff von JamesH65 bei mir nicht funktioniert. Es wurde eine Patchdatei erstellt, die sofort angewendet werden sollte. Dies könnte für Leute nützlich sein: https://github.com/bortek/EZ-WifiBroadcast/blob/master/kernel/linux-4.9.28-brcmfmac-tos.patch

Dateiname sagt 4.9.28, sollte aber mindestens bis 4.9.35 (und wahrscheinlich auch später) gelten.

Kopieren Sie diese Datei in das Kernelbaum-Stammverzeichnis und wenden Sie sie mit patch -p1 < linux-4.9.28-brcmfmac-tos.patch

Zusätzliche (aber merkwürdige) Informationen:

Wenn der Pi Zero W mit wlan0 verbunden ist, aber sonst nichts tut (Cron-Skript überprüft sntp höchstens alle 15 Minuten), kommt es sehr häufig zu Verbindungsabbrüchen, die in der Größenordnung von 1 bis 10 / Stunde jeweils höchstens eine Sekunde dauern.

Wenn ich jedoch die Verbindung verwendet habe, z. B. im Leerlauf im IRC (mehrere große Kanäle), wird die Verbindung während der gesamten Zeit, in der dies der Fall ist, nicht ein einziges Mal unterbrochen.

Es stellte sich heraus, dass das Laden der 4.9.39-Kernelmodule auf 4.9.35 keine gute Idee war.

Ein weiterer Fehlerbericht aus dem Forum, Mailbox-Fehler scheint häufig.

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

Der neueste RPI-Update-Kernel enthält jetzt den BCDC-Prioritäts-Patch.

Cypress (war Broadcom) hat uns neue Versionen der WLAN- und Bluetooth-Firmwares zum Testen gegeben. Sie können eine Pre-Release - Download hier . Führen Sie nach dem Herunterladen auf Ihren Pi Folgendes aus:

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

Dadurch wird die neue Firmware extrahiert und dann installiert (die alten Versionen werden zuerst gesichert).

So kehren Sie zur ursprünglichen Firmware zurück (was ich vor der Installation einer ordnungsgemäßen Version empfehle):

./brcmfw -u

Was hat sich geändert:

1. CVE-2017-9417: Problembehebung bei „Broadpwn“
2. Fügen Sie der Versionszeichenfolge die Zeichenfolge "CY" hinzu.
3. Deadlock-Fix für AMPDU-Sequenznummer (mögliche Korrektur für dieses Problem)
4. CLM-Versions-Upgrade
5. CVE-2017-0572: Speicherbeschädigung behoben

Nur eine Randnotiz - Ich habe das interne WLAN auf meinem ersten Pi Zero W deaktiviert und auf einen USB-WLAN-Dongle umgestellt, alle Probleme sind verschwunden. Vor einigen Tagen habe ich einen weiteren Pi Zero W installiert, um meinen 3D-Drucker zu steuern (mit OctoPi). Ich war etwas überrascht zu sehen, dass das interne WLAN einwandfrei zu funktionieren scheint - aber nach einigen Tests kann ich bestätigen, dass das WLAN unterbrochen wird, sobald ich eine Verbindung von meinem LG G4 Android-Telefon (Chrome-Browser) herstelle. Wenn ich darüber nachdenke, denke ich, dass das Verhalten auf dem ersten Pi ziemlich ähnlich war ...
Die Verbindung von meinem PC führt nicht zu solchen Effekten.

Bitte probieren Sie die neue Firmware aus und berichten Sie über Ihre Ergebnisse.

Ich habe die Vorschau-Firmware installiert. Ich erhalte immer noch den Fehler "raspberrypi kernel: brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt:", gefolgt von einem WLAN-Fehler.

Was ist Ihr Anwendungsfall?

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

Probieren Sie die dort veröffentlichte Arbeitskonfiguration aus. Ich werde aktualisieren.

Bitte geben Sie Ihre Kernel-Version, eine Zusammenfassung der angeschlossenen Geräte und die Dauer an, bis der Fehler auftritt.

Der Postfachfehler wird noch untersucht, ich erwarte dies nicht
Firmware, um es zu beheben. Diese Firmware enthält mehr Debugging, um die Nachverfolgung zu erleichtern
es aber runter. Wenn Sie das Debuggen des Treibers aktivieren (sorry, auf Mobilgeräten und
Ich habe keine Details dazu) und sehe den Fehler
Debug- und Posting-Details hier, wenn Sie den Postfachfehler erhalten, wäre
nützlich.

Am 13. August 2017 um 21:40 Uhr schrieb "Stefan Wahren" [email protected] :

Bitte geben Sie Ihre Kernel-Version, eine Zusammenfassung der angeschlossenen Geräte und
Es dauert lange, bis der Fehler auftritt.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322062745 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHRwsQyHa-QqOP7ntTqgCfWlgXpEqks5sX1DlgaJpZM4HupC5
.

Das Debuggen ist standardmäßig deaktiviert und erfordert eine Modulwiederherstellung, um es zu aktivieren (möglicherweise sollten wir dies während dieser Untersuchungen ändern). Die erforderlichen Änderungen sind das Hinzufügen von BRCMDBG=y zu .config, gefolgt von einer Neuerstellung, und das Hinzufügen von brcmfmac.debug=0x???????? zu /boot/cmdline.txt , wobei ???????? eine hexadezimale Zahl ist, die die Hier dokumentierte Bitwerte: https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h#L22

Versucht die von pelwell gepostete Test-Firmware, das Problem bleibt weiterhin bestehen. Die Verbindung friert alle 1 - 2 Stunden ein. Wenn die Verbindung unterbrochen wurde und ich versuchte zu pingen ( ping 8.8.8.8 ), funktioniert es wieder kurz bis zum 8. Ping. Das Ping-Verhalten ist über das Einfrieren hinweg konsistent. Arbeiten-> Einfrieren-> Ping 8.8.8.8-> Arbeiten -> 8. Ping -> Einfrieren Danach muss ich meinen Himbeer-Pi neu starten. Ich weiß nicht, ob es Hilfe ist.

Kernel:
Linux raspberrypi 4.9.41-v7 + # 1023 SMP Di Aug 8 16:00:15 BST 2017 armv7l GNU / Linux

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

Gibt es etwas Relevantes in dmesg, wenn es passiert?

Am 14. August 2017, 13:16 Uhr, "GIlang Charismadiptya" [email protected]
schrieb:

Versucht die von pelwell gepostete Test-Firmware, das Problem bleibt weiterhin bestehen.
Die Verbindung friert alle 1 - 2 Stunden ein. Als die Verbindung unterbrochen wurde und ich
versucht zu pingen (ping 8.8.8.8), es funktioniert wieder kurz bis zum 8 ..
Klingeln. Danach muss ich meinen Himbeer-Pi neu starten.

Kernel:
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 Di Aug 8 16:00:15 BST 2017 armv7l GNU / Linux

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

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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=
.

Nein, nichts interessantes. Vielleicht, weil ich das Modul mit Debugging-Unterstützung nicht neu erstellt habe. Wie es geht? oder werden Sie das kompilierte Modul bereitstellen? Vielen Dank.

Im Folgenden finden Sie die dmesg-Protokolle:

`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
`

Weitere Informationen zum Debug-Modul finden Sie in Phils Beitrag oben. Wir sind besonders
interessiert an der Debug-Ablaufverfolgung, wenn der Postfachfehler auftritt.

Am 14. August 2017, 17:52 Uhr, "GIlang Charismadiptya" [email protected]
schrieb:

Nein, nichts interessantes. Vielleicht, weil ich das Modul mit nicht neu erstellt habe
Debugging-Unterstützung. Wie es geht? oder werden Sie das kompilierte Modul bereitstellen?
Vielen Dank.

Anbei das Dmesg-Protokoll:

` pi @ raspberrypi : ~ $ sudo dmesg

[4.654722] brcmfmac: Firmware-Version = wl0: 7. August 2017 00:46:29 Version
7.45.41.46 (r666254 CY) FWID 01-f8a78378
[5.752968] smsc95xx 1-1.1: 1.0 eth0: Hardware kann nicht remote
aufwachen
[5.753285] IPv6: ADDRCONF (NETDEV_UP): eth0: Link ist nicht bereit
[6.206530] IPv6: ADDRCONF (NETDEV_UP): wlan0: Link ist nicht bereit
[6.206577] brcmfmac: Energieverwaltung deaktiviert
[7.088933] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: Link wird bereit
[7.340040] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: Link wird bereit
[7.340841] smsc95xx 1-1.1: 1.0 eth0: Verbindung, 100 Mbit / s, Vollduplex, lpa
0xCDE1
[7.431235] Hinzufügen von 102396k Swap on / var / swap. Priorität: -1 Umfang: 4
über: 217088k SSFS
[10.182342] IPv6: ADDRCONF (NETDEV_UP): wlan0: Link ist nicht bereit
[10.182357] brcmfmac: Energieverwaltung deaktiviert
[10.872838] IPv6: ADDRCONF (NETDEV_UP): wlan0: Link ist nicht bereit
[10.872903] brcmfmac: Energieverwaltung deaktiviert
[11.594201] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: Link wird bereit
[14.128592] ip_tables: (C) Netfilter-Kernteam 2000-2006
[14.172268] nf_conntrack Version 0.5.0 (15360 Eimer, max. 61440)
[54.604680] zufällig: crng init erledigt

pi @ raspberrypi : ~ $ sudo dmesg -l err
[4.501055] Himbeer-Pi-Touchscreen 3f700000.dsi.0: Unbekannte Atmel-Firmware
Revision: 0xfa
`

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322228992 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHXuy3Eo5PqPAP8FfSFiYWMUQL7fAks5sYG1HgaJpZM4HupC5
.

Der neueste Kernel für das RPI-Update aktiviert BRCMDBG, wodurch die von @pelwell zuvor vorgeschlagene brcmfmac.debug=0x???????? zugelassen werden sollte .

Errrr ..... mein Pi3, der mit WLAN absolut solide war, verliert es jetzt auch, seit ich vor ein paar Tagen auf das neueste Raspbian aktualisiert habe :-(

Was sind die Symptome? Ich würde keine Regression in der Firmware erwarten, oder
in der Tat der Fahrer selbst.

Am 24. August 2017 um 20:07 schrieb Crrispy [email protected] :

Errrr ..... mein Pi3, der mit WLAN absolut solide war, verliert es jetzt auch, seit ich
vor ein paar Tagen auf den neuesten Raspbian aktualisiert :-(

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-324728431 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHUxvLV3OzKGpcmEMGEoSad_piujBks5sbcoHgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

@ Crrispy
Versuche dies:
Ich habe alle Erwähnungen von eth0 aus meiner Datei / etc / network / interfaces entfernt, allow-hotplug durch auto ersetzt und dann das drahtlose Ausschalten von wlan0 und wlan1 erzwungen.

meine / etc / network / interfaces-Datei:

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`

Dann habe ich arp gespült:

ip -s -s wiehern alle spülen

Dann habe ich neu gestartet:

sudo jetzt neu starten

Ich bin mir ziemlich sicher, dass ich regelmäßig auf diesen Fehler stoße. Ausführen von hostapd, Verwenden des internen Broadcom-WLAN zum Hosten eines Zugriffspunkts und Weiterleiten von Clients, die eine Verbindung über einen USB-WLAN-Dongle herstellen, der als drahtloser Client dient. Es sind mehrere Geräte verbunden, aber sobald ich den Pi außerhalb der Reichweite der angeschlossenen Geräte trage, scheint der WLAN-Absturz aufzutreten. Wie bei anderen fällt nur das interne WLAN-WLAN-Gerät aus: Ethernet und das andere WLAN bleiben unberührt. Ich erhalte auch den Fehler "Mailbox" im Systemprotokoll:

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

(Weitere Protokolldetails unter https://pastebin.com/NPB00ZEq)

Ich hatte festgestellt, dass die Ausgabe von iwconfig den Wert Tx_Power nicht mehr anzeigt, wenn sich das WLAN-Gerät im ausgefallenen Zustand befindet. Daher habe ich in der Zwischenzeit einen automatischen Neustart als Problemumgehung verwendet.

Ich habe gerade auf das neueste RPI-Update aktualisiert, die oben genannten Test-WLAN-Treiber installiert und das Debug-Flag zu meiner cmdline.txt hinzugefügt, wobei ich den Hex-Wert für BRCMF_TRACE_VAL verwendet habe: bcrmfmac.debug=0x00000002

Wenn Sie regelmäßig den Postfachfehler erhalten, sind wir für die Ergebnisse des Debug-Treibers dankbar. Wenn Sie den Postfachfehler erhalten, gehen Sie bitte so vor, um die Forensik zu erhalten und die Ergebnisse hier zu veröffentlichen. Ich kann sie an Cypress weiterleiten, die das Problem untersuchen.

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

Nun, was war ein leicht reproduzierbares Problem, das ich nicht mehr duplizieren kann, seit ich rpi-update ausgeführt habe. Wenn dies hilfreich wäre, könnte ich dies möglicherweise erreichen, indem ich ab dem 21. Juni 2017 ein Downgrade auf eine Neuinstallation des Raspbian-Builds durchführe.

@ JamesH65
Es ist gelungen, die von Ihnen angeforderte Forensik (nach dem Postfachfehler) zu erfassen. Dies ist jedoch nach dem Downgrade auf den im Raspbian-Build vom 21. Juni enthaltenen Kernel der Fall. Möglicherweise wurde das Problem bereits behoben, da ich das Problem nach der Installation der von @pelwell vor etwa zwei Wochen veröffentlichten

Hier ist ein Link zur Forensik:
https://pastebin.com/VVqVQ8FW

Hoffe das ist hilfreich ...

Also mit der alten Firmware vermute ich. Wir hoffen, die Forensik für zu bekommen
die neue Firmware, die (anscheinend) zusätzliche Nachrichten enthält, die auf die Verfolgung abzielen
das Postfachproblem. Das lässt mich denken, dass Cypress immer noch zu denken scheint
Das Postfachproblem wird auch nach den anderen Korrekturen vorhanden sein. Gibt die Daten trotzdem weiter, falls es hilft.

Gut zu wissen, dass Fehler viel schwerer zu reproduzieren sind!

Am 29. August 2017 um 15:51 schrieb randyoo [email protected] :

@ JamesH65
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jamesh65&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=owdl09j03eJ21jjmS-pXzxuHC0FQIGtHaCHVAUCN42I&s=3RXFuPnppW2lu6j302oN0bZFkwDQhfTLIZ4fb-qzMds&e=
Es ist gelungen, die von Ihnen angeforderte Forensik zu erfassen, aber um klar zu sein:
Dies erfolgt nach dem Downgrade auf den im Raspbian vom 21. Juni enthaltenen Kernel
bauen. Es könnte durchaus schon gelöst worden sein, weil ich es nicht kann
Duplizieren Sie das Problem nach der Installation der von @pelwell bereitgestellten Test-Firmware
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=
vor ungefähr zwei Wochen.

Hier ist ein Link zur Forensik:
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=

Hoffe das ist hilfreich ...

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Das lässt mich denken, dass Cypress immer noch zu denken scheint
Das Postfachproblem wird auch nach den anderen Korrekturen vorhanden sein.

Ja, das verstehe ich auch.

@randyoo Danke für das positive Feedback.

@ JamesH65
Okay, es ist wieder passiert, diesmal mit der neuesten RPI-Update-Firmware und unter Verwendung der von @pelwell veröffentlichten Test-Firmware. Leider sieht die forensische Ausgabe identisch mit der im vorherigen Beitrag aus. (Ich bin mir nicht sicher, warum ich im forensischen Speicherauszug keine anderen / detaillierteren Informationen erhalte, da das Debuggen in meiner cmdline.txt gemäß meinem vorherigen Beitrag aktiviert ist.)

Ich habe auch den Inhalt der anderen / sys / kernel / debug-Inhalte gelöscht. Hier ist es: https://pastebin.com/pdFUPBxN

Beim letzten Einfrieren des WLANs scheint die Kernel-Protokollablaufverfolgung detaillierter zu sein. Siehe den Link:
https://pastebin.com/KTxbgpYV

Hoffentlich hilft das.

Gab es weitere Details in der Firmware-Forensik? Ich denke das ist das
Bit Cypress sind wirklich interessiert, wenn der Postfachfehler auftritt.

Am 31. August 2017 um 21:56 schrieb randyoo [email protected] :

Beim letzten Einfrieren des WLANs scheint die Kernel-Protokollablaufverfolgung detaillierter zu sein.
Siehe den Link:
https://pastebin.com/KTxbgpYV
https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_KTxbgpYV&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=Q-jbAaSSLWAuC7E9Mh2NDxUucRiJHVodu4QDmS5Tcoo&s=9SV25GVatAz8aDQRiSTEUEGmojqbPPSY5MnyCHwA3X0&e=

Hoffentlich hilft das.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Richtig, sorry. Es ist gelungen, eine Erfassung der Forensik zu erhalten, und ja, dort scheint es viel mehr Details zu geben:
https://pastebin.com/qypfAfAp

Da manchmal neue Fälle helfen, bekomme ich sie auch von Zeit zu Zeit:

pi @ jempi : ~ $ grep "brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012" / var / log / syslog
14. August 22:16:23 jempi-Kernel: [501.247242] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
17. August 20:26:20 jempi-Kernel: [509.684277] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
24. August 23:57:37 jempi-Kernel: [573.652189] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
29. August 23:50:16 jempi-Kernel: [5052.517999] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
30. August 00:02:18 jempi-Kernel: [170.978988] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
30. August 23:58:03 jempi-Kernel: [8254.502431] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
2. September 00:33:28 jempi-Kernel: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012

Ich verwende das interne WLAN (wlan0) als AP und stecke einen Dongle (wlan1) ein, um eine Verbindung zu meinem Router herzustellen:
pi @ jempi : ~ $ ifconfig wlan0
wlan0 Link encap: Ethernet HWaddr b8: 27: eb: cf: db: b8
inet addr: 10.3.141.1 Bcast: 10.3.141.255 Maske: 255.255.255.0
inet6 addr: fe80 :: 6b56: 4657: 75cd: a501 / 64 Geltungsbereich: Link
UP BROADCAST RUNNING MULTICAST MTU: 1500 Metrisch: 1
Empfangspakete : 0 Fehler: 0 verworfen: 0 Überläufe: 0 Frame: 0
TX- Pakete: 30 Fehler: 0 verworfen: 0 Überläufe: 0 Träger: 0
Kollisionen: 0 t xqueuelen: 1000
RX- Bytes: 0 (0,0 B) TX- Bytes: 5492 (5,3 KiB)

pi @ jempi : ~ $ ifconfig wlan1
wlan1 Link encap: Ethernet HWaddr 00: 60: b3: db: 8a: 4a
inet addr: 192.168.1.74 Bcast: 192.168.1.255 Maske: 255.255.255.0
inet6 addr: fe80 :: 260: b3ff: fedb: 8a4a / 64 Geltungsbereich: Link
UP BROADCAST RUNNING MULTICAST MTU: 1500 Metrisch: 1
RX- Pakete: 1358 Fehler: 0 verworfen: 2 Überläufe: 0 Frame: 0
TX- Pakete: 789 Fehler: 0 verworfen: 0 Überläufe: 0 Träger: 0
Kollisionen: 0 t xqueuelen: 1000
Empfangsbytes: 256652 (250,6 KiB) TX- Bytes: 215250 (210,2 KiB)

Ich hatte Kernel 4.9.35-v7 + und habe ihn gestern auf 4.9.46-v7 + aktualisiert (mit RPI-Update), aber es hilft nicht. Eingabe von Syslog, wenn es fehlschlägt:

2. September 00:33:28 jempi-Kernel: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
2. September 00:34:00 jempi-Kernel: [6011.624839] brcmfmac: brcmf_netdev_wait_pend8021x: Zeitüberschreitung beim Warten auf keine ausstehenden 802.1x-Pakete
2. September 00:34:02 jempi-Kernel: [6014.184823] brcmfmac: send_key_to_dongle: wsec_key error (-110)
2. September 00:34:05 jempi-Kernel: [6016.744833] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON fehlgeschlagen -110
2. September 00:34:06 jempi-Kernel: [6017.704831] brcmfmac: brcmf_netdev_wait_pend8021x: Zeitüberschreitung beim Warten auf keine ausstehenden 802.1x-Pakete
2. September 00:34:08 jempi-Kernel: [6020.264850] brcmfmac: send_key_to_dongle: wsec_key error (-110)
2. September 00:34:11 jempi-Kernel: [6022.824903] brcmfmac: brcmf_cfg80211_change_station: Einstellen der SCB-Autorisierung (De-) ist fehlgeschlagen, -110

Starten Sie die wlan0-Schnittstelle mit sudo neu. Ifconfig wlan0 down und dann up hat nicht geholfen.

@bulrog Bitte geben Sie auch die Forensik an, wie von James oben erklärt.
Welchen Treiber verwendet wlan1? Tritt dieses Problem immer noch bei einem nicht angeschlossenen Dongle auf?

Noch ein paar forensische Aufnahmen:
https://pastebin.com/vqh3UcF3

Für den Fall, dass dies Cypress dabei hilft, im richtigen Bereich zu suchen: Ich habe dieses Problem schon viele Male erlebt und es scheint sich zu manifestieren, wenn ein Gerät versucht, eine Verbindung herzustellen. Es ist viele Male passiert, nachdem Sie in Reichweite des AP gegangen sind oder wenn ein Schlafgerät geweckt wurde.

Ich habe diese Konfiguration lange genug beibehalten, um die Forensik zu erfassen, und wenn ich weitere Details bereitstellen kann, würde ich dies gerne tun, aber die WLAN-Abstürze treten jetzt so häufig auf, dass mein Gerät dadurch unbrauchbar wird. Ich beabsichtige, einen anderen USB-WLAN-Dongle zu verwenden, um das interne Radio zu ersetzen, um Zuverlässigkeit zu erreichen.

Ich habe Ihre letzte Forensik an Cypress weitergegeben - danke, dass Sie sich die Zeit genommen haben.

Ich wollte mich nur einschalten. Ich habe genau das gleiche Problem bei drei RPI3s, auf denen die neueste Firmware ausgeführt wird. Ich benutze Octopi für alle drei und greife über Printoid darauf zu.

bcrmfmac.debug sollte brcmfmac.debug (danke, dass Sie @MilhouseVH entdeckt haben)
Ich werde die früheren Beiträge bearbeiten.

bcrmfmac.debug sollte brcmfmac.debug sein (danke, dass Sie @MilhouseVH entdeckt haben)
Ich werde die früheren Beiträge bearbeiten.

Auf dieser Grundlage ging ich davon aus, dass die von mir erfasste Forensik nicht vollständig war.

Ich habe die forensische Erfassung wiederholt. Sie kann unter der folgenden URL eingesehen werden:
https://pastebin.com/ha5rd7SW

Außerdem ist meine Datei /var/log/kern.log fast 200 MB groß und besteht größtenteils aus sehr ähnlichen Einträgen. Ich habe den Postfachfehler um 00:53:19 gefunden und einige Sekunden vor und nach dem Fehler abgeschnitten. Hoffentlich hilft es, sehen Sie es hier:
https://pastebin.com/JcE0zstS

Ich glaube, ich habe das gleiche Problem gefunden, siehe https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=192735

Ich kann es innerhalb von 5 Minuten reproduzieren. Sie benötigen viel Verkehr über WLAN (Kamera-Webinterface) und ein sehr geringes WLAN-Signal. Ich habe pi Null und es reicht aus, um Ihre Finger / Hände um die Bordantenne zu legen, um das Signal auf fast Null zu bringen (mein Router zeigt 15-20% Signal). Nach ca. 1 Minute in diesem Zustand stürzt das WLAN ab

@lategoodbye Nach einer Woche habe ich meinen Pi eingeschaltet und kein Problem, solange nichts den AP verwendet hat und nach einer Weile ein Problem aufgetreten ist, als ich mit meinem Telefon mit wlan0 verbunden war. Ich führe den Befehl aus und das Ergebnis finden Sie hier: https://pastebin.com/77tGfRcU

Für wlan1 habe ich einen ziemlich alten Dongle verwendet. Ich kann mich nicht erinnern, welchen Treiber ich installieren musste, um ihn zum Laufen zu bringen, aber das gibt lsusb für die von mir verwendete HW:

Bus 001 Gerät 005: ID 0 cde: 0008 Z-Com XG-703A 802.11g Drahtloser Adapter [Intersil ISL3887]

Ich weiß nicht, ob das hilft, aber hier ist meine Erfahrung:

Ich kaufte einen Pi3 und testete ihn einige Tage lang mit internem WLAN (nicht weit vom AP entfernt). Er schien ziemlich gut zu funktionieren (ich hatte keine hohen Bitraten erwartet, er musste nur für eine Remote-Shell über SSH nützlich sein ).

Nachdem es in ein Aluminiumgehäuse gesteckt worden war, schien es immer noch in Ordnung zu sein, aber dann wurde WLAN nach und nach unbrauchbar. Bis zu Minuten ohne Ping. Es gab immer noch Fälle, in denen es einige Sekunden lang sehr gut funktionierte, aber es wurde wieder auf die Erfahrung "Ein Tastendruck pro Sekunde" umgeschaltet oder es funktionierte überhaupt nicht mehr.

Es scheint keine "langsame, aber brauchbare" Verbindung zu geben, nur eine "sehr gute" oder eine "unbrauchbare". Dies kann an einem Fehler in der Firmware liegen. Ich habe keine Ahnung und ehrlich gesagt habe ich die Geduld verloren und stattdessen einen sehr kleinen USB-Dongle verwendet, der 100% stabil funktioniert.

Hat jemand eine Problemumgehung gefunden, um das Problem zu erkennen (im AP-Modus) und das WLAN-Gerät programmgesteuert zurückzusetzen?

Nicht, dass ich es gesehen hätte, ein Neustart der Benutzeroberfläche hat nicht geholfen. Für mich bestand die Eindämmung darin, ein externes WLAN-USB-Gerät zu kaufen, und es funktioniert wie ein Zauber, aber es ist schade, da ich jetzt das WLAN des Pi ausgeschaltet habe (seufz!)

Meinen Sie das Postfachproblem? Das wird bei Cypress noch untersucht.

Am 21. September 2017 um 08:38 Uhr schrieb "morel jerome" [email protected] :

Nicht, dass ich es gesehen hätte, ein Neustart der Benutzeroberfläche hat nicht geholfen. Für mich die Eindämmung
war ein externes WLAN USB-Gerät zu kaufen und es funktioniert wie ein Zauber, aber es ist
ein schade wie jetzt habe ich das wifi des pi ausgeschaltet (seufz!)

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
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= ,
oder schalten Sie den Thread stumm
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=
.

Ja, das Postfachproblem. Ich hoffe es wird behoben, aber als Containment musste ich auf ein externes Gerät umsteigen.

OK. In diesem Fall sind wir Cypress ausgeliefert - es handelt sich um ein Firmware-Problem, und sie sind die einzigen, die Zugriff haben. Ich werde sie immer wieder daran erinnern ... wir brauchen vielleicht etwas mehr Forensik, werden aber hier posten, wenn dies der Fall ist.

Mein WLAN trennt sich nach einigen Sekunden Inaktivität und verbindet sich wieder (ich gehe davon aus, dass dies Strom spart, obwohl ich es mit iw oder möglicherweise durch Interferenz deaktiviert habe). Ich bin mir nicht sicher, ob dies das gleiche Problem ist wie hier beschrieben (da die Verbindung sofort wieder hergestellt wird).

Wenn ich mich mit ssh -o ServerAliveInterval 5 ... , wird die Verbindung nicht mehr getrennt.

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

@asssaf ,
Nicht das Problem, wenn es wieder verbunden wird, ist es im Allgemeinen nur ein Latenzproblem, aber wenn es ohne Kopf über WLAN läuft (eines der wichtigsten potenziellen Merkmale des PiZero-W), wenn das WLAN ausfällt und sich nicht automatisch wieder verbindet, ist das System abgestürzt für alle praktischen Zwecke.

Selbst wenn ich HDMI, Maus und Tastatur unter starker Netzwerklast wie bei Motioneye habe, besteht die einzige Möglichkeit zur Wiederherstellung manchmal darin, das Gerät aus- und wieder einzuschalten.

Ich habe die Installation und Konfiguration von Motioneye auf einem Pi2 mit einem WiPi-USB-WiFi-Dongle wiederholt und bisher funktionierte es perfekt mit Lasten, die den PiZero-W in wenigen Stunden zuverlässig töteten. Für mich scheint dies ein Problem mit dem WLAN-Chip / Treiber zu sein und kein Problem mit Raspbian-Stretch.

@ PeterTheMaster1 @randyoo @joshfria

OK, Nachricht an alle, die das Postfachproblem regelmäßig sehen und etwas für mich testen können.

Wir haben eine Diagnose-Firmware von Cypress, mit deren Hilfe das Problem möglicherweise behoben werden kann. Wenn jemand mit dem Postfachproblem bereit wäre, diese Firmware auszuführen, und wenn das Postfachproblem auftritt, die Forensik sichern und die Ergebnisse hier veröffentlichen, ist dies eine große Hilfe. Beachten Sie, dass diese Firmware nur für diesen Test verwendet werden sollte, da sie nicht optimal ist! Bitte kommentieren Sie hier, wenn Sie den Test durchführen können, und ich werde mich mit der Firmware und den Anweisungen in Verbindung setzen.

@iurly : Ich habe ein Skript geschrieben, das das Problem

@ JamesH65 : Ich würde gerne weiterhelfen. Ist es eine neue Version der Diagnose-Firmware? Ich habe vor 3 Wochen (auf dieser Problemseite) eine forensische Erfassung mit der zuvor auf dieser Seite veröffentlichten Diagnose- / Debugging-Firmware veröffentlicht.

Ja, neue Firmware von Cypress ab Montag, 25. September. Es hat mehr
Diagnose darin. Die zuvor von Ihnen bereitgestellte Forensik wurde eingegrenzt
Das Problem ist jedoch, dass sie etwas detaillierter sein müssen. Ich habe eine Maschine betrieben
Bisher für 24 Stunden ohne Postfachfehler, daher kann es derzeit nicht repliziert werden
mich selber.

Kannst du mir eine E-Mail über James schicken? [email protected] und ich können Ihnen die Firmware besorgen. Ich möchte es nicht globaler veröffentlichen, weil es wirklich nur zu Testzwecken dient.

Am 27. September 2017 um 14:48 schrieb randyoo [email protected] :

@iurly https://github.com/iurly : Ich habe ein Skript geschrieben, das es erkennen würde
das Problem, und dann neu starten, da die Schnittstelle nach unten und oben bringen
hat nicht geholfen ... Bu dann wurde es so oft neu gestartet, dass ich nur eine bekommen konnte
nützliches Gerät, indem Sie es aus dem AP-Modus entfernen (und meinem AP AP-Aufgaben zuweisen
USB-Dongle)

@ JamesH65 https://github.com/jamesh65 : Ich würde gerne helfen, als
Vor. Ist es eine neue Version der Diagnose-Firmware? Ich habe eine gepostet
Forensics Capture vor 3 Wochen (auf dieser Issue-Seite) mit dem
Diagnose- / Debugging-Firmware, die weiter oben auf dieser Seite veröffentlicht wurde.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332526471 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHW_vEVuxFD-9RuxE003QZc_2NoFaks5smlIjgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

@ JamesH65 Wenn Sie so freundlich wären, einen Link zur neuen Firmware bereitzustellen, kann ich diese installieren und versuchen, die Forensik erneut zu erfassen, wie Sie es gewünscht haben.

Leider bedeutet das Bereitstellen eines Links hier, dass er öffentlich verfügbar ist, und
Da dies sehr viel eine Test-Firmware ist, wäre es mir lieber, wenn sie nicht entkommen würde
das wilde. Daher bitte per E-Mail zu tun. Wenn das ein Problem ist, werde ich hochladen
es irgendwo und kann einen Link posten.

Am 27. September 2017 um 15:56 schrieb randyoo [email protected] :

@ JamesH65 https://github.com/jamesh65 Wenn Sie so freundlich wären
Wenn Sie einen Link zur neuen Firmware bereitstellen, kann ich diese installieren und versuchen, sie zu erfassen
wieder Forensik, wie Sie es gewünscht hatten.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332548884 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHbVhHD2rk_hp3kG51WBY0R0IQzL3ks5smmIbgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

@ JamesH65 Ich weiß, dass die interne Wireless-Karte des RPI3 im AP-Modus regelmäßig eingefroren wird, daher wäre ich mehr als bereit zu helfen, aber ich bin mir nicht ganz sicher, ob es sich um ein Postfachproblem oder etwas anderes handelt. Ich habe meine Protokolle tatsächlich nach solchen Nachrichten durchsucht, sie aber nicht gefunden.

Ich verwende die mit Kernel 4.4.50 gelieferte Firmware (und kann aufgrund einer Regression nicht wirklich auf die neueste Version 4.9 aktualisieren, siehe # 2197). Würde diese Version diese Meldung anzeigen oder wurde diese zu einem späteren Zeitpunkt hinzugefügt?

Vielen Dank!

@iurly Sie sagten eine Sache richtig, das Absturzproblem in den Broadcom-Treibern tritt im AP-Modus auf, und ich weiß nicht, ob dies mit dem Postfachfehler zusammenhängt. Es scheint, dass es hier mehr als einen Fehler gibt. Vielleicht handelt es sich um einen Hardwarefehler, da das Problem zu dem Zeitpunkt besteht und keine Lösung gefunden wurde.

Was mich wirklich stört, ist das Fehlen einer Problemumgehung, ohne das gesamte System neu zu starten.
Ich meine, es gibt nicht einmal eine Möglichkeit, das Peripheriegerät zurückzusetzen und hostapd neu zu starten?!?

@iurly Sie sagten eine Sache richtig, das Absturzproblem in den Broadcom-Treibern tritt im AP-Modus auf, und ich weiß nicht, ob dies mit dem Postfachfehler zusammenhängt. Es scheint, dass es hier mehr als einen Fehler gibt. Vielleicht handelt es sich um einen Hardwarefehler, da das Problem zu dem Zeitpunkt besteht und keine Lösung gefunden wurde.

Nur zu Ihrer Information, ich habe auch Probleme im Client / Station-Modus. Ausführen von LEDE Master, 4.9 Kernel und Verwenden der Firmware 7.45.41.46.

@ JamesH65
Verstehen Sie den Wunsch, die Veröffentlichung der Test-Firmware zu verhindern. E-Mail wäre in Ordnung, aber ich möchte meine Adresse hier auch nicht öffentlich veröffentlichen, und ich sehe keine Möglichkeit, Nachrichten auf Github zu senden.

Verwenden Sie meine oben angegebene Pi-Adresse, um mir eine E-Mail zu senden, und ich werde Ihnen die Firmware senden.

Re. Ap-Modus
Seit 4.4 wurden einige Korrekturen vorgenommen. Es lohnt sich also, die neueste Strecke auszuprobieren
um zu sehen, ob dieses Problem weiterhin auftritt.

Ah, wenn Sie einen Kommentar bearbeiten, wird kein E-Mail-Update gesendet, und ich habe in meiner Pi-E-Mail den obigen Eintrag bearbeitet, sodass Sie möglicherweise nicht aktualisiert wurden. Verwenden Sie die Github-Website, um zu sehen, wo Sie mir eine E-Mail senden müssen.

@ JamesH65 Schickte Ihnen eine E-Mail. Ich bin froh zu hören, dass die vorherige forensische Erfassung zumindest dazu beigetragen hat, sie einzugrenzen ... Es sieht so aus, als würden sich viele Menschen freuen, wenn dieses Problem behoben ist.

@ JamesH65
Hier ist eine forensische Erfassung der Firmware, die Sie per E-Mail gesendet haben: https://pastebin.com/zdB36ttj
Ich hoffe es hilft.

Genial, wird an Cypress weitergegeben. Danke dafür.

Ich habe gerade einen Pi in einem Setup, wo ich ihn anscheinend nach Belieben reproduzieren kann. Wenn es hilfreich ist, mehr Forensik zu sammeln, lassen Sie es mich wissen. Der Postfachfehler ist alles, was ich in den Protokollen sehen kann.

Nachdem ich die microSD in meinem Zero W ausgetauscht habe, wurde sie 7 Tage lang ohne Probleme verbunden. Ich glaube nicht, dass es jemals so lange überlebt hat. Klingt seltsam, dass eine SD-Karte das WLAN beeinflussen könnte, aber da beide mit dem SDIO-Bus verbunden sind, kann es sein, dass eine die andere beeinflusst.

Die Karte, die ich zuvor verwendet habe, war eine (wahrscheinlich billige) 8-GB-Transcend-Klasse 4, die mit meinem UDOO Quad-Board geliefert wurde. Im Moment ist es ein Samsung EVO 32GB. Personen, die auf Probleme stoßen, möchten möglicherweise versuchen, ob die Verwendung einer anderen Karte hilfreich ist.

@stintel Interessant, aber vielleicht war es ein Problem beim Einstellen der Software auf der anderen microSD oder sogar eine beschädigte microSD.

Könnte das machtbezogen sein? Vielleicht hat die billige Karte momentan zu viel Strom aus dem Bus gezogen?

Ich habe Pelwells veröffentlichte Firmware geladen und eine RIESIGE Verbesserung festgestellt. Früher war ein SSH zu meinem Pi 0W wie das Einwählen in ein Terminal mit einem 2400-Baud-Modem und einer beschissenen Telefonleitung. Jetzt kann ich Remote X ausführen und es funktioniert großartig.

Vielen Dank!

Ich habe das gleiche Problem. Durch die Übertragung einer großen Anzahl von Dateinamen (Sync-over-FTP) von raspberryPi3-internal-wifi auf Galaxy S5 funktioniert das WLAN nicht mehr. aber manchmal funktioniert ...

Ich hatte das gleiche Problem mit der Postfachnachricht mit meinem RPi3-WLAN-AP, aber ich habe in diesem Forum eine Lösung gefunden, die bei mir funktioniert hat. Die Lösung bestand darin, die folgenden Parameter in /etc/hostapd/hostapd.conf zu ändern

wpa = 3 wurde in wpa = 2 geändertauth_algs = 3 wurde in auth_algs = 1 geändert

Ich habe es 1 Woche lang getestet und es werden keine Postfachprobleme mehr angezeigt.

Ich bin mir nicht sicher, ob es für euch alle funktionieren würde, aber ihr könnt es versuchen und hier posten, wenn es funktioniert.

Dies ist das funktionierende Hostapd, conf:

interface=wlan0
driver=nl80211
country_code=CO
ctrl_interface=wlan0
ctrl_interface_group=0
ssid=Mailbox Issue Test
hw_mode=g
channel=5
wpa=2
wpa_passphrase=mailbox
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
beacon_int=100
auth_algs=1
macaddr_acl=0
wmm_enabled=1
eap_reauth_period=360000000

Gibt es ein Update zu diesem Thema? Oder ist eine Problemumgehung bekannt?

Ich erlebe dies immer noch auf einem kürzlich gekauften Pi Zero W mit den neuesten stretch-lite und rpi-update von gestern.

Wenn ich das RPi verwende, um einen Kamera-Feed über RTSP (udp) zu streamen, kann ich sehen, dass sich die Verbindung drastisch verschlechtert, kurz bevor die WiFi-Verbindung unterbrochen wird. Danach wird die WiFi-Verbindung nie wieder hergestellt und ich muss den Pi0W aus- und wieder einschalten.

Ein dmesg > dmesg.log zeigt nur:

brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Wenn ich den Pi0W näher an meinen Zugangspunkt bewege, tritt das Problem nicht auf.

Ich verwende den Pi0W nicht als Zugangspunkt, sondern nur als Client. Ich habe verschiedene Stromquellen ausprobiert.

Wir warten derzeit auf Cypress, die Anbieter des drahtlosen Chips,
um das Problem voranzutreiben. Ich werde sie wieder anpingen.

Am 25. Oktober 2017 um 14:02 Uhr, Matthias Urhahn [email protected]
schrieb:

Gibt es ein Update zu diesem Thema? Oder ist eine Problemumgehung bekannt?

Ich erlebe dies immer noch auf einem kürzlich gekauften Pi Zero W mit dem neuesten
Stretch-Lite und RPI-Update ab gestern.

Wenn ich das RPi verwende, um einen Kamera-Feed über RTSP (udp) zu streamen, kann ich das sehen
Die Verbindung verschlechtert sich drastisch, kurz bevor die WLAN-Verbindung unterbrochen wird.
Danach wird die WiFi-Verbindung nie wieder hergestellt und ich muss das Gerät aus- und wieder einschalten
Pi0W.

Ein dmesg> dmesg.log zeigt nur:

brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012

Wenn ich den Pi0W näher an meinen Zugangspunkt bewege, tritt das Problem nicht auf.

Ich verwende den Pi0W nicht als Zugangspunkt, sondern nur als Client. Ich habe versucht
verschiedene Stromquellen.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-339322153 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHRlPhJBGXc3JFWbpw_Tf4_EKmgAeks5svzFQgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Nun ... Ich habe auf den neuesten Kernel / die neueste Firmware aktualisiert (apt-get upgrade, dann rpi-update), und jetzt verliert auch mein Pi3, der ein solides WLAN hatte, es nach ein paar Stunden !! Ich weiß, wenn es nicht kaputt ist, reparieren Sie es nicht ... hätte nicht aktualisiert werden sollen, aber da ich von Zeit zu Zeit Tests in meinem 2. Pi3 mit derselben SD-Karte durchführe.

FWIW, ich kann dieses Problem auch nach Belieben reproduzieren. Ich habe bei Raspberry Pi einen Forumsbeitrag erstellt, der das Problem erklärt:

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

HINWEIS: Ich verwende den Pi nicht als AP. Ich kann bei der Forensik helfen oder eine experimentelle Firmware usw. testen, wenn das hilft.

Selbes Problem hier. Ich habe ownCloud eingerichtet und kann problemlos Dateien von meinem Laptop übertragen.
Aber sobald ich Dateien mit meinem Samsung Galaxy S7 übertrage, bricht WLAN und
raspberrypi kernel: [ 962.273390] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012 :
erscheint.

Mein Router ist eine FRITZ! Box 7490.

Danke @srinathava für den Beitrag, der mein Problem gut beschreibt!

Können die Personen, die mit der Test-Firmware getestet haben, Folgendes versuchen - weitere Debug-Informationen, die von Cypress benötigt werden.

1. Wenn Sie insmod ausführen, fügen Sie "debug = 0x100000" hinzu.
2. Sobald das Problem auftritt, speichern Sie die Ausgabe "dmesg"

Vielen Dank.

Eine weitere Bitte um Hilfe in diesem Fall.

Können die Personen, die mit der Test-Firmware getestet haben (siehe oben), bitte Folgendes versuchen - weitere Debug-Informationen, die von Cypress benötigt werden.

Wenn Sie insmod ausführen, fügen Sie "debug = 0x100000" hinzu.
Sobald das Problem auftritt, speichern Sie die Ausgabe "dmesg" - dies ist das Bit, an dem wir interessiert sind.

Vielen Dank.

@ JamesH65 Nur um Sie wissen zu lassen, ich versuche jetzt, die Informationen zu sammeln, aber das Problem hat sich noch nicht gezeigt. Ich habe nur ein paar kleine Änderungen an der Datei /etc/hostapd/hostapd.conf vorgenommen, aber diese Änderungen haben dieses Problem möglicherweise versehentlich umgangen. Wenn das Problem nicht innerhalb weniger Tage auftritt, werde ich diese Änderungen rückgängig machen, um das Problem zu replizieren und die Debugdaten zu sammeln.

Danke für die Hilfe dazu.

Es wäre interessant zu sehen, welche Änderungen Sie an hostapd vorgenommen haben, wenn dies tatsächlich das Problem umgeht.

Nach 4 Tagen Stabilität habe ich meine Änderungen an der Datei /etc/hostapd/hostapd.conf zurückgesetzt, und nach nur wenigen Stunden trat das Problem erneut auf. Hier ist die Ausgabe von 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

Ich verwende ein Softwarepaket namens RaspAP und bin mir ziemlich sicher, dass es die Datei hostapd.conf in meinem Namen konfiguriert hat, obwohl ich nicht 100% sicher bin.

Wie auch immer, indem Sie diese Zeile in /etc/hostapd.conf auskommentieren: und ersetzen Sie es durch dieses: Ich hatte 4 Tage lang einen stabilen Betrieb, während er innerhalb weniger Stunden oder manchmal sogar Minuten abstürzte!

Hoffe das alles hilft.

Entschuldigung, wenn ich am falschen Ort poste, tritt beim Senden von UDP-Unicast-Paketen unter Raspbian ein seltsames Verhalten mit dem internen RPI3-WLAN (Broadcom) auf.
Ich sende einmal pro Sekunde ein kleines Datenpaket von 2 KB, am Empfängerseite wird dies alle 120 Sekunden für ca. 3-4 Sekunden blockiert. Dieser Test läuft wie am Schnürchen und ich kann mit iperf Folgendes reproduzieren

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

Ubuntu-PC als WiFi-Client mit RPi3 verbunden (IP 192.168.1.22 wie oben)

iperf -u -s -i 1

Garantiert alle 120 Sekunden eine Blockade. Interessanterweise scheint dies mit TCP nicht zu geschehen
Nachdem ich den Treibercode heruntergeladen und angesehen hatte (und nichts verstand), bemerkte ich schließlich eine verdächtige Erwähnung von

Definieren Sie BRCMF_SCAN_PASSIVE_TIME 120

Welches wird dann im Treibercode verwendet

Könnte dies zusammenhängen, ich bin am Ende meines Witzes und versuche zu lösen?
Danke

Ich habe Folgendes in /etc/rc.local eingefügt und meins scheint viel besser zu funktionieren:

Iwconfig wlan0 ausschalten

PI Null w

Sean

Am 19. Dezember 2017, um 03:42 Uhr, schrieb LeeMooreImperas [email protected] :

Entschuldigung, wenn ich am falschen Ort poste, tritt beim Senden von UDP-Unicast-Paketen unter Raspbian ein seltsames Verhalten mit dem internen RPI3-WLAN (Broadcom) auf.
Ich sende einmal pro Sekunde ein kleines Datenpaket von 2 KB, am Empfängerseite wird dies alle 120 Sekunden für ca. 3-4 Sekunden blockiert. Dieser Test läuft wie am Schnürchen und ich kann mit iperf Folgendes reproduzieren

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

Ubuntu-PC als WiFi-Client mit RPi3 verbunden (IP 192.168.1.22 wie oben)

iperf -u -s -i 1

Garantiert alle 120 Sekunden eine Blockade. Interessanterweise scheint dies mit TCP nicht zu geschehen
Nachdem ich den Treibercode heruntergeladen und angesehen hatte (und nichts verstand), bemerkte ich schließlich eine verdächtige Erwähnung von

Definieren Sie BRCMF_SCAN_PASSIVE_TIME 120

Welches wird dann im Treibercode verwendet

Könnte dies zusammenhängen, ich bin am Ende meines Witzes und versuche zu lösen?
Danke

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Hallo Sean
Vielen Dank für Heads-Ups, leider wird dies vom Broadcom-Gerät nicht akzeptiert, verstehe ich

Error for wireless request "Set Power Management" (8B2C) 
    Set failed on device wlan0; Invalid argument

Ich verwende jedoch den folgenden Befehl in meinem Setup, um das gleiche Ziel zu erreichen
$ iw dev wlan0 set power_save off
Dies wird akzeptiert und wenn ich nach Einstellungen frage
$ iwconfig wlan0
Ich verstehe
Power Management:off

So ziemlich sicher, dass die Energieeinsparung ausgeschaltet ist, aber dieses Problem nicht behebt
Danke

@LeeMooreImperas Ich schlage vor, ein separates Problem zu öffnen und mindestens die Kernel-Version und die Wifi-Firmware-Version bereitzustellen.

Ich habe diesen Thread vor langer Zeit kommentiert, musste dann aber aufhören, ihn anzusehen, weil ich ihn nicht mehr reproduzieren konnte. Nun, ich habe einige neue Daten und finde das sehr interessant.

Ich habe zwei Himbeer-Pis; ein B + V1.2 und ein original Raspberry PI (C) 2011.

Wenn ich auf dem RaspPi B + "4.1.19+ # 858 Di Mar 15 15:52:03 GMT 2016" ausführe, zeigt der Edimax WiFi-Chip das Problem, das andere gesehen haben.

Wenn ich "4.9.27+ # 1 Do 11 Mai 17:40:53 UTC 2017" auf demselben RaspPi B + ausführe, zeigt derselbe Edimax WiFi-Chip das Problem nicht an.

Ich frage mich jetzt, ob es eher eine Inkompatibilität mit der Hardware ist, und ich werde auch daran erinnert, dass bei viel älteren RaspPi-Karten das USB-WLAN ein spezielles Kabel benötigte, um die + 5V-Stromversorgung zu erhöhen, da die von der Karte kommende Energie nicht vorhanden war. t genug, um es zu fahren. Ich werde die SD-Karten so zurückschalten, dass sie das Problem aufweisen, und dann prüfen, ob dieser Kabeltyp hilft.

Ok, ich glaube ich hatte das falsch.

Das Ausführen von 4.9.27+ auf dem älteren RaspPi zeigt das Problem. Jetzt überprüfen.

Ok, das ist definitiv und sehr interessant.

Mit einer originalen Raspberry Pi-Karte (ca. 2011) und Linux 4.9.27+ (von "uname -a") kann ich das Problem reproduzieren, dass der Edimax USB-WLAN-Chip jedes Mal die WLAN-Verbindung und damit die IP-Adresse verliert innerhalb weniger Minuten.

Mit der gleichen originalen Raspberry Pi-Karte und der gleichen Linux-Version, aber der EINZIGEN Änderung, einfach ein USB-Kabel zu verwenden, mit dem ich die + 5V von einer sekundären Quelle auf das USB-WLAN erweitern kann, ist das System stabil.

Es scheint also definitiv ein Problem zu geben, dass die Edimax USB WiFi-Karte in diesem Setup nicht genügend Strom erhält. Dies hilft natürlich nicht denjenigen, die einen Raspberry Pi mit integriertem WLAN verwenden, aber in diesen Fällen frage ich mich, ob möglicherweise ein ähnliches Problem auftritt und ob möglicherweise ein Wechsel zu einem USB-Adapter möglich ist, der mehr Verstärker erzeugt ein Unterschied?

Es ist möglich, dass der Netz-zu-USB-Adapter, der den Pi mit Strom versorgt, in einigen Fällen keine sauberen 5 V liefert.
Da der Wechselstrom geregelt und dann geglättet werden muss, bevor er 5 V beträgt, kommt es dennoch zu einer gewissen Welligkeit des ausgegebenen Gleichstroms.
Die 5 V von einem Laptop oder PC sind eher welligkeitsfrei als ein billiges Netz-zu-USB-Ladegerät

Es wäre interessant, ein Oszilloskop an der Stromversorgung des WLAN-Chips unter verschiedenen Bedingungen anzubringen, um zu sehen, wie die Welligkeit während eines Ausfalls / Nichtausfalls aussieht

Bitte behalten Sie dieses Problem bei Problemen mit dem ONBOARD Brcm Wireless-Chip auf dem Pi3 bei. Wenn Sie Probleme mit anderen Geräten haben, nutzen Sie bitte das Forum, um Ratschläge zu erhalten. Dies ist einfach so, dass Informationen, die wir an Cypress weitergeben müssen, nicht zu verwirrt werden.

@ JamesH65
@lategoodbye

Hallo James, Stefan,
Daher widersprach das Problem, das ich protokollierte, in direktem Zusammenhang mit RPi3 BRCM WiFi.
Sollte dies also in einen anderen Thread gehen (wie von lategoodbye vorgeschlagen)?
Ich hätte gedacht, dass dieser Thread speziell mein Problem betrifft?

Ich bin froh, das Thema zu verschieben

Danke

@LeeMooreImperas Obwohl Ihr Problem mit der integrierten drahtlosen Verbindung besteht, tritt bei Ihnen alle 2 Minuten eine Pause auf. In diesem Problem wird ein vollständiger Fehler bei der drahtlosen Sperrung beschrieben, der in zufälligen Intervallen

Fügen Sie ein weiteres "Ich auch" hinzu.
Hardware: Raspberyy Pi 3, Modell B.
Kernel: Linux raspberrypi 4.9.70-v7 +
Betriebssystem: Raspbian GNU / Linux 9 (Stretch)
Geladenes Bild: 2017-11-29-raspbian-align.img
Bild MD5:
SDCard: Beim Hersteller nicht sicher, es wurde mit dem Kit geliefert
Schnittstellendatei: interfaces.txt
hostapd.conf: hostapd.txt
dmesg-Ausgabe (während der Arbeit): dmesg_20171230.txt

Das Gerät ist als Zugangspunkt für mein drahtloses Netzwerk konfiguriert. Mein primärer Router ist eine Linksys EA6400-Firmware-Version 1.1.40 (Build 184085). Sowohl Linksys als auch Pi bieten dieselbe SSID auf verschiedenen Kanälen an. Pi ist über eine Kabelverbindung mit einem nicht verwalteten Switch dazwischen mit dem Router verbunden.
Die Betriebssystemlast auf dem Gerät ist ziemlich frisch. Ich hatte ein RetroPie-Image auf dem System und hatte die gleichen Probleme. Ich lud nach Raspbian, um zu sehen, ob es besser funktionierte.
Ich sehe sporadische Aussetzer der Brücke. Das Hauptsymptom ist, dass das vom Pi bereitgestellte drahtlose Netzwerk vom kabelgebundenen Netzwerk isoliert zu sein scheint. Die kabelgebundene Schnittstelle funktioniert weiterhin normal und ich kann den Pi über SSH erreichen. Wenn ich in diesem Zustand einen tcpdump auf der drahtlosen Schnittstelle (wlan0) ausführe, kann ich immer noch Datenverkehr zu und von verbundenen Geräten sehen.
Das Durchlaufen der drahtlosen Verbindung (ifdown; ifup) scheint das Problem nicht zu beheben. Ich habe noch nicht versucht, die Bridge-Schnittstelle (br0) zu wechseln. Im Allgemeinen habe ich das Gerät neu gestartet, wodurch das Problem behoben wurde.
Ich bin nicht sicher, ob es verwandt ist; Das Problem scheint jedoch aufzutreten, wenn ich versuche, mein ChromeCast 2 zu steuern, nachdem es eine Weile ausgeführt wurde. Wenn ich beispielsweise eine Show über Netflix auf dem ChromeCast abspiele und dann versuche, die Show anzuhalten, scheint die Bridge zu diesem Zeitpunkt auszufallen. Ich konnte dies noch nicht über tcpdump abfangen. Aber das ist ein nächster Schritt für mich.
Ich habe darüber nachgedacht, dass es sich um ein Hitzeproblem handeln könnte. Ich hatte jedoch /opt/vc/bin/vcgencmd measure_temp in einer 30-Sekunden-Schleife während eines der Aussetzer und meine CPU-Temperatur lag im Bereich von 50 ° C. Ich bin mir nicht sicher, wie ich einen Temperaturmesswert auf dem LAN-Chip abrufen soll, da dort möglicherweise ein Hitzeproblem auftritt.

Ich bin froh, Protokolle / PCaps nach Bedarf zu erfassen, um das Problem weiter zu beheben. Bitte beachten Sie jedoch die Anweisungen, da ich einige Lücken in meinen Linux-Kenntnissen habe.

EDIT: hatte gerade einen Ausfall und machte ein sudo ifdown br0 && sudo ifup br0 und es scheint wieder angefangen zu haben zu arbeiten. Ich werde es bei meinem nächsten Ausstieg erneut testen.

EDIT2: Hier ist ein Dmesg-Dump, bei dem die Verbindung fehlgeschlagen ist. Die sudo ifdown br0 && sudo ifup br0 schienen diesmal die Verbindung nicht wiederherzustellen.
dmesg_20171220_failed.txt
Besonders hervorzuheben scheint der Fehler zu sein:
brcmfmac: brcmf_cfg80211_stop_ap: Einstellung des INFRA-Modus fehlgeschlagen -7

EDIT3: Dieser Thread ist auf ein ähnliches Problem gestoßen, das auf diesen Thread zurückgeht. Führen Sie die angeforderte Änderung am brcmfmac-Modul aus, um das Debuggen zu aktivieren. Hatte den Fehler ausgelöst und die dmesg-Ausgabe erfasst:
dmesg_debug_failed.txt
Außerdem bemerkte ich, dass im anderen Thread auch ein Samsung-Handy erwähnt wurde. Wir haben festgestellt, dass sich die Bridge-Probleme mit meinem Pi anscheinend um mein Samsung Galaxy S7 drehen. Die Apple-Geräte meiner Frau (iPhone und iPad) scheinen das Problem nicht auszulösen.

EDIT4: Ran a sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000 Gefolgt von dmesg erneut. Ausgabe unten:
dmesg_debug_failed_reset_driver.txt

Hmm, nicht der erwartete Postfachfehler. Ich werde es im neuen Jahr an die Cypress-Entwickler weitergeben.

Ich bin mir nicht sicher, ob dies das gleiche Problem ist, aber mein Symptom ist, dass RPi3 drahtlos intermittierend ist. 10 Sekunden gute Pings, gefolgt von 20-30 Sekunden ohne Pings, und für immer wiederholen. Wenn keine Pings vorhanden sind, empfängt der Remote-Host die ICMP-Echoanforderungen und sendet die ICMP-Echoantworten. Der Access Point gibt den ICMP-Host zurück, der für den Remote-Host nicht erreichbar ist.

Voraussetzung sind sowohl Ethernet als auch Wireless. Die Wahrscheinlichkeit, dass dies passiert, hat sich erheblich verbessert, da dhcpcd unnötig neu gestartet wurde.

Problemumgehung besteht darin, die Netzwerkschnittstelle in den Promiscuous-Modus zu versetzen. sudo ifconfig wlan0 promisc . Das Symptom kehrt innerhalb von zehn Sekunden zu einer Minute von sudo ifconfig wlan0 -promisc .

Weitere Informationen erhalten Sie bei Bedarf.

@ Sylver-Dragon, für mich hat ein tcpdump das Symptom verhindert, und vielleicht haben Sie das gleiche gefunden; Versuchen Sie das Flag -p , das den Promiscuous-Modus deaktiviert. es ließ das Symptom weitergehen.

https://github.com/iiab/iiab/issues/638

@quozl Ich habe versucht, tcpdump sowohl auf der drahtlosen Schnittstelle als auch auf der Bridge-Schnittstelle auszuführen, und hatte während der Ausführung Abstürze. Ich werde den Promiscuous-Modus ausprobieren und sehen, ob es einen Unterschied macht. Basierend auf der Debug-Ausgabe des Treibers für die drahtlose Schnittstelle, insbesondere:
wl0: _wlc_bss_update_beacon: out of mem, 0 Bytes malloced
Ich vermute, dies ist eine Art Ressourcenleck (Speicher?) Seitens des Treibers. Wenn ich etwas mehr Zeit habe, möchte ich eine Paketerfassung durchführen und mich mit dem Moment befassen, in dem sie abstürzt. Ich vermute, mein Telefon sendet entweder ein ungerades oder ein fehlerhaftes Paket oder eine Reihe von Paketen an das Gerät, das die Sperrung auslöst. Wenn ich das erfassen und isolieren kann, sollte es helfen, das Update zu informieren.

Sieht nach einem anderen Fehler aus als das Postfachproblem, das wir derzeit verfolgen. Welches ist ärgerlich. Ist Ihr Handy ein Samsung BTW? Das Postfachproblem scheint häufiger von SS-Geräten ausgelöst zu werden. Wenn Sie herausfinden können, was die Probleme verursacht, wäre dies sehr nützlich

Ich jage jetzt seit Wochen dasselbe (?). Ich habe das Gefühl, ich muss jeden Bericht über dieses und ähnliche Themen gelesen haben. Also hier noch ein paar Infos von mir:

Ich benutze das interne WLAN eines Himbeer-Pi 3 als Zugangspunkt. Ich verwende den Standard-Raspbian-Kernel und -Module (Linux-Version 4.9.35-v7 + (dc4 @ dc4-XPS13-9333) (gcc-Version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) # 1014 SMP Fr 30 Jun 14:47:43 BST 2017).

Wifi-Firmware ist: brcmfmac: Firmware-Version = wl0: 7. August 2017 00:46:29 Version 7.45.41.46 (r666254 CY) FWID 01-f8a78378

Ich bin mir ziemlich sicher, dass dieses Hardware-Setup früher funktioniert hat, aber nach einigen Updates (auch des Kernels), glaube ich, gingen die Dinge nach Süden. Das Erstellen des AP funktioniert einwandfrei, aber nach einiger Zeit (ca. 30 Minuten, nicht jedes Mal gleich) und Streaming mit einem Chromecast funktioniert die Verbindung nicht mehr. Es könnte sein (aber hier bin ich mir nicht sicher), dass dies am häufigsten passiert, wenn ich den Stream pausiere / stoppe, aber nur selten mitten im Anschauen. Wenn dies fehlschlägt, werden vorhandene Verbindungen getrennt und neue Verbindungsversuche werden von keinem Client akzeptiert. Das Neuladen von hostapd führt zu brcmf_cfg80211_stop_ap: setting INFRA mode failed -7 (Modus kann nicht auf Master gesetzt werden). Dies kann vorübergehend durch erneutes Laden des Treibers behoben werden: rmmod brcmfmac; modprobe brcmfmac . Die Dinge funktionieren dann wieder wie erwartet, bis sie das nächste Mal fehlschlagen. Alternativ "behebt" ein Neustart auch das Problem.

Das einzige, was ich im fehlgeschlagenen Zustand (mit aktiviertem Debug) in Syslog bekomme, ist:

Kernel: [3615.491795] brcmfmac: brcmf_netdev_wait_pend8021x: Zeitüberschreitung beim Warten auf keine ausstehenden 802.1x-Pakete
hostapd: wlan0: STA xx: xx: xx: xx: xx: xx IEEE 802.11: aufgrund lokaler Deauth-Anforderung nicht authentifiziert

Diese Fehlermeldung macht für mich keinen Sinn. Es ist eine Zeitüberschreitung, während auf "keine ausstehenden Pakete" gewartet wird? Wie auch immer:

Ich habe Strom sparen:

iw wlan0 get power_save Power save: off

roam_off wird auf 1 gesetzt und das Debuggen ist aktiviert:

`systool -a -v -m brcmfmac
Module = "brcmfmac"

Attribute:
coresize = "222874"
initsize = "0"
initstate = "live"
refcnt = "0"
srcversion = "10E8F4629D109E78E1F506C"
taint = ""
Ereignis =

Parameter:
alternative_fw_path =
debug = "1048576"
Roamoff = "1"
`

Ich habe kein Samsung-Handy, aber einige Android-Handys. Keines davon ist mit diesem Zugangspunkt verbunden. Die einzigen direkten Clients sind zwei Chromecasts (ein Video, ein Nur-Audio-Client sowie ein Android-Tablet). Alles andere kommt über die Kabelschnittstelle.

@ Knarrff
Bitte durchsuchen Sie diese Seite nach meinem vorherigen Kommentar von vor 3 Wochen für eine gute Problemumgehung.

@ JamesH65
Ich habe nie eine Bestätigung von dir bekommen. Haben Sie die dmesg-Ausgabe, die ich vor 3 Wochen von diesem Kommentar geteilt habe, an die Cypress-Leute kopiert / weitergeleitet?

@randyoo : Ich habe sowohl "rsn_pairwise = CCMP" als auch "wpa = 2" in meiner hostapd.conf. Hilft in meinem Fall nicht. Nicht geheime Einträge aus meiner Datei:
`
interface = wlan0

Treiber = nl80211
ssid = XXX
hw_mode = g
Kanal = 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
`

Es wird auch klar, dass der Fehler immer bei mir auftritt, wenn ich versuche, einen Netflix-Stream für den Chromecast anzuhalten (was nicht bedeutet, dass er immer fehlschlägt, wenn ich dies versuche, nur dass ich es getan habe, wenn es fehlschlägt ). Auf der anderen Seite könnte dies ein roter Hering sein, da ich dies fast die ganze Zeit mit diesem WLAN-Netzwerk mache. Es kann einfach sein, dass das Problem einfach auftritt, wenn ein Gerät versucht, sich beim AP zu authentifizieren (wie das Android-Tablet, das wahrscheinlich das WLAN im Schlaf deaktiviert hat). Weitere Tests werden zeigen. Ich werde es ohne Chromecast versuchen - nur normales WLAN auf dem Tablet, einschließlich WLAN-Schlafzyklen.

Sieht nicht so aus, als wäre mein Problem dasselbe wie dieses Problem, also wechsle ich in den Lauer-Modus. Mein ifconfig wlan0 promisc hat es für @holta (https://github.com/iiab/iiab/issues/638) ansehen .

Ich kann dies ohne Netflix oder Chromecast zuverlässig reproduzieren, indem ich über ein Google-Tablet eine Verbindung zum Netzwerk herstelle, das Tablet dann in den Ruhezustand versetze, wieder aufnehme (das Tablet versucht, die Verbindung wiederherzustellen), und in diesem Moment ist der AP "tot".

Auf einem Linux-Computer erhalte ich diese im Syslog, wenn ich versuche, sie zuzuordnen (unter Verwendung der richtigen Anmeldeinformationen):

`

[42231.476518] wlan7: sende auth an b8: 27: eb: 33: 98: 14 (versuche 1/3)
[42231.583434] wlan7: Authentifizierung an b8: 27: eb: 33: 98: 14 senden (versuchen Sie 2/3)
[42231.694397] wlan7: sende auth an b8: 27: eb: 33: 98: 14 (versuche 3/3)
[42231.799368] wlan7: Zeitüberschreitung bei Authentifizierung mit b8: 27: eb: 33: 98: 14
[42236.585750] wlan7: Authentifizierung mit b8: 27: eb: 33: 98: 14
[42236.598833] wlan7: sende auth an b8: 27: eb: 33: 98: 14 (versuche 1/3)
[42236.602344] wlan7: authentifiziert
[42236.603480] wlan7: assoziiere mit b8: 27: eb: 33: 98: 14 (versuche 1/3)
[42236.619322] wlan7: RX AssocResp von b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 aid = 1)
[42236.623181] wlan7: zugeordnet
[42236.623325] IPv6: ADDRCONF (NETDEV_CHANGE): wlan7: Link wird bereit
[42236.625464] wlan7: Begrenzung der Sendeleistung auf 30 (30 - 0) dBm gemäß b8: 27: eb: 33: 98: 14
[42239.730365] wlan7: von b8: 27: eb: 33: 98: 14 nicht authentifiziert (Grund: 2 = PREV_AUTH_NOT_VALID)
[42241.243434] wlan7: Authentifizierung mit b8: 27: eb: 33: 98: 14
[42241.256326] wlan7: sende auth an b8: 27: eb: 33: 98: 14 (versuche 1/3)
[42241.260724] wlan7: authentifiziert
[42241.263403] wlan7: assoziiere mit b8: 27: eb: 33: 98: 14 (versuche 1/3)
[42241.279537] wlan7: RX AssocResp von b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 aid = 1)
[42241.282500] wlan7: zugeordnet
[42241.336166] wlan7: Begrenzung der Sendeleistung auf 30 (30 - 0) dBm gemäß b8: 27: eb: 33: 98: 14
[42244.392213] wlan7: von b8: 27: eb: 33: 98: 14 nicht authentifiziert (Grund: 2 = PREV_AUTH_NOT_VALID)
[42253.916626] wlan7: Authentifizierung mit b8: 27: eb: 33: 98: 14
[42253.928966] wlan7: sende auth an b8: 27: eb: 33: 98: 14 (versuche 1/3)
[42253.936020] wlan7: authentifiziert
[42253.939533] wlan7: assoziiere mit b8: 27: eb: 33: 98: 14 (versuche 1/3)
[42253.943361] wlan7: RX AssocResp von b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 aid = 2)
[42253.945415] wlan7: zugeordnet
[42254.035149] wlan7: Begrenzung der Sendeleistung auf 30 (30 - 0) dBm gemäß b8: 27: eb: 33: 98: 14
[42257.053762] wlan7: von b8: 27: eb: 33: 98: 14 nicht authentifiziert (Grund: 2 = PREV_AUTH_NOT_VALID)
`

b8: 27: eb: 33: 98: 14 ist das fragliche RPI3, auf dem ich wieder die dmesg-Einträge bekomme:
brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets

Ich verstehe nicht ganz, warum der AP PREV_AUTH_NOT_VALID sendet, während ich anscheinend verbunden bin. Ich habe den Eindruck, dass die Authentifizierung vor der Zuordnung erfolgt. Es sollte keinen Fall geben, in dem ich verbunden, aber nicht authentifiziert bin.

Hallo

Ich verwende einen Pi3 als Medienserver. Die Kommunikation erfolgt über das integrierte WLAN

Upgrade-Update für Rasbian Stretch Lite 4.9 (jetzt)
Plex Media Server

Ich erhalte...

Kernel: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012

In Dmesg und Syslog ist dies beim Herstellen einer Verbindung zum Pi mit dem BubbleUPnp-Client auf einem Samsung S5 SM_G900F Android 7.1.2 so gut wie garantiert und erfordert einen Neustart, damit das PiWiFi wieder verwendet werden kann.

Auf meinem alten Sony Xperia XP Android 6.0.1 mit BubbleUPnp funktioniert es bisher einwandfrei. Das ist meine Lösung. Wenn ich Ihnen jedoch weiterhelfen kann, werde ich gerne einen Beitrag leisten.

John

Es funktioniert auch auf dem iPad mit mConnectLite

@johnthesoftwareathome Bitte schreiben Sie eine E-Mail von Raspberry Pi an James Hughes, damit er Ihnen eine Wifi-Debug-Firmware senden kann.

E-Mail-Adresse über die Raspberry Pi-Kontaktseite von James Hughes

OK, wir haben eine neue Debug-Firmware von Cypress, mit der ich testen möchte - diese enthält mehr Debug, aber keine Korrekturen, also nur für diejenigen, die gerne testen. Wenn Sie mir bereits Ihre E-Mail-Adresse gesendet haben, geben Sie hier an, dass Sie einige Tests durchführen möchten, und ich werde die Firmware senden, oder kontaktieren Sie mich per PM in den Pi-Foren.

Damit die Leute nicht mehr nach der Installation / Ausführung der neuen Firmware suchen.

Kopieren Sie die Debug-Firmware-Datei nach:

/lib/firmware/brcm/

(Sie möchten zuerst das Original sichern)

Ich denke, Sie müssen zu diesem Zeitpunkt neu starten.

Starten Sie nun den Linux-Treiber im Debug-Modus neu

sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000

Lass es schief gehen .. !!

Dump dmesg zum Ablegen und Posten hier.

Um das zu ergänzen, was James sagt, ziehen Sie es möglicherweise vor, die Sequenz rmmod / modprobe zu vermeiden, indem Sie brcmfmac.debug=0x100000 zu /boot/cmdline.txt hinzufügen.

@ JamesH65 Ich würde gerne beim Testen helfen. Obwohl ich mich gerade im Pi Forum registriert habe, kann ich keine Nachrichten senden. Verwenden Sie dort den gleichen Benutzernamen, wenn das hilft.

Ich habe gestern die neue Debug-Firmware ausprobiert und auch brcmfmac.debug = 0x100000 zu /boot/cmdline.txt hinzugefügt.

Seltsamerweise habe ich jedoch keine Debug-Ausgabe in dmesg gesehen. Noch seltsamer, wo ich das Problem vorher zuverlässig reproduzieren konnte, funktionierte es den ganzen Abend, unabhängig davon, was ich tat. Ich hatte kein einziges Problem und alles, was ich anders gemacht habe, war, die neue Firmware-Datei (md5 sum ba679a85c1dc76e9775603af45440bc0) anstelle der alten zu verwenden und den Eintrag zu /boot/cmdline.txt hinzuzufügen, anstatt die Option mit modprobe hinzuzufügen. Ich hatte gestern keine Zeit, zur alten Firmware zurückzukehren, um zu sehen, ob dies zu den alten Problemen zurückkehrt. Ich melde mich zurück, sobald ich es getan habe. In der Zwischenzeit: Ist alles, was sich in dieser Firmware geändert hat, wirklich "mehr Debug"?

Ich dachte, es wäre nur ein Debug, aber ich werde genauso deutlich zu Cypress zurückkehren
etwas anderes hat sich geändert, hoffentlich auf eine gute Weise!

Am 11. Januar 2018 um 06:48 schrieb Frank Löffler [email protected] :

Ich habe gestern die neue Debug-Firmware ausprobiert und auch hinzugefügt
brcmfmac.debug = 0x100000 to /boot/cmdline.txt.

Seltsamerweise habe ich jedoch keine Debug-Ausgabe in dmesg gesehen. Sogar mehr
Seltsamerweise funktionierte es, wo ich das Problem vorher zuverlässig reproduzieren konnte
den ganzen Abend, egal was ich getan habe. Ich hatte kein einziges Problem und
Ich habe nur die neue Firmware-Datei verwendet (MD5-Summe)
ba679a85c1dc76e9775603af45440bc0). Ich hatte gestern keine Zeit zu gehen
Zurück zur alten Firmware, um zu sehen, ob dies zu den alten Problemen zurückkehrt. Krank
melde dich zurück, sobald ich es getan habe. In der Zwischenzeit: hat sich daran alles geändert?
Firmware wirklich "mehr Debug"?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-356842102 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHam4jUgDCkSFxMXS-KW4axCLoPZhks5tJa6fgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Meine Erfahrung war ähnlich wie die von @knarrf , außer dass ich Debug-Meldungen in dmesg gesehen habe.

Früher war mein Samsung S5 als Plexserver-Client unbrauchbar, aber als ich die Debug-Firmware lud, funktionierte es (mit, wie ich bereits sagte, Debug-Meldungen in dmesg), sodass ich zu meiner ursprünglichen Binärdatei zurückkehrte (gesichert und Größe überprüft) und es immer noch funktioniert. Also laufe ich jetzt wieder mit der Debug-Firmware (ich habe den cmdline.txt-Mod nicht ausprobiert, nur den rmmod / modprobe) und habe einige Stunden Musik ohne Fehler gehört. Ich habe versucht, die meisten der vielen WiFi-Geräte, die ich verstreut habe, ohne Wirkung zu aktivieren.

Ich werde dies einige Tage lang versuchen, um festzustellen, ob etwas passiert. Laden Sie dann das Original neu und versuchen Sie es erneut. Möglicherweise habe ich den Pi zwischen den Neustarts nicht ausgeschaltet. Ich werde sicherstellen, dass ich dies tue, wenn ich zurückkehre, um zu sehen, ob es sich möglicherweise um eine Art Registeraufbewahrung handelt.

Heute Abend habe ich ältere Firmware hochgeladen (entnommen aus einem Raspian-Installationsimage; weitere Informationen zu den unten verwendeten Versionen) und das Modul damit neu geladen (und das Debugging aktiviert). Zwischendurch habe ich sogar einen Neustart durchgeführt. Die kurze Ausgabe in dmesg bestätigt, dass die alte Version jetzt geladen ist. Und wie bei @johnthesoftwareathome funktionierte es den ganzen Abend weiter, obwohl

Im Moment scheint es meine Aufgabe zu sein, es wieder auf "nicht funktionieren" zu bringen, um herauszufinden, was los ist. Mein nächster Versuch, obwohl nicht mehr heute, besteht darin, einen Hard-Reset durchzuführen (Strom für einige Zeit zu entfernen, anstatt nur den Befehl 'reboot' zu verwenden) und eine völlig neue Installation von einem neuen Image zu verwenden.

Außerdem kann ich leider nicht ausschließen, dass das Image, mit dem ich Fehler bekam, noch eine andere Version war, da ich vergessen habe, ein Backup zu erstellen, bevor ich es mit dem Debug-Image überschrieb. Vielleicht könnte @johnthesoftwareathome posten, mit welchem ​​Bild er genau arbeitet und Probleme hatte / hat? Andererseits habe ich damals nur die Firmware mit den Standardpaketen aktualisiert, und ich habe die Paketversion firmware-brcm80211 (1: 0.43 + rpi6) installiert. Obwohl der letzte Eintrag im Änderungsprotokoll nicht die Firmware-Version angibt, lautet der vorletzte: 7.45.41.26, der älter ist als der aus dem Image. Angenommen, das Änderungsprotokoll wurde korrekt geschrieben, wäre dies ein starker Hinweis darauf, dass die Firmware seit der Erstellung des Images nicht ersetzt wurde und dass das von mir als "Image" bezeichnete das zuvor verwendete ist.

Informationen zu meinen beiden Firmware-Dateien (Image: das aus dem Raspbian-Installations-Image, Debug: das, das ich direkt von @ JamesH65 erhalten habe :

debuggen:
Firmware-Version = wl0: 23. Oktober 2017 03:55:53 Version 7.45.98.38 (r674442 CY) FWID 01-e58d219f
md5sum: ba679a85c1dc76e9775603af45440bc0
Bild:
Firmware-Version = wl0: 7. August 2017 00:46:29 Version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
md5sum: 5f520a38ab4e943bfa1ba102f80fb2a0

@johnthesoftwareathome : Wie sieht die neue "Debug" -Ausgabe aus? Ich bekomme immer noch nichts, was auch nur aus der Ferne wie ein umfangreiches Debugging aussieht, unabhängig davon, wie ich das Modul lade. Ich bekomme während des Betriebs keine Einträge, und selbst nach dem Booten sieht alles etwas relevant aus:

als root: dmesg | grep brcm
[0.000000] Kernel-Befehlszeile: 8250.nr_uarts = 0 bcm2708_fb.fbwidth = 640 bcm2708_fb.fbheight = 480 bcm2708_fb.fbdepth = 16 bcm2708_fb.fbswap = 1 vc_mem.mem_b00 = 0x_m_ , 115200 console = tty1 root = PARTUUID = f8e4f7c2-02 rootfstype = ext4 liftator = Deadline fsck.repair = yes rootwait brcmfmac.debug = 0x100000
[3.500135] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[3.662113] brcmfmac: Firmware-Version = wl0: 7. August 2017 00:46:29 Version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[3.774278] brcmfmac: Energieverwaltung deaktiviert
[4.711443] brcmfmac: Energieverwaltung deaktiviert

Kleines Update: Wenn ich auf einen meiner älteren Kommentare in diesem Thread zurückblicke, kann ich tatsächlich bestätigen, dass die alte Firmware, die ich heute verwendet habe ('image'), die war, mit der ich Probleme hatte, bis ich das neuere Debug-Image ausprobiert habe.

Leeres Haus, also endlich Bowies letztes Album anhören. Alles hat perfekt funktioniert (das Album nicht so). Bis morgen von zu Hause weg, werde ich das dann abholen.

Es ist gelungen, die ursprüngliche Firmware wie zuvor zum Scheitern zu bringen, jedoch nicht zuverlässig zwischen der Verwendung und der Debug-Firmware. Derzeit wird nur ein Neustart mit dem Debug-Material ohne Fehler durchgeführt.

Ich habe falsch verstanden, was @knarrf über die Debug-Ausgabe bedeutete, und angenommen, dass er nicht sehen konnte, dass die neue Firmware installiert wurde, anstatt zu bedeuten, dass er eine Art Debug-Stream erwartete (den ich auch nicht sehen kann). Er hat ein Argument. Wenn dies fehlschlägt, sehen wir etwas oder ist das Debug-Hex falsch?

Auch einer der Fehler war nicht sofort erledigt. Es erlaubte mir, wieder einzuschalten, bevor ich einen Neustart benötigte. Syslog enthält Folgendes:

13. Januar 08:34:48 plexServer-Kernel: [46.648630] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
13. Januar 08:35:14 plexServer-Kernel: [72.161473] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
13. Januar 08:35:14 plexServer-Kernel: [72.161484] brcmfmac: brcmf_cfg80211_get_channel: chanspec fehlgeschlagen (-110)

Das ist eine sehr vertraute Reihe von Fehlermeldungen, aber es ist immer noch nützlich zu wissen, dass Sie das gleiche Problem hatten, das jetzt möglicherweise behoben ist.

Cypress bereitet eine neue Firmware-Version für uns vor - wir werden hier posten, wenn etwas zum Testen verfügbar ist. Vielen Dank an alle für Ihr Interesse, Ihre Zeit und Ihre Geduld.

OK. Vielen Dank für einen funktionierenden Fahrer.

Möglicherweise haben sich die Dinge seitdem weiterentwickelt.

https://tech4research.wordpress.com/2014/07/23/brcmfmac-debugging-and-eigniate-debug-values/

und ich schätze, dass der Debug-Schalter für die neue Firmware eine besondere Ergänzung sein kann, aber diese Schalter scheinen sowohl für die ursprüngliche als auch für die 'Debug'-Firmware' zu funktionieren, und der erwartete Debug-Strom wird ausgespuckt.

Wahrscheinlich schon gesehen worden; TPLink behauptet jedoch, dass Android-Geräte ihre Geräte mit MDNS-Paketen versorgen, wenn sie aus dem Ruhezustand aufwachen und versuchen, die Verbindung mit Chromecast oder ähnlichen Geräten wiederherzustellen.
Wenn ich mich in eine PC-Kappe stöbere, die ich von einem eigenen Gerät getrennt habe, sehe ich ~ 3.500 MDNS-Pakete, die innerhalb von ~ 2,25 Sekunden eingehen, kurz bevor meine Verbindung unterbrochen wird. Es scheint zu diesem Muster zu passen und kann verwandt sein.

Nur um einige Informationen in dieser Ausgabe hinzuzufügen / zu bestätigen:

• Das Einstellen der WLAN-Schnittstelle auf promiscuous ( ifconfig wlan0 promisc ) scheint das Problem zu mindern
• Das Problem scheint nur durch mein Android 7.1.2 Galaxy S7-Telefon verursacht zu sein (das ich vor einer Woche bekommen habe und zu diesem Zeitpunkt begannen die Probleme).

Ich führe Debian Buster mit aarch64 auf meinem Pi3 aus und starte einen Nextcloud-Server darauf. Das Scp'en größerer Dateien von einem Linux-Laptop verursacht keine Probleme und Nextcloud wird auch nicht von diesem Laptop synchronisiert. Sobald ich jedoch einen Stapel Dateien von der Galaxie hochlade, wird der Fehler Unknown mailbox data content: 0x40012 angezeigt und die WLAN-Konnektivität wird angezeigt hat verloren.

Die von mir verwendete brcmfmac-Firmware ist 7.45.41.26 (r640327) FWID 01-4527cfab

Leider habe ich kein älteres Android zum Testen.

Ich habe einen Upload vom Samsung auf den Pi3 getcpdumped, aber dann war das Wifi im Promiscuous-Modus und alles hat gut funktioniert. Wenn ich die Zeit finde, werde ich einen Blick auf die PCAP werfen und zurückmelden, wenn ich etwas Nützliches / Interessantes finde.

PS: Cast (der im TPLink-Artikel beschriebene Haupttäter) ist nicht aktiv (oder zumindest kann ich ihn in den Konnektivitätseinstellungen nicht sehen).

Hallo allerseits,

Ich möchte nur bestätigen, dass das Ausschalten des Powersafe-Modus und das Aktivieren des Promiscuis-Modus das Problem für mich behoben hat: Zum ersten Mal konnte es 24 Stunden lang in Verbindung bleiben.

sudo iw wlan0 set power_save off
sudo ifconfig wlan0 promisc

Vielen Dank,
Luc

Weitere Informationen zu einer neuen Firmware-Version finden Sie in diesem Forumsbeitrag. Jeder, der das Postfachproblem oder tatsächlich Probleme mit dem WLAN sieht, sollte dies ausprobieren, um festzustellen, ob es hilft.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508

@ JamesH65
Hallo James,
Können Sie einige Installationsanweisungen bereitstellen? Ist die .bin-Datei im Archiv eine selbstinstallierende ausführbare Datei?
Danke
Lee

Anleitung jetzt auf der verlinkten Forenseite.

Einchecken nach mehr als einer Woche Ausführen der neuen Firmware. Bisher war es solide. Ich habe mein Samsung-Gerät nach langer Zeit wiederholt aufgeweckt und die drahtlose Schnittstelle auf meinem Pi läuft weiter. Ich glaube, ich hatte einen Fall, in dem es vorübergehend abfiel und sich dann erholte. Das konnte ich allerdings nicht reproduzieren. Alles in allem sieht es solide aus. Vielen Dank an James, der daran festgehalten hat, und an das Cypress-Team, das dieses Problem behoben hat.

Danke für den Bericht.

Kann mir jemand sagen, ob das Firmware-Update es bereits in der offiziellen Raspbian-Distribution geschafft hat, damit es über apt update installiert werden kann, oder wenn noch nicht, informieren Sie mich, nachdem dies der Fall war?

Kann mir jemand sagen, ob das Firmware-Update es bereits in der offiziellen Raspbian-Distribution geschafft hat, damit es über ein passendes Update installiert werden kann, oder wenn noch nicht, informieren Sie mich, nachdem dies der Fall war?

Ja. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508&start=25#p1270212
Einige Probleme werden nach der allgemeinen Aktualisierung auf Pi0W gemeldet, aber es ist nicht ganz klar, ob es sich nur um eine Firmware-Änderung oder etwas anderes handelt - https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=204882

Ich habe die Firmware aktualisiert

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.bin
ba679a85c1dc76e9775603af45440bc0  /lib/firmware/brcm/brcmfmac43430-sdio.bin

habe aber immer noch das gleiche Problem

$ 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

Das Folgende vermeidet dieses Problem ebenfalls nicht

sudo iw wlan0 set power_save off
sudo ifconfig wlan0 promisc

Ich verwende das RPi3 als Zugangspunkt mit hostapd und dnsmasq .
Ich kann das Problem immer reproduzieren, wenn ich einen Download in der Spotify-App auf meinem Android-Handy starte.

Muss ich auch die folgende Datei aktualisieren?

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.txt
9a88b55134d9f8f3ad2331b93f4b7b79  /lib/firmware/brcm/brcmfmac43430-sdio.txt

Wird es vom Fahrer verwendet oder kann es ignoriert werden?

Bearbeiten:
Ja. Die Datei brcmfmac43430-sdio.txt ist ebenfalls erforderlich.
Ich verwende jedoch die neuesten besten Versionen von https://github.com/RPi-Distro/firmware-nonfree/tree/927fa8ebdf5bcfb90944465b40ec4981e01d6015/brcm

Ich habe auch meinen 4.9.35-v7 + -Kernel auf 4.14.18-v7 + aktualisiert.
Das Problem besteht jedoch weiterhin.

Auf meinem RPi3 tritt das gleiche Problem auf: Wifi wird nach einiger Betriebszeit (z. B. über Nacht) fast ohne Verkehr gelöscht.
Die dmesg-Ausgabe zeigt nur:

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

Ich habe versucht, den Treiber neu zu laden (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

Das hat irgendwie nicht funktioniert - Treiber geladen, aber nein, ich habe keine Schnittstelle
Versuchte nochmal:

[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

..und ich bin wieder auf.

Pi3 führt den Kernel '4.14.24-v7 + # 1097' aus - die Firmware ist die ältere vom 7. August 2017 - derselbe Firmware-Blob, der auf einem Pi Zero W-Kernel '4.9.77+ # 1081' einwandfrei funktioniert (Betriebszeit> 2 Monate).
Beide Pis sind mit demselben Router und einem Raum voneinander verbunden. Beide sind nur über WLAN verbunden.

Es lohnt sich wahrscheinlich, die neueste Firmware für 4.14 zu verwenden, da 4.14 alle erforderlichen Änderungen enthält, um mit dieser Firmware zu arbeiten.

:) Aktualisiert auf die neueste fw (23.10.2017 03:55:53 Version 7.45.98.38) gestern nach dem Posten - scheint atm zu funktionieren - mal sehen, was passiert ..

Es scheint, dass Raspbian auf das Firmware-Paket vom August 2017 zurückgegriffen hat. Gibt es neue Anforderungen für das RPI 3B + Wireless?

Das Stretch-Repo- Firmware-brcm80211 1: 20161130-3 + -Rpt3- Paket der neuesten Foundation enthält die

Ich habe auch dieses Problem mit dem Sterben von WLAN.

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

Dies ist mit 4.14.27-v7 + und mit
/ sbin / iw dev wlan0 setzt power_save aus
/ sbin / ifconfig wlan0 promisc
in /etc/rc.local.

gleiche Fehlermeldungen wie bei @ flok99 - unter Verwendung der neuesten Firmware (RPI-Update) auf Stretch.

OK, der Fehler, den Cypress behoben haben soll, ist also immer noch vorhanden. Zurück zu
Zypresse geht es. Es hat ein Jahr gedauert, um diese Version zu bekommen. Atem anhalten nicht
empfohlen.

Muss die Version allerdings bestätigen, bitte poste den Inhalt von

dmesg | grep brcmfmac

Am 18. März 2018 um 01:44 schrieb Rebroad [email protected] :

gleiche Fehlermeldungen wie @ flok99 https://github.com/flok99 - mit neuesten
Firmware (RPI-Update) auf Stretch.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373966343 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHY1Cmntz_kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

[4.112717] brcmfmac: F1-Signatur read @ 0x18000000 = 0x15264345
[4.119827] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm / brcmfmac43455-sdio.bin für Chip 0x004345 (17221) rev 0x000006
[4.120314] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[4.440371] brcmfmac: brcmf_c_preinit_dcmds: Firmware-Version = wl0: Feb.
27 2018 03:15:32 Version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[4.440958] brcmfmac: brcmf_c_preinit_dcmds: CLM-Version = API: 12.2
Daten: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Erstellung: 2018-03-09
18:56:28
[10.911757] brcmfmac: Energieverwaltung deaktiviert
[12.016088] brcmfmac: Energieverwaltung deaktiviert
[2074.090674] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
fehlgeschlagen mit Status -5
[2074.090687] brcmfmac: brcmf_cfg80211_get_tx_power: Fehler (-5)
[2074.090745] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[2074.090753] brcmfmac: brcmf_link_down: WLC_DISASSOC fehlgeschlagen (-5)
[2074.610583] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[2074.611992] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[2074.613945] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[2074.613971] brcmfmac: brcmf_cfg80211_get_channel: chanspec fehlgeschlagen (-5)
[2074.729716] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[2074.729733] brcmfmac: brcmf_cfg80211_reg_notifier: Ländercode iovar
gab err = -5 zurück
[2074.871693] usbcore: Abmelden des Schnittstellentreibers brcmfmac
[2074.929084] brcmfmac: F1-Signatur read @ 0x18000000 = 0x15264345
[2074.936897] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm / brcmfmac43455-sdio.bin für Chip 0x004345 (17221) rev 0x000006
[2074.937139] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[2075.118180] brcmfmac: brcmf_c_preinit_dcmds: Firmware-Version = wl0: Feb.
27 2018 03:15:32 Version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2075.118706] brcmfmac: brcmf_c_preinit_dcmds: CLM-Version = API: 12.2
Daten: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Erstellung: 2018-03-09
18:56:28
[2075.215365] brcmfmac: Energieverwaltung deaktiviert
[2075.263751] brcmfmac: Energieverwaltung deaktiviert
[2085.475001] brcmfmac: Energieverwaltung deaktiviert
[2124.380808] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[2124.381146] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[2124.381156] brcmfmac: brcmf_cfg80211_get_channel: chanspec fehlgeschlagen (-5)
[2124.622345] usbcore: Abmelden des Schnittstellentreibers brcmfmac
[2124.705432] brcmfmac: F1-Signatur read @ 0x18000000 = 0x15264345
[2124.714194] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm / brcmfmac43455-sdio.bin für Chip 0x004345 (17221) rev 0x000006
[2124.716213] usbcore: neuer Schnittstellentreiber brcmfmac registriert
[2124.929556] brcmfmac: brcmf_c_preinit_dcmds: Firmware-Version = wl0: Feb.
27 2018 03:15:32 Version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2124.929993] brcmfmac: brcmf_c_preinit_dcmds: CLM-Version = API: 12.2
Daten: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Erstellung: 2018-03-09
18:56:28
[2125.105218] brcmfmac: Energieverwaltung deaktiviert
[2125.150290] brcmfmac: Energieverwaltung deaktiviert
[8237.434034] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt:
0x40012
[8239.890302] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[8239.890822] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[8239.890835] brcmfmac: brcmf_run_escan: error (-110)
[8239.890845] brcmfmac: brcmf_cfg80211_scan: Scanfehler (-110)
[8254.280425] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
fehlgeschlagen mit Status -5
[8254.280438] brcmfmac: brcmf_cfg80211_get_tx_power: Fehler (-5)
[8254.280491] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8254.280498] brcmfmac: brcmf_link_down: WLC_DISASSOC fehlgeschlagen (-5)
[8254.800394] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8254.803873] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8254.808353] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8254.808370] brcmfmac: brcmf_cfg80211_get_channel: chanspec fehlgeschlagen (-5)
[8254.881402] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8254.881420] brcmfmac: brcmf_cfg80211_reg_notifier: Ländercode iovar
gab err = -5 zurück
[8255.001550] usbcore: Abmelden des Schnittstellentreibers brcmfmac
[8255.071184] brcmfmac: F1-Signatur read @ 0x18000000 = 0x15264345
[8255.077098] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm / brcmfmac43455-sdio.bin für Chip 0x004345 (17221) rev 0x000006
[8255.077348] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[8257.730418] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[8257.751038] brcmfmac: brcmf_c_get_clm_name: Abrufen von Revisionsinformationen
fehlgeschlagen (-110)
[8257.751049] brcmfmac: brcmf_c_process_clm_blob: CLM-Blob-Dateinamen abrufen
fehlgeschlagen (-110)
[8257.751068] brcmfmac: brcmf_c_preinit_dcmds: CLM-Blob-Datei herunterladen
fehlgeschlagen, -110
[8257.751076] brcmfmac: brcmf_bus_started: fehlgeschlagen: -110
[8257.751114] brcmfmac: brcmf_sdio_firmware_callback: Dongle nicht
reagieren
[8304.417684] usbcore: Abmelden des Schnittstellentreibers brcmfmac
[8304.486099] brcmfmac: F1-Signatur read @ 0x18000000 = 0x15264345
[8304.493613] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm / brcmfmac43455-sdio.bin für Chip 0x004345 (17221) rev 0x000006
[8304.494078] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[8304.686761] brcmfmac: brcmf_c_preinit_dcmds: Firmware-Version = wl0: Feb.
27 2018 03:15:32 Version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8304.687203] brcmfmac: brcmf_c_preinit_dcmds: CLM-Version = API: 12.2
Daten: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Erstellung: 2018-03-09
18:56:28
[8304.829994] brcmfmac: Energieverwaltung deaktiviert
[8304.907662] brcmfmac: Energieverwaltung deaktiviert
[8357.441791] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt:
0x40012
[8359.891146] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[8359.891655] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[8359.891668] brcmfmac: brcmf_run_escan: error (-110)
[8359.891677] brcmfmac: brcmf_cfg80211_scan: Scanfehler (-110)
[8371.731226] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[8371.731731] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[8371.731746] brcmfmac: brcmf_cfg80211_get_channel: chanspec fehlgeschlagen (-110)
[8373.941267] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
fehlgeschlagen mit Status -5
[8373.941280] brcmfmac: brcmf_cfg80211_get_tx_power: Fehler (-5)
[8373.941330] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8373.941338] brcmfmac: brcmf_link_down: WLC_DISASSOC fehlgeschlagen (-5)
[8374.461245] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8374.461942] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8374.463553] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8374.463573] brcmfmac: brcmf_cfg80211_get_channel: chanspec fehlgeschlagen (-5)
[8374.564729] brcmfmac: brcmf_fil_cmd_data: Bus ist ausgefallen. wir haben nichts
machen.
[8374.564750] brcmfmac: brcmf_cfg80211_reg_notifier: Ländercode iovar
gab err = -5 zurück
[8374.702401] usbcore: Abmelden des Schnittstellentreibers brcmfmac
[8374.759839] brcmfmac: F1-Signatur read @ 0x18000000 = 0x15264345
[8374.767561] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm / brcmfmac43455-sdio.bin für Chip 0x004345 (17221) rev 0x000006
[8374.771137] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[8377.411255] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[8377.431924] brcmfmac: brcmf_c_get_clm_name: Abrufen von Revisionsinformationen
fehlgeschlagen (-110)
[8377.431934] brcmfmac: brcmf_c_process_clm_blob: CLM-Blob-Dateinamen abrufen
fehlgeschlagen (-110)
[8377.431941] brcmfmac: brcmf_c_preinit_dcmds: CLM-Blob-Datei herunterladen
fehlgeschlagen, -110
[8377.431949] brcmfmac: brcmf_bus_started: fehlgeschlagen: -110
[8377.432003] brcmfmac: brcmf_sdio_firmware_callback: Dongle nicht
reagieren
[8424.133114] usbcore: Abmelden des Schnittstellentreibers brcmfmac
[8424.229631] brcmfmac: F1-Signatur read @ 0x18000000 = 0x15264345
[8424.237210] brcmfmac: brcmf_fw_map_chip_to_name: using
brcm / brcmfmac43455-sdio.bin für Chip 0x004345 (17221) rev 0x000006
[8424.239352] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[8424.460736] brcmfmac: brcmf_c_preinit_dcmds: Firmware-Version = wl0: Feb.
27 2018 03:15:32 Version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8424.461174] brcmfmac: brcmf_c_preinit_dcmds: CLM-Version = API: 12.2
Daten: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Erstellung: 2018-03-09
18:56:28
[8424.646993] brcmfmac: Energieverwaltung deaktiviert
[8424.708633] brcmfmac: Energieverwaltung deaktiviert

Am Sonntag, den 18. März 2018 um 11:30 Uhr, James Hughes [email protected]
schrieb:

OK, der Fehler, den Cypress behoben haben soll, ist also immer noch vorhanden. Zurück zu
Zypresse geht es. Es hat ein Jahr gedauert, um diese Version zu bekommen. Atem anhalten nicht
empfohlen.

Muss die Version allerdings bestätigen, bitte poste den Inhalt von

dmesg | grep brcmfmac

Am 18. März 2018 um 01:44 schrieb Rebroad [email protected] :

gleiche Fehlermeldungen wie @ flok99 https://github.com/flok99 - using
neueste
Firmware (RPI-Update) auf Stretch.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -373966343
,
oder schalten Sie den Thread stumm
kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5>
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373987387 ,
oder schalten Sie den Thread stumm
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 

Sieht so ziemlich so aus, als wären Sie auf einem neueren Pi3b + und nicht auf einem originalen Pi3: Also vielleicht eine andere Sache?

Völlig anderer Chip und Firmware, obwohl der Linux-Seitentreiber der ist
gleich. (brcmfmac).

Am 19. März 2018 um 16:26 schrieb macmpi [email protected] :

@ flok99 https://github.com/flok99

brcmfmac: brcmf_fw_map_chip_to_name: Verwenden von brcm / brcmfmac43455-sdio.bin für den Chip
Firmware-Version = wl0: 27. Februar 2018 03:15:32 Version 7.45.154 (r684107 CY) FWID 01-4fbe0b04

Sieht so ziemlich so aus, als wären Sie auf einem neueren Pi3b + und nicht auf einem originalen Pi3: also
vielleicht eine andere Sache?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/raspberrypi/linux/issues/1342#issuecomment-374274045 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/ADqrHeP6-sc-P-OSggQFPrl3O8z_B2aRks5tf9wbgaJpZM4HupC5
.

- -
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd.

Ich denke, es ist am besten, einen anderen Thread für Pi3B + -Probleme zu haben und bei Bedarf auf diesen zurückzugreifen, da es sonst sehr schwierig sein wird, ihn zu verfolgen. Kann @ flok99 bitte eine neue Ausgabe mit seinen Berichten erstellen, um sicherzustellen, dass sich der Titel auf die 3b + bezieht. Ich werde den Titel dieses Artikels ändern, um ihn nur für Pi3B wiederzugeben.

erledigt

Hat jemand, der dieses Problem abonniert hat und 3B (nicht plus) ausführt, immer noch die Probleme mit der neuesten Firmware und dem neuesten Kernel gesehen? Ich hätte gerne Berichte über anhaltende Misserfolge - die letzten Beiträge zu dem oben genannten Thema scheinen zu implizieren, dass die Dinge jetzt in Ordnung sind.

Mein 3B ist seit 44 Tagen damit:

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

Keine Probleme seitdem ..

Gute Nachrichten. Sofern ich nichts anderes höre, werde ich diesen Thread wahrscheinlich in ein oder zwei Wochen schließen, obwohl er jederzeit wieder geöffnet werden kann, wenn Probleme erneut auftreten.

Ich hatte vor ungefähr einer Woche angefangen, dieses Problem zu haben, nachdem ich vorher noch nichts davon gehört hatte. Ich benutze das pi auch am häufigsten mit einem Samsung-Telefon als Router - meins ist ein s4. Ich schreibe dies direkt mit dem s4 über USB verbunden, dh mit rndis. Hier sind meine Details vom heutigen Boot:
0 aktualisiert, 0 neu installiert, 0 entfernt und 0 nicht aktualisiert.
thenry @ pi3portable : ~ $ dmesg | grep brcmfmac
[9.965782] brcmfmac: F1-Signatur read @ 0x18000000 = 0x1541a9a6
[9.972059] brcmfmac: brcmf_fw_map_chip_to_name: Verwenden von brcm / brcmfmac43430-sdio.bin für Chip 0x00a9a6 (43430) rev 0x000001
[9.972250] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[10.147562] brcmfmac: brcmf_c_preinit_dcmds: Firmware-Version = wl0: 7. August 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 Daten: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Erstellung: 2014-05-26 10:53:55 Inc Daten: 9.10.41 Inc Compiler: 1.29 .4 Inc ClmImport: 1.36.3 Erstellung: 2017-08-07 00:37:47
[18.538641] brcmfmac: Energieverwaltung deaktiviert
[30.629545] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
[33.191450] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[33.194850] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[35.751496] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[35.754898] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[35.754906] brcmfmac: brcmf_pno_clean: Code -110 fehlgeschlagen
[43.271438] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[43.274800] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[43.274807] brcmfmac: brcmf_do_escan: error (-110)
[43.274811] brcmfmac: brcmf_cfg80211_scan: Scanfehler (-110)
[7673.758073] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[7673.761437] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[7673.761454] brcmfmac: _brcmf_set_multicast_list: Das Festlegen von mcast_list ist fehlgeschlagen, -110
[7676.328075] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[7676.331449] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[7676.331466] brcmfmac: _brcmf_set_multicast_list: Das Einstellen von allmulti ist fehlgeschlagen, -110
[7678.878084] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[7678.881460] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[7681.448101] brcmfmac: _brcmf_set_multicast_list: Das Setzen von BRCMF_C_SET_PROMISC ist fehlgeschlagen, -110
[7689.118098] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
[7689.118241] brcmfmac: Energieverwaltung deaktiviert
[7691.678100] brcmfmac: brcmf_cfg80211_set_power_mgmt: Fehler (-110)
[7694.238122] brcmfmac: _brcmf_set_multicast_list: Das Festlegen von mcast_list ist fehlgeschlagen, -110
[7696.798118] brcmfmac: _brcmf_set_multicast_list: Das Einstellen von allmulti ist fehlgeschlagen, -110
[7699.358158] brcmfmac: brcmf_do_escan: error (-110)
[7699.358167] brcmfmac: brcmf_cfg80211_scan: Scanfehler (-110)
[7701.918127] brcmfmac: _brcmf_set_multicast_list: Das Setzen von BRCMF_C_SET_PROMISC ist fehlgeschlagen, -110
[11406.881341] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg fehlgeschlagen mit Status -110
[11406.881352] brcmfmac: brcmf_cfg80211_reg_notifier: Der Ländercode iovar hat err = -110 zurückgegeben
[11579.921479] brcmfmac: _brcmf_set_multicast_list: Das Festlegen von mcast_list ist fehlgeschlagen, -110
[11582.491485] brcmfmac: _brcmf_set_multicast_list: Das Einstellen von allmulti ist fehlgeschlagen, -110
[11587.611478] brcmfmac: _brcmf_set_multicast_list: Das Setzen von BRCMF_C_SET_PROMISC ist fehlgeschlagen, -110
thenry @ pi3portable : ~ $
thenry @ pi3portable : ~ $ uname -a
Linux pi3portable 4.14.27-v7 + # 1100 SMP Fr 16. März 13:51:48 GMT 2018 armv7l GNU / Linux
thenry @ pi3portable : ~ $
Ich verwende diesen Kernel, weil ich beim Testen des Bootens von USB zum nächsten Stream gewechselt bin und mich danach nicht mehr geändert habe. Dann bekam ich die Nachricht über den neuen Kernel (4.14) und beschloss, das vor ungefähr einem Monat zu versuchen. Es war in Ordnung, keine Probleme bis zu diesem. Nur eine weitere wichtige Änderung ist, dass ich vor einigen Tagen von NetworkManager zu systemd-networkd gewechselt bin, aber das ist, nachdem sich dieses Problem zum ersten Mal gezeigt hat.
Grüße,
Trevor Henry

Aktualisieren:
Nachdem ich alle zugehörigen Beiträge gelesen hatte, fand ich die neueste Firmware im Beitrag https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508
und das hat mein Problem behoben.

Testversion von brcmfmas43430-sdio.bin installiert 250418

Version 7.45.98.38 23. Oktober 2017, ersetzte Version 7.45.41.46 7. August 2017

Vor:

[10.368086] brcmfmac: F1-Signatur read @ 0x18000000 = 0x1541a9a6
[10.376702] brcmfmac: brcmf_fw_map_chip_to_name: Verwenden von brcm / brcmfmac43430-sdio.bin für Chip 0x00a9a6 (43430) rev 0x000001
[10.377026] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[10.599523] brcmfmac: brcmf_c_preinit_dcmds: Firmware-Version = wl0: 7. August 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 Daten: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Erstellung: 2014-05-26 10:53:55 Inc Daten: 9.10.41 Inc Compiler: 1.29 .4 Inc ClmImport: 1.36.3 Erstellung: 2017-08-07 00:37:47
[126.642710] brcmfmac: Energieverwaltung deaktiviert
[139.249230] brcmfmac: brcmf_sdio_hostmail: Unbekannter Postfachdateninhalt: 0x40012
[141.751545] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[141.754973] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[144.311482] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[144.314959] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[144.314975] brcmfmac: brcmf_pno_clean: Code -110 fehlgeschlagen
[151.831564] brcmfmac: brcmf_sdio_bus_rxctl: Wird bei Zeitüberschreitung fortgesetzt
[151.835066] brcmfmac: brcmf_sdio_checkdied: Firmware-Falle im Dongle
[151.835079] brcmfmac: brcmf_do_escan: error (-110)
[151.835084] brcmfmac: brcmf_cfg80211_scan: Scanfehler (-110)

nach dem:

thenry @ pi3portable : ~ $ dmesg | grep brcm
[10.115833] brcmfmac: F1-Signatur read @ 0x18000000 = 0x1541a9a6
[10.134926] brcmfmac: brcmf_fw_map_chip_to_name: Verwenden von brcm / brcmfmac43430-sdio.bin für Chip 0x00a9a6 (43430) rev 0x000001
[10.135115] usbcore: Registrierter neuer Schnittstellentreiber brcmfmac
[10.367703] brcmfmac: brcmf_c_preinit_dcmds: Firmware-Version = wl0: 23. Oktober 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 Daten: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Erstellung: 2014-05-26 10:53:55 Inc Daten: 9.10.39 Inc Compiler: 1.29 .4 Inc ClmImport: 1.36.3 Erstellung: 2017-10-23 03:47:14
[18.045308] brcmfmac: Energieverwaltung deaktiviert
thenry @ pi3portable : ~ $

Es hat mehrere Stiefel weiter funktioniert und ich benutze es jetzt, verbunden über WLAN mit dem Samsung S4-Telefon.
Vielen Dank für Ihre Hilfe, Grüße, Trevor Henry.

Ich dachte, die neueste Firmware war bereits in den neuesten Images enthalten, hätte also erwartet, dass ein Upgrade auf 4.14 die neueste Firmware eingeführt hätte. Haben Sie Ihren eigenen Kernel erstellt?

Ja - die aktuellen Raspbian-Bilder haben die Firmware 7.45.98.38 vom 23. Oktober 2017.

Hallo, nein, ich habe den Kernel nicht erstellt, ich habe ein Upgrade mit rpi-update durchgeführt, und wie Sie sehen, wurde nach dem Update immer noch die Firmware vom August 2017 ausgeführt.

rpi-update aktualisiert nur den Kernel, die Firmware und eine kleine Anzahl von VideoCore-spezifischen Dienstprogrammen. Um alles zu aktualisieren, einschließlich der WiFi-Firmware, müssen Sie apt-get upgrade / distupgrade verwenden.

Hallo,
Ich habe dieses Problem und es ist besser mit der neuesten FW, 7.45.98.38, als es war, aber ich habe immer noch Probleme.
Beobachtungen
Wenn ich die Himbeere boote, ohne etwas zu tun, wird das WLAN so gestartet, wie es sollte.
Wenn ich versuche, die Bluetooth-Tastatur oder -Maus zu verwenden, bevor das WLAN aktiv ist, bleibt das Problem bestehen. Ich erhalte keine Verbindung.
Wenn ich eine Verbindung habe und das drahtlose Netzwerk deaktiviere / aktiviere, stellt das WLAN keine Verbindung her.
Wenn ich das WLAN über Nacht eingeschaltet lasse, funktioniert die Verbindung nicht mehr.
Ich habe drei identische Setups und das Verhalten ist bei allen gleich.
Ich weiß nicht, ob es wichtig ist, aber wir verwenden WPA2 Enterprise, PEAP und MSCHAPv2

Treten diese Probleme nur auf, wenn die BT-Geräte angeschlossen sind?

Ja! Bluetooth deaktiviert und USB-Tastaturen und -Maus verbunden und das WLAN schneller verbunden als jemals zuvor.

Dann gibt es noch einige Probleme mit der Koexistenz. Muss wohl bei Cypress gemeldet werden, denke ich.

Nur um zu überprüfen, verwenden Sie den neuesten Raspbian? Oder etwas ziemlich Neues?

@ Pelwell Ping

Beschreibung: Raspbian GNU / Linux 9.4 (Stretch)
Benötigen Sie weitere Informationen?

Es hängt nach:
14. Mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: STRG-EREIGNIS-EAP-METHODE EAP-Anbieter 0 Methode 25 (PEAP) ausgewählt

siehe Protokollausschnitt unten

14. Mai 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.7887] Gerät (wlan0): Status der Supplicant-Schnittstelle: nicht verbunden -> Zuordnung
14. Mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: Assoziiert mit 44: d9: e7: f7: d5: 34
14. Mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: STRG-EREIGNIS-EAP-STARTED Die EAP-Authentifizierung wurde gestartet
14. Mai 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.9263] Gerät (wlan0): Status der Supplicant-Schnittstelle: Assoziieren -> Assoziiert
14. Mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD Vendor = 0 Methode = 25
14. Mai 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: STRG-EREIGNIS-EAP-METHODE EAP-Anbieter 0 Methode 25 (PEAP) ausgewählt
14. Mai 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0716] Gerät (wlan0): Aktivierung: Die Zuordnung (WLAN) hat zu lange gedauert
14. Mai 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0718] Gerät (wlan0): Statusänderung: config -> need-auth (Grund 'none') [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 Grund = 3 lokal_generiert = 1
14. Mai 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0937] Gerät (wlan0): Aktivierung: (WLAN) fragt nach neuen Geheimnissen
14. Mai 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0959] sup-iface [0x1c438c0, wlan0]: Verbindung getrennt (Grund -3)

Ich habe das gleiche Problem mit octoPi 0.14 (jedes Paket aktualisiert, spätestens RPI-Firmware, jedes Octoprint-Plugin aktualisiert).

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

Mit diesem Setup ist es 100% reproduzierbar. Das Aufrufen der Octoprint-Website auf dem Pi (erster Zugriff nach dem Booten) von meinem Samsung S4 Active (Android 5.0.1, mit Chrome) oder von meinem Samsung Tablet 10-Zoll-Note-Ding mit auch Android 5.xi erraten und Chrome tötet das WLAN, wenn das Seite ist halb geladen.
Kein Kabel an meinen Pi3 angeschlossen, WLAN auf Kanal 11 mit wpa2.
Ich habe versucht, die WLAN-Stromversorgung zu deaktivieren und ohne Glück auf WLAN-Kanal 6 umzuschalten (Tipps von oben) - aber ich hatte das Gefühl, dass es mit Kanal 6 etwas besser war.

Aber jetzt kommt der interessante Hinweis auf den Fehler:
Ich habe kein Problem, wenn ich die Octopi / Octoprint-Site (auf dem Pi) von meinem Windows 10- oder Ubuntu 16-Computer aus öffne (über Chrom, Kabelverbindung zum Router). Meine Vermutung ist jetzt, dass es sich um einen Android-, Samsung- oder WLAN-Fehler handelt. Und ich glaube, ich habe vor einiger Zeit etwas über Android / RPI-Probleme gelesen.

Hoffe das hilft. Wenn Sie einen Tester für eine Version benötigen, würde ich es versuchen.

Ich dachte nur, ich würde hier läuten und sagen, wir haben auch gesehen, wie WiFi-bezogene Blockierungsstände um diesen Treiber aussehen, die möglicherweise mit einem anderen SBC zusammenhängen. Es ist nicht Raspberry PI-spezifisch.

Das passiert mir auch.

Installieren

• Pi 3B 1.2 (a02082)
• Kernel:

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

Ausführen von Raspbian Version 9.4:

pi<strong i="14">@raspberrypi</strong>:~ $ cat /etc/debian_version
9.4

Firmware Version:

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 Energieverwaltung ist deaktiviert:

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

Ich benutze das eingebaute WiFi. An den Ethernet-Port ist nichts angeschlossen.

Das System wurde mit apt-get upgrade , apt-get dist-upgrade und rpi-update aktualisiert.

Was ich sehe

Nachdem der Pi etwa eine Stunde lang aktiv war, ist er vom Netzwerk aus nicht mehr erreichbar. Ich kann den Pi nicht über mein lokales Netzwerk erreichen (Ping und SSH funktionieren nicht).

In dmesg sehe ich, dass ich Folgendes bekomme:

brcmfmac: power management disabled
...
snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned

Aber keine Fehler.

Etwas Interessantes

Mir ist aufgefallen, dass in diesem Fall die Dinge wieder funktionieren, wenn ich mich direkt mit dem Pi verbinde und meinen Laptop anpinge. Außerdem sind die Ping-Zeiten etwas seltsam - es scheint, als würde es ein wenig dauern, bis sich die Dinge „aufgewärmt“ haben:

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

Wenn jemand weitere Informationen benötigt, würde ich diese gerne zur Verfügung stellen.

@bugok , ifconfig wlan0 promisc ).

@quozl : Es hat nicht geholfen. Nach einer Weile begann Ping zu scheitern:

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

Rückmeldung: Mein Problem scheint behoben zu sein und hat nichts mit dem Problem in diesem Thread zu tun.

Details hier , aber das Wesentliche ist, dass ich eine statische IP auf dem Pi selbst festgelegt habe (in /etc/dhcpcd.conf ). Nachdem Sie die statische IP im Router definiert, die statische IP-Konfiguration aus /etc/dhcpcd.conf und neu gestartet haben, scheinen die Dinge zu funktionieren.

Ein schnelles Update: Dieses Problem (Fehler "Unbekannter Postfachdateninhalt", begleitet von einer vollständigen drahtlosen Sperrung) bleibt auf der neuesten Firmware mit allen installierten Updates bestehen (dist-upgrade).

Durch Ändern einer einzelnen Zeile in der Datei hostapd.conf (gemäß meinem vorherigen Kommentar) wird das Problem für mich weiterhin behoben.

Verwenden von Rpi3B mit Kernel 4.14.52-v7 (Himbeerpi-Kernel 1.20180703-1) und (Firmware-brcm80211 1: 20161130-3 + rpt4)
Ich stehe auch immer noch vor dem Problem, dass WLAN einfriert (90 Geräte, von denen 2 pro Tag das Problem haben). In einigen Fällen fehlt der Adapter und in anderen reagiert er nicht. Ich bin nicht mit dem Pi im AP - Modus, nur
Ich habe versucht, es wie in RPi-3B + neu zu binden, aber ohne Erfolg.

Ich habe derzeit eine Lösung erstellt, wenn keine Netzwerkverbindung erkannt wird. Der Pi wird neu gestartet. Dies ist jedoch keine richtige Lösung, und zumindest versuche ich, den Treiber neu zu laden

Ich sah immer wieder dasselbe Problem auf einem zuvor funktionierenden Pi 3. Ich erkannte, dass die einzige Änderung, die ich vorgenommen hatte, darin bestand, einen LCD-Touchscreen anzuschließen und Strom aus dem Pi zu ziehen. Als ich den Touchscreen aussteckte, funktionierte WiFi korrekt. Es scheint also sicherlich machtbezogen zu sein. Hierbei wurde das offizielle Raspberry-Netzteil verwendet.

Das ist ein sehr interessanter Datenpunkt. War es eines unserer LCDs?

@ JamesH65 Ich habe auch angefangen, WLAN-Abstürze und https://www.waveshare.com/wiki/5inch_HDMI_LCD installiert habe. Ich habe eine 3b + eine RPI-Kamera v2 und das Display, das an ein 3-A-Netzteil angeschlossen ist Keine Stromwarnungen erhalten ...

Hallo Leute, gibt es ein Update dazu? Ich habe versucht, Raspivid auf einem Null-W mit einem TCP-Stream zu verwenden, und nach einigen Minuten ist mein WLAN weg, ich denke, es ist das gleiche Problem.

Ich hatte das Problem seit mindestens einem Jahr nicht mehr. Ich fange zunehmend an zu denken, dass es einfach damit zusammenhängt, dass die USB-Stromquelle nicht genügend Verstärker bereitstellt, aber ich würde den Beweis begrüßen, dass dies nicht der Fall ist. Versuchen Sie als Test, Ihr USB-Kabel an einen Adapter mit höherem Verstärker anzuschließen, insbesondere wenn Sie das Problem leicht reproduzieren können.

Ich bin mir ziemlich sicher, dass es nicht direkt mit dem Verstärker zusammenhängt, da ich nur etwa 2 Ampere verwende. Meist alte Samsung-Ladegeräte. es könnte jedoch eine Welligkeit oder etwas mit dem Netzteil oder der pi-Hardware sein.

-------- Ursprüngliche Nachricht --------
Von: rajid [email protected]
Datum: 07.04.2019 02:15 (GMT + 01: 00)
An: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , Kommentar [email protected]
Betreff: Re: [raspberrypi / linux] wlan friert in himbeer pi 3 / PiZeroW ein (nicht
3B +) (# 1342)

Ich hatte das Problem seit mindestens einem Jahr nicht mehr. Ich fange zunehmend an zu denken, dass es einfach damit zusammenhängt, dass die USB-Stromquelle nicht genügend Verstärker bereitstellt, aber ich würde den Beweis begrüßen, dass dies nicht der Fall ist. Versuchen Sie als Test, Ihr USB-Kabel an einen Adapter mit höherem Verstärker anzuschließen, insbesondere wenn Sie das Problem leicht reproduzieren können.

- Sie erhalten dies, weil Sie einen Kommentar abgegeben haben. Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.
{"api_version": "1.0", "publisher": {"api_key": "05dde50f1d1a384dd78767c55493e4bb", "name": "GitHub"}, "entity": {"external_key": "github / raspberrypi / linux", "title ":" raspberrypi / linux "," subtitle ":" GitHub repository "," 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 ":" In GitHub öffnen "," url ":" https://github.com/raspberrypi/linux "}}," updates ": {" snippets ": [{" icon ":" PERSON "," message ":" @rajid in # 1342: Ich hatte das Problem seit mindestens einem Jahr nicht mehr Ich fange zunehmend an zu denken, dass es einfach damit zusammenhängt, dass die USB-Stromquelle nicht genügend Verstärker bereitstellt, aber ich würde den Beweis begrüßen, dass dies nicht der Fall ist. Versuchen Sie als Test, Ihr USB-Kabel an einen Adapter mit höherem Verstärker anzuschließen, insbesondere Wenn Sie das Problem leicht reproduzieren können. "}]," action ": {" name ":" View Issue "," url ":" https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753 "}}}
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"potentielle Aktion": {
"@type": "ViewAction",
"Ziel": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"name": "Problem anzeigen"
},
"description": "Dieses Problem auf GitHub anzeigen",
"Verleger": {
"@type": "Organisation",
"name": "GitHub",
"url": " https://github.com "
}}
}}
]]

Ich habe immer noch das Problem, aber nicht annähernd so oft - vielleicht alle paar Wochen - und ich kann es nicht mehr zuverlässig auslösen, indem ich eine Verbindung von Samsung-Android-Geräten herstelle.

Ich versorge den Pi zero w mit einem 3A-USB-Netzteil und einem 15-cm-USB-Kabel zum Laden von Powerbanks (keine Datenleitungen, nur Stromleitungen).

Wenn ich die Verbindung regelmäßig verwende (wie ein normaler Benutzer), funktioniert sie einwandfrei. Wenn ich jedoch MJPEG mit 5 Mbit / s streame, stürzt sie nach einigen Minuten ab. Im Journal wird ein Postfachfehler (oder ein ähnlicher Fehler) angezeigt (ich kann mich nicht erinnern, wie ich bin für eine Woche außer Haus), ssh stoppt, kein Ping, Wi-Fi fällt ab, iwconfig braucht einige Sekunden, um Ergebnisse anzuzeigen und sie sind fast leer.

@vascojdb Wenn Sie den Pi als Zugangspunkt verwenden (AP-Modus), sollte diese Problemumgehung (siehe den fett gedruckten Text unten) Ihr Problem lösen.

Lass uns wissen?

Nein, es befindet sich nicht im AP-Modus. Ich bin mit meinem 2,4-GHz-WLAN-Heimnetzwerk verbunden

Hallo,

Ich habe ein WLAN-Problem beim Synchronisieren der Zeit beim Start mit dem NTP-Server mithilfe von LibreELEC auf RPI3B + seit Version 9.0.0.
Nach einigen Diskussionen mit einigen LE-Teammitgliedern ( siehe hier ) wurde das Problem nach dieser Änderung behoben.

Es scheint jedoch, dass diese Problemumgehung rückgängig gemacht wurde und das Problem immer noch besteht.
Ist es möglich, es wieder zu reparieren?

Niemand, der dieses Problem beantwortet oder eskaliert?

Gleicher Fehler. Gibt es Neuigkeiten zu diesem Thema?

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)

Versucht, die Energieverwaltung vorerst auszuschalten. Ist dies ein alter Fehler, der wieder eingeführt wurde?

https://patchwork.kernel.org/patch/9948825/

Gleicher Fehler. Gibt es Neuigkeiten zu diesem Thema?

Diese Meldung besagt nur, dass die Firmware des WLAN-Chips abgestürzt ist. Der Linux-Kernel kann nur zurücksetzen. Ein hilfreicher Fehlerbericht enthält die folgenden Informationen:

Welche WLAN-Firmware verwenden Sie?
Wie bedienen Sie das WLAN (AP, Client, ...)?
Können Sie dies innerhalb einer definierten Zeit reproduzieren?
Welche anderen WLAN-Geräte sind beteiligt?

Es ist in meinem letzten Kommentar, da es damals reproduzierbar war, aber es ist schlecht zu reproduzieren und ändert sich mit Softwareänderungen, wenn es abstürzt.

-------- Ursprüngliche Nachricht --------
Von: Stefan Wahren [email protected]
Datum: 01.05.2020 10:21 (GMT + 01: 00)
An: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , Kommentar [email protected]
Betreff: Re: [raspberrypi / linux] wlan friert in himbeer pi 3 / PiZeroW ein (nicht
3B +) (# 1342)

Gleicher Fehler. Gibt es Neuigkeiten zu diesem Thema?

Diese Meldung besagt nur, dass die Firmware des WLAN-Chips abgestürzt ist. Der Linux-Kernel kann nur zurücksetzen. Ein hilfreicher Fehlerbericht enthält die folgenden Informationen:
Welche WLAN-Firmware verwenden Sie?
Wie bedienen Sie das WLAN (AP, Client, ...)?
Können Sie dies innerhalb einer definierten Zeit reproduzieren?
Welche anderen WLAN-Geräte sind beteiligt?

- Sie erhalten dies, weil Sie einen Kommentar abgegeben haben. Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder melden Sie sich ab.
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"potentielle Aktion": {
"@type": "ViewAction",
"Ziel": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"name": "Problem anzeigen"
},
"description": "Dieses Problem auf GitHub anzeigen",
"Verleger": {
"@type": "Organisation",
"name": "GitHub",
"url": " https://github.com "
}}
}}
]]

Gleicher Fehler. Gibt es Neuigkeiten zu diesem Thema?

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)

Versucht, die Energieverwaltung vorerst auszuschalten. Ist dies ein alter Fehler, der wieder eingeführt wurde?

https://patchwork.kernel.org/patch/9948825/

Keine nennenswerte Lösung, aber ich habe genau das gleiche Problem auf einem Rpi4 mit der neuesten installierten Firmware. Ich habe es auf ein SD-Karten-Image zurückgesetzt, das ich vor einigen Monaten erstellt habe, und das Problem ist behoben. Da ich hostapd verwende, glaube ich, dass eines oder eine Kombination dieser Upgrades es für mich kaputt gemacht hat:

$ apt list - aktualisierbar
Listing ... Fertig
...
Hostapd / Stable 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u2 armhf [Upgrade von: 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u1]
firmware-brcm80211 / testing 1: 20190114-1 + rpt6 all [aktualisierbar von: 1: 20190114-1 + rpt4]
raspberrypi-kernel / testing 1.20200212-1 armhf [aktualisierbar von: 1.20200114-1]
...

Ich habe auch versucht, die Energieverwaltung auszuschalten (und bestätigt, dass sie mit iwconfig deaktiviert ist), aber es hatte keine Auswirkung, wenn hostapd ausgeführt wurde. Ich muss auf Firmware-Upgrades verzichten, bis sie behoben sind, da wir viele davon versenden und stabile APs für unsere Kunden benötigen.

Wenn Firmware-Traps, Timeouts (-110) usw. auftreten, aktivieren Sie das Firmware-Debugging, damit wir einige Daten erfassen können.

Fügen Sie brcmfmac.debug=0x100000 zu /boot/cmdline.txt hinzu, halten Sie es in einer einzigen langen Zeile und starten Sie es neu. Das Ausführen von dmesg | grep brcmfmac sollte zu einer Ausgabe wie der folgenden führen:

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

Dann machen Sie einfach weiter wie gewohnt. Wenn die brcmfmac-Firmware ausfällt, erfassen Sie die Ausgabe von dmesg in einer Datei und hängen Sie sie (oder einen Link zu Pastebin usw.) hier an.

Da der Fehler andere Kernel-Nachrichten auslöst, besteht die Gefahr, dass die nützliche Ausgabe verloren geht, bevor Sie die Möglichkeit haben, sie zu erfassen. Eine Möglichkeit, dies zu vermeiden, besteht darin, eine Shell zu verlassen, die die Kernel-Nachrichten ständig in einer Datei speichert:

$ dmesg -w > kernel_log.txt &

Ich sehe das gleiche Problem hier. Ich werde das oben erwähnte Debug versuchen.

Ausführen von hostapd im AP-Modus, wireguard und frr. Auch mit Sixfab Handyhut.

[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

Ich kann dies auch im 5.4-Zweig neu erstellen. FWIW, ich kann diesen Fehler immer manuell auslösen, indem ich eine große Datei (> 400 MB) auf meinen Pi Zero W übertrage.

Wenn es hilft, ist meine Kernel-Version ab diesem 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

Absturzprotokoll mit Debugging:

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

Während des obigen Absturzes habe ich ein ifdown und ein ifup ausgeführt, bei denen das WLAN nicht wiederhergestellt wurde. Die einzige Lösung besteht darin, entweder den pi oder rmmod & modprobe brcmfmac neu zu starten.

Es ist erwähnenswert, dass dies bei deaktivierter Energieverwaltung geschieht, da ich dies in meiner Schnittstellendatei habe: