EDIMAX EW-7811UN .... Itu menggunakan chipset rtl8188cus, IIRC.

Jika Anda belum memilikinya, buat /etc/modprobe.d/8192cu.conf, dengan konten ....

Nonaktifkan manajemen daya

opsi 8192cu rtw_power_mgnt = 0 rtw_enusbss = 0

Rpi3 sebenarnya menggunakan driver brcmfmac untuk wifi inbuilt
ada masalah yang mengharuskan penghematan / pengelolaan daya dimatikan

Saya pikir kernel raspian yang lebih baru telah menambal ini untuk menonaktifkan penghematan daya secara default tetapi saya pikir itu belum ada di cabang 4,5 ini

Apa yang saya lakukan saat ini (gentoo install) adalah sebagai berikut saat boot untuk menonaktifkan penghematan daya pada kartu wifi

iw wlan0 matikan power_save

Rpi3 sebenarnya menggunakan driver brcmfmac untuk wifi inbuilt

Ya saya tahu. Oh begitu. Dia tidak lagi menggunakan dongle EDIMAX EW-7811UN. Dia biasa menggunakannya dengan RPi2.

ya, saya tidak lagi menggunakan usb wifi, bagaimana cara menyiapkan jalur cmd untuk mematikan manajemen daya?
crontab
@reboot iw wlan0 berangkat power_save

Tidak yakin untuk raspian, karena saya menggunakan gentoo itu akan berbeda

Coba ini: https://gist.github.com/mkb/40bf48bc401ffa0cc4d3

Sepertinya berfungsi sejak saya mematikan powermanagement, saya belum mengalami crash wlan lagi.

Sekadar menyebutkannya, untuk memulai ulang wlan secara otomatis setelah macet, ini di sini membantu:
sudo cp /etc/wpa_supplicant/ifupdown.sh /etc/ifplugd/action.d/ifupdown

BTW, kernel pemutakhiran apt-get terbaru memiliki manajemen daya dinonaktifkan secara default.
@ dh-connect apakah ini berfungsi untuk Anda jika Anda menghapus solusi saat ini?

itu masih macet setelah peningkatan terbaru, sekarang saya mendapatkan kesalahan ini di syslog:
brcmfmac: brcmf_sdio_bus_txdata: keluar dari bus-> txq !!!

Saat Anda mengatakan itu macet, apakah ada gejala selain pesan kesalahan?

tidak, hanya yang saya posting di sini tetapi ada di log berkali-kali

wlan berhenti bekerja, saya masih dapat bekerja dengannya tetapi untuk mendapatkan wlan kembali berfungsi saya harus mem-boot ulang

Terima kasih - Saya pikir "wlan berhenti bekerja" dianggap sebagai gejala.

Saya sudah mencoba beberapa hal, tetapi wlan masih rusak

untuk menjawab pertanyaan di atas ketika saya mengambil kembali konfigurasi tersebut
daya nirkabel mati di / etc / network / interfaces
dan reboot
dan periksa pengaturan dengan iwconfig
manajemen daya ist dihidupkan kembali sehingga secara default saya tidak akan mengatakan bahwa ini dinonaktifkan jadi saya akan meninggalkan konfigurasi

Saya mencobanya dengan kernel 4.1.19 dan sekarang juga dengan kernel 4.1.20 ... tidak ada perubahan

ketika wlan crash dan saya coba hidupkan kembali dengan ifdown dan ifup wlan0 saya mendapatkan ini:
Kesalahan untuk permintaan nirkabel "Set Power Management" (8B2C): SET gagal pada perangkat wlan0; Pertukaran tidak valid.

Saya juga mendapat beberapa kesalahan lagi di syslog:

dhcpcd [532]: wlan0: xxx: opsi kedaluwarsa 25

21 Mar 17:29:35 kernel raspberrypi: [6627.337503] brcmfmac: _brcmf_set_multicast_list: Pengaturan mcast_list gagal, -52
21 Mar 17:29:36 raspberrypi wpa_supplicant [6318]: Berhasil menginisialisasi wpa_supplicant
21 Mar 17:29:36 raspberrypi dhcpcd [532]: wlan0: operator hilang

21 Mar 17:29:43 kernel raspberrypi: [6635.337616] brcmfmac: _brcmf_set_multicast_list: Pengaturan mcast_list gagal, -52

21 Mar 17:29:45 kernel raspberrypi: [6637.337588] brcmfmac: brcmf_do_escan: error (-52)
21 Mar 17:29:45 kernel raspberrypi: [6637.337602] brcmfmac: brcmf_cfg80211_scan: kesalahan pemindaian (-52)

21 Mar 17:29:47 kernel raspberrypi: [6639.337596] brcmfmac: _brcmf_set_multicast_list: Pengaturan allmulti gagal, -52
21 Mar 17:29:49 kernel raspberrypi: [6641.337632] brcmfmac: _brcmf_set_multicast_list: Pengaturan BRCMF_C_SET_PROMISC gagal, -52

apakah ada hal lain yang bisa saya coba?

juga ini:

21 Mar 21:26:55 raspberrypi dhcpcd [526]: wlan0: xxx: opsi kedaluwarsa 25
21 Mar 21:28:54 kernel raspberrypi: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
21 Mar 21:30:16 raspberrypi dhcpcd [526]: wlan0: xxx tidak dapat dijangkau, kedaluwarsa

Saya tidak terkejut bahwa iwconfig menganggap perangkat tersebut telah mengaktifkan penghematan daya - Saya memblokirnya di dalam driver itu sendiri, dan status disimpan di lapisan yang lebih tinggi atau ada perubahan lain yang diperlukan untuk melaporkannya dengan benar. Bagaimanapun, buktinya kuat bahwa kami telah menghindari bug hemat daya, tetapi beberapa masalah lain masih tetap ada.

Apakah Anda memiliki angka kasar untuk waktu-hingga-kegagalan dan kira-kira berapa banyak data yang mungkin telah ditransfer (dari ifconfig)?

ya saya lakukan, ketika saya baru saja menjalankan webserver dengan lalu lintas tidak banyak (kurang dari 100 MB) itu berlangsung satu atau dua hari, ketika saya mentransfer file data besar seperti 1 GB wlan crash dalam 1 jam

ada yang bisa saya berikan untuk membantu menemukan bug?

berikut beberapa kesalahan dari syslog:

29 Mar 14:20:56 raspberrypi dhcpcd [535]: wlan0: xxx: opsi kedaluwarsa 25
29 Mar 14:30:15 raspberrypi dhcpcd [535]: wlan0: xxx tidak dapat dijangkau, kedaluwarsa
29 Mar 17:18:42 kernel raspberrypi: [186148.102420] brcmfmac: brcmf_sdio_bus_txdata: keluar dari bus-> txq !!!
29 Mar 17:18:43 kernel raspberrypi: [186149.101045] brcmfmac: brcmf_sdio_bus_txdata: keluar dari bus-> txq !!!
29 Mar 17:18:43 kernel raspberrypi: [186149.101145] brcmfmac: brcmf_sdio_bus_txdata: keluar dari bus-> txq !!!
29 Mar 17:18:44 kernel raspberrypi: [186150.101209] brcmfmac: brcmf_sdio_bus_txdata: keluar dari bus-> txq !!!
29 Mar 17:18:50 raspberrypi wpa_supplicant [478]: wlan0: CTRL-EVENT-DISCONNECTED bssid = xxx reason = 3 local_generated = 1
29 Mar 17:18:50 kernel raspberrypi: [186156.181033] brcmfmac: brcmf_cfg80211_disconnect: error (-52)
29 Mar 17:18:52 kernel raspberrypi: [186158.181028] brcmfmac: send_key_to_dongle: kesalahan wsec_key (-52)
29 Mar 17:18:54 kernel raspberrypi: [186160.181046] brcmfmac: send_key_to_dongle: kesalahan wsec_key (-52)
29 Mar 17:18:56 kernel raspberrypi: [186162.181048] brcmfmac: send_key_to_dongle: kesalahan wsec_key (-52)
29 Mar 17:18:58 kernel raspberrypi: [186164.181049] brcmfmac: send_key_to_dongle: kesalahan wsec_key (-52)
29 Mar 17:18:58 kernel raspberrypi: [186164.185477] cfg80211: Memanggil CRDA untuk memperbarui domain regulasi dunia
29 Mar 17:18:58 raspberrypi dhcpcd [535]: wlan0: operator hilang
29 Mar 17:18:58 raspberrypi wpa_supplicant [7354]: Berhasil menginisialisasi wpa_supplicant
29 Mar 17:18:58 kernel raspberrypi: [186164.314511] brcmfmac: brcmf_cfg80211_reg_notifier: bukan kode ISO3166
29 Mar 17:18:58 kernel raspberrypi: [186164.314541] cfg80211: Domain regulasi dunia diperbarui:
29 Mar 17:18:58 kernel raspberrypi: [186164.314548] cfg80211: Wilayah Master DFS: tidak disetel
29 Mar 17:18:58 kernel raspberrypi: [186164.314555] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
29 Mar 17:18:58 kernel raspberrypi: [186164.314565] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N / A, 2000 mBm), (N / A)
29 Mar 17:18:58 kernel raspberrypi: [186164.314573] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N / A, 2000 mBm), (N / A)
29 Mar 17:18:58 kernel raspberrypi: [186164.314581] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N / A, 2000 mBm), (N / A)
29 Mar 17:18:58 kernel raspberrypi: [186164.314592] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (N / A)
29 Mar 17:18:58 kernel raspberrypi: [186164.314602] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 dtk)
29 Mar 17:18:58 kernel raspberrypi: [186164.314611] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N / A, 2000 mBm), (0 s)
29 Mar 17:18:58 kernel raspberrypi: [186164.314645] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N / A, 2000 mBm), (N / A)
29 Mar 17:18:58 kernel raspberrypi: [186164.314654] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 0 mBm), (N / A)

Terima kasih atas tawarannya, tapi sekarang ini ada di tangan Broadcom.

Adakah pembaruan dari Broadcom jika ini adalah bug yang akan diperbaiki? Saya sekarang memiliki pengaturan pekerjaan cron untuk menurunkan dan menaikkan wlan0 ketika gagal melakukan ping.

pembaruan cepat dari pihak saya, saya bisa mendapatkan masalah yang diperbaiki tampaknya terkait dengan driver, saya menginstal Ubuntu MATE 16.04 dengan kernel 4.4.8 dan tidak memiliki masalah dengan wifi sejak itu

Maksud saya yang mereka iklankan adalah: "Ubuntu MATE 16.04 juga memiliki Bluetooth dan Wifi yang berfungsi penuh di Raspberry Pi 3" yang tampaknya benar

mungkin itu juga bekerja dengan rilis Debian baru, yang saya tidak tahu

@ juched78 Apakah Anda menjalankan kernel 4.4? Jika tidak, jalankan sudo rpi-update untuk mendapatkan versi 4.4.8 terbaru dan lihat apakah itu mengalami masalah yang sama.

Driver Broadcom telah berubah secara signifikan sejak 4.1, dan struktur 4.4 kami menyertakan port belakang dari beberapa perbaikan yang masuk ke versi 4.5. Saya tidak mengetahui adanya bug yang luar biasa selain kegagalan untuk bangun dari tidur (manajemen daya masih dinonaktifkan) - saluran 12 & 13 dapat digunakan jika diizinkan, dan mode Ad Hoc tidak macet - tetapi mungkin masih ada masalah yang mengintai .

Oh, ada satu bug yang dilaporkan masih di 4.4.8 - tampaknya penggunaan hostapd yang berat dapat menyebabkan peringatan kernel (lihat https://github.com/raspberrypi/linux/issues/1375).

Saya sedang berlari:
Linux XXX 4.4.8-v7 + # 880 SMP Jum 22 Apr 21:55:04 BST 2016 armv7l GNU / Linux

27 Apr 2016 11:06:18
Hak Cipta (c) 2012 Broadcom
versi 9b52ab7b475f4a056658fd2d95d2440b32167390 (bersih) (rilis)

Dengan Netgear R7000 saya menjalankan Shibby Tomato, sekitar 2 hari di wifi turun, dan di log sys saya melihat:

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

Kemudian sepertinya tidak pernah menyambung kembali ...

Menggunakan sudo ifdown wlan0 diikuti oleh sudo ifup wlan0 mengembalikan koneksi saya.

Baru saja ditingkatkan ke:
Linux JuchePi 4.4.8-v7 + # 881 SMP Sab 30 Apr 12:16:50 BST 2016 armv7l GNU / Linux

Tidak yakin apa yang semuanya berbeda dari tanggal 22 hingga 30. Saya akan memantau koneksi.

RPi 3 saya juga terkena masalah itu. Saya mendapat beberapa pesan kernel yang berbeda. Terutama salah satunya di bawah ini.
Setelah itu saya bisa 'mendapatkan WiFi yang berfungsi, menurunkan wlan0 lalu naik tidak membantu.

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 didukung dari adaptor daya asli untuk versi 3. Saya menjalankan OSMC terbaru:
$ uname -a
Linux osmc 4.4.8-3-osmc # 1 SMP PRESEMPT Min 1 Mei 18:57:43 UTC 2016 armv7l GNU / Linux

Masih memantau. Saya memiliki openhab offline setelah berjalan 3 hari tetapi untuk beberapa alasan saya masih bisa ssh ke Pi yang biasanya saya tidak bisa. Bagian atas jam dan skrip wifi berlari untuk menurunkan dan memunculkan koneksi dan kemudian terhubung kembali ke organisasi openhab saya. Aneh. Akan terus menonton.

Saya juga mengalami masalah yang sama - dmesg trace sebagai berikut:

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)

Pemakaian:

rp3 digunakan sebagai router / titik akses

Panjang konektivitas tampak acak - Saya mengalami paling lama dua minggu, dan paling buruk beberapa menit. Akhir-akhir ini sudah keluar setiap 20 menit atau lebih. Menurunkan dan mencadangkan wlan0 tidak menyelesaikan masalah - diperlukan booting ulang penuh.

Masalah tampaknya diperburuk saat streaming Netflix dari AppleTV saya. Meskipun ini tidak terjadi ketika saya memiliki waktu aktif dua minggu.

Saya menggunakan 4.4.10-v7 +

Saya mengganti saluran dari 13 menjadi 6 untuk memeriksa apakah itu bisa menjadi masalah (ada beberapa cacat tentang saluran tinggi) dan sejak itu saya belum memiliki freez WiFi. Tapi itu bisa jadi kebetulan ...

Mengubah saluran titik akses tidak membantu. WiFi masih rusak. Beberapa kali terakhir saya harus memulai ulang beberapa kali berturut-turut untuk membuatnya berfungsi.

Saya mengalami masalah ini secara khusus ketika saya mencoba melakukan transfer SFTP antara rpi3 dan ponsel Galaxy S5 saya. Ketika saya mencoba melakukan transfer yang sama dari laptop saya, semuanya berjalan lancar.

Menjalankan kernel terbaru dari rpi-update:

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

Pesan kesalahan dari syslog:

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

Tampaknya satu-satunya solusi setelah kesalahan ini adalah reboot.

Saya mengalami penurunan jaringan dua kali dalam seminggu terakhir. Pertama kali saya terburu-buru jadi cabut saja dan reboot. Beberapa hari kemudian itu terjadi lagi, reboot lagi dan kemudian menjalankan pembaruan sistem lengkap (termasuk firmware) dan akan memantau. Sudah dipasang tanpa monitor di dekatnya, jadi mendapatkan detail tentang kesalahan membutuhkan lebih banyak usaha :)

Masalah yang sama disini. Itu selalu macet saat mentransfer file besar dengan sftp. Hanya reboot untuk menyelesaikannya

Masalah ini mungkin terkait dengan https://github.com/raspberrypi/linux/issues/1313

Broadcom mengatakan bahwa # 1313 adalah non-issue, dan kernel terbaru tidak lagi menampilkan pesan-pesan itu.

Saya tidak dapat mereproduksi masalah ini. Adakah yang bisa menangkap jejak paket sekitar waktu kegagalan?

Jika ada yang punya waktu untuk melakukan pengujian lagi dengan modul driver yang mendukung debug, akan sangat dihargai:

1) Jalankan sudo rpi-update dan reboot. Ini untuk menaikkan kernel Anda ke level yang sama dengan milik saya sehingga modulnya kompatibel.

2) Unduh dan instal modul driver yang diperbarui:

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

Nyalakan ulang untuk mengaktifkan modul baru.

3) Gunakan Pi Anda seperti biasa, lalu jika WiFi Anda macet:

dmesg > wifi_freeze.txt

dan unggah ke situs tempel favorit Anda (atau buat Intinya). Satu atau dua batang kayu harus cukup.

Untuk mengembalikan versi asli modul:

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

Terima kasih sebelumnya.

Tunggu sebentar sementara kami memverifikasi bahwa keluaran debug benar-benar diaktifkan.

Anda juga perlu mengaktifkan fitur debug pada driver:

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

Saya telah mengubah instruksi di atas.

Setelah reboot, output dmesg Anda akan menyertakan sesuatu seperti ini:

[   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 setelah menjalankan instruksi Anda, saya tidak lagi memiliki wifi ...

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

Coba ini:

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

Dan reboot.

wlan0 tidak terkait.
wireless.txt
(di salah satu dari banyak reboot saya melihat asosiasi selama beberapa menit, belum menangkapnya (belum) di dmesg)

Sepertinya masalah ini telah teratasi untuk saya dengan meningkatkan dari 4.4.11-v7 + ke 4.4.15-v7 +

Saya mencoba membuat ulang masalah yang saya alami dengan transfer SFTP dari ponsel Android, tetapi saya tidak melihat masalah apa pun saat ini.

@pelwell setelah menunggu lama wlan0 berhasil mengasosiasikan; menambahkan dmesg ke log sebelumnya:
wireless.txt
menunggu sekarang untuk pembekuan atau kehilangan asosiasi
semoga bermanfaat

@pelwell dengan cepat kehilangan koneksi lagi; ditambahkan dmesg ke:
wireless.txt

Terima kasih. Itu lambat bagi saya pertama kali. Saya sibuk mendapatkan Raspbian yang bersih dan menerapkan tambalan untuk mencoba mereproduksi masalah - saya akan tetap melanjutkan.

@pelwell
wireless.txt
dan dihubungkan kembali: ditambahkan dmesg lagi
apakah kamu ingin aku melanjutkan?

@pelwell : kehilangan asosiasi lagi
wireless_associationloss.txt

@pelwell
itu dinyalakan / dimatikan secara tidak teratur
wireless_associationloss.txt

Saya pikir Anda sebaiknya beralih kembali sekarang sebelum kotak masuk saya meluap.

baik; Saya akan kembali ke dongle MT7601U € 3 saya. ;)

Terima kasih atas bantuan Anda sejauh ini,

Saya baru saja menemukan masalah ini, jadi dapatkah saya memastikan bahwa ini mirip dengan yang saya lihat? Saya telah menyiapkan RPi 3 sebagai titik akses dan sering kali saya tidak dapat menyambungkannya. Saya dapat melakukan ssh melalui koneksi kabel dan saya melihat bahwa wlan0 masih aktif dengan alamat IP yang benar tetapi satu-satunya cara agar titik akses berfungsi kembali adalah dengan reboot. Saya melihat jejak tumpukan seperti ini di /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 ]---

Kernel saya adalah 4.4.13-v7 + dan saya baru saja menjalankan rpi-update untuk pertama kalinya jadi saya belum tahu apakah itu akan membantu.

Saya ingin tahu apakah ini mungkin terkait, atau mungkin masalah terpisah
https://www.youtube.com/watch?v=_D_fi_ck9Vo

RPI3 saya berfungsi tanpa masalah melalui WiFi sampai saya meningkatkannya ke udev terbaru ...

Sekarang, sudah tidak terhubung lagi ...

Saya juga telah menginstal modul yang ditambal dari Pelwell tetapi kami tidak berhasil: hanya tidak terhubung ...

Beri tahu saya jika saya bisa membantu,

Yang terbaik,
Mimmo

@ dh-connect apakah masalah Anda sudah teratasi? Jika demikian, harap tutup masalah ini. Terima kasih.

Saya bekerja dengan lan sejak, belum mencoba wlan

Hai,

Saya mengalami masalah yang tampaknya sama dengan rpi 3. Saya telah kembali menggunakan dongle usb wifi resmi RPI yang sangat solid, tetapi wifi bawaan mati setelah ~ 20 jam konektivitas dengan pesan semacam ini di syslog

brcmfmac: brcmf_cfg80211_reg_notifier: bukan kode ISO3166
cfg80211: Domain regulasi dunia diperbarui:
cfg80211: Wilayah Master DFS: tidak disetel

ini ada di raspbian terbaru, firmware terbaru

Apakah mungkin untuk membuka kembali masalah ini?
Mengapa ditutup?

Saya bekerja dengan lan sejak, belum mencoba wlan
dh-connect ditutup 13 hari yang lalu ini

Ini bukan solusi yang layak untuk menutup masalah ...

Saya masih mengalami masalah dan dapat mereproduksi bug tersebut.

Porsi dmesg saya yang relevan adalah:

[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

Saya mengalami masalah yang sama dengan @jrmhaig dan sekarang telah ditingkatkan

$ 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

Siapkan hostapd dengan jembatan.

/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

Untuk orang-orang dengan masalah WiFi, Cypress (was Broadcom) telah memberi kami modul debug untuk membantu mendiagnosis masalah. Karena modul adalah khusus untuk versi kernel, Anda harus terlebih dahulu memperbarui (atau mungkin mengembalikan) ke rilis firmware tertentu:

sudo rpi-update b0ef6e25679d3612a980708cf4c3907ce6e13e84
sudo shutdown -r now

Sekarang Anda dapat mengunduh dan menginstal modul debug:

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

Perintah terakhir akan menjalankan skrip instalasi, yang menyalin modul asli ke satu sisi sebelum menggantinya dengan versi debug. Menjalankan perintah lagi akan mengembalikan ke versi aslinya.

Setelah instalasi, reboot Pi 3 Anda - sekarang dmesg | grep brcmfmac akan menampilkan pesan diagnostik seperti ini:

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

Ketika Anda menemukan masalah, gunakan dmesg > wifidbg.txt untuk merekam penelusuran ke file, bersama dengan pesan kernel lainnya, lalu unggah file di suatu tempat (gist, pastebin, dropbox, dll.) Dan kirim tautan ke sana bersama dengan deskripsi tentang apa yang Anda lakukan saat kesalahan terjadi.

segarkan ingatan saya: perintah apa yang digunakan untuk kembali ke firnmware yang stabil
jika saya memutuskan untuk berhenti men-debug?

sudo apt-get update
sudo apt-get upgrade

harus melakukan triknya. Dan sudo ./brcmdbg untuk kembali ke driver non-debug.

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

Memulai debugging; dibutuhkan sekitar 5 atau 6 kali mencoba untuk mengasosiasikan; tidak tahu mengapa semua kecuali upaya terakhir gagal; akan membiarkannya berjalan sampai saya melihat asosiasi kehilangan dan membuang dmesg baru kemudian. Perilaku asosiasi yang tidak konsisten adalah masalah saya sebelum saya berhenti menggunakan wifi onboard jadi ini mungkin di tempat. Beri tahu saya jika ada aktivitas tambahan yang bisa membantu.

https://gist.github.com/BenoitSvB/bf8acdbb7b664df90e885603bb4774ce#file -201609081628_wifidbg-txt
Tidak melakukan apa-apa selain menunggu; apakah kita melihat di sini beberapa kerugian / pemulihan asosiasi?

Terima kasih untuk itu. Hmm - log itu tidak terlalu informatif, tapi mari kita lihat dengan apa Cypress kembali.

https://gist.github.com/BenoitSvB/98db53ff884e7b1a57bf1475d6106c56
Kehilangan dan pemulihan asosiasi yang tidak dapat dijelaskan; cukup lama untuk dilihat di ikon systray.
Accesspoint adalah Linksys wrt160n dengan Firmware: DD-WRT v24-sp2 (08/07/10) std.
Sepertinya saya bisa berhenti men-debug untuk saat ini dan kembali ke dongle MT7601U € 3 saya, tetapi beri tahu saya jika saya bisa membantu lebih lanjut.

@pelwell Saya tidak melihat pemulihan firmware apa pun setelah sudo apt-get update && sudo apt-get upgrade dan sudo rpi-update memberikan
*** Firmware Anda sudah diperbarui; Sepertinya saya perlu menjalankan rpi-update dengan git hash tertentu untuk kembali ke firmware yang stabil. Apakah Anda tahu hash yang mana?

Riwayat komit di repo RPI-Distro menunjukkan bahwa Anda ingin komit 390f53ed0fd79df274bdcc81d99e09fa262f03ab dari repo firmware, jadi jalankan:

sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab

@pelwell :
root @ pi3b : / home / pi # sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab
** Updater firmware Raspberry Pi oleh Hexxeh, ditingkatkan oleh AndrewS dan Dom* * Melakukan pembaruan sendiri
** Meluncurkan kembali setelah pembaruan* * Pembaruan firmware Raspberry Pi oleh Hexxeh, ditingkatkan oleh AndrewS dan Dom
Git hash yang ditentukan tidak valid

Ah, firmware rpi Hexxeh memiliki ID komit yang berbeda - coba 569e6611ac20c735647eb0e550484a73935a672d.

Saya ingin tahu apakah https://github.com/raspberrypi/linux/issues/1552 / # 1444 mungkin terkait dengan masalah ini juga.

Saya baru-baru ini menerapkan pengaturan 40xRPI3 yang melakukan beberapa hal bluetooth, kami harus mendapatkan antarmuka wifi usb atau wlan akan terus membeku .. Kami sekarang menggunakan perangkat bl internal dan modul wifi internal masuk daftar hitam di modprobe.d.

Mungkin berguna untuk melakukan hcitool name 11:11:11:11:11:11 dan melihat apakah itu menghasilkan entri log yang menarik juga .. Saya baru saja mengikuti masalah ini, belum punya waktu untuk menyiapkan lingkungan lab saya untuk menguji sendiri. Kami mengalami beberapa pembekuan wifi tanpa mengaktifkan BT, tetapi kombinasi wifi + bt kurang lebih selalu dapat mematikan wifi dalam rentang waktu yang sangat singkat .. Ini selalu dapat direproduksi pada sejumlah rpi kami

@pelwell
BAIK; uname -a memberikan Linux pi3b.thuis 4.4.13-v7 + # 894 SMP Sen 13 Jun 13:13:27 BST 2016 armv7l GNU / Linux
Sekadar informasi: di mana orang bisa menemukan git hash untuk versi firmware stabil yang sebenarnya?

@tokopedia
meskipun saya memiliki Bluetooth, saya tidak menggunakannya saat ini. nama hcitool 11: 11: 11: 11: 11: 11 tidak mengembalikan apa pun; yang, saya kira, diharapkan karena saya tidak terhubung ke perangkat apa pun. Mungkin saya harus membelikan saya perangkat audio BT untuk dimainkan.

Tentukan stabil.

Hash yang saya (akhirnya) berikan kepada Anda adalah untuk firmware rilis 20 Juni, yang akan Anda dapatkan jika Anda menjalankan:

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

Saya tidak mengetahui satu tempat pun yang berisi hash dari rilis "stabil" terbaru, tetapi dengan melalui RPI-Distro seperti yang saya lakukan kemudian referensi silang dengan repo Hexxeh Anda bisa mendapatkan hash pembaruan rpi untuk rilis apa pun kamu suka. Jika Anda menganggap rilis 2016-05-23 stabil karena itu adalah bagian dari rilis Raspbian penuh terakhir, maka Anda menginginkan hash 3b98f7433649e13cf08f54f509d11491c99c4c0b yang diterjemahkan menjadi hash pembaruan rpi 2b9c0bfacfc11ee8bb9b30dc9cdb36289698.

@BenoitSvB Hanya menjalankan perintah hcitool dari boot baru tanpa menyentuh hci0 dengan perangkat lunak lain menyebabkan wifi mulai berperilaku buruk dalam pengujian kami, saya tidak tahu apakah penting jika ada perangkat bluetooth lain tetapi itu adalah contoh terkecil yang dapat direproduksi Saya dapat memikirkan untuk memicu masalah pembekuan wifi.

Saya juga menguji dongle bt eksternal + wifi internal tetapi wifi internal terkadang macet bahkan ketika driver bcm bt internal tidak dimuat. "Solusi" (seperti dalam perbaikan cepat) bagi kami adalah menggunakan adaptor wifi usb, yang telah terbukti stabil dalam pengujian dan penggunaan produksi kami.

Saya masih mencurigai # 1313 terkait.

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

Saya juga menguji dongle bt eksternal + wifi internal tetapi internal
wifi terkadang hang bahkan ketika driver bcm internal tidak
sarat. "Solusi" (seperti dalam perbaikan cepat) bagi kami adalah menggunakan wifi usb
adaptor, yang telah terbukti stabil dalam pengujian dan penggunaan produksi kami.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245649229,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AFyzObJxRjzQ-uMUlfe8hjRasrfq3nkwks5qoDLXgaJpZM4HupC5.

@pelwell
stable dalam hal ini adalah firmware yang dirilis oleh Foundation dengan gambar terakhirnya yang dipublikasikan dan diperbarui dengan "sudo apt-get update && sudo apt-get upgrade" saja, jadi tanpa permintaan rpi-update (dengan atau tanpa git khusus hash, yang dimaksudkan seperti yang saya pahami untuk meningkatkan ke firmware yang lebih baru untuk tujuan tertentu saja).
Yang membawa saya ke pertanyaan: dapatkah saya membaca hash dari firmware operasional saya sebelum memuat firmware baru untuk pengujian, untuk membuat pemulihan setelah pengujian lebih mudah karena saya tidak percaya diri saya melakukan referensi silang yang Anda sebutkan ...

Mungkin - cat /boot/.firmware_revision ditulis oleh rpi-update, tapi
tanpa mencobanya, saya tidak dapat memberi tahu Anda apakah rilis Raspbian juga menulis
saya t.

boot / .firmware-revision adalah hal pembaruan rpi (
https://www.raspberrypi.org/forums/viewtopic.php?t=106073&p=732449#p731830)

Tapi saya temukan dengan:

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

yang memang saya inginkan:

• firmware pada 390f53ed0fd79df274bdcc81d99e09fa262f03ab

Saya memahami crossref dari
https://github.com/RPi-Distro/firmware/commits/debian?author=popcornmix ke
https://github.com/Hexxeh/rpi-firmware/commits/master dibuat dengan hati-hati
membandingkan tanggal dan deskripsi dari komit.

Mempelajari sesuatu; terima kasih :)

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

Mungkin - cat /boot/.firmware_revision ditulis oleh rpi-update, tapi
tanpa mencobanya, saya tidak dapat memberi tahu Anda apakah rilis Raspbian juga menulis
saya t.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245693018,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AFyzOQ_pfODaEmuBGR6pQVXs2W6LggW8ks5qoFO2gaJpZM4HupC5
.

@BenoitSvB : Jejak Anda tampaknya menunjukkan jenis masalah yang berbeda - firmware tidak memberikan petunjuk apa pun tentang mengapa Anda terputus. Anda mungkin mendapatkan lebih banyak petunjuk dari packet sniffer seperti WaveShark.

@mathieugouin @ dh-connect @ juched78 @maciex @duncanmcdowell : Saya memiliki seorang insinyur Cypress yang ingin mengetahui lebih banyak tentang masalah Anda; jika Anda mengirim email kepada saya - phil di raspberrypi dot org - saya dapat menghubungkan Anda dengannya. Jika Anda ingin mempercepat, instal modul debug seperti yang dijelaskan di atas dan simpan output dmesg ketika terjadi kesalahan.

@pelwell Google tidak mengembalikan banyak hal substansial pada 'packet sniffer Waveshark' tapi saya rasa yang Anda maksud adalah WireShark. Fakta bahwa memasukkan brcmutil & brcmfmac ke daftar hitam saat menggunakan dongle MT7601U membuat perilaku sambungkan / putuskan sambungan yang tidak menentu menghilang, dikombinasikan dengan kemunculan 'out-of-order' yang sering (lihat # 1313, sekarang tersembunyi tetapi tidak terpecahkan) membuat saya mencurigai Broadcom / Penyebab hardware Cypress.
Wireshark mungkin bisa membantu, tetapi saya memerlukan bantuan untuk menyiapkan / melakukan upaya perangkat keras debugging yang serius.

Ya, maksud saya wireshark.

Anda dapat menggunakan utilitas dumpcap (bagian dari paket mode teks tshark) untuk merekam semua aktivitas ke file, lalu mematikannya jika log dmesg menyertakan pesan yang mencurigakan. Sesuatu seperti ini:

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

Perhatikan bahwa meskipun "grep --max-count 1" seharusnya berhenti setelah satu pertandingan, tampaknya membutuhkan satu baris masukan lagi untuk benar-benar menghentikannya, tetapi itu seharusnya tidak menjadi masalah dalam praktiknya.

Jika file rekaman Anda terlalu besar, Anda bisa mendapatkan dumpcap untuk menggunakan perekaman durasi tetap menggunakan opsi "-b durasi: 60 " (untuk satu menit). Ada kemungkinan bahwa memulai ulang penangkapan seperti ini dapat terjadi pada waktu yang buruk dan kehilangan paket yang menarik, tetapi ini tidak mungkin. Anda selalu dapat mengurangi kemungkinannya dengan meningkatkan durasinya.

@BenoitSvB Ada utas di sini yang menyarankan untuk menonaktifkan roaming di driver WiFi Pi3 sebagai cara untuk menghindari masalah konektivitas. Roaming memungkinkan perangkat untuk secara otomatis berpindah antar AP dengan SSID yang sama, tetapi kemungkinan itu kurang berguna pada perangkat statis seperti Pi3, dan ada saran bahwa hal itu pada akhirnya dapat menyebabkan hilangnya konektivitas total.

Bisakah Anda mencoba mengaktifkan parameter modul roamoff ? Anda perlu membuat create /etc/modprobe.d/brcmfmac.conf yang berisi berikut ini:

options brcmfmac roamoff=1

@pelwell : Menonaktifkan roaming bukanlah solusi; tetapi itu membuat saya bermain dengan saluran yang berbeda dan titik akses kedua. Saya menemukan bahwa adaptor wifi onboard hanya bermasalah dengan beberapa saluran (misalnya 1, 5) dan hanya pada Linksys WRT160N dengan firmware DD-WRT. Anehnya, meskipun tidak ada klien wifi saya yang lain yang berbagi masalah ini: mereka akan terhubung tanpa masalah di semua saluran yang ditawarkan di kedua titik akses. Bagus untuk saya, saya memiliki solusi yang stabil (tidak menggunakan saluran onboard wifi bermasalah dengan) tetapi tidak ada kejelasan dalam masalah ini.
Apakah Anda ingin saya melakukan pengujian khusus?
Ngomong-ngomong kita perlu mengatur parameter
options brcmfmac debug = 1
di /etc/modprobe.d/brcmfmac.conf saat menggunakan driver tes khusus?
Dan tahukah Anda cara mengukur waktu aktif asosiasi wifi: maka saya dapat menguji semua saluran secara lebih sistematis untuk waktu yang lebih lama tanpa membuat file tangkapan besar.

Saya yakin bahwa debugging yang diminta diaktifkan di driver debug secara default (ini memiliki efek yang sama seperti options bcrmfmac debug=0x100000 ), tetapi jangan ragu untuk bereksperimen dengan nilai yang berbeda.

Saya tidak mengetahui cara apa pun untuk mengukur waktu kerja untuk suatu asosiasi, selain sering melakukan polling dan berharap melihat perubahan.

Seorang karyawan Cypress mengetahui utas ini, tetapi kirimkan saya email (phil di raspberrypi dot org) jika Anda senang dihubungi secara langsung.

Halo,

Apakah ada kemajuan dalam masalah ini? Saya dapat terhubung ke jaringan Wi-Fi terbuka saya, dan setelah waktu acak saya memiliki ini di log saya:

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

Dan kemudian saya tidak bisa melakukan ping ke router.

Setelah ifdown wlan0 && ifup wlan0 berfungsi lagi, sampai wlan0: carrier lost .

Manajemen daya dinonaktifkan, bluetooth dinonaktifkan, roaming dinonaktifkan (seperti yang Anda sarankan) dan versi saya adalah Linux pi3 4.4.17-v7+ .

itu selalu terjadi ketika jembatan eth0 dengan wlan0 ， saya mendapat masalah yang sama seperti https://github.com/raspberrypi/linux/issues/1375

Saya memiliki masalah yang sama persis dengan WiFi onboard Pi3 yang putus setelah jangka waktu acak. ifup membuatnya berjalan kembali tidak masalah.

Setelah banyak penyelidikan, saya menemukan itu karena memiliki tiga AP (BSSID) dengan satu SSID (masing-masing 1 di saluran 1, 6, & 11). Pengaturan ini mendukung roaming tanpa batas dan berfungsi sempurna dengan semua klien WLAN lainnya.

Mengaktifkan debugging / logging dengan driver standar tampaknya menunjukkan bahwa pada tahap tertentu Pi memutuskan untuk membatalkan autentikasi dan bahkan membuat daftar hitam salah satu BSSID. Alasannya tidak jelas, tetapi tampaknya keputusan dibuat di akhir Pi.

Ketika saya memiliki konfigurasi yang persis sama di Pi tetapi dengan hanya satu BSSID untuk SSID, Pi dapat bertahan selama berhari-hari tanpa hambatan.

Sayangnya, menonaktifkan roaming sesuai tautan pelwell (http://projectable.me/optimize-my-pi-wi-fi/) tidak benar-benar memungkinkan, hanya memiliki satu BSSID per SSID bukanlah pilihan, dan saya akan bukan harus bergantung pada skrip yang melakukan ping ke beberapa host & kemudian menjalankan ifdown / ifup.

Apakah penyelidikan lebih lanjut sedang dilakukan untuk mendukung beberapa BSSID per SSID, atau dapatkah saya melakukan sesuatu secara khusus untuk mendukung penyelidikan?

Terima kasih!

Saya mengalami masalah ini dan jaringan saya mirip dengan @TheOriginalMrWolf .
Saya memiliki stasiun pangkalan Apple dan bandara ekspres dalam konfigurasi mesh menggunakan WDS.

Saya juga mengalami masalah ini. Jika saya menyalin file ke share samba, koneksi wifi terputus (raspberry 3, raspbian baru diinstal).
Syslog:
brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012

Saya mendapatkan masalah yang persis sama saat memutar musik dengan upnp (gmediarender).

Saya mengalami masalah yang sama saat memulai panggilan suara di wechat, dengan rpi sebagai AP menggunakan hostapd. Saya mendapatkan banyak spam seperti ini:

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

Dengan jejak seperti ini:

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

Jejaknya tampak mirip dengan

Saya baru saja ini terjadi lagi, dan melakukan debugging. Saya mendapat beberapa pesan berbeda kali ini, yang tampaknya menarik (sepertinya itu adalah pesan yang sama yang pernah diterima @maciex ):

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

1. Sepertinya seluruh sistem membeku saat ini terjadi. Menjalankan while sleep 1; do date; done dalam satu putaran menghasilkan celah saat pembekuan terjadi. Saya ingin tahu apakah ini berarti brcmf_proto_bcdc_msg mengembalikan -110 (batas waktu) hanyalah gejala dari masalah sebenarnya - itu hanya mencatat di mana pun kami membekukan.
2. Saya mengukur (dengan vcgencmd ) suhu dan voltase pada saat pembekuan. Tidak ada yang perlu dilaporkan di sana, sejauh yang saya tahu.
3. Sistem saya adalah AP dengan penerusan ke modem ZTE 4G melalui USB (mis. client -> wlan0 -> rpi -> usb0 -> 4g . Sepertinya usb0 masih dapat mengakses internet ketika wifi freeze terjadi.

Re: komentar di atas, ini terjadi dalam mode berbagi NAT untuk saya dengan roamoff=1 . Tak satu pun dari mereka yang memperbaiki atau mengurangi masalah untuk saya.

Setelah menonaktifkan WPA (menggunakan create_ap -w 2 dalam kasus saya untuk hanya mengaktifkan WPA2), masalah tampaknya sudah diperbaiki. Namun tidak jelas mengapa.

Saya juga menghadapi masalah yang dilaporkan di sini. Dalam kasus saya itu terjadi setiap kali saya mengakses file (biasanya mp3) melalui Samba dari pengelola file dan pemutar Samsung + ES.

Raspberry pi3 saya adalah wifi yang terhubung ke AP saya. Oleh karena itu semua komunikasi dengannya dianggap jaringan wifi. Itu tidak memiliki monitor atau keyboard atau mouse.

Saya dapat dengan mudah mereproduksi kesalahan tersebut, jadi jika ada yang ingin saya membuat file log, beri tahu saya bagaimana saya bisa membantu.

Di bawah entri syslog saya.

27 Des 16:11:50 kernel raspberrypi: [560.902063] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
27 Des 16:11:52 kernel raspberrypi: [562.928930] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
27 Des 16:11:54 kernel raspberrypi: [564.926659] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
27 Des 16:11:54 kernel raspberrypi: [564.926820] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO gagal, -52
27 Des 16:11:56 kernel raspberrypi: [566.924560] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
27 Des 16:11:58 kernel raspberrypi: [568.922555] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
27 Des 16:11:58 kernel raspberrypi: [568.928073] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO gagal, -52
27 Des 16:12:00 kernel raspberrypi: [570.920675] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
27 Des 16:12:02 kernel raspberrypi: [572.918980] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
27 Des 16:12:02 kernel raspberrypi: [572.924580] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO gagal, -52
27 Des 16:12:04 kernel raspberrypi: [574.917259] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
27 Des 16:12:06 kernel raspberrypi: [576.915703] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
27 Des 16:12:06 kernel raspberrypi: [576.921498] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO gagal, -52
27 Des 16:12:06 raspberrypi ifplugd (wlan0) [1149]: Menggunakan mode deteksi: IFF_RUNNING

@tokopedia
Saya juga mengalami masalah yang sama dengan penyiapan yang sama.

Solusi setelah berjam-jam debugging:
Matikan IPv6 pada raspberry di /etc/modprobe.d/ipv6.conf:
alias net-pf-10 mati
alias ipv6 mati
opsi ipv6 disable_ipv6 = 1

Ini hanya solusi jika Anda tidak menggunakan ipv6 di jaringan Anda.

Terima kasih @ varl0g Anda adalah pahlawan saya! :)
Sepertinya solusi ini berhasil untuk saya, tidak dapat mereproduksi masalah lagi.

@ varl0g : Ini jahitan solusi bekerja karena saya tidak dapat mereproduksi kesalahan.

Terima kasih dan selamat tahun 2017.

Saya mencoba mematikan ipv6. Itu tidak membuat perbedaan. Saya mencoba mematikan mode hemat daya. Masih tidak ada perbedaan. Namun, ketika saya mengatur saluran AP saya ke 6 (bukan 11), Raspberry Pi saya telah aktif selama 2 hari tanpa masalah!

Saya ingin mengonfirmasi bahwa solusi dengan mematikan IPv6 tidak berfungsi.
Sayangnya, saya memiliki masalah yang sama dengan router RPi3 dan Apple Airport Extreme.

@rajid , @ dh-connect
Anehnya, itu menyelesaikan masalah saya juga ketika saya mengubah saluran wifi AP saya menjadi 6 alih-alih otomatis, terima kasih @rajid

Saya juga punya bug ini - brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
Dimana perbaiki ????
Saya mencoba 4.9 kernel, 4.4.41 kernel - semuanya memiliki bug ini. Catu daya 2.4a.

Saya harus mencabut komentar saya sebelumnya tentang channel 6. Ternyata, kebetulan RPI3 saya memiliki WiFi yang stabil selama 6 hari.

Hanya ingin tahu apakah ada yang beruntung dengan masalah ini. Saya telah mencoba menonaktifkan manajemen daya, bluetooth, dan beralih saluran. Sejauh ini tidak ada yang berhasil. Saya menjalankan Octoprint dengan webcam terpasang. Tampaknya ini cukup sering terjadi, dan saya perhatikan itu terjadi lebih sering ketika saya memiliki lebih dari satu koneksi http yang dibuat.
kesalahan syslog sebelum mode hemat daya:
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
kesalahan syslog setelah mode hemat daya:
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 !!!
Saat ini saya menjalankan Linux octopi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

Saya akhirnya mendapatkan RaspPi 3 saya menjadi stabil di wifi saya dengan mengubah saluran 2.4Ghz wifi saya menjadi "6". Saya lupa apa itu sebelumnya, 11 saya pikir tapi saya tidak yakin. Itu tidak bekerja dengan baik dan saya menemukan halaman web yang mengatakan itu adalah masalah tetapi 6 berfungsi dengan baik. Jauh lebih baik sejak saya mengganti wifi rumah saya ke saluran 6.

/ raj

Pada 3 Mar 2017, pukul 20:39, Daniel < [email protected] [email protected] > menulis:

Hanya ingin tahu apakah ada yang beruntung dengan masalah ini. Saya telah mencoba menonaktifkan manajemen daya, bluetooth, dan beralih saluran. Sejauh ini tidak ada yang berhasil. Saya menjalankan Octoprint dengan webcam terpasang. Tampaknya ini cukup sering terjadi, dan saya perhatikan itu terjadi lebih sering ketika saya memiliki lebih dari satu koneksi http yang dibuat.
kesalahan syslog sebelum mode hemat daya:
brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
kesalahan syslog setelah mode hemat daya:
kernel gurita: [10317.342360] brcmfmac: brcmf_sdio_bus_txdata: keluar dari bus-> txq !!! kernel gurita: [10317.342593] brcmfmac: brcmf_sdio_bus_txdata: keluar dari bus-> txq !!! kernel gurita: [10327.358384] brcmfmac: brcmf_sdio_bus_txdata: keluar dari bus-> txq !!!
Saat ini saya menjalankan Linux octopi 4.1.19-v7 + # 858 SMP Sel 15 Mar 15:56:00 GMT 2016 armv7l GNU / Linux

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-284126948 , atau nonaktifkan utas https://github.com/notifications/unsubscribe-auth/AFAlZVD- 39p6wrK1h7WmH2Hc13mwu55Zks5riOr_gaJpZM4HupC5 .

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

channel 6, channelwidth 20 MHz, terlihat stabil selama berminggu-minggu sekarang.

Saya telah mengamati masalah yang sama Mematikan ipv6 seperti yang disarankan oleh @ varl0g memecahkan masalah saya. Wifi sekarang stabil selama berhari-hari sedangkan sebelumnya akan rusak beberapa menit setelah boot.

Saya belum beruntung di saluran 6 atau 7. memastikan tidak ada orang lain di saluran tersebut.
Saya mencoba mem-flash sd saya dengan gambar baru dan sekarang pengontrol wifi saya tidak mendapatkan sewa DHCP yang tepat. Mereka melakukan boot dengan 169.254.xx.xx ips lokal, bukan subnet dari server dhcp saya.

Memutuskan untuk hanya menghapusnya dan menginstal raspbian terbaru dan menginstal octoprint dari sumber. sejauh ini tidak ada masalah.

Dari apa yang saya tahu, ini adalah masalah dalam perangkat lunak driver brcm80211 sdio.c itu sendiri.
String 0x40012 benar-benar 0x00040012, yang jika diinterpretasikan menggunakan masker dan kode dari sini ~ baris 55, dapat dilihat sebagai string kotak surat yang menunjukkan perubahan kontrol aliran ke DEVREADY. Yang aneh, adalah bahwa string tidak pernah ditafsirkan seperti itu, dan dengan demikian mengenai bagian driver yang kompatibel dengan mundur ~ baris 1127 dari file sdio.c dalam sumber brcm80211 / brcmfmac di sini ..

Saya tidak memiliki pengalaman hebat dengan driver itu sendiri, atau kemampuan untuk mengkompilasi ulang dan menguji (saya hanya punya satu rpi3, dan saya lebih suka tidak mengacaukan lingkungan tempat tinggalnya, saat ini. Juga, saya ' saya tidak ahli dalam mengkompilasi ulang / memperbarui driver linux ..) jadi saya tidak terlalu yakin, tetapi tampaknya dua pesan HMB dikirim bolak-balik dengan sangat cepat, pengemudi tidak memiliki cukup waktu untuk menafsirkan keduanya .

Bagi mereka yang bertanya-tanya, saat ini saya menjalankan octoprint (Dibuat secara manual) pada rpi3 saya melalui nirkabel (duh ..) dengan layar sentuh kapasitif adafruit pitft2.8 "dan kernel khusus adafruit (v 4.4.27-v7 +) dan menduplikasi masalah saat mencoba mengakses aliran video (Logitech C270) di Samsung Galaxy S7 saya melalui PrintDroid pro atau melalui Chrome. Penguncian terjadi tanpa gagal setiap kali ini dilakukan, dan hanya terjadi pada nirkabel. Saya telah meningkatkan catu daya, menonaktifkan ipv6 dan manajemen daya, tidak berhasil.

@TGYK Dapatkah Anda memeriksa masalah yang direferensikan - apakah tampaknya sama bagi Anda? Pesan apa yang Anda dapatkan di dmesg? jatuh tajam?

@TY. Anda telah menautkan ke halaman github Broadcom asli - dapatkah Anda memberikan indikasi di mana masalah tersebut muncul di pohon kernel Raspberry Pi di sini? Agak sulit untuk melacak baris kode apa yang Anda maksud.

sdio.c ada di sini di pohon 4.9 https://github.com/raspberrypi/linux/tree/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac.

@ JamesH65 Di laman github yang Anda
"Isi data kotak surat tidak dikenal: 0x40012", diikuti oleh kesalahan escan (-52).

Masalah yang sama seperti topik referensi Anda tidak terjadi, karena saya tidak menjembatani antarmuka nirkabel dan kabel saya dengan cara apa pun. Sejauh yang saya tahu, masalah saya, dan masalah utas ini hanya berkaitan dengan antarmuka nirkabel.

Terima kasih untuk informasi. Masalah yang mungkin terkait adalah, saya percaya, serupa karena ini adalah masalah dengan driver Wifi yang mungkin mendapatkan pesan aneh yang menyebabkan lebih banyak keanehan nanti dalam tumpukan, tetapi saya masih menggali.

Saya mengalami masalah yang sama dengan raspberry pi Zero W dengan gejala yang mirip dengan @TGYK. Dalam kasus saya, saya menjalankan mpd di nol, dan mengendalikannya melalui klien android pada Samsung Galaxy S5. Tanpa gagal, jika saya meletakkan telepon dalam keadaan siaga saat aplikasi pengontrol berjalan (yaitu, tanpa kembali ke layar utama terlebih dahulu), wifi nol akan rusak dengan pesan "Konten data kotak surat tidak dikenal". Jika saya membiarkan perangkat diam, atau berhati-hati untuk selalu menutup aplikasi sebelum membiarkan ponsel saya tidur, itu tetap menyala tanpa batas.

Saya pernah mengalami masalah ini di Raspian dan sekarang OSMC.

Sebagian besar terputus-putus, tetapi yang menarik mengakses antarmuka web Kodi dari S7 saya akan selalu memicu masalah ini. Melakukan hal yang sama dari iPhone istri saya bekerja dengan sempurna dan tidak pernah memicu masalah.

@daedalia : Saya memiliki masalah yang sangat mirip dengan Samsung Galaxy Tab

Perangkat Samsung saya merusak wifi ketika mencoba mengakses antarmuka web tvheadend.

Itu tidak terjadi ketika diakses dari browser Firefox dari PC windows.

Senang saya menemukan utas ini, mengira saya adalah satu-satunya. Saya mengalami masalah yang sama dengan poster di atas, wifi putus di pi3 / osmc saya saat diakses dari Samsung Galaxy Tab A. Berfungsi dengan baik jika diakses dari tablet Nexus 7, ponsel OnePlus atau laptop Acer, hanya Samsung yang memberikan masalah. Mudah diulang. Sepertinya driver wifi samsung tidak suka wifi pi3 inbuilt? Menambahkan dongle wifi tp-link ke pi3 adalah solusi bagi saya.

@philborman Saya ingin tahu, apakah Anda menggunakan browser seluler yang sama di Samsung vs Nexus?

Keduanya menjalankan chrome, tetapi ini bukan hanya masalah browser. Jika saya menggunakan Yatse untuk
kontrol kodi berfungsi dengan baik dari nexus / mobile / laptop tetapi WiFi pi3 turun
jika saya mencoba hal yang sama dari samsung. Sama jika i ssh in, crash dengan Samsung
dan bukan yang lainnya. Dengan ssh saya dapat melakukan sedikit, tetapi transfer file atau
bahkan mengedit file teks akan menyebabkan koneksi wifi terputus.

Pada Rabu, 12 Apr 2017, 19:03 Mathieu Gouin, [email protected] menulis:

@philborman https://github.com/philborman Saya ingin tahu, apakah Anda menggunakan file
browser seluler yang sama di Samsung vs Nexus?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-293643847 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ALmHOdtJ9AQtpfU7tmeVouI-a4STg2WMks5rvQPJgaJpZM4HupC5
.

Adakah yang berkomentar di sini memiliki kemampuan untuk membangun kernel dengan tambalan yang saya miliki yang mungkin bisa membantu? Ini didasarkan pada 4.9 tetapi mungkin berfungsi dengan baik pada 4.4. Catatan, ini hanya tes ...

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

Halo,

Saya memiliki masalah yang sama yang dijelaskan di sini dengan salah satu dari 2 Pi3 saya. Wifi kehilangan koneksi setelah beberapa waktu, bisa apa saja antara 30 menit dan beberapa jam. Saya benar-benar mencoba semua yang disarankan di sini, termasuk mengubah saluran wifi di AP, dll ... tetapi tidak berhasil. Yang sangat aneh adalah bahwa pada Pi3 kedua saya (rev 1.2 juga, persis sama), dan dengan kartu SD / instalasi yang sama (Raspbian) yang saya tukar di antara keduanya, Wifi sangat solid selama berhari-hari ...

Ini sangat aneh. Kedua Pi3 diperbarui dengan rpi-update, kernel 4.9 dan firmware # 991, tetapi itu sudah sama dengan rilis kernel / firmware sebelumnya.

Jika Anda melakukan update-rpi, Anda akan mendapatkan patch di atas sebagaimana yang diterima oleh kernel devs - ini untuk driver smsc9x dan driver brcmfmac, seperti tadi malam. Bisakah kamu mencobanya? Jika masih gagal, dapatkah Anda melakukan 'dmesg' dan melihat apakah ada yang aneh di syslog? Meskipun, kecurigaan saya mungkin adalah kesalahan HW yang terlihat saat chip nirkabel menghangat karena Pi lain berfungsi dengan baik dengan kartu yang sama.

Terima kasih. Saya melakukan itu di papan yang mencurigakan, wifi terputus setelah beberapa menit.
dmesg memberikan bahwa:
``
[266.654964] brcmfmac: brcmf_sdio_bus_sleep: kesalahan saat mengubah status bus tidur -110
[266.655033] brcmfmac: brcmf_sdio_txfail: kesalahan sdio, batalkan perintah dan hentikan frame
[266.659215] brcmfmac: brcmf_sdiod_regrw_helper: gagal menulis data F1 @ 0x1000d , err: -110
[266.663346] brcmfmac: brcmf_sdiod_regrw_helper: gagal membaca data F1 @ 0x1001a , err: -110
[266.667472] brcmfmac: brcmf_sdiod_regrw_helper: gagal membaca data F1 @ 0x10019 , err: -110
[266.671608] brcmfmac: brcmf_sdiod_regrw_helper: gagal membaca data F1 @ 0x1001a , err: -110
[266.675736] brcmfmac: brcmf_sdiod_regrw_helper: gagal membaca data F1 @ 0x10019 , err: -110
[266.679866] brcmfmac: brcmf_sdiod_regrw_helper: gagal membaca data F1 @ 0x1001a , err: -110
[266.683992] brcmfmac: brcmf_sdiod_regrw_helper: gagal membaca data F1 @ 0x10019 , err: -110
[269.655049] brcmfmac: brcmf_sdio_bus_sleep: kesalahan saat mengubah status bus tidur -110
[272.069378] net_ratelimit: 35 callback disembunyikan

......... maka "putaran" ini terus mengisi log dmesg beberapa kali per menit.

Sunting: Saya menyentuh semua komponen di papan, semuanya tidak panas, saya akan mengatakan sekitar 30 °, hanya sedikit lebih hangat dari kulit jari saya.

Hmm, barang-barang SDIO adalah antarmuka antara Pi dan chip nirkabel - waktunya habis (-110). Ini memang terlihat seperti masalah HW - saat chip memanas, mungkin ada sambungan solder yang buruk pada garis antarmuka sdio di suatu tempat yang berarti komunikasi terputus.

Ping @ Roger-Thornton - Roger, adakah yang bisa kita lakukan untuk menguji ini?

@Crrispy Dapatkah Anda memeriksa bahwa Pi Anda tidak kekurangan daya - apa yang dilaporkan vcgencmd get_throttled ?

@pelwell : setelah kehilangan wifi, saya memeriksa, dan mencekik = 0x0

Saya tidak berpikir itu adalah kesalahan perangkat keras, reboot sederhana selalu menyelesaikan masalah secara instan.

@ JamesH65 Saya rasa ini tidak terlihat seperti masalah pembuatan perangkat keras karena semua jalur berfungsi sebagaimana mestinya. Jika ada petunjuk lain untuk masalah perangkat keras, saya dapat melihat di papan tulis.

Tampaknya tidak menjadi masalah yang sama dengan saya. Saya hanya memiliki satu pi3 dan itu
wifi sangat solid sampai saya terhubung dari tablet Samsung. Terhubung dengan
apa pun dan tidak masalah. Sepertinya tidak bertenaga atau terlalu panas
terkait karena baik-baik saja selama berhari-hari sampai saya terhubung dari yang salah
tablet dan jatuh.

Saya menduga itu terkait driver atau firmware, sesuatu yang samsung
pengemudi mengirimkan bahwa pi3 tidak suka.

Pada Kamis, 27 Apr 2017, 22:01 Crrispy, [email protected] menulis:

@pelwell https://github.com/pelwell : setelah kehilangan wifi, saya memeriksa, dan
dicekik = 0x0

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297823068 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5
.

Ada beberapa perbaikan untuk jaringan di raspbian terbaru -
kapan terakhir kali Anda melakukan a

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

?
Mungkin patut dicoba untuk melihat apakah itu memperbaiki sesuatu.

Pada 28 April 2017 pukul 14:38, philborman [email protected] menulis:

Tampaknya tidak menjadi masalah yang sama dengan saya. Saya hanya memiliki satu pi3 dan itu
wifi sangat solid sampai saya terhubung dari tablet Samsung. Terhubung dengan
apa pun dan tidak masalah. Sepertinya tidak bertenaga atau terlalu panas
terkait karena baik-baik saja selama berhari-hari sampai saya terhubung dari yang salah
tablet dan jatuh.

Saya menduga itu terkait driver atau firmware, sesuatu yang samsung
pengemudi mengirimkan bahwa pi3 tidak suka.

Pada Kamis, 27 Apr 2017, 22:01 Crrispy, [email protected] menulis:

@pelwell https://github.com/pelwell : setelah kehilangan wifi, saya memeriksa,
dan
dicekik = 0x0

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
atau nonaktifkan utasnya
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHag08r5c96nB39R3F-mFW772qBbGks5r0evJgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Saya memiliki masalah yang sama dengan raspbery pi zero W. Setelah beberapa waktu saya tidak dapat melakukan ssh untuk itu. Saya mencoba segalanya. Satu fakta lucu adalah ... ketika saya menghubungkan rpi ke TV saya untuk melakukan beberapa pemecahan masalah setelah saya tidak dapat melakukan ssh ke itu ... itu bekerja selama 18 jam solid. Kemudian, saya mengganti HDMI untuk perangkat lain dan setelah beberapa saat ketika saya ingin ssh ke pi saya mendapat info indah "tidak ada rute ke host". Ketika saya mencolokkan kabel HDMI lagi saya bisa melakukan ping ke gateway. Tidak ada kesalahan di log, iwconfig sepertinya baik-baik saja. systemctl restart jaringan membantu.

Seperti di atas, silakan coba Raspbian terbaru, dan laporkan kembali jika Anda masih melihat
masalah.

Pada 28 April 2017 pukul 19:30, frankja2 [email protected] menulis:

Saya memiliki masalah yang sama dengan raspbery pi zero W. Setelah beberapa waktu saya tidak
bisa ssh untuk itu. Saya mencoba segalanya. Satu fakta lucu adalah ... ketika saya terhubung
rpi ke TV saya untuk melakukan pemecahan masalah setelah saya tidak dapat melakukan ssh ke
itu ... itu bekerja untuk 18 jam rock solid. Kemudian, saya mengganti HDMI dengan yang lain
perangkat dan setelah beberapa waktu ketika saya ingin ssh ke pi saya menjadi cantik "tidak
rute ke host "info. Ketika saya pasang kabel HDMI lagi saya bisa ping
pintu gerbang. systemctl restart jaringan membantu.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D298073149&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=RRDqSoxb3C7hDEBxNO3XBNmSEOtX2e-ViBXtXxAJvMY&s=fnPJANeV-xMcDLPhx_cDGAdzEL2Lkk9HBD9Re7R8i2E&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Saya mungkin satu-satunya yang cukup berkepala dingin untuk menjadi masalah ini, tetapi saya menemukan bahwa wpa_supplicant.conf saya memiliki kode negara yang salah (Tidak terjawab bahwa itu adalah item konfigurasi terpisah dari opsi lokalisasi lainnya). Saya tidak akan mengatakan bahwa masalah hilang sepenuhnya, tetapi setelah saya memperbaikinya, itu berhenti kehilangan koneksi jaringannya dalam "setiap kali saya terhubung dari samsung saya" seperti sebelumnya.

Baru saja memutakhirkan ke yang terbaru (apt-get dist-upgrade) dan itu tampak penuh harapan.
Peningkatan saya sebelumnya sekitar 2 minggu yang lalu sebelum saya melaporkan
masalah awal. Bekerja dengan baik selama beberapa jam terakhir, tidak ada wifi
putus sekolah sama sekali. Terimakasih banyak!

Pada 28/04/17 15:53, James Hughes menulis:

Ada beberapa perbaikan untuk jaringan di raspbian terbaru -
kapan terakhir kali Anda melakukan a

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

?
Mungkin patut dicoba untuk melihat apakah itu memperbaiki sesuatu.

Pada 28 April 2017 pukul 14:38, philborman [email protected] menulis:

Tampaknya tidak menjadi masalah yang sama dengan saya. Saya hanya memiliki satu pi3 dan
nya
wifi sangat solid sampai saya terhubung dari tablet Samsung. Terhubung dengan
apa pun dan tidak masalah. Sepertinya tidak bertenaga atau terlalu panas
terkait karena baik-baik saja selama berhari-hari sampai saya terhubung dari yang salah
tablet dan jatuh.

Saya menduga itu terkait driver atau firmware, sesuatu yang samsung
pengemudi mengirimkan bahwa pi3 tidak suka.

Pada Kamis, 27 Apr 2017, 22:01 Crrispy, [email protected] menulis:

@pelwell https://github.com/pelwell : setelah kehilangan wifi, saya memeriksa,
dan
dicekik = 0x0

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub

< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
,
atau nonaktifkan utasnya
ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub

https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ,
atau nonaktifkan utasnya

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

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298003537 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ALmHORKJxKdws0fMKU5tpfoJHJSah0Ffks5r0e9FgaJpZM4HupC5 .

Ini diperbaiki untuk saya pada rilis terbaru.

Sebagian besar "perbaikan" lainnya tampaknya melewatkan titik di mana sistem saya bekerja
sempurna dengan segala sesuatu kecuali satu tablet (Samsung) sehingga tampaknya
Masalahnya adalah samsung mengirim sesuatu driver / firmware wifi pi3
tidak bisa mengatasinya.

Jika kode negara saya salah, mengapa hanya Samsung yang menyebabkan
masalah. Tablet / ponsel / laptop lain semuanya terhubung dengan baik.

Bagaimanapun, itu sudah diperbaiki sekarang - setidaknya itu tidak jatuh dalam beberapa terakhir
jam. Lebih banyak waktu akan memberi tahu ...

Pada 28/04/17 21:09, rraszews menulis:
>

Saya mungkin satu-satunya yang cukup berkepala dingin untuk masalah ini, tapi
Saya menemukan bahwa wpa_supplicant.conf saya memiliki kode negara yang disetel
salah (Merindukan bahwa itu adalah item konfigurasi terpisah dari yang lain
opsi pelokalan). Saya tidak akan mengatakan bahwa masalahnya hilang
seluruhnya, tetapi setelah saya memperbaikinya, ia berhenti kehilangan jaringannya
koneksi dalam "setiap kali saya terhubung dari samsung saya" dengan cara itu
sebelumnya.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298082370 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ALmHOWtM-_MXCz5RoQd8XShI4Mk-4LAyks5r0jlUgaJpZM4HupC5 .

Dalam kasus saya itu berlangsung sekitar 19 jam. Setelah itu saya tidak bisa ssh lagi ...

Apa perbedaan antara rpi-update dan dist-upgrade?

Karena setelah rpi-update saya mendapatkan 4.9.25+ # 995 dan kemudian saya membuat dist-upgrade dan kernel dikembalikan ke 4.9.24+ # 993. Pokoknya buat saya masalah masih belum terselesaikan. Yang saya lakukan kali ini adalah saya menggunakan rpi0w lain dan PSU yang berbeda :) langkah terakhir adalah menggunakan kartu sd lain.

OK, terima kasih atas informasinya.

Akan membutuhkan lebih banyak informasi untuk dicoba dan ditiru. Pengaturan Anda, apa
Anda telah terhubung dan jenis lalu lintas jaringan sedang berlangsung, log dmesg apa pun
atau pesan kesalahan lainnya setelah sh berhenti bekerja.

Terima kasih.

Pada 29 April 2017 pukul 16:16, franko [email protected] menulis:

Dalam kasus saya itu berlangsung sekitar 19 jam. Setelah itu saya bisa ssh lagi ...

Apa perbedaan antara rpi-update dan dist-upgrade?

Karena setelah pembaruan rpi saya punya 4.9.25+ # 995
https://github.com/raspberrypi/linux/pull/995 lalu saya buat
dist-upgrade dan kernel dikembalikan ke 4.9.24+ # 993
https://github.com/raspberrypi/linux/pull/993 . Pokoknya bagi saya masalahnya adalah
masih belum diperbaiki.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298175041 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHQR8cadrEhb55YJj5PV6PP_odmJmks5r01RJgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Halo,

Saya telah meletakkan Pi3 dalam wadah dengan kipas yang cukup kuat dan suhu ruangan saat ini 19 ° C sehingga tidak bisa menjadi masalah panas. Menukar catu daya dengan yang lain (5V 3A juga). Menggunakan kartu SD lain, dist-upgrade lalu rpi-update.
Kemarin sudah beberapa jam, saya berharap sudah diperbaiki tetapi setelah 3-4 jam terputus (ping -t berjalan dari mesin windoze saya).
Coba lagi pagi ini, wifi mati setelah kurang dari 20 menit :-(
Masih error -110 dari driver wifi di sdio (lihat di atas), yang berulang secara berulang hingga reboot.
Dan Pi3 saya yang lain terhubung selama 3-4 hari sekarang, tidak ada masalah.
Jadi ini mungkin terlihat sebagai kegagalan perangkat keras. Tapi .. kenapa tidak pernah gagal saat boot, dan selalu berfungsi setelah reboot? Benar-benar membingungkan.
Mengapa program mencoba mengubah "status bus tidur" karena manajemen daya dinonaktifkan untuk wlan0? (maaf jika pertanyaannya bodoh).

baru saja menyelesaikan apt-get update; apt-get dist-upgrade . Sayangnya tidak ada perubahan buat saya. Dari pengamatan saya, masalah terkait dengan menjembatani wlan0 bertanya-tanya apakah itu bisa terkait dengan mode promiscuous. Sudah lelah rpi-update juga untuk memeriksa 4.9.25

sebenarnya bahkan lebih buruk dari sebelumnya karena koneksi terputus sekarang biasanya hanya dalam beberapa menit dan saya dapat melihat log biasa

[  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

"Karena setelah rpi-update saya memiliki 4.9.25+ # 995 dan kemudian saya membuat dist-upgrade dan kernel dikembalikan ke 4.9.24+ # 993."

Itu aneh. Saya melakukan peningkatan dist, pergi ke 4.9.24+ # 993 dan ketika saya melakukan pembaruan rpi sekarang, dikatakan saya sudah memiliki firmware terbaru dan tidak ada hubungannya ... mengapa tidak ditingkatkan ke 4.9.25 / # 995?

Sebenarnya harus dikatakan bahwa menggunakan brcmfmac/wlan0 bridged tampaknya bekerja lebih stabil daripada dengan wlan0 murni (semua dengan hostapd)

Jadi, dapatkah Anda memberikan deskripsi lengkap dan akurat tentang penyiapan Anda, bersama dengan
jenis perangkat yang terhubung, dan pesan kesalahan dmesg yang mungkin Anda terima
saat nirkabel gagal.

Saya benar-benar membutuhkan cara untuk mereplikasi masalah yang tidak memakan waktu berjam-jam, jadi
informasi apa pun yang diberikan yang dapat membantu untuk itu diterima dengan rasa syukur.

Pada 1 Mei 2017 pukul 17:27, Szymon Stasik [email protected] menulis:

Sebenarnya harus dikatakan bahwa menggunakan brcmfmac / wlan0 bridged tampaknya lebih berhasil
stabil dibandingkan dengan wlan0 murni (semua dengan hostapd)

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D298367138&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=EjlHynB9dJ8jSAEyJJ1GhRYyOmqDmnvnudeSn-6_IGA&s=u8cZPP8YoQwzh97BQP6tqY2_2yZ30j_UKtU-Lrb3WCc&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Saya tidak tahu apakah ini secara khusus terkait dengan aspek masalah ini tetapi IIRC saya dapat sepenuhnya mereproduksi satu cara untuk menjatuhkan wifi menggunakan perintah hcitool .. Mungkin itu tidak memungkinkan lagi, seperti setahun yang lalu sekarang dan kami menggunakan wifi usb untuk menyelesaikan masalah yang berfungsi untuk sekelompok rpis ...

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

@thomasf Apa pengaturan sistem Anda (perangkat mandiri, titik akses, jalur akses yang dijembatani, dll) dan di mesin mana Anda menjalankan perintah hcitool? Tes cepat pada perangkat yang terhubung ke Pi lain melalui nirkabel tidak menunjukkan masalah.

@ JamesH65 Kami melewati banyak skenario dan masalah dapat direkonstruksi dalam konfigurasi apa pun ..

Ketika perintah hcitool dijalankan pada rpi biasanya kehilangan koneksi jaringan (wifi) dalam hitungan detik .. IIRC lebih mudah untuk mereproduksi jika ada lalu lintas jaringan pada perangkat (seperti transfer file).

Dengan cepat melihat sistem penyediaan terakhir kami, berikut wpa_supplicant.conf adalah yang terakhir yang kami gunakan .. Saya pikir itu tidak terlihat jauh berbeda dari yang menyebabkan masalah dengan antarmuka wifi internal ,,, Saya yakin itu kami mulai menggunakan hanya satu AP namun masih mendapatkan masalah ..

(SSID dan kunci dihapus):

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

Saya baru saja menemukan skrip bernama troublemaker.sh di repo penyediaan sekarang ..

Ini sangat hacky, saya pikir saya menyediakannya untuk dijalankan saat start up ~ seperti sekali setiap beberapa menit atau lebih ~~ (edit: mungkin hanya sekali karena melakukan beberapa perulangan dengan sendirinya) pada sekelompok rpi untuk memprovokasi masalah dan mendapatkan beberapa log diselamatkan..

Ini terutama digunakan sebelum saya memahami lebih banyak tentang masalahnya .. Saya pikir waktu ping dan packet loss meningkat untuk periode sebelum wifi benar-benar terputus ..

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

Menjalankan skrip pembuat masalah pada Raspbian stabil terbaru (kernel 4.9) tidak menunjukkan kesalahan, yang bagus, tetapi buruk untuk mencoba mereplikasi kesalahan!

@ciekawy Melihat ke belakang, Anda tampaknya dapat dengan mudah meniru masalah yang tidak dapat kami lakukan di sini. Bisakah Anda memberi saya gambaran tentang penyiapan persis Anda, jadi saya dapat menyelidikinya. Juga layak mendapatkan pembaruan rpi terbaru karena ada beberapa perbaikan di sana untuk USB yang mungkin atau mungkin tidak memiliki relevansi (jika Anda menggunakan ethernet). Saya perlu mengetahui topologi jaringan Anda, bagaimana Pi diatur, apa yang tampaknya memicu masalah. Sesuatu yang benar-benar!

@ JamesH65 , pengaturan saya saat ini adalah:

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

juga untuk 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

Perlu disebutkan bahwa RPI ini berjalan stabil selama berhari-hari (meskipun transfer 10mbps yang lebih tahan lama juga dapat menimbulkan beberapa masalah) ketika peran dialihkan dan wlan0 brcmfmac digunakan untuk terhubung ke internet dan AP lokal berjalan di wlan2 ath9k. Saya telah mengubah konfigurasi karena saya perlu menggunakan antena yang lebih baik yang terhubung ke wlan2 untuk akses internet.

rpi-updated saya baru-baru ini pada tanggal 1 Mei

Saya memiliki masalah yang sama persis di rpi3 menggunakan Archlinux-ARM.

Setelah beberapa jam menjalankan create_ap itu berhenti bekerja dengan pesan dmesg yang sudah dilaporkan oleh orang lain:
[11418.347554] brcmfmac: send_key_to_dongle: kesalahan wsec_key (-110)

Terkadang berhasil selama 1 hari tanpa masalah, dan terkadang berfungsi beberapa menit sebelum masalah terjadi.

Alarm Linux 4.9.25-2-ARCH # 1 SMP Jum 5 Mei 00:46:52 UTC 2017 armv7l GNU / Linux

Masalah yang sama pada Pi Zero W, Raspbian Lite saat ini. Setelah beberapa waktu (berbeda dari menit ke jam) 'dmesg' muncul
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
Mulai saat ini koneksi wifi hilang dan hanya dapat dimulai ulang dengan rmmod'ing dan modprob'ing brcmfmac.

Saya menonaktifkan manajemen daya: tidak ada perubahan.
Saya memperbarui semuanya melalui apt-get upgrade / dist-upgrade: tidak ada perubahan
Saya memperbarui hal-hal melalui rpi-update: tidak ada perubahan

brcmfmac pasti disadap. Saya mengalami masalah yang sama dengan dmesg msg "brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak dikenal: 0x40012" dan terkadang pesan yang berbeda juga, seperti yang dilaporkan dalam posting saya di atas.

Saya menggunakan adaptor wifi usb tp-link dan aplikasi saya berfungsi dengan baik sekarang.

Saya harap broadcom bisa memperbaiki bug di brcmfmac.

Ada solusi?

Seperti yang saya sebutkan di awal percakapan ini, saya mengubah router Wifi saya untuk menggunakan saluran 6, bukan 11 (yang digunakan sebelumnya), dan rPi saya telah aktif sejak saat itu (dari bulan Januari sampai sekarang) tanpa masalah di semua.

Mungkinkah ini terkait dengan catatan modul kernel ini:

Generasi chip ini berisi dukungan regulasi tambahan yang tidak bergantung pada pengemudi. Perangkat menggunakan satu domain peraturan di seluruh dunia, dengan saluran 12-14 (pita 2,4 GHz) dan saluran 52-64 dan 100-140 (pita 5 GHz) yang dibatasi untuk operasi pasif. Transmisi pada saluran tersebut ditekan sampai lalu lintas lain yang sesuai diamati pada saluran tersebut. Di dalam pengemudi, kami menggunakan kode negara fiktif "X2" untuk mewakili domain peraturan seluruh dunia ini. Saat ini tidak ada antarmuka untuk mengkonfigurasi domain yang berbeda. Pengemudi membaca kode negara SROM dari chip dan menyerahkannya ke mac80211 sebagai petunjuk peraturan, namun informasi ini sebaliknya tidak digunakan dengan pengemudi.
(dari sini: https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211)

Saya kira ini berarti bahwa bahkan kode negara "DE" (yang seharusnya memungkinkan saluran wifi yang lebih tinggi) tidak berpengaruh? Tetapi saya tidak yakin apakah ini bisa memiliki efek yang mirip dengan masalah Unknown mailbox data content: 0x40012 ...

Setidaknya bagi saya itu tidak ada solusi - beralih dari saluran 11 ke saluran 6 hari ini, 2 jam kemudian: Unknown mailbox data content: 0x40012

Saya mengalami masalah itu sampai saya meningkatkan kekuatan sinyal dengan range extender.
Bisakah Anda menguji apakah koneksi lebih stabil memindahkan Pi ke tempat dengan sinyal yang lebih baik?

Mungkin ini disebabkan oleh daya tambahan yang diperlukan untuk beroperasi pada kekuatan sinyal yang buruk.

Masalah yang sama seperti Crrispy.

Bagi mereka yang mengerjakan ini dengan adaptor USB WiFi (mengubah saluran, dll, juga tidak berfungsi untuk saya), Edimax EW-7811Un langsung berfungsi ketika saya mencolokkannya ke kabel USB OTG saya pada RPI Zero W. Saya tidak ' t harus melakukan konfigurasi atau ifconfig - itu langsung ada di jaringan! Kemarin, saya main-main dengan TP-Link Archer T1U AC450 selama beberapa jam.

@ b3nj1 - maaf ikut

Saya memilih solusi yang sama - membeli adaptor USB dengan antena eksternal dan chipset mt7601 (sekitar 5 Eur) untuk Zero W saya, bekerja dengan sempurna. Seharusnya membeli non-W di tempat pertama ... masalah ini ada selama lebih dari satu tahun dan tidak ada perbaikan yang terlihat.

@blacktigersoftware - ini aneh, bukan !? Zero W WiFi berfungsi dengan baik. Zero W Bluetooth berfungsi dengan baik. Tapi, jika saya menggunakan keduanya secara bersamaan, sistem menjadi sangat lambat dan akhirnya tidak dapat dijangkau melalui wifi.

Telah melihat sekilas masalah maibox yang dijelaskan di atas. Google menunjukkan ini tampaknya terjadi sedikit adil (dan setidaknya satu referensi ke platform non-Pi). Kode driver mendeteksi bahwa pesan yang datang kembali dari kotak surat (saya anggap koneksi ke firmware HW) memiliki beberapa bit yang disetel yang seharusnya tidak ada. Namun, ini hanya mencetak pesan - tidak melakukan pemulihan atau pengembalian kesalahan. Karena ini tampaknya merupakan nilai yang dikembalikan dari firmware, saya tidak memiliki akses ke sana untuk benar-benar melihat apa yang sedang terjadi, dan lembar data pada chip sama sekali tidak membantu. Jadi saya pikir yang ini perlu didorong ke Broadcom / Cypress / linux-wireless untuk penyelidikan.

Juga perlu dicatat bahwa kami tampaknya memiliki firmware HW terbaru sesuai dengan https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm. File memiliki perbedaan panjang satu atau dua byte tetapi hanya itu.

Masalahnya adalah kesalahan kotak surat diikuti oleh kesalahan lain (-52, -110, dll), dan hanya me-reboot sistem wifi kembali berfungsi.

-110 adalah kesalahan batas waktu, menandakan ada hal lain yang sekarat dan tidak merespons. -52 adalah pertukaran yang tidak valid, yang berada di sepanjang garis yang sama. Saya menduga bahwa pada saat terjadi kesalahan kotak surat, firmware pada chip tidak berfungsi dengan baik, sehingga kesalahan lain ini melanjutkannya.

Adakah orang yang dapat mereplikasi masalah yang dapat membangun kernel dev Pi terbaru (4.11, tersedia dari github kami) dan melihat apakah kesalahan kotak surat masih terjadi. Sebelum saya mulai mendorong upstream, saya ingin tahu ini masih terjadi di kernel terbaru, dan saya belum dapat menirunya.

Saya dapat mengonfirmasi masalah yang terjadi di: Alarm Linux 4.9.25-2-ARCH # 1 SMP Jum 5 Mei 00:46:52 UTC 2017 armv7l GNU / Linux

Saya belum menguji di kernel 4.11

Driver yang digunakan dalam pengujian saya: brcmfmac: Versi firmware = wl0: 15 Des 2015 18:10:45 versi 7.45.41.23 (r606571) FWID 01-cc4eda9c

@ b3nj1 - wow, terima kasih atas perhatiannya

Semua orang - apakah ini hanya terjadi saat GPU dihidupkan?

GPU selalu aktif (sampai batas tertentu), di semua model Pi.

Yang Anda maksud saat Bluetooth aktif?

@ JamesH65 - Saya akan mencoba 4.11. Apakah saya hanya mengkloning / membangun sesuai dengan yang berikut? Saat mengkloning menurut petunjuk tersebut, saya berada di cabang rpi-4.9.y. Haruskah saya membayar rpi-4.11.y atau yang lainnya?

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

Terima kasih sebelumnya

Periksa cabang rpi-4.11.y, kemudian bangun kembali menggunakan instruksi Anda
telah ditautkan ke.

Pada 25 Mei 2017 pukul 05:02, b3nj1 [email protected] menulis:

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

• Saya akan mencoba 4.11. Apakah saya hanya mengkloning / membangun sesuai dengan yang berikut?
  Saat mengkloning sesuai, saya berada di cabang rpi-4.9.y. Haruskah saya checkout
  rpi-4.11.y atau yang lain?

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

Terima kasih sebelumnya

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D303916506&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=MvrZEWZr46JRqX_2LLKdchnCVZJLmKJ9gMYoScOCXTc&s=AGANXJT8mm2dDDBNh9M40Me6Y0E0V8bfRyuFuxauBlQ&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Sekadar mengulangi beberapa informasi yang saya berikan di tempat lain, saya telah menguji koneksi nirkabel dalam kondisi daya rendah. Saya telah menurunkannya ke titik perangkat USB putus, tetapi tidak melihat masalah koneksi nirkabel. Meskipun itu adalah bukti bahwa ini bukan masalah kekuasaan, perlu diperhatikan.

Saya kebetulan menemukan cara mereproduksi ini dengan menjalankan sudo memtester 256M 1 melalui SSH menggunakan ponsel saya; wifi mati segera setelah memtester mulai membanjiri dengan karakter "memuat":

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

Anehnya, wifi hanya hang saat melakukan ini di ponsel saya. Saya sudah mencoba PC saya, pi lain dan router saya tidak berhasil.

@ JamesH65 - Pembaruan 2: Saya bisa boot dengan 4.11 (Saya salah konfigurasi kernel pada kali pertama).
Linux rpiz 4.11.2+ #2 Thu May 25 21:19:11 PDT 2017 armv6l GNU/Linux

Sayangnya, sistemnya masih responsif saat saya palu di BT.

Ketika saya mencolokkan kembali WiFi USB eksternal dan menghubungkan alamat adaptor itu, semuanya baik-baik saja.

• Benjamin

Kernel baru dibangun dan diinstal dari cabang rpi-4.11.y mengikuti instruksi di sini: 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

Sayangnya, wifi masih hang dengan kesalahan yang sama:
brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Jika Anda menghibur saat wifi padam, Anda dapat memulai ulang. Saya sedang menguji skrip bash sekarang untuk melihat apakah ini membantu. Saya akan menjalankannya di cron. Ini dia jika ada yang tertarik.

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

Saya telah menjalankan ini selama sehari dan sejauh ini saya belum memperhatikan penurunan wifi saya.

@ Jr1994
Apakah masih berfungsi?
Seberapa sering Anda menjalankannya?
Setiap menit ?

Saya akan mencobanya di beberapa raspberry saya, saya punya beberapa yang saya restart setiap kali tidak bisa melakukan ping ke router

Terima kasih sebelumnya

Sejauh ini bagus. Saya memeriksa setiap 2 menit.

Perhatikan bahwa revisi firmware terakhir untuk brcmfmac terlalu lama:

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

@semeion Tidak yakin firmware apa yang Anda gunakan - yang saat ini harus "Versi: 7.45.41.26 CRC: 5932ca06 Tanggal: Jum 2016-05-27 00:15:32 PDT Ucode Ver: 1043.2060 FWID: 01-df77e4a7". Ini secara efektif sama dengan yang ada di repo firmware-linux, meskipun kami mendapatkannya langsung dari Brcm.

@ JamesH65 Pesan itu dikembalikan di dmesg.

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

Tetapi menggunakan vcgencmd version itu menunjukkan:

$ /opt/vc/bin/vcgencmd version

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

Itu bukan firmware chip Wifi, itu firmware SoC, yang mendapatkannya
diperbarui cukup sering.

Masih tidak yakin mengapa sistem Anda menganggapnya memiliki firmware lama itu. Kamu
memiliki firmware SoC terbaru jadi mungkin Anda telah melakukan peningkatan apt-get
baru saja?

Pada 5 Juni 2017 pukul 17:55, Alexandre Bolelli [email protected] menulis:

@Jamal_jogja
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=
Pesan itu dibalas di dmesg. Tetapi menggunakan versi vcgencmd itu menunjukkan:
Versi `$ / opt / vc / bin / vcgencmd
Versi Firmware

30 Mei 2017 15:23:29
Hak Cipta (c) 2012 Broadcom
versi b8cdd5ae76f39d9f353dfa8fb48bf7e33b74903c (bersih) (rilis) `

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D306242176&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=W4TAJLAOB4LK3uzOCSYuvCg12E0PPs2YnLK7F3dSY6o&s=w68PzYzJ8vnRpMlooVMqrykuimfbvRpWuispieW9KgU&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

@ JamesH65 Seperti yang saya katakan di atas, saya menggunakan Archlinux-ARM, itu adalah distro rilis bergulir, dan ya sistem saya diperbarui dengan pacman -Syu (pacman -Syu adalah apt-get upgrade / update equivalent).

Tidak tahu mengapa firmware lama itu sudah tua di sistem saya. Mungkin itu yang menjadi penyebab bug itu. Bagaimana menurut anda?

Bagaimanapun, bug terjadi dengan raspbian kan? Bug itu dilaporkan pada Maret 2016? Sudah tua.

PS. Bahasa Inggris bukan bahasa ibu saya, maaf atas kesalahan / kesalahan eja.

Oke, tidak menyadari bahwa Anda menggunakan ARCH. Sepertinya mereka tidak memasok
gumpalan firmware terbaru untuk chip Wifi. Anda bisa memperbaruinya secara manual
mungkin memperbaiki masalah Anda, mungkin tidak - saya pikir mungkin ada beberapa
bug nirkabel, dan tidak ada jaminan bahwa Anda yang Anda lihat adalah
satu orang melihat di Raspbian.

Anda harus melaporkan firmware kedaluwarsa ke pengelola lengkungan, dan
mungkin bug nirkabel juga, karena itu mungkin disebabkan oleh distro Arch.

Perhatikan bahwa umumnya kami tidak mendukung distro lain, distro internal kami adalah
Raspbian, jadi untuk menyelidiki masalah, kami harus dapat mereplikasi masalah tersebut
bahwa.

Pada 5 Juni 2017 pukul 23:13, Alexandre Bolelli [email protected] menulis:

@ JamesH65 https://github.com/jamesh65 Seperti yang saya katakan di atas, saya menggunakan
Archlinux-ARM, itu adalah distro rilis bergulir, dan ya sistem saya diperbarui
dengan pacman -Syu (pacman -Syu adalah apt-get upgrade / update equivalent).

Tidak tahu mengapa firmware lama itu sudah tua di sistem saya. Mungkin bisa
alasan bug itu. Bagaimana menurut anda?

Bagaimanapun, bug terjadi dengan raspbian kan? Bug dilaporkan di
Maret 2016? Sudah tua.

PS. Bahasa Inggris bukan bahasa ibu saya, maaf atas kesalahan / kesalahan eja.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306325452 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHaL4XsN5drPggS8eJDZWme4LyKXWks5sBH2CgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

@ james65 Ya memang. Saya akan mencoba bertanya di # archlinux-arm mengapa firmware itu sudah tua. Bagaimanapun saya akan mengikuti masalah ini dan mencari solusinya. Saya akan melaporkan di sini setiap informasi yang ditemukan.

Terima kasih sebelumnya.

@ JamesH65 Saya dapat mereplikasi secara konsisten di Raspbian saya (RPi 3). Jika ada yang bisa saya lakukan untuk membantu, beri tahu saya!

Apa pengaturan Anda? Bagaimana Anda mereplikasi masalah tersebut?

Pada 6 Juni 2017 pukul 14:17, Dan [email protected] menulis:

@ JamesH65 https://github.com/jamesh65 Saya bisa menggandakannya
secara konsisten di Raspbian saya (RPi 3). Jika ada yang bisa saya lakukan untuk membantu
dengan ini, beri tahu saya!

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306483030 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHWyW5cQuS47k3xTmi3UX-QW7ffEYks5sBVF5gaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Lihat di komentar sebelumnya, saya sudah menjelaskan cara mereproduksinya belum lama ini.
Pi menjalankan Raspbian penuh dengan layar 3,5 "di atas menggunakan catu daya resmi. Tidak ada yang mewah, semuanya terus diperbarui dengan rpi-update dan apt upgrade.

Setelah beberapa hari, wifi internal berhenti berfungsi dengan pesan berikut di 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

Saya menjalankan hostapd pada antarmuka ini dan memiliki antarmuka wifi usb lain yang terpasang ke Pi. Informasi sistem saya:

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

Ya, dan ketika menunjukkan bahwa (-110) Anda perlu mem-boot ulang sistem agar berfungsi kembali ...

Senang mengetahui itu terjadi di Raspbian juga, bugnya independen distro. Terjadi hal yang sama di Archlinux.

Namun, sejak saya memindahkan wifi saya dari saluran 11, ke saluran 6 sebagai gantinya, saya belum melihat masalah sejak itu. Saya mengerti, dari balasan saya sebelumnya di utas ini, sudah sejak 7 Januari ketika saya melakukan perubahan ke saluran 6. Saat ini saya menjalankan dua RaspPI Zero W dan satu RaspPi 3, semuanya tanpa masalah. Kedua RaspPi W menjalankan DietPi.

Saya juga memiliki masalah ini di Raspberry Pi 3. Saya sudah mencoba saluran wifi yang berbeda.
Saya mengamati bahwa jika saya menghubungkan port LAN juga, wifi stabil sekali. Segera setelah saya mencabut port LAN, wifi terus turun sepanjang waktu.

Itu sangat aneh ......!

Pada 15 Juni 2017 pukul 23:02, macmeck [email protected] menulis:

Saya juga memiliki masalah ini di Raspberry Pi 3. Saya mencoba saluran wifi yang berbeda
sudah.
Saya mengamati bahwa jika saya menghubungkan port LAN juga, wifi stabil sekali.
Segera setelah saya mencabut port LAN, wifi terus turun sepanjang waktu.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-308878043 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHbUKBO9mG3xpKHFK977h4hrFUhrGks5sEantgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Saya punya
"brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012"
masalah juga di rpi3 saya. solusi saya yang paling dapat diandalkan untuk mencegah kesalahan ini telah
"Wondershaper 9000 9000"
Saya berharap akar masalahnya ditentukan.

Saya memiliki masalah yang sama persis. Pi3 saya memiliki gejala berikut saat terhubung dengan WIFI SAJA:

1. Wifi KELUAR bekerja HEBAT. Saya dapat terhubung ke internet dan mengunduh file tanpa masalah di pi3 saya.
2. SEMUA koneksi wifi MASUK gagal. Ping timeout, port 80 http mengakses timeout, ssh gagal, semuanya gagal INBOUND ONLY.
   CATATAN:
3. Setelah Ethernet terhubung ke pi3, maka wifi berfungsi LEBIH BAIK tetapi masih menjatuhkan paket.
4. Setelah Ethernet dihapus lagi, wifi benar-benar gagal semua koneksi masuk.
5. Setelah Ethernet terhubung lagi ke pi3, wifi bekerja LEBIH BAIK dan memungkinkan beberapa paket masuk. tapi masih banyak yang turun.

Tolong perbaiki ini!

Saya telah memperhatikan yang berikut di ifconfig:

Paket RX: 1613 kesalahan: 0 dijatuhkan: 1074 overruns: 0 frame: 0
Paket TX kesalahan: 0 dijatuhkan: 0 overruns: 0 operator: 0
emisi: 0 ton bahan bakar: 1000

Jadi pada dasarnya sisi RX dari WIFI pi3 menjatuhkan paket seperti orang gila. Tidak heran mengapa itu tidak akan menanggapi koneksi masuk. TX berfungsi dengan baik!

Sejak saya mengatur skrip itu, saya tidak memiliki masalah dengan wifi di kedua saya
RPI3s.

Pada hari Rabu, 21 Jun 2017 jam 4:26 pagi, Edward Kang [email protected]
menulis:

Saya telah memperhatikan yang berikut di ifconfig:

Paket RX: 1613 kesalahan: 0 dijatuhkan: 1074 overruns: 0 frame: 0
Paket TX kesalahan: 0 dijatuhkan: 0 overruns: 0 operator: 0
emisi: 0 ton bahan bakar: 1000

Jadi pada dasarnya sisi RX dari WIFI pi3 menjatuhkan paket seperti orang gila.
Tidak heran mengapa itu tidak akan menanggapi koneksi masuk.

HARAP PERBAIKI INI !!

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310049620 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AFHmIH6kkxraxahE22_PpstdDkqW8Pgqks5sGP3ggaJpZM4HupC5
.

Itu semua sangat baik mengatakan "tolong perbaiki ini" tetapi masalah seperti ini benar-benar bajingan untuk ditemukan. Butuh waktu sebulan untuk menemukan kesalahan pada driver smsc / brcmfmac saat menjembatani, dan saya beruntung menemukannya, dan saya curiga kesalahan ini lebih jarang dan lebih sulit ditemukan. Jika ada yang bisa menemukan test case yang dapat direplikasi yang menunjukkan kesalahan dengan cepat, itu akan sangat membantu. Beberapa orang tampaknya sering mendapatkan kesalahan besar, saya sangat jarang mendapatkannya.

Adapun masalah dengan paket yang jatuh, ini sedang diperiksa ketika saya memiliki celah dalam jadwal. Dalam kasus di atas, Anda tampaknya membuang hampir semua paket, yang paling aneh, dan biasanya tidak dilihat oleh sebagian besar orang. Apakah ini terjadi dengan semua perangkat yang terhubung ke Pi? Atau hanya satu saja.

maaf, james!

Saya tidak yakin apa yang Anda maksud dengan semua perangkat yang terhubung ke Pi. Paket yang dijatuhkan berasal dari menjalankan ifconfig secara langsung pada pi. Pi terhubung melalui wifi ke router. Ketika pi terhubung ke jaringan wifi saja, pi secara konstan menerima dan menjatuhkan paket.

@ JamesH65 Baiklah, saya setuju dengan Anda, sulit untuk menyelesaikannya ... Tetapi dengan menggunakan Arch Linux-ARM, menginstal paket "create_ap" dan mengaktifkannya (pacman -S create_ap; systemctl start / enable create_ap), Anda bisa mendapatkan - 110 kesalahan dan "Isi data kotak surat tidak dikenal: 0x40012" dalam beberapa menit pengoperasian ... Cukup sambungkan ponsel cerdas Anda dan / atau TV pintar sesekali dan kesalahan akan datang.

Kami tidak mendukung Arch, Raspbian adalah OS yang kami dukung dan itu adalah I
harus dapat memperbaiki masalah ini. Saya tidak tahu versi
kernel atau driver yang digunakan ARCH, mereka bisa sangat berbeda dari
yang ada di Raspbian.

Apakah orang-orang masih melihat masalah saat menggunakan Pi sebagai titik akses?
Menggunakan bridging? IPv4 atau IPv6? Ini adalah jenis informasi (bukan
Eksklusif tentu saja, diperlukan informasi sebanyak mungkin)
untuk mereplikasi masalah.

Perhatikan bahwa Broadcom telah diberitahu tentang kesalahan kotak surat (Ini chip mereka
dan pengemudi, tentu saja), tetapi segala sesuatunya cenderung bergerak lambat bersama mereka.

Pada 21 Juni 2017 pukul 18:27, Alexandre Bolelli [email protected]
menulis:

@Jamal_jogja
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=
Yah, saya setuju dengan Anda, ini sulit untuk dipecahkan ... Tetapi menggunakan Arch Linux-ARM,
menginstal paket "create_ap" dan mengaktifkannya (pacman -S create_ap;
systemctl / startenable create_ap), Anda bisa mendapatkan kesalahan -110 dan
"Isi data kotak surat tidak dikenal: 0x40012" dalam beberapa menit pengoperasian ... Hanya
menghubungkan smartphone Anda dan / atau smart TV di kadang-kadang dan kesalahan
akan datang.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D310149166&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w&s=bv5qC2cUEdCUx-HsDkQYbYJ1fuscyuPU_iPIGs7ViHA&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Saya menggunakan ipv4 statis pada beberapa perangkat dan mengalami masalah yang sama dengan file
yang lain menggunakan dhcp

22-06-2017 04:06 GMT-03.00 James Hughes [email protected] :

Kami tidak mendukung Arch, Raspbian adalah OS yang kami dukung dan itu adalah I
harus dapat memperbaiki masalah ini. Saya tidak tahu versi
kernel atau driver yang digunakan ARCH, mereka bisa sangat berbeda dari
yang ada di Raspbian.

Apakah orang-orang masih melihat masalah saat menggunakan Pi sebagai titik akses?
Menggunakan bridging? IPv4 atau IPv6? Ini adalah jenis informasi (bukan
Eksklusif tentu saja, diperlukan informasi sebanyak mungkin)
untuk mereplikasi masalah.

Perhatikan bahwa Broadcom telah diberitahu tentang kesalahan kotak surat (Ini chip mereka
dan pengemudi, tentu saja), tetapi segala sesuatunya cenderung bergerak lambat bersama mereka.

Pada 21 Juni 2017 pukul 18:27, Alexandre Bolelli [email protected]
menulis:

@Jamal_jogja
3A__github.com_jamesh65 & d = DwMFaQ & c = DpyQ_ftY536pf7wCBQXXU58xADDRY77THQz
Ju1OmzOo & r = w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m =
BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w & s = o90aBGb27vZvog3BdioLSa2_
MEySix0ymtnTgiNb87c & e =>
Yah, saya setuju dengan Anda, ini sulit untuk dipecahkan ... Tetapi menggunakan Arch Linux-ARM,
menginstal paket "create_ap" dan mengaktifkannya (pacman -S create_ap;
systemctl / startenable create_ap), Anda bisa mendapatkan kesalahan -110 dan
"Isi data kotak surat tidak dikenal: 0x40012" dalam beberapa menit operasi ...
Hanya
menghubungkan smartphone Anda dan / atau smart TV di kadang-kadang dan kesalahan
akan datang.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D310149166 & d =
DwMFaQ & c = DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo & r = w09_
2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m = BDIwUx7SC6sTRvRQKgA0QZB_
ZlIJDs3bd_wzKoIw_7w & s = bv5qC2cUEdCUx-HsDkQYbYJ1fuscyuPU_iPIGs7ViHA & e =>,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310294786 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ACeQBFj8ICNkDl7xYwYJcD6TK-k6_4K5ks5sGhJ1gaJpZM4HupC5
.

Satu hal yang perlu diperhatikan adalah bahwa wifi berfungsi dengan sempurna untuk saya sejak saya mendapatkan pi3 tahun lalu hingga sekitar 3 bulan yang lalu ketika wifi berhenti berfungsi.

Jelas pasti ada semacam perubahan pada perangkat lunak sekitar waktu itu yang menyebabkan wifi berhenti berfungsi.

Jika wifi Anda telah berhenti berfungsi sepenuhnya, maka itu menunjukkan masalah di pihak Anda (yang mungkin diperparah oleh masalah perangkat lunak tentu saja), karena untuk orang lain, Wifi umumnya berfungsi (meskipun saya melihat paket yang jatuh).

BTW rpi3 saya adalah merek baru di Inggris.

Saya telah melawan ini juga selama beberapa bulan. Terkadang itu berlangsung selama beberapa menit. Terkadang berminggu-minggu. Penyebut umum ketika saya kehilangan koneksi adalah saya melihat panggilan untuk mengatur ulang domain regulasi dunia CRDA segera sebelum kehilangan koneksi. Setiap saat. Jalur akses Ubiquiti AC, saluran 11, lebar saluran HT40 (hanya hal yang mungkin istimewa).

28 Jun 14:19:31 kernel raspberrypi: [980.387378] cfg80211: Domain regulasi dunia diperbarui:
28 Jun 14:19:31 kernel raspberrypi: [980.387387] cfg80211: Wilayah Master DFS: tidak disetel
28 Jun 14:19:31 kernel raspberrypi: [980.387396] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 Jun 14:19:31 kernel raspberrypi: [980.387411] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N / A, 2000 mBm), (N / A)
28 Jun 14:19:31 kernel raspberrypi: [980.387426] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N / A, 2000 mBm), (N / A)
28 Jun 14:19:31 kernel raspberrypi: [980.387439] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N / A, 2000 mBm), (N / A)
28 Jun 14:19:31 kernel raspberrypi: [980.387453] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (N / A)
28 Jun 14:19:31 kernel raspberrypi: [980.387468] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2000 mBm), (0 dtk)
28 Jun 14:19:31 kernel raspberrypi: [980.387481] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N / A, 2000 mBm), (0 dtk)
28 Jun 14:19:31 kernel raspberrypi: [980.387493] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N / A, 2000 mBm), (N / A)
28 Jun 14:19:31 kernel raspberrypi: [980.387505] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 0 mBm), (N / A)
28 Jun 14:19:32 kernel raspberrypi: [981.262521] cfg80211: Domain regulasi diubah menjadi negara: AS
28 Jun 14:19:32 kernel raspberrypi: [981.262536] cfg80211: Wilayah Master DFS: FCC
28 Jun 14:19:32 kernel raspberrypi: [981.262540] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
28 Jun 14:19:32 kernel raspberrypi: [981.262549] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N / A, 3000 mBm), (N / A)
28 Jun 14:19:32 kernel raspberrypi: [981.262557] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2300 mBm), (N / A)
28 Jun 14:19:32 kernel raspberrypi: [981.262565] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N / A, 2300 mBm), (0 dtk)
28 Jun 14:19:32 kernel raspberrypi: [981.262571] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N / A, 2300 mBm), (0 dtk)
28 Jun 14:19:32 kernel raspberrypi: [981.262578] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N / A, 3000 mBm), (N / A)
28 Jun 14:19:32 kernel raspberrypi: [981.262584] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N / A, 4000 mBm), (N / A)

Maaf membuang bahan bakar ke atas api, tetapi memiliki masalah serupa pada Pi Zero W juga, saya kira.

Saat beralih wlan0 antara mode titik akses (saat menggunakan hostapd) dan mode koneksi normal (yaitu menghubungkan ke router) wlan0 terkadang kehilangan kemampuan untuk mengasosiasikan dengan titik akses.

Ini akan macet dalam keadaan ini:

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

dan reboot tidak akan memperbaikinya. Saya perhatikan di dmesg kesalahan berikut ketika ini terjadi:

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

Yang mengkhawatirkan saya adalah ini sepenuhnya sewenang-wenang dan acak. Terkadang saya dapat beralih di antara dua mode tersebut cukup lama sebelum masalah terjadi. Tapi akhirnya berhasil.

FWIW Saya pikir memuat ulang modul kernel wifi (dengan melakukan "modprobe -r -v brcmfmac && modprobe brcmfmac") memperbaikinya jadi saya hanya perlu membuat skrip yang melakukan ini setiap kali Pi saya memiliki masalah wifi.

Ini sementara hal yang aneh. Saya memiliki jenis masalah ini pada Raspberry pi zero & zero W, tetapi masalah itu hilang sama sekali ketika saya beralih saluran (seperti yang dibahas sebelumnya di utas ini).

Juga, akhir-akhir ini saya telah menggunakan OS DietPi dan tidak mengalami masalah sama sekali. Anda mungkin ingin mencobanya.

Saya benar-benar ingin melihat masalahnya, setelah melihatnya sebelumnya, tetapi saya tidak bisa mewujudkannya hari ini! :(

/ raj
(dikirim dari iPhone)

Pada 5 Juli 2017, pukul 09:01, timdonovanuk [email protected] menulis:

FWIW Saya pikir memuat ulang modul kernel wifi (dengan melakukan "modprobe -r -v brcmfmac && modprobe brcmfmac") memperbaikinya jadi saya hanya perlu membuat skrip yang melakukan ini setiap kali Pi saya memiliki masalah wifi.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Semakin banyak orang yang dapat melihat ini semakin baik, saya terbatas waktu
Saya dapat membelanjakan ini saat ini karena proyek lain. Satu masalah besar
adalah mekanisme yang solid untuk menirunya.

Pada 5 Juli 2017 pukul 17:10, rajid [email protected] menulis:

Ini sementara hal yang aneh. Saya mengalami masalah seperti ini di Raspberry pi
nol & nol W, tetapi mereka hilang sama sekali ketika saya beralih saluran (seperti
dibahas sebelumnya di utas ini).

Juga, akhir-akhir ini saya telah menggunakan OS DietPi dan tidak mengalami masalah sama sekali
semua. Anda mungkin ingin mencobanya.

Saya sangat ingin melihat masalahnya, setelah melihatnya sebelumnya, tetapi saya
tidak bisa terjadi hari ini! :(

/ raj
(dikirim dari iPhone)

Pada 5 Juli 2017, pukul 09:01, timdonovanuk [email protected]
menulis:

FWIW Saya pikir memuat ulang modul kernel wifi (dengan melakukan "modprobe -r -v
brcmfmac && modprobe brcmfmac ") memperbaikinya jadi saya hanya perlu membuat file
skrip yang melakukan ini setiap kali Pi saya memiliki masalah wifi.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D313150296&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=UAE2wwxV4_BdJX0zfG2qnu3kAD_j1y0Js_FZxpJl4b4&s=haaEuyne9neeuPZzAlNI2PG7DctVLxxfwV3oezxYcwI&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

@timdonovanuk mungkin senang berbagi skrip Anda dengan kami, saya sedang mencari beberapa solusi. Mungkin beberapa skrip pemantauan berjalan seperti layanan systemd ... Bagaimana menurut Anda?

Apakah ada cara bagi saya untuk memicu pembaruan domain regulasi secara manual? Seperti yang saya katakan, tampaknya cukup konsisten bagi saya setiap kali berjalan, koneksi terputus. Saya tertarik untuk menjalankannya secara manual beberapa kali untuk melihat apakah saya dapat mereproduksi dengan andal untuk Anda.

@rajid , apakah Anda menjalankan saluran dengan lebar 40? Dan apakah Anda ingat jika Anda melihat pembaruan peraturan dunia yang serupa sebelum penurunan? Penasaran apakah mungkin ada kombinasi di sana sekitar saluran 11 dan lebar saluran ekstra lebar ... dan jenis router / AP apa yang Anda gunakan? Hanya mencari kesamaan, karena saya melihat ini di saluran 11 juga, seperti yang lainnya ... AP saya adalah seorang Ubiquiti.

Solusi untuk beralih dari saluran otomatis di Apple extreme ke saluran 6 tidak berhasil untuk saya. Saya akan menggunakan LAN selama liburan.

Sunting: Sekarang saya kehilangan koneksi bahkan dengan LAN, sebagian besar ada sesuatu yang lebih di sini, apakah ini masalah panas menggunakan kasing Resmi (tidak ada kipas)?

Halo,
Saya menghadapi masalah yang sangat mirip pada Raspberry Pi Zero W.

Saya telah mengembangkan API yang berjalan dengan Node.JS di Pi dan terintegrasi dengan GPIO.
Pi terhubung ke LAN saya melalui Wifi. Semuanya bekerja dengan baik saat klien PC memanggil API. Namun, segera setelah saya menanyakan API saya dengan perangkat Android, Pi macet. Error tersebut terjadi secara acak: terkadang API dapat dipanggil oleh perangkat Android beberapa kali dan tiba-tiba error tersebut terjadi.
Yang saya maksud dengan crash adalah ping loss tetapi Pi masih aktif dan berjalan.

Memanggil API yang sama melalui PC tidak pernah memicu kerusakan apa pun.

Saya mencoba untuk mengubah saluran Wifi tetapi tidak mendapatkan hasil yang lebih baik.

Jika saya dapat menjalankan apa pun untuk membantu diagnosis / solusi, jangan ragu untuk bertanya!

Ada sesuatu di forum ini, posting bantuan?

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

Pada 11 Juli 2017 pukul 16:22, matthiasbou [email protected] menulis:

Halo,
Saya menghadapi masalah yang sangat mirip pada Raspberry Pi Zero W.

Saya telah mengembangkan API yang berjalan dengan Node.JS di Pi dan terintegrasi
dengan GPIO.
Pi terhubung ke LAN saya melalui Wifi. Semuanya bekerja dengan baik saat PC
klien memanggil API. Namun, segera setelah saya menanyakan API saya dengan Android
perangkat, Pi macet. Kerusakan itu terjadi secara acak: terkadang API bisa
dipanggil oleh perangkat Android beberapa kali dan tiba-tiba terjadi kerusakan.
Memanggil API yang sama melalui PC tidak pernah memicu kerusakan apa pun.

Saya mencoba untuk mengubah saluran Wifi tetapi tidak mendapatkan hasil yang lebih baik.

Jika saya dapat menjalankan apa pun untuk membantu diagnosis / solusi, jangan ragu untuk bertanya!

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314479400 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHYDohQoNRBDcX4oG49rK9e6kwpjjks5sM5MpgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

@septianjoko_

Menarik apa yang Anda katakan, driver broadcom saya mengembalikan kesalahan -110 (terkadang kesalahan lain) dan macet persis saat saya menghubungkan smartphone Motorola X2 (Android) saya. Tetapi juga kesalahan yang sama terjadi saat menghubungkan SmartTV saya. Bagaimanapun, saya dapat mengonfirmasi bahwa crash terjadi pada saat koneksi dibuat.

Negara saya disetel dengan benar, ipv6 nonaktif dan roamoff = 1, saya menggunakan saluran 6, masalah masih terjadi. mode hemat daya wifi dan bluetooth dinonaktifkan secara default di distro saya.

@ JamesH65 : Saya mencoba solusi menarik untuk mengatur negara yang benar (bukan itu masalahnya), menonaktifkan IPV6 dan roaming tetapi masih mengalami masalah yang sama :(

Wifi terhubung, tetapi segera setelah saya mulai "bermain" dengan perangkat Android yang membuat beberapa panggilan API di Pi Zero W, setelah beberapa saat, itu macet.

Mengapa menonaktifkan IPv6 memperbaiki masalah Wifi? Adakah penjelasan yang masuk akal mengapa IPv6 terlibat, yang dapat direproduksi? Satu-satunya hal yang dapat saya pikirkan bahwa IPv6 mungkin memiliki sedikit beban multicast tambahan karena RA.

Untuk apa nilainya, saya menjalankan dua Pi Zero W sebagai jembatan IPv6 antara wlan0 terintegrasi dan eth0 eksternal, dengan IPv4 diblokir. wlan0 dalam mode AP dan menjalankan server ISC dHCPv4. Saya menghubungkan berbagai tablet Android dan smartphone ke sana. Sejauh ini tidak melihat masalah apa pun, tetapi mungkin saya perlu membiarkannya berjalan untuk jangka waktu yang lebih lama. Saya menggunakan saluran 6.

Maaf, saya menggunakan kotak Apple Airport, dan tidak ada pengaturan atau penyebutan "lebar saluran". Saya cukup mengatur saluran 6 untuk jaringan 2.3Ghz. Saya sekarang menggunakan DietPi pada sistem RaspPi Zero W. saya. RaspPi lain yang saya miliki sudah diatur sejak lama dengan Edimax USB dan tidak pernah mengalami masalah. Saya yakin satu-satunya saat saya melihat masalah adalah dengan Raspbian di sistem Zero W. Saya harus memuatnya lagi dan melihat apakah saya dapat mereproduksinya.

/ raj

Pada tanggal 5 Juli 2017, pada pukul 15.19, Michael Hallock < [email protected] [email protected] > menulis:

Apakah ada cara bagi saya untuk memicu pembaruan domain regulasi secara manual? Seperti yang saya katakan, tampaknya cukup konsisten bagi saya setiap kali berjalan, koneksi terputus. Saya tertarik untuk menjalankannya secara manual beberapa kali untuk melihat apakah saya dapat mereproduksi dengan andal untuk Anda.

@rajid https://github.com/rajid , apakah Anda menjalankan saluran dengan lebar 40? Dan apakah Anda ingat jika Anda melihat pembaruan peraturan dunia yang serupa sebelum penurunan? Penasaran apakah mungkin ada kombinasi di sana sekitar saluran 11 dan lebar saluran ekstra lebar ... dan jenis router / AP apa yang Anda gunakan? Hanya mencari kesamaan, karena saya melihat ini di saluran 11 juga, seperti yang lainnya ... AP saya adalah seorang Ubiquiti.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-313242611 , atau nonaktifkan utas https://github.com/notifications/unsubscribe-auth/AFAlZVdfvh5QzIlsZYtt9sjpXolJqcmWksCp5sLAvd4HgaJup5 .

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

Saya baru saja melakukan lebih banyak tes dan mengubah router yang terhubung dengan Pi.
Hingga saat ini, semuanya berfungsi saat Pi ada di router Wifi lain ini (tidak ada perubahan di sisi perangkat Android):
Konfigurasi Router yang berfungsi :
Saluran 6
WPA-PSK
Bandwidth 20Mhz

Konfigurasi router tidak berfungsi (kehilangan Wifi setelah beberapa akses dari Android Wifi):
Netgear WNR1000v2
Saluran 6
WPA2-PSK [AES]
Panjang Fragmentasi 2346
CTS / RTS Ambang 2347

Saya akan mengalihkan router yang berfungsi ke WPA2-PSK untuk melihat apakah masalahnya kemudian dapat direkonstruksi.

@TheDiveO Berkenaan dengan IPv6, driver memiliki jalur kode yang berbeda untuk ipv6, seperti halnya kernel. Mungkin ada bug di salah satu jalur yang tidak ada di ipv6, atau, karena ISTR dari bug beberapa waktu lalu, sesuatu menjalankan jalur kode ipv6 ketika seharusnya menjalankan jalur kode ipv4 atau sebaliknya. Seluruh tumpukan cukup berbelit-belit.

perilaku baru. Mengubah lokal dan melakukan peningkatan dan pembaruan apt-get sekarang memiliki perilaku berikut ketika pi3 saya terhubung melalui WIFI:

sekarang perangkat di luar LAN lokal dapat terhubung ke PI melalui TCP / IP.

PI tetap menolak semua koneksi (TCP / IP) di LAN saja.

PI masih dapat mengakses internet luar melalui WIFI.

udah lah. Tidak ada yang berubah. Ini adalah perilaku yang sama persis seperti sebelumnya. Wifi Pi3 menjatuhkan semua paket di LAN lokal.

Hanya untuk menindaklanjuti sedikit ... Saya memulai AP baru (Linksys E4200 V2), yang telah saya sediakan. Saya mengaturnya di saluran 11 untuk 2.4Ghz, mengkonfigurasi WPA2 Personal, BSSID dan kata sandi. Kemudian konfigurasikan ini pada raspberry pi zero w saya. Itu terhubung dengan baik. Saya kemudian memindahkan AP ini ke ruangan yang sama di mana AP rumah normal saya berada (yang ada di saluran 6). RaspPi saya kemudian mendapatkan ASSOC-REJECT status_code = 16. Memindahkan AP kembali ke kantor saya sekali lagi membuat asosiasi RaspPi baik-baik saja.

Jadi, tampaknya dalam kasus saya, setidaknya saluran 11 bermasalah jika AP ada di ruangan lain. Saya menduga ini mungkin menunjukkan masalah interferensi.

Saya juga akan memposting di sini halaman web yang saya temukan yang memberi tahu semua status_codes dan kode kegagalan:

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

Ini menunjukkan "status_code = 16" saya disebabkan oleh waktu tunggu, jadi salah satu sistem tidak menerima paket secara tepat waktu.

Saya hanya berpikir saya akan membuang informasi ini ke luar sana jika itu membantu siapa pun.

Ketika saya menyalakan lampu di dapur saya, itu mematikan koneksi wifi saya di
ruang tamu ... entah kenapa tapi ketika kamu bicara tentang gangguan, kurasa
saya tidak gila

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

Hanya untuk menindaklanjuti sedikit ... Saya memulai AP baru (Linksys E4200 V2),
yang saya telah berbaring di sekitar. Saya mengaturnya di saluran 11 untuk 2.4Ghz, dikonfigurasi
WPA2 Personal, BSSID dan kata sandi. Kemudian konfigurasikan ini di raspberry saya
pi nol w. Itu terhubung dengan baik. Saya kemudian memindahkan AP ini ke ruangan yang sama
di mana AP rumah normal saya berada (yang ada di saluran 6). RaspPi saya
mendapat ASSOC-REJECT status_code = 16. Memindahkan AP kembali ke kantor saya sekali
sekali lagi membuat asosiasi RaspPi baik-baik saja.

Jadi, tampaknya dalam kasus saya, setidaknya, saluran 11 menjadi masalah jika AP bermasalah
di ruangan lain. Saya menduga ini mungkin menunjukkan gangguan
masalah.

Saya juga akan memposting di sini halaman web yang saya temukan yang menceritakan apa semua itu
status_codes dan kode kegagalan adalah:

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

Ini menunjukkan "status_code = 16" saya disebabkan oleh waktu tunggu, jadi salah satu dari
sistem tidak menerima paket secara tepat waktu.

Saya hanya berpikir saya akan membuang informasi ini ke luar sana jika itu membantu
siapa saja.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314872003 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ACeQBJdfk2zp1sReVVs1wvrilKHXNm53ks5sNR42gaJpZM4HupC5
.

Ada program WiFi Analyzer yang sangat bagus untuk Android, yang menunjukkan AP apa yang ada di sekitar Anda, bersama dengan informasi terperinci mereka. (Saya berharap sesuatu seperti itu ada untuk iPhone / iPad, tapi Apple ...)

@ JamesH65 Anda benar-benar membuat saya tidak nyaman mengatakan bahwa driver lapisan data link (lapisan 3) tidak main-main dengan lapisan jaringan 3. "Mess" mungkin bukan kata yang tepat untuk situasi ini juga ...

Saya tidak benar-benar mengatakan itu. Saya bukan ahli di jaringan Linux
tumpukan, tapi sepertinya saya ingat melihat beberapa hal spesifik IPv6 di
seorang pengemudi di suatu tempat.

Semuanya ada di dalam pohon kernel, Anda dipersilakan untuk melihatnya
diri Anda sendiri untuk menenangkan pikiran Anda.

Pada 13 Juli 2017 pukul 08:58, TheDiveO [email protected] menulis:

@ JamesH65 https://github.com/jamesh65 Anda benar-benar membuat saya tidak nyaman
mengatakan bahwa pengandar lapisan data link (lapisan 3) tidak main-main dengan
lapisan jaringan 3. "Mess" mungkin bukan kata yang tepat untuk ini
situasi baik ...

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315002002 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHUSoqqxnhaw4k2ECkzGC9CDkIlhYks5sNc4ngaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

@TheDiveO James mengacu pada hal-hal seperti
SMSC95xx misalnya hanya dapat mendukung pembongkaran checksum IPv4 karena IPv6 memerlukan checksum 0x0000 untuk menggantikan 0xFFFF. Lihat https://github.com/torvalds/linux/commit/fe0cd8ca1b82983db24b173bb8518ea646c02d25. Oleh karena itu, IPv6 dan IPv4 akan mengikuti jalur kode yang berbeda. Tidak ada yang meragukan di sana, tetapi melekat dalam tumpukan jaringan di mana perangkat keras tidak dapat mencakup semua situasi.

Saya cukup yakin bug ini ada di driver Broadcom, bukan kernelnya.

Hampir pasti. Driver Brcm adalah sebagian besar kode, dan bug
seperti ini tidak mudah untuk di-debug. Terutama ketika Anda tidak dapat mereplikasi mereka ...

Pada 13 Juli 2017 pukul 13:04, Alexandre Bolelli [email protected]
menulis:

Saya cukup yakin bug ini ada di driver Broadcom, bukan kernelnya.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315058283 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHbr5SiWPKvQZOY7rN8IbyIIscNfVks5sNgexgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Semakin saya kesulitan dengan ini, semakin saya mulai bertanya-tanya apakah ini terkait dengan ketidakmampuan Ubuntu / Debians untuk menghubungkan wlan0 dan eth0 ke subnet yang sama tanpa beberapa konfigurasi yang ekstensif. Saya akan melihat ini lebih dalam dan melihat apakah ini masalahnya.

@ JamesH65 apakah akan membantu jika saya (atau orang lain) akan mengatur nol w atau rpi 3 untuk Anda dalam lingkungan di mana ini mudah direproduksi dan memberi Anda akses ssh di sana untuk Anda debug? (Saya perlu membeli nol w ekstra untuk ini).

Mungkin tidak tapi terima kasih atas tawarannya. Saya cenderung menjalankan perubahan khusus pada file
driver dan kernel, dengan perubahan yang dilakukan beberapa kali sehari. Melakukan itu
jarak jauh tidak memungkinkan. Mekanisme untuk mereproduksi masalah dengan andal adalah
benar-benar apa yang dibutuhkan.

Pada 13 Juli 2017 pukul 13:57, Tuomas Airaksinen [email protected]
menulis:

@ JamesH65 https://github.com/jamesh65 apakah akan membantu jika saya (atau seseorang
else) akan mengatur nol w atau rpi 3 untuk Anda di lingkungan di mana ini
mudah direproduksi dan memberi Anda akses ssh di sana untuk Anda debug? (SAYA
perlu membeli nol w ekstra untuk ini).

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315069935 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHeQ1RECH-uIIHWPX6ItvRdVbZG_Xks5sNhRWgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

James,
Jika saya melakukan polling loop sederhana ini, saya dengan cepat melihat jaringan wifi onboard diturunkan ke status tidak dapat digunakan. Ketika saya mematikan wifi onboard dan menggunakan wifi USB, itu berfungsi. Saya tidak ingat apakah itu sensitif terhadap perangkat BT ada atau tidak, dan tidak dapat dengan mudah memeriksanya selama beberapa hari. Saya membatasi waktu 10 menit sehingga saya bisa kembali ke nilai nol w setelah percobaan.

bash# ((t= tanggal +% s +600)); while [ tanggal +% s -lt $t ] ; do hcitool name <BTMAC>; done
Semoga membantu,
Benjamin

Potongan kode itu kehilangan kutu punggung saya. Melarikan diri dari mereka ...

((t = `tanggal +% s` + 600)); while [`date +% s` -lt $ t]; lakukan nama hcitool "masukkan BT MAC"; selesai

YA TUHAN. Saya pikir itu sudah diperbaiki. Wi-Fi aktif saat ethernet dicabut. Luar biasa.

Saya menghapus semua penyebutan eth0 dari file / etc / network / interfaces saya, mengganti allow-hotplug dengan auto, dan kemudian mematikan daya nirkabel pada wlan0 dan wlan1.

file / etc / network / interfaces saya:

otomatis lo
iface lo inet loopback

daya nirkabel mati
wlan0 otomatis
iface wlan0 manual inet
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

daya nirkabel mati
wlan1 otomatis
iface wlan1 inet manual
wpa-conf / etc / wpa_supplicant / wpa_supplicant.conf`

Lalu aku memerah arp:

ip -s -s neigh flush all

Lalu saya reboot:

sudo reboot now

Dan sekarang wifi saya berfungsi. Luar biasa. Terima kasih untuk semua yang mengomentari utas ini.

Masalah konfigurasi khusus Anda mungkin teratasi, bug di driver Broadcom masih ada.

Oke, kami telah melihat ini. Masalah pertama saya adalah ketika SSH masuk ke perangkat pengujian saya, sesi terkunci KECUALI kabel ethernet juga dimasukkan. Ternyata ARP ditangani oleh salah satu antarmuka, jadi ketika ethernet terhubung, itu digunakan. Karena tidak terhubung berarti sedang ditangani oleh Wifi dan mengalami masalah. Masalah ini dapat diperbaiki dengan mematikan QoS / ToS di SSH (lihat di sini https://expresshosting.net/ssh-hanging-authentication/), yang pada gilirannya menyiratkan bahwa driver Broadcom Wifi sangat tidak senang dengan TOS (jenis service) / kolom DSCP sedang disetel. Ini telah terlihat sebelumnya di NTP (Masalah # 1519). Saya menduga bahwa ini bisa menjadi penyebab masalah Wifi terkait masalah ini dan saya akan menggali melalui driver Brcm hari ini untuk melihat apakah saya dapat menemukan sesuatu.

Laporan interim. Kami pasti melihat masalah dengan nilai paket TOS tertentu yang menyebabkan paket dijatuhkan secara diam-diam, menyebabkan SSH terkunci. Belum ada yang jelas dalam kode driver yang tidak bisa ditembus, dimana TBH seharusnya tidak menyentuh bagian paket ini, tapi jelas ada sesuatu yang terjadi. Apakah ini ada hubungannya dengan pembekuan umum wlan yang dilaporkan di sini? Belum tahu.

Saya memiliki masalah serupa pada Pi Zero W dengan raspbian jessie dan kernel 4.9.35+
Saya memiliki masalah yang sama yang disebutkan oleh JamesH65 dengan SSH dan ntpd (TOS). Perbaikan dari https://expresshosting.net/ssh-hanging-authentication/ bekerja untuk sshd. Saya juga memiliki masalah pemutusan wlan0, tetapi dengan pesan log yang agak kurang bertele-tele. Ini secara dangkal hanya terlihat seperti operator hilang, dan wpa_supplicant terkadang gagal untuk menegosiasikan ulang. Satu-satunya jalan keluar adalah dengan mengeluarkan ifdown wlan0, tunggu, ifup wlan0 untuk saya, kemudian wlan0 mulai berfungsi kembali. Senang memberikan log jika ada yang membutuhkannya. Katakan saja padaku yang mana.

Laporan interim. Ingin mencatat beberapa catatan sebelum dilupakan. Kami telah menentukan bahwa itu adalah respons dari pi yang terhubung secara nirkabel yang akan hilang saat mengakses melalui SSH dari perangkat lain. Jika respons tersebut memiliki kolom TOS yang disetel maka paket tersebut akan dijatuhkan secara diam-diam - tidak pernah kembali ke pemohon. Kami dapat mereplikasi ini menggunakan netcat. Perintah net cat sederhana dari Pi nirkabel dengan set bendera TOS tampaknya tidak berhasil keluar dari perangkat.
Jadi pada PI nirkabel, coba dan kirim paket UDP ke perangkat lain ...
nc -T 0x10 -u7
Perangkat sepertinya tidak menerima paket (seperti yang ditunjukkan dengan menjalankan tcpdump di tujuan)
nc -T 0x00 -u7
akan sampai ke sistem jarak jauh.
Kami hanya mencoba ini melalui jaringan nirkabel di sini, di kantor. Saya perlu menyiapkan jaringan Wifi lain untuk melihat apakah itu terkait dengan router, atau ada masalah pada driver.

Koreksi kecil pada perintah netcat di atas
nc -T 0x10 -u <dest_ip> 7
UDP port 7 dipilih karena merupakan layanan echo. Tidak masalah bahwa ini tidak berjalan pada mesin jarak jauh, meskipun hal itu mengarah pada respons ICMP yang tidak dapat dijangkau yang merupakan petunjuk berguna bahwa ujung jarak jauh mendapatkan pesan tersebut.

Mulai berpikir bahwa masalah SSH / ToS sebenarnya tidak terkait. Saya telah menelusuri paket ke tingkat HW dan tidak masalah apakah bendera TOS disetel atau tidak, paket tampaknya membuatnya ke firmware (atau setidaknya fungsi brcmf_sdiod_send_pkt yang melewati penanganan prioritas apa pun di driver linux). Yang menunjukkan bahwa masalahnya ada di firmware dalam chip (sumber tertutup), atau sebenarnya terkait dengan router - yaitu router nirkabel yang saya gunakan tidak membiarkan melalui tanda TOS yang bukan nol (atau mungkin> 0x04). Saya akan mencoba router nirkabel lain besok untuk mencoba dan mengonfirmasi ini.

Apakah ada kemungkinan menemukan departemen yang bertanggung jawab untuk mengembangkan modul brcmfmac sehingga seseorang dapat mengikuti utas itu atau setidaknya merespons jika ada perbaikan untuk bug ini akan dirilis?

Kami sudah berhubungan melalui milis linux-nirkabel.

Pada 19 Juli 2017 19:06, "Alexandre Bolelli" [email protected] menulis:

Apakah ada peluang untuk menemukan departemen yang bertanggung jawab untuk pengembangan
modul brcmfmac sehingga seseorang dapat mengikuti utas itu atau setidaknya
menanggapi jika ada perbaikan untuk bug ini akan dirilis?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316469790 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHYtYvpxdKd3SBBynOnlDN-ZXiWs_ks5sPkW9gaJpZM4HupC5
.

Kami sudah berhubungan melalui milis linux-nirkabel.

... dan lebih banyak rute langsung. Masalahnya selalu menjadi salah satu reproduktifitas - setelah kami memiliki cara untuk menunjukkan dengan jelas masalah tersebut, kami dapat menyampaikannya kepada Broadcom / Cypress dan memperbaikinya. Saya tidak pernah bisa melihat masalah saat menggunakan NTP, tetapi James mengalami kegagalan yang sukses dengan SSH jadi saya optimis kita akan sampai ke akar masalahnya.

@pelwell +1 untuk istilah "_kegagalan yang berhasil" _ :)

Saya memiliki perbaikan hacky untuk masalah penguncian SSH. Tampaknya ada masalah di firmware. Berikut beberapa detailnya.

`
Kami telah menyelidiki masalah pada Raspberry Pi, di mana SSH dan
Sesi NTP gagal saat bendera TOS disetel di header IPv4.

Berikut ini ekstrak tentang TOS:

KL adalah 0x08 atau 0x10. Hanya satu dari 4 bit yang diizinkan untuk disetel dalam satu waktu.
0x10 - meminimalkan penundaan
0x08 - memaksimalkan throughput
0x04 - memaksimalkan keandalan
0x02 - meminimalkan biaya moneter.
Secara teknis TOS telah digantikan oleh DSCP, tetapi masih didukung.

Kami dapat mencoba membuat ulang masalah ini dengan DSCP jika benar-benar diperlukan, tetapi ternyata tidak
tampaknya relevan.

Detail tentang masalah SSH, dan penyelesaiannya dapat ditemukan di sini https://expresshosting.net/ssh-hanging-authentication/

Namun, ini jelas merupakan masalah di suatu tempat dalam komunikasi
tumpukan, jadi inilah yang telah kami selidiki.

Kami telah mampu mereplikasi contoh sederhana menggunakan netcat. Pertama,
hubungkan Pi secara nirkabel ke AP (PiA), dengan perangkat lain terhubung
baik secara nirkabel atau melalui ethernet ke jaringan yang sama (PiB).

Saat PiB dijalankan

sudo tcpdump -n 'udp port 7' -v -i wlan0 <<<< atau eth0 tergantung koneksi

Di PiA,

nc -T 0x10 -u7

Ini mengirim paket UDP ke port 7, dengan flag TOS disetel ke 0x10.

Ini TIDAK akan tiba (atau kadang-kadang tertunda sangat parah - 10 detik)

Mengirim TOS sebagai 0

nc -T 0x0 -u7

Akan tiba. 0x02 dan 0x04 juga akan tiba, 0x8 dan 0x10 tidak akan.

Menginstruksikan driver brcmfmac menunjukkan bahwa paket tersebut dengan TOS
flag = 0x10 dengan benar dikirim ke tumpukan ke HW, tapi kemudian
paket hilang.

Kami bisa mendapatkan paket dengan meretas kode BCDC,
dalam fungsi bcdc.c! brcmf_proto_bcdc_hdrpush, prioritas
paket juga didorong ke header bcdc. Dengan mengatur ini ke a
nilai konstan (yang bisa berupa apa saja dari 0-7), paketnya
ditularkan. Jadi tampaknya nilai prioritas bcdc konstan
berfungsi, tetapi mengaturnya ke prioritas sebagaimana ditentukan oleh yang masuk
skb prioritas hal-hal gagal JIKA KL adalah 0x08 atau 0x10. Jadi, sepertinya begitu
menjadi kombinasi paket dengan berbagai macam prioritas yang menyebabkan
nilai prioritas yang lebih tinggi gagal, bukan nilai itu sendiri.

Karena prioritas header BCDC ditujukan untuk firmware, ini
tampaknya menjadi masalah di firmware itu sendiri, bukan di Linux
sopir.

Berikut ini perbedaan perubahan yang tampaknya menghentikan terjadinya masalah.

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 Bagus. Karena saya tidak mengharapkan perbaikan firmware segera, bisakah Anda menyalin ini ke linux-nirkabel?

Saya akan menunggu beberapa informasi dari Broadcom / Cypress, sejak saya
tidak yakin peretasan ini aman dalam segala situasi. Saya telah mengirim email kepada mereka. Sekali
Saya mendapat umpan balik, saya akan mengirimkan tambalan ke linux-nirkabel.

Pada 20 Juli 2017 pukul 12:41, Stefan Wahren [email protected] menulis:

@ JamesH65 https://github.com/jamesh65 Bagus. Karena saya tidak mengharapkan file
segera perbaiki firmware, bisakah Anda menyalin ini ke linux-wireless?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316678154 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHY3DlxTr9mehRDlxBK3NWbjowxxyks5sPzzqgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Beberapa hasil tes tampaknya menunjukkan tidak ada efek buruk dari peretasan ini. Baru saja mentransfer data bolak-balik, 500MB ke Wireless Pi, 3,4GB dikirim. Paket RX 56 turun dari 794730, tidak ada paket TX yang turun dari 2813930. Performa tampaknya tepat untuk koneksi 11Mbit / s. Jadi terlihat dapat diterima, tetapi peretasan ini sebenarnya menonaktifkan sesuatu yang mungkin harus diaktifkan, jadi bukan solusi jangka panjang.

@lategoodbye Telah merenungkan tentang mendorong ini ke linux-nirkabel. Karena peretasan ini benar-benar hanya relevan / diuji ke chip tertentu pada Pi (BCM43438?), Dan kode driver untuk beberapa model chip, tambalan perlu menentukan jenis chip yang digunakan sebelum melakukan perubahan, dan saya curiga bahwa linux-nirkabel tidak akan senang dengan perubahan semacam itu dan saya tetap tidak dapat mengujinya. Saya pasti akan PR di repo kami (kecuali perbaikan firmware akan datang, saya ragu itu dalam jadwal yang masuk akal). Hanya tidak yakin bagaimana mendorongnya ke linux-nirkabel, jika ada.

@bulan
Menurut Anda, apakah ini bisa didorong ke ARCH linux-raspberrypi?

@ JamesH65 Tentu,

Saya menyarankan agar kami memasukkannya ke repo kami untuk menyelesaikan beberapa pengujian serius - mulai dengan rpi-4.12.y yang digunakan oleh build LibreElec yang mutakhir setiap malam.

Satu pemikiran - dapatkah Anda membuat tambalan lebih selektif dalam pemfilteran prioritasnya dan masih memperbaiki masalahnya?

Saya hanya menyiapkan PR untuk ini untuk pergi ke Pi repo.

Berkenaan dengan pemeriksaan selektif, saya memang mencoba dengan hanya mendeteksi prioritas
6 (salah satu yang diturunkan tumpukan - ini diterjemahkan dari KL
nilai ke sesuatu yang lebih spesifik tumpukan Linux), dan menyetelnya ke 0 dan
yang tampaknya berhasil, tetapi kecurigaan saya adalah bahwa ini adalah kombinasi dari
prioritas yang berbeda daripada secara khusus 6 yang menyebabkan masalah. Kita
juga tahu bahwa TOS 0x08 juga memiliki masalah, yaitu, IIRC,
dikonversi menjadi 2 pada saat mencapai titik ini. Kami hanya bisa mengatakan, jika
itu 6 atau 2, lalu setel ke nol, tetapi saya masih tidak yakin itu akan berhasil
segala sesuatu yang dapat menyebabkan masalah. Karena nilainya 0-7, saya rasa,
untuk peretasan ini, lebih baik setel ke 0 dalam semua kasus. Kami tahu itu
berfungsi, tentu saja mungkin tidak optimal, tetapi saya pikir semua paket akan melakukannya
melewati. Perhatikan bahwa pengaturan ini TIDAK mempengaruhi nilai TOS di
Paket IPv4 - tetap sama, hanya saja sistem pengiriman file
prioritas untuk chip dan bagaimana kemudian menanganinya yang tampak terkelupas.

Pada 21 Juli 2017 pukul 09:35, Phil Elwell [email protected] menulis:

Satu pemikiran - dapatkah Anda membuat tambalan lebih selektif dalam prioritasnya
memfilter dan masih memperbaiki masalahnya?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D316940828&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=bmJYpA4c2HSXiPbO68JUYdepjN1tnBs_lkuzpPvnoh4&s=lTkmZTnZKvmqZQgONBOnkdo5C-y1dP_Z61sUY17WvV0&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Saya telah melakukan kontak dengan Cypress, yang akan mencoba dan mendapatkan ini
melihat secepat mungkin.

Pada 21 Juli 2017 pukul 10:11, James Hughes [email protected] menulis:

Saya hanya menyiapkan PR untuk ini untuk pergi ke Pi repo.

Berkenaan dengan pemeriksaan selektif, saya mencoba dengan hanya mendeteksi
prioritas 6 (salah satu yang diturunkan tumpukan - itu diterjemahkan dari
nilai TOS ke sesuatu yang lebih spesifik tumpukan Linux), dan menyetelnya ke
0 dan itu tampaknya berhasil, tetapi kecurigaan saya adalah bahwa ini adalah kombinasi
prioritas yang berbeda daripada secara khusus 6 yang menyebabkan masalah.
Kami juga tahu bahwa TOS 0x08 juga memiliki masalah, dan itu adalah, IIRC,
dikonversi menjadi 2 pada saat mencapai titik ini. Kami hanya bisa mengatakan, jika
itu 6 atau 2, lalu setel ke nol, tetapi saya masih tidak yakin itu akan berhasil
segala sesuatu yang dapat menyebabkan masalah. Karena nilainya 0-7, saya rasa,
untuk peretasan ini, lebih baik setel ke 0 dalam semua kasus. Kami tahu itu
berfungsi, tentu saja mungkin tidak optimal, tetapi saya pikir semua paket akan melakukannya
melewati. Perhatikan bahwa pengaturan ini TIDAK mempengaruhi nilai TOS di
Paket IPv4 - tetap sama, hanya saja sistem pengiriman file
prioritas untuk chip yang tampak bersisik dan bagaimana kemudian menanganinya
tampak bersisik.

Pada 21 Juli 2017 pukul 09:35, Phil Elwell [email protected] menulis:

Satu pemikiran - dapatkah Anda membuat tambalan lebih selektif dalam prioritasnya
memfilter dan masih memperbaiki masalahnya?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D316940828&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=bmJYpA4c2HSXiPbO68JUYdepjN1tnBs_lkuzpPvnoh4&s=lTkmZTnZKvmqZQgONBOnkdo5C-y1dP_Z61sUY17WvV0&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Kita juga tahu bahwa TOS 0x08 juga memiliki masalah, yaitu, IIRC, diubah menjadi 2 pada saat ia mencapai titik ini.

Benar. TOS 0x08 (maksimalkan throughput) dipetakan ke 2. Nilai tersebut adalah TC_PRIO_xxx dari http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/pkt_sched.h#L19. 6 = INTERAKTIF, 2 = MASSAL.

Pengujian sebelumnya dengan pengaturan IPQoS ke 8 di sshd_config, atau dengan netcat menggunakan TOS 8 menghasilkan paket yang turun.
Baik 0x02 maupun 0x04 tidak menyebabkan masalah apa pun, tetapi ada sedikit yang dapat dilakukan driver wifi atas perbedaan biaya (tidak ada) atau keandalan sehingga mungkin mengabaikannya.
edit Sebenarnya tabel pemetaan di http://elixir.free-electrons.com/linux/latest/source/net/ipv4/route.c#L177 mengambil tos>>1 menyetel TOS 0x02 dan 0x04 ke TC_PRIO_BESTEFFORT = 0 bagaimanapun, yang menjelaskan mengapa mereka tidak memiliki masalah apa pun.

Hanya laporan singkat. Cypress mampu mereplikasi masalah tersebut, dan memang
memeriksa firmware jadi tampak penuh harapan. Respon yang sangat menyenangkan dan cepat
dari orang-orang di sana.

Pada 21 Juli 2017 pukul 11:07, 6by9 [email protected] menulis:

Kami juga tahu bahwa TOS 0x08 juga memiliki masalah, dan itu adalah, IIRC,
dikonversi menjadi 2 pada saat mencapai titik ini.

Benar. TOS 0x08 (maksimalkan throughput) dipetakan ke 2. Mereka adalah TC_PRIO_xxx
nilai dari http://elixir.free-electrons.com/linux/latest/source/
sertakan / uapi / linux / pkt_sched.h # L19. 6 = INTERAKTIF, 2 = MASSAL.

Pengujian sebelumnya dengan pengaturan IPQoS ke 8 di sshd_config, atau dengan
netcat menggunakan TOS 8 menghasilkan paket yang turun.
Baik 0x02 maupun 0x04 tidak menyebabkan masalah apa pun, tetapi ada sedikit driver wifi
dapat melakukan lebih dari perbedaan biaya (tidak ada) atau keandalan sehingga mungkin
mengabaikan mereka (saya belum memeriksa).

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316962443 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHXTmjzqVW0o4T9IIoYFPprKvEvS7ks5sQHhXgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Cara lebih mudah untuk mereproduksi - gunakan ping! (Saya lupa bahwa ping / ICMP di atas IP - konyol saya)

ping -Q 0x10 <dest ip addr> di Pi3
dan jalankan tcpdump -n -v -i wlan0 'icmp' di tempat tujuan.
Menghasilkan> 90% packet loss pada -Q 0x10 atau -Q 0x08. Ini sering dimulai OK dengan 4 paket berurutan melewati, tetapi kemudian berjalan sangat terputus-putus.
Ini sedikit lebih berguna daripada netcat karena (a) terus berulang, dan (b) memberi tahu Anda saat mendapat respons.

Ada solusinya di sini: https://github.com/raspberrypi/linux/pull/2126
Jika Anda ingin mengujinya dengan 4.9 kernel, gunakan rpi-update.
Kemudian ganti:
modules / 4.9.39 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko dengan ini
modules / 4.9.39-v7 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko dengan ini

EDIT: Kernel pembaruan rpi terbaru sekarang menyertakan tambalan, jadi mengunduh modul tidak lagi diperlukan.

Tidak yakin apakah terkait. Sambungan pada broadcom on-board di Pi Zero W saya terputus setiap 2 jam ketika antarmuka kedua wlan1 aktif dengan dongle rt8192eu / 8192eu. Tampaknya bukan masalah daya karena sangat bersiklus, saya memiliki pastebin dari pemutusan di https://pastebin.com/5hMQHWeW

Saat ini sedang berlangsung, wpa_supplicant terkadang berhenti mencoba tanpa alasan yang jelas selain kegagalan untuk mengautentikasi dan satu-satunya cara untuk mendapatkan kembali konektivitas di wlan0 adalah dengan mengeluarkan ifdown / ifup yang kemudian berfungsi 100%.

Sekarang saya tidak tahu apakah ini adalah masalah modul kernel Broadcom yang menyebabkan masalah, atau apakah itu buggy 8192eu atau keduanya. Senang memberikan lebih banyak baris log jika diperlukan atau memposting di utas yang berbeda, tetapi seseorang di #raspbian menyarankan saya menambahkan ini di sini.

Jika Anda dapat mengkonfirmasi bahwa vcgencmd get_throttled mengembalikan 0x0 setelah pemutusan hubungan yang akan menyingkirkan masalah listrik.

Biasanya terjadi ketika saya tertidur / tidak dengan Pi dan saya mengetahuinya dalam retrospeksi ketika saya tidak dapat terhubung lagi (kemudian saya biasa terhubung melalui AP kedua dan mengatur ulang wlan0). Namun, karena dongle 8192eu dicabut sekarang, belum ada acara. Saya dapat mencolokkan dongle kedua dengan modul buggy, tetapi seberapa cepat setelah memutus sambungan ke saya perlu memeriksa vcgencmd get_throttled?

Selama Anda belum mem-boot ulang bit atas akan memberi tahu Anda jika pernah ada peristiwa voltase di bawah.

Jalankan saja. Pasti tidak di-boot ulang sejak pemutusan terakhir. Dapat mengonfirmasi vcgencmd get_throttled pengembalian:
dicekik = 0x0

Sayangnya get_throttled tidak akan berfungsi pada Pi0 / Pi0w (tidak memiliki sirkuit deteksi tegangan di bawah).

Untuk beberapa alasan, menyalin & menempelkan perbedaan dari JamesH65 tidak berhasil untuk saya. Membuat patchfile yang seharusnya segera diterapkan, orang-orang yang mengira mungkin menganggap ini berguna: https://github.com/bortek/EZ-WifiBroadcast/blob/master/kernel/linux-4.9.28-brcmfmac-tos.patch

Nama file mengatakan 4.9.28, tetapi harus berlaku setidaknya hingga 4.9.35 (dan mungkin yang lebih baru juga).

Salin file ini ke direktori akar pohon kernel dan terapkan dengan patch -p1 < linux-4.9.28-brcmfmac-tos.patch

Informasi tambahan (tapi ganjil):

Jika Pi Zero W terhubung ke wlan0, tetapi sebaliknya tidak melakukan apa-apa (skrip cron memeriksa sntp paling banyak setiap 15 menit), ada sangat sering terputus, sesuatu dalam urutan 1-10 / jam berlangsung paling lama satu detik masing-masing.

Jika saya memiliki sesuatu yang menggunakan koneksi, misalnya, tidak aktif di IRC (beberapa saluran besar), koneksi tidak terputus satu kali pun sepanjang waktu.

Ternyata memuat modul kernel 4.9.39 di 4.9.35 bukanlah ide yang baik.

Laporan bug lain dari forum, kesalahan kotak surat tampaknya umum.

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

Kernel update rpi terbaru sekarang menyertakan patch prioritas BCDC.

Cypress (dulu Broadcom) telah memberi kami rilis baru dari firmware WiFi dan Bluetooth untuk diuji. Anda dapat mendownload pra-rilisnya di sini . Setelah mengunduh ke Pi Anda, jalankan:

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

Ini akan mengekstrak kemudian menginstal firmware baru (versi lama akan di-backup terlebih dahulu).

Untuk kembali ke firmware asli (yang saya sarankan Anda lakukan sebelum menginstal rilis yang tepat):

./brcmfw -u

Apa yang berubah:

1. CVE-2017-9417: Perbaikan masalah “Broadpwn”
2. Tambahkan string "CY" di string versi.
3. Perbaikan kebuntuan nomor urut AMPDU (kemungkinan perbaikan untuk masalah ini)
4. Peningkatan versi CLM
5. CVE-2017-0572: perbaikan kerusakan memori

Sekadar catatan - Saya menonaktifkan wifi internal pada Pi Zero W pertama saya dan beralih ke dongle wifi USB, semua masalah hilang. Beberapa hari yang lalu saya menginstal Pi Zero W lain untuk mengontrol printer 3D saya (menggunakan OctoPi). Saya sedikit terkejut melihat bahwa wifi internal tampaknya berfungsi dengan sempurna - tetapi setelah beberapa tes saya dapat mengonfirmasi bahwa wifi rusak segera setelah saya terhubung dari ponsel Android LG G4 saya (browser Chrome). Ketika saya memikirkannya, saya kira perilaku pada Pi pertama sangat mirip ...
Koneksi dari PC saya tidak menyebabkan efek seperti itu.

Silakan coba firmware baru dan laporkan kembali dengan temuan Anda.

saya menginstal firmware pratinjau. Saya masih mendapatkan "kernel raspberrypi: brcmfmac: brcmf_sdio_hostmail: Konten data kotak surat tidak dikenal:", diikuti oleh kegagalan wifi.

Apa kasus penggunaan Anda?

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

mencoba konfigurasi kerja yang dipasang di sana. Saya akan memperbarui.

Harap berikan versi kernel Anda, ringkasan dari perangkat yang terhubung dan lama waktu yang dibutuhkan sampai kesalahan muncul.

Kesalahan kotak surat masih dalam penyelidikan, saya tidak mengharapkan ini
firmware untuk memperbaikinya. Ada lebih banyak debugging dalam firmware ini untuk membantu melacak
itu turun. Jika Anda mengaktifkan driver debugging (maaf, di ponsel dan
tidak memiliki detail tentang cara melakukannya) dan melihat kesalahan, lalu membuang file
debug dan detail posting di sini ketika Anda mendapatkan kesalahan kotak surat akan
berguna.

Pada 13 Agustus 2017 21:40, "Stefan Wahren" [email protected] menulis:

Harap berikan versi kernel Anda, ringkasan perangkat yang terhubung dan
lama waktu yang dibutuhkan hingga kesalahan muncul.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322062745 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHRwsQyHa-QqOP7ntTqgCfWlgXpEqks5sX1DlgaJpZM4HupC5
.

Proses debug dinonaktifkan secara default dan perlu membangun kembali modul untuk mengaktifkannya (mungkin kita harus mengubahnya selama penyelidikan ini). Perubahan yang diperlukan adalah penambahan BRCMDBG=y ke .config diikuti oleh pembangunan kembali, lalu tambahkan brcmfmac.debug=0x???????? ke /boot/cmdline.txt , di mana ???????? adalah bilangan heksadesimal yang terdiri dari nilai bit didokumentasikan di sini: https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h#L22

Mencoba firmware uji yang diposting oleh pelwell, masalah masih berlanjut. Koneksi macet setiap 1 - 2 jam. Ketika koneksi terputus dan saya mencoba melakukan ping ( ping 8.8.8.8 ), itu berfungsi lagi _briefly_ hingga ping ke-8. Perilaku ping konsisten di seluruh freeze. Bekerja-> membekukan-> ping 8.8.8.8-> bekerja -> ping ke-8 -> membeku Setelah itu, saya perlu me-reboot pi raspberry saya. Tidak tahu apakah itu membantu ..

Inti:
Linux raspberrypi 4.9.41-v7 + # 1023 SMP Sel 8 Agustus 16:00:15 BST 2017 armv7l GNU / Linux

Firmware:
BT: test_170808
Tempat WiFi: test_170808
WiFi txt: test_170808

Adakah yang relevan di dmesg saat itu terjadi?

Pada 14 Agustus 2017 13:16, "GIlang Charismadiptya" [email protected]
menulis:

Mencoba firmware uji yang diposting oleh pelwell, masalah masih berlanjut.
Koneksi macet setiap 1 - 2 jam. Ketika koneksi terputus dan saya
mencoba melakukan ping (ping 8.8.8.8), itu berfungsi lagi sebentar sampai tanggal 8
ping. Setelah itu, saya perlu me-reboot pi raspberry saya.

Inti:
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 Sel 8 Agustus 16:00:15 BST 2017 armv7l GNU / Linux

Firmware:
BT: test_170808
Tempat WiFi: test_170808
WiFi txt: test_170808

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D322164546&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=AKaU_LFRmDMObaVb2VxPhT3pS6_Sd6Qnrtg_9TSH5pc&s=lhUPrFZ2Xcg2O_gDeznrblSKqMffIk4hXHFaUrCfNIc&e= ,
atau nonaktifkan utasnya
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=
.

Tidak, tidak ada yang menarik. Mungkin karena saya belum membangun kembali modul dengan dukungan debugging. Bagaimana cara melakukannya? atau apakah Anda akan memberikan modul yang telah dikompilasi? Terima kasih.

Terlampir di bawah ini adalah log dmesg:

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

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

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

Lihat posting Phil di atas untuk detail tentang modul debug. Kami secara khusus
tertarik dengan jejak debug saat terjadi kesalahan kotak surat.

Pada 14 Agustus 2017 17:52, "GIlang Charismadiptya" [email protected]
menulis:

Tidak, tidak ada yang menarik. Mungkin karena saya belum membangun ulang modul dengan
dukungan debugging. Bagaimana cara melakukannya? atau apakah Anda akan memberikan modul yang telah dikompilasi?
Terima kasih.

Terlampir di bawah log dmesg:

` pi @ raspberrypi : ~ $ sudo dmesg

[4.654722] brcmfmac: Versi firmware = wl0: 7 Agustus 2017 versi 00:46:29
7.45.41.46 (r666254 CY) FWID 01-f8a78378
[5.752968] smsc95xx 1-1.1: 1.0 eth0: perangkat keras tidak dapat melakukan remote
bangun
[5.753285] IPv6: ADDRCONF (NETDEV_UP): eth0: tautan belum siap
[6.206530] IPv6: ADDRCONF (NETDEV_UP): wlan0: tautan belum siap
[6.206577] brcmfmac: manajemen daya dinonaktifkan
[7.088933] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: tautan menjadi siap
[7.340040] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: tautan menjadi siap
[7.340841] smsc95xx 1-1.1: 1.0 eth0: link up, 100Mbps, full-duplex, lpa
0xCDE1
[7.431235] Menambahkan 102396k swap di / var / swap. Prioritas: -1 luasan: 4
melintasi: 217088k SSFS
[10.182342] IPv6: ADDRCONF (NETDEV_UP): wlan0: tautan belum siap
[10.182357] brcmfmac: manajemen daya dinonaktifkan
[10.872838] IPv6: ADDRCONF (NETDEV_UP): wlan0: tautan belum siap
[10.872903] brcmfmac: manajemen daya dinonaktifkan
[11.594201] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: tautan menjadi siap
[14.128592] ip_tables: (C) 2000-2006 Tim Inti Netfilter
[14.172268] nf_conntrack versi 0.5.0 (15.560 keranjang, maks 61440)
[54.604680] random: crng init selesai

pi @ raspberrypi : ~ $ sudo dmesg -l err
[4.501055] raspberrypi-touchscreen 3f700000.dsi.0: Firmware Atmel tidak diketahui
revisi: 0xfa
`

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322228992 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHXuy3Eo5PqPAP8FfSFiYWMUQL7fAks5sYG1HgaJpZM4HupC5
.

Kernel pembaruan rpi terbaru mengaktifkan BRCMDBG yang seharusnya mengizinkan opsi baris perintah brcmfmac.debug=0x???????? disarankan oleh @pelwell sebelumnya.

Errrr ..... Pi3 saya yang sangat solid dengan wifi sekarang juga hilang karena saya mengupgrade ke raspbian terbaru beberapa hari yang lalu :-(

Apa gejalanya? Saya tidak mengharapkan regresi dalam firmware, atau
memang pengemudi itu sendiri.

Pada 24 Agustus 2017 pukul 20:07, Crrispy [email protected] menulis:

Errrr ..... Pi3 saya yang dulunya solid dengan wifi sekarang juga kehilangannya sejak saya
memutakhirkan ke raspbian terbaru beberapa hari yang lalu :-(

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-324728431 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHUxvLV3OzKGpcmEMGEoSad_piujBks5sbcoHgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

@Rumahsakitotak
Coba ini:
Saya menghapus semua penyebutan eth0 dari file / etc / network / interfaces saya, mengganti allow-hotplug dengan auto, dan kemudian mematikan daya nirkabel pada wlan0 dan wlan1.

file / etc / network / interfaces saya:

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`

Lalu aku memerah arp:

ip -s -s meringkik semua

Lalu saya reboot:

sudo reboot sekarang

Saya cukup yakin bahwa saya menghadapi bug ini secara teratur. Menjalankan hostapd, menggunakan wifi Broadcom internal untuk menghosting titik akses, dan merutekan klien yang terhubung ke sana melalui dongle wifi USB yang berfungsi sebagai klien nirkabel. Beberapa perangkat terhubung, tetapi segera setelah saya membawa Pi keluar dari jangkauan perangkat yang terhubung, wlan crash tampaknya terjadi. Seperti yang lainnya, hanya perangkat broadcom wlan internal yang mati: ethernet dan wlan lainnya tetap tidak terpengaruh. Saya juga mendapatkan kesalahan "kotak surat" di log sistem:

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

(detail log selengkapnya di https://pastebin.com/NPB00ZEq)

Saya telah memperhatikan bahwa output iwconfig tidak lagi menunjukkan nilai Tx_Power ketika perangkat wlan dalam keadaan gagal, jadi saya telah menggunakannya untuk membuat skrip reboot otomatis sebagai solusi sementara itu.

Saya baru saja memperbarui ke rpi-update terbaru, menginstal driver wifi uji yang dirujuk di atas, dan menambahkan tanda debug ke cmdline.txt saya, menggunakan nilai hex untuk BRCMF_TRACE_VAL: bcrmfmac.debug=0x00000002

Jika Anda sering mendapatkan kesalahan kotak surat, kami akan berterima kasih atas hasil dari driver debug. Ketika Anda mendapatkan kesalahan kotak surat, lakukan sesuatu seperti ini untuk mendapatkan forensik dan posting hasilnya di sini, saya dapat meneruskannya ke Cypress yang sedang menyelidiki masalah tersebut.

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

Nah, apa yang merupakan masalah yang mudah direproduksi, saya tidak lagi dapat menduplikasi, sejak menjalankan pembaruan rpi. Saya mungkin dapat mewujudkannya dengan menurunkan versi kembali ke instalasi baru dari versi Raspbian mulai 21 Juni 2017, jika itu akan membantu.

@Jamal_jogja
Berhasil menangkap forensik yang Anda minta (setelah kesalahan kotak surat), tetapi untuk memperjelas, ini setelah menurunkan versi ke kernel yang termasuk dalam versi Raspbian 21 Juni. Ini mungkin sudah diselesaikan, karena saya belum menduplikasi masalah setelah menginstal firmware uji yang diposting oleh @pelwell sekitar dua minggu yang lalu, dan menjalankan rpi-update.

Berikut tautan ke forensik:
https://pastebin.com/VVqVQ8FW

Semoga bermanfaat ...

Jadi dengan firmware lama saya curiga. Kami berharap mendapatkan forensik untuk
firmware baru yang memiliki pesan tambahan (tampaknya) ditujukan untuk pelacakan
masalah kotak surat. Ini membuatku berpikir Cypress sepertinya masih memikirkannya
masalah kotak surat akan ada, bahkan setelah perbaikan lainnya. Akan tetap meneruskan data kalau-kalau itu membantu.

Perlu diketahui bahwa kesalahan jauh lebih sulit untuk direproduksi!

Pada 29 Agustus 2017 pukul 15:51, randyoo [email protected] menulis:

@Jamal_jogja
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=
Berhasil menangkap forensik yang Anda minta, tetapi untuk memperjelas,
Ini setelah menurunkan ke kernel yang termasuk dalam Raspbian 21 Juni
membangun. Mungkin sudah diselesaikan, karena saya tidak bisa
duplikat masalah setelah menginstal firmware uji yang diposting oleh @pelwell
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pelwell&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=owdl09j03eJ21jjmS-pXzxuHC0FQIGtHaCHVAUCN42I&s=OEna5EdFdm9tLu51AyYXqp_FN2kYCjSiEmIG7OTV8yI&e=
sekitar dua minggu lalu.

Berikut tautan ke 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=

Semoga bermanfaat ...

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D325689126&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=owdl09j03eJ21jjmS-pXzxuHC0FQIGtHaCHVAUCN42I&s=0aM55qLQhMgI2neXi8qVWOJ4FNsV4VlNCOyxI3AW_2c&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Ini membuatku berpikir Cypress sepertinya masih memikirkannya
masalah kotak surat akan ada, bahkan setelah perbaikan lainnya.

Ya, itu pemahaman saya juga.

@randyoo Terima kasih atas umpan balik positifnya.

@Jamal_jogja
Oke, itu terjadi lagi, kali ini di firmware pembaruan rpi terbaru, dan menggunakan firmware uji yang diposting oleh @pelwell . Sayangnya, keluaran forensik tersebut terlihat identik dengan postingan sebelumnya. (Tidak yakin mengapa saya tidak mendapatkan info yang berbeda / lebih detail di dump forensik, karena saya memang mengaktifkan debugging di cmdline.txt saya, sesuai posting saya sebelumnya)

Saya melanjutkan dan membuang konten dari hal-hal / sys / kernel / debug lainnya juga. Ini dia: https://pastebin.com/pdFUPBxN

Pada pembekuan wlan terakhir, jejak log kernel tampak lebih detail. Lihat linknya:
https://pastebin.com/KTxbgpYV

Semoga membantu.

Apakah ada detail lebih lanjut di forensik firmware? Saya pikir itu adalah
bit Cypress benar-benar tertarik ketika terjadi kesalahan kotak surat.

Pada 31 Agustus 2017 pukul 21:56, randyoo [email protected] menulis:

Pada pembekuan wlan terakhir, jejak log kernel tampak lebih detail.
Lihat linknya:
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=

Semoga membantu.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D326418448&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=Q-jbAaSSLWAuC7E9Mh2NDxUucRiJHVodu4QDmS5Tcoo&s=IZRQxkqqxvIzHVKqJB-6M_URsEqng8tIkcmxDIzkkiw&e= ,
atau nonaktifkan utasnya
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
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Benar, maaf. Berhasil mendapatkan gambaran forensik, dan ya, tampaknya ada lebih banyak detail di sana:
https://pastebin.com/qypfAfAp

Karena terkadang memiliki kasus baru membantu, saya juga mendapatkannya dari waktu ke waktu:

pi @ jempi : ~ $ grep "brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012" / var / log / syslog
14 Agustus 22:16:23 kernel jempi: [501.247242] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
17 Agustus 20:26:20 kernel jempi: [509.684277] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
24 Agustus 23:57:37 kernel jempi: [573.652189] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
29 Agustus 23:50:16 kernel jempi: [5052.517999] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
30 Agustus 00:02:18 kernel jempi: [170.978988] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
30 Agustus 23:58:03 kernel jempi: [8254.502431] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
2 Sep 00:33:28 kernel jempi: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012

Saya menggunakan wifi internal (wlan0) sebagai AP dan memasang dongle (wlan1) untuk terhubung ke router saya:
pi @ jempi : ~ $ ifconfig wlan0
wlan0 Tautan encap: Ethernet HWaddr b8: 27: eb: cf: db: b8
inet addr: 10.3.141.1 Bcast: 10.3.141.255 Topeng: 255.255.255.0
inet6 addr: fe80 :: 6b56: 4657: 75cd: a501 / 64 Cakupan: Tautan
UP BROADCAST RUNNING MULTICAST MTU: 1500 Metrik: 1
Paket RX kesalahan: 0 dijatuhkan: 0 overruns: 0 frame: 0
Paket TX kesalahan: 0 dijatuhkan: 0 kelebihan beban: 0 operator: 0
Kualitas: 0 ton bahan bakar: 1000
RX byte: 0 (0,0 B) TX byte: 5492 (5,3 KiB)

pi @ jempi : ~ $ ifconfig wlan1
wlan1 Tautan encap: Ethernet HWaddr 00: 60: b3: db: 8a: 4a
inet addr: 192.168.1.74 Bcast: 192.168.1.255 Topeng: 255.255.255.0
inet6 addr: fe80 :: 260: b3ff: fedb: 8a4a / 64 Cakupan: Tautan
UP BROADCAST RUNNING MULTICAST MTU: 1500 Metrik: 1
Paket RX error: 0 dijatuhkan: 2 overruns: 0 frame: 0
Paket TX kesalahan: 0 dijatuhkan: 0 overruns: 0 pembawa: 0
emisi: 0 ton bahan bakar: 1000
RX byte: 256652 (250,6 KiB) TX byte: 215250 (

Saya memiliki kernel 4.9.35-v7 + dan memutakhirkannya kemarin menjadi 4.9.46-v7 + (dengan pembaruan rpi) tetapi tidak membantu. Masukan dari syslog jika gagal:

2 Sep 00:33:28 kernel jempi: [5979.773944] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
2 Sep 00:34:00 kernel jempi: [6011.624839] brcmfmac: brcmf_netdev_wait_pend8021x: Waktu habis menunggu tidak ada paket 802.1x yang tertunda
2 Sep 00:34:02 kernel jempi: [6014.184823] brcmfmac: send_key_to_dongle: kesalahan wsec_key (-110)
2 Sep 00:34:05 kernel jempi: [6016.744833] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON gagal -110
2 Sep 00:34:06 kernel jempi: [6017.704831] brcmfmac: brcmf_netdev_wait_pend8021x: Waktu habis menunggu tidak ada paket 802.1x yang tertunda
2 Sep 00:34:08 kernel jempi: [6020.264850] brcmfmac: send_key_to_dongle: kesalahan wsec_key (-110)
2 Sep 00:34:11 kernel jempi: [6022.824903] brcmfmac: brcmf_cfg80211_change_station: Pengaturan SCB (de-) otorisasi gagal, -110

Mulai ulang antarmuka wlan0 dengan sudo ifconfig wlan0 turun dan naik tidak membantu.

@ bulrog Harap berikan juga forensik seperti yang dijelaskan oleh James di atas.
Driver mana yang digunakan wlan1? Apakah masalah ini masih terjadi dengan dongle yang dicabut?

Beberapa rekaman forensik lagi:
https://pastebin.com/vqh3UcF3

Jika ini membantu Cypress melihat area yang tepat: Saya telah mengalami masalah ini berkali-kali sekarang, dan tampaknya terwujud dengan sendirinya setiap kali perangkat mencoba untuk terhubung. Ini terjadi berkali-kali setelah berjalan ke jangkauan AP, atau saat perangkat tidur dibangunkan.

Saya telah menyimpan konfigurasi ini cukup lama untuk merekam forensik, dan jika ada lebih banyak detail yang dapat saya berikan, saya akan senang melakukannya, tetapi wlan crash sekarang terjadi begitu sering sehingga membuat perangkat saya tidak berguna. Saya bermaksud untuk menggunakan dongle wifi USB lain untuk menggantikan radio internal, untuk mendapatkan keandalan.

Saya telah menyampaikan forensik terbaru Anda kepada Cypress - terima kasih telah meluangkan waktu.

Hanya ingin ikut campur. Saya memiliki masalah yang sama persis pada tiga RPI3 yang menjalankan firmware terbaru. Saya menggunakan Octopi pada ketiganya dan mengaksesnya melalui Printoid.

bcrmfmac.debug seharusnya brcmfmac.debug (terima kasih telah melihat @MilhouseVH)
Saya akan mengedit posting sebelumnya.

bcrmfmac.debug harus brcmfmac.debug (terima kasih telah melihat @MilhouseVH)
Saya akan mengedit posting sebelumnya.

Berdasarkan ini, saya berasumsi bahwa forensik yang saya tangkap tidak lengkap.

Saya telah mengulangi tangkapan forensik, itu dapat dibaca dengan teliti di URL berikut:
https://pastebin.com/ha5rd7SW

Selain itu, file /var/log/kern.log saya berukuran hampir 200MB, sebagian besar terdiri dari entri yang sangat mirip. Saya menemukan kesalahan kotak surat pada 00:53:19, dan memotong beberapa detik sebelum dan sesudah kesalahan. Semoga membantu, simak disini:
https://pastebin.com/JcE0zstS

jadi saya pikir saya telah menemukan masalah yang sama, lihat https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=192735

saya dapat mereproduksinya dalam 5 menit. Anda membutuhkan lalu lintas dalam jumlah tinggi melalui wifi (antarmuka web kamera) dan sinyal wifi yang sangat rendah. Saya memiliki pi nol dan itu cukup untuk meletakkan jari / tangan Anda di sekitar antena onboard untuk mendapatkan sinyal hampir nol (router saya menunjukkan sinyal 15-20%). Setelah sekitar 1 menit dalam keadaan ini wifi macet

@lategoodbye setelah seminggu keluar saya menyalakan pi saya dan tidak ada masalah selama tidak ada yang menggunakan AP dan setelah beberapa saat mendapat masalah ketika terhubung dengan ponsel saya ke wlan0. Saya menjalankan perintah dan hasilnya dapat ditemukan di sini: https://pastebin.com/77tGfRcU

untuk wlan1, saya menggunakan dongle yang cukup tua. Tidak dapat mengingat driver mana yang harus saya instal agar berfungsi tetapi inilah yang diberikan lsusb untuk HW yang saya gunakan:

Bus 001 Perangkat 005: ID 0 cde: 0008 Z-Com XG-703A 802.11g Adaptor Nirkabel [Intersil ISL3887]

Saya tidak tahu apakah itu membantu tetapi inilah pengalaman saya:

Saya membeli Pi3 dan mengujinya selama beberapa hari dengan wifi internal (tidak jauh dari AP), dan tampaknya berfungsi dengan cukup baik (saya tidak mengharapkan bitrate tinggi, itu hanya berguna untuk shell jarak jauh melalui ssh ).

Setelah memasukkannya ke dalam casing aluminium, awalnya masih terlihat oke, tetapi kemudian wifi terus menjadi tidak dapat digunakan secara acak. Hingga menit tidak ada ping yang masuk. Masih ada saat-saat ketika itu bekerja dengan sangat baik selama beberapa detik tetapi itu beralih ke pengalaman "satu penekanan tombol per detik" lagi atau berhenti bekerja sama sekali.

Tampaknya tidak ada koneksi yang "lambat tetapi dapat digunakan", hanya mungkin yang "sangat bagus" atau "yang tidak dapat digunakan". Ini mungkin karena bug di firmware. Saya tidak tahu dan terus terang saya kehilangan kesabaran dan menggunakan dongle usb yang sangat kecil yang berfungsi 100% stabil.

Adakah yang menemukan solusi untuk mendeteksi masalah (dalam mode AP) dan mengatur ulang perangkat wlan secara terprogram?

Bukan yang saya lihat, memulai ulang antarmuka tidak membantu. Bagi saya penahanannya adalah untuk membeli perangkat usb wifi eksternal dan berfungsi seperti pesona tetapi itu menyebalkan karena sekarang saya mematikan wifi pi (menghela nafas!)

Maksud Anda masalah kotak surat? Itu masih diselidiki di Cypress.

Pada 21 Sep 2017 08:38, "morel jerome" [email protected] menulis:

Bukan yang saya lihat, memulai ulang antarmuka tidak membantu. Bagi saya penahanan itu
adalah untuk membeli perangkat usb wifi eksternal dan berfungsi seperti pesona tetapi sebenarnya
Sayang sekali karena sekarang saya mematikan wifi dari pi (menghela napas!)

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_1342-23issuecomment-2D331077428&d=DwMCaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=yJzPdDsdAiNsKtR1oEpYjjGEpQ0eJYC9ewXwEfkuqPc&s=6bBJAhWAGVPWclnkLVfXnnxkjzhpirqKWLaw_h7N5vE&e= ,
atau nonaktifkan utasnya
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=
.

Ya masalah kotak surat. Saya berharap ini diperbaiki tetapi sebagai penahanan saya harus beralih ke perangkat eksternal.

BAIK. Kami bergantung pada belas kasihan Cypress untuk yang satu ini - ini masalah firmware, dan mereka adalah satu-satunya yang memiliki akses. Saya akan terus mengingatkan mereka ..... kami mungkin memerlukan beberapa forensik lagi, tetapi akan memposting di sini jika itu masalahnya.

wlan saya terputus dan terhubung kembali setelah beberapa detik tidak aktif (saya menganggap ini hemat daya, meskipun saya menonaktifkannya dengan iw, atau mungkin gangguan). Tidak yakin apakah ini masalah yang sama seperti yang dibahas di sini (karena akan segera tersambung kembali).

Jika saya terhubung dengan ssh -o ServerAliveInterval 5 ... itu tidak terputus lagi.

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

@bayu_joo
Bukan masalah, jika terhubung kembali umumnya hanya akan menjadi masalah latensi, tetapi ketika menjalankan tanpa kepala melalui WiFi (salah satu fitur potensial utama PiZero-W) ketika WiFi putus dan tidak secara otomatis terhubung kembali, sistem telah macet untuk semua tujuan praktis.

Bahkan jika saya memiliki HDMI, mouse, dan keyboard di bawah beban jaringan yang berat seperti dengan Motioneye, terkadang satu-satunya cara untuk memulihkannya adalah dengan menyalakan siklus.

Saya telah mengulangi instalasi dan konfigurasi Motioneye pada Pi2 dengan dongle WiPi USB WiFi dan sejauh ini berfungsi dengan sempurna dengan beban yang secara andal membunuh PiZero-W dalam beberapa jam. Bagi saya ini sepertinya mengkonfirmasi masalah chip / driver WiFi dan bukan masalah dengan Raspbian-stretch.

@ PeterTheMaster1 @randyoo @joshfria

Oke, pesan untuk siapa saja yang melihat masalah kotak surat secara teratur, dan akan dapat menguji sesuatu untuk saya.

Kami memiliki firmware diagnostik dari Cypress, yang dapat membantu melacak masalah. Jika ada orang dengan masalah kotak surat yang bersedia untuk menjalankan firmware ini, dan ketika masalah kotak surat terjadi, buang forensik, dan posting hasilnya di sini, itu akan sangat membantu. Catatan, firmware ini tidak boleh digunakan untuk hal lain selain pengujian ini karena akan 'tidak optimal'! Silakan beri komentar di sini jika Anda dapat melakukan tes, dan saya akan menghubungi firmware dan instruksi.

@iurly : Saya menulis skrip yang akan mendeteksi masalah, dan kemudian reboot, karena antarmuka turun dan naik tidak membantu ... Tapi itu sering reboot, sehingga saya hanya bisa mendapatkan perangkat yang berguna dengan mengambilnya keluar dari mode AP (dan menetapkan tugas AP ke dongle USB saya)

@ JamesH65 : Saya akan dengan senang hati membantu, seperti sebelumnya. Apakah ini versi baru dari firmware diagnostik? Saya memposting tangkapan forensik 3 minggu yang lalu (di halaman masalah ini) menggunakan firmware diagnostik / debugging yang diposting sebelumnya di halaman ini.

Ya, firmware baru dari Cypress per Senin 25 September. Ini memiliki lebih banyak
diagnostik di dalamnya. Forensik sebelumnya yang Anda berikan telah dipersempit
masalahnya, mereka membutuhkan sedikit lebih banyak detail. Saya telah menjalankan mesin
selama 24 jam sejauh ini tanpa kesalahan kotak surat, jadi saat ini tidak dapat menirunya
diri.

Bisakah Anda mengirimi saya email tentang james. [email protected] dan saya bisa memberikan firmware tersebut kepada Anda. Saya tidak ingin mempublikasikannya secara lebih global karena ini hanya untuk tujuan pengujian.

Pada 27 September 2017 pukul 14:48, randyoo [email protected] menulis:

@iurly https://github.com/iurly : Saya menulis skrip yang akan mendeteksi
masalah, dan kemudian reboot, karena membawa antarmuka ke bawah dan ke atas
tidak membantu ... Tapi saat itu terlalu sering reboot, sehingga saya hanya bisa mendapatkan file
perangkat yang berguna dengan mengeluarkannya dari mode AP (dan menetapkan tugas AP ke file
Dongle USB)

@ JamesH65 https://github.com/jamesh65 : Saya akan dengan senang hati membantu, sebagai
sebelum. Apakah ini versi baru dari firmware diagnostik? Saya memposting
forensik menangkap 3 minggu lalu (di halaman terbitan ini) menggunakan
firmware diagnostik / debugging yang diposting sebelumnya di halaman ini.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332526471 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHW_vEVuxFD-9RuxE003QZc_2NoFaks5smlIjgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

@ JamesH65 Jika Anda berbaik hati memberikan tautan ke firmware baru, saya dapat menginstalnya dan mencoba menangkap forensik lagi, seperti yang Anda minta.

Sayangnya, memberikan tautan di sini berarti tersedia untuk umum, dan
karena ini adalah firmware uji, saya lebih suka tidak melarikan diri ke dalamnya
Alam liar. Karenanya permintaan untuk dilakukan melalui email. Jika itu masalah, saya akan mengunggah
itu di suatu tempat dan dapat memposting tautan.

Pada 27 September 2017 pukul 15:56, randyoo [email protected] menulis:

@ JamesH65 https://github.com/jamesh65 Jika Anda akan berbaik hati
berikan tautan ke firmware baru, saya dapat menginstalnya dan mencoba menangkap
forensik lagi, seperti yang Anda minta.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332548884 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHbVhHD2rk_hp3kG51WBY0R0IQzL3ks5smmIbgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

@ JamesH65 Saya tahu saya memiliki pembekuan rutin kartu Nirkabel internal RPI3 dalam mode AP jadi saya akan sangat bersedia membantu, tetapi saya tidak begitu yakin itu masalah kotak surat atau sesuatu yang lain. Saya benar-benar mencari log saya untuk pesan semacam itu tetapi saya belum menemukannya.

Saya menjalankan firmware yang dikirimkan dengan kernel 4.4.50 (dan saya tidak dapat benar-benar meningkatkan ke versi 4.9 terbaru karena regresi, lihat # 2197), apakah versi itu menunjukkan pesan itu atau apakah ini ditambahkan di tahap selanjutnya?

Terima kasih!

@ iurly Anda mengatakan satu hal yang benar, masalah crash di driver broadcom terjadi dalam mode AP, dan saya tidak tahu apakah ini terkait dengan kesalahan kotak surat. tampaknya ada lebih dari 1 bug di sini, mungkin itu adalah beberapa bug perangkat keras karena waktu masalahnya ada dan tidak ada solusi yang ditemukan.

Yang benar-benar mengganggu saya adalah kurangnya solusi, selain me-reboot seluruh sistem.
Maksud saya, bahkan tidak ada cara untuk mengatur ulang periferal dan memulai ulang hostapd?!?

@ iurly Anda mengatakan satu hal yang benar, masalah crash di driver broadcom terjadi dalam mode AP, dan saya tidak tahu apakah ini terkait dengan kesalahan kotak surat. tampaknya ada lebih dari 1 bug di sini, mungkin itu adalah beberapa bug perangkat keras karena waktu masalahnya ada dan tidak ada solusi yang ditemukan.

Sekadar informasi, saya juga mengalami masalah dalam mode klien / stasiun. Menjalankan master LEDE, 4.9 kernel dan menggunakan firmware 7.45.41.46.

@Jamal_jogja
Pahami keinginan untuk mencegah firmware uji dipublikasikan. Email akan baik-baik saja, tetapi saya juga tidak ingin memposting alamat saya di sini secara publik, dan saya tidak melihat cara untuk mengirim pesan di github.

Gunakan alamat pi saya di atas untuk mengirim email kepada saya dan saya akan mengirimkan firmware kepada Anda.

Kembali. Mode ap
Ada beberapa perbaikan sejak 4.4, jadi patut untuk mencoba peregangan terbaru
untuk melihat apakah masalah itu masih terjadi.

Ah, ketika Anda mengedit komentar, tidak ada pembaruan email yang dikirim, dan saya mengedit di email Pi saya ke entri di atas, jadi Anda mungkin belum diperbarui. Gunakan situs web github untuk melihat di mana Anda perlu mengirimi saya email.

@ JamesH65 Mengirimi Anda email. Senang mendengar bahwa rekaman forensik sebelumnya membantu mempersempitnya, setidaknya ... Sepertinya banyak orang akan senang ketika masalah ini diselesaikan.

@Jamal_jogja
Berikut adalah tangkapan forensik dari firmware yang Anda kirimi email: https://pastebin.com/zdB36ttj
Semoga membantu.

Luar biasa, akan diteruskan ke Cypress. Terima kasih sudah melakukannya.

Saya memiliki pi dalam pengaturan sekarang di mana sepertinya saya dapat mereproduksi ini sesuka hati. Jika mengumpulkan lebih banyak forensik bermanfaat beri tahu saya. Hanya kesalahan kotak surat yang bisa saya lihat di log.

Setelah saya mengganti microSD di Zero W saya, itu telah terhubung selama 7 hari tanpa masalah. Saya tidak berpikir itu akan bertahan selama ini. Kedengarannya aneh bahwa kartu SD dapat memengaruhi WiFi, tetapi karena keduanya terhubung ke bus SDIO, ada kemungkinan yang satu memengaruhi yang lain.

Kartu yang saya gunakan sebelumnya adalah (mungkin murah) Transcend kelas 4 8GB yang disertakan dengan papan UDOO Quad saya. Sekarang ini adalah Samsung EVO 32GB. Orang yang mengalami masalah mungkin ingin mencoba jika menggunakan kartu lain dapat membantu.

@stintel Menarik, tapi mungkin ada masalah setting software di microSD lain, atau malah microSD yang rusak.

Mungkinkah itu terkait dengan kekuasaan? Mungkin kartu murah itu untuk sesaat menyedot terlalu banyak daya dari bus?

Saya memuat firmware yang diposting Pelwell dan melihat peningkatan BESAR. Sebelumnya, SSH ke Pi 0W saya seperti menelepon ke terminal dengan modem 2400 baud dan saluran telepon yang jelek. Sekarang, saya dapat menjalankan X jarak jauh dan berfungsi dengan baik.

Terima kasih!

Saya memiliki masalah yang sama. Dengan mentransfer sejumlah besar nama file (sync-over-ftp) dari raspberryPi3-internal-wifi ke Galaxy S5 wifi berhenti bekerja. tetapi beberapa kali berhasil ...

Saya memiliki masalah yang sama pada pesan kotak surat dengan RPi3 WiFi AP saya, tetapi saya telah menemukan solusi di forum ini , dan itu berhasil untuk saya. Solusinya adalah mengubah parameter berikut di /etc/hostapd/hostapd.conf

wpa = 3 diubah menjadi wpa = 2auth_algs = 3 diubah menjadi auth_algs = 1

Saya telah mengujinya selama 1 minggu dan tidak menunjukkan masalah kotak surat lagi.

Saya tidak yakin apakah ini akan berhasil untuk Anda semua, tetapi Anda dapat mencobanya dan memposting di sini jika berhasil.

Ini adalah hostapd yang berfungsi, 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

Ada pembaruan tentang masalah ini? Atau apakah ada solusi yang diketahui?

Masih mengalami hal ini pada Pi Zero W yang baru saja dibeli dengan stretch-lite dan rpi-update kemarin.

Menggunakan RPi untuk mengalirkan umpan kamera melalui RTSP (udp) saya dapat melihat koneksi memburuk secara drastis tepat sebelum koneksi WiFi terputus, setelah itu koneksi WiFi tidak pernah pulih dan saya harus menyalakan siklus Pi0W.

A dmesg > dmesg.log hanya menunjukkan:

brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Jika saya memindahkan Pi0W lebih dekat ke titik akses saya, masalah tidak akan terjadi.

Saya tidak menggunakan Pi0W sebagai titik akses, ini hanya klien. Saya telah mencoba sumber daya yang berbeda.

Kami sedang menunggu Cypress, penyedia chip nirkabel,
untuk memajukan masalah. Aku akan mem-ping mereka lagi.

Pada 25 Oktober 2017 pukul 14:02, Matthias Urhahn [email protected]
menulis:

Ada pembaruan tentang masalah ini? Atau apakah ada solusi yang diketahui?

Masih mengalami hal ini pada Pi Zero W yang baru dibeli dengan yang terbaru
stretch-lite dan rpi-update mulai kemarin.

Menggunakan RPi untuk mengalirkan umpan kamera melalui RTSP (udp) saya dapat melihat file
koneksi memburuk secara drastis tepat sebelum koneksi WiFi terputus,
setelah itu koneksi WiFi tidak pernah pulih dan saya harus menyalakan siklus
Pi0W.

A dmesg> dmesg.log hanya menampilkan:

brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012

Jika saya memindahkan Pi0W lebih dekat ke titik akses saya, masalah tidak akan terjadi.

Saya tidak menggunakan Pi0W sebagai titik akses, ini hanya klien. saya telah mencoba
sumber daya yang berbeda.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-339322153 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHRlPhJBGXc3JFWbpw_Tf4_EKmgAeks5svzFQgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Yah ... Saya telah mengupgrade ke kernel / firmware terbaru (apt-get upgrade lalu rpi-update), dan sekarang, bahkan Pi3 saya yang memiliki wifi yang kuat juga kehilangannya setelah beberapa jam !! Saya tahu, jika tidak rusak, jangan perbaiki ... seharusnya tidak ditingkatkan, tetapi karena saya melakukan tes dari waktu ke waktu di Pi3 ke-2 saya dengan kartu SD yang sama ..

FWIW, saya juga bisa mereproduksi masalah ini sesuka hati. Saya membuat posting forum di Raspberry Pi yang menjelaskan masalahnya:

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

CATATAN: Saya tidak menggunakan Pi sebagai AP. Saya dapat membantu dengan forensik atau menguji firmware eksperimental, dll. Jika itu membantu.

Masalah yang sama disini. Saya menyiapkan ownCloud dan dapat mentransfer file dari laptop saya tanpa masalah.
Tetapi segera setelah saya mentransfer file dengan wifi Samsung Galaxy S7 saya rusak dan
raspberrypi kernel: [ 962.273390] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012 :
muncul.

Router saya adalah FRITZ! Box 7490.

Terima kasih @srinathava untuk kiriman yang menjelaskan masalah saya dengan baik!

Dapatkah orang-orang yang telah menguji dengan firmware uji coba yang berikut ini - informasi debug lebih lanjut yang diperlukan oleh Cypress.

1. saat melakukan insmod, tambahkan "debug = 0x100000"
2. setelah masalah terjadi, simpan keluaran "dmesg"

Terima kasih.

Permintaan bantuan lain untuk yang satu ini.

Bisakah orang-orang yang telah menguji dengan firmware uji (lihat di atas) silakan coba berikut - informasi debug lebih lanjut yang diperlukan oleh Cypress.

saat melakukan insmod, tambahkan "debug = 0x100000"
setelah masalah terjadi, simpan output "dmesg" - ini adalah bagian yang kami minati.

Terima kasih.

@ JamesH65 Sekadar memberi tahu Anda, saya sekarang mencoba mengumpulkan infonya, tapi masalah belum muncul dengan sendirinya. Saya hanya membuat beberapa perubahan kecil pada file /etc/hostapd/hostapd.conf, tetapi perubahan tersebut mungkin secara tidak sengaja mengatasi masalah ini. Jika masalah tidak muncul dengan sendirinya dalam beberapa hari, saya akan mengembalikan perubahan tersebut dalam upaya untuk mereplikasi masalah dan mengumpulkan data debug.

Terima kasih atas bantuannya.

Akan menarik untuk melihat perubahan yang Anda buat pada hostapd jika, itu benar-benar menyelesaikan masalah.

Setelah 4 hari stabil, saya mengembalikan perubahan saya ke file /etc/hostapd/hostapd.conf, dan setelah beberapa jam, masalah tersebut terulang kembali. Berikut adalah keluaran dari 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

Saya menjalankan paket perangkat lunak yang disebut RaspAP , dan saya cukup yakin itu mengkonfigurasi file hostapd.conf atas nama saya, meskipun saya tidak 100% yakin.

Bagaimanapun, dengan mengomentari baris ini di /etc/hostapd.conf: dan menggantinya dengan ini: Saya menjalani operasi yang stabil selama 4 hari berturut-turut, sementara itu biasanya crash dalam beberapa jam, atau terkadang bahkan beberapa menit!

Semoga semua ini membantu.

Mohon maaf jika saya memposting di tempat yang salah, saya mengalami perilaku aneh dengan internal RPi3 (broadcom) wlan saat mengirim paket UDP Unicast di bawah raspbian.
Saya mengirim paket kecil data 2kb sekali setiap detik, di ujung penerima ini diblokir setiap 120 detik selama sekitar 3-4 detik. Tes ini berjalan seperti jarum jam, dan saya dapat mereproduksi dengan iperf melakukan hal berikut

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

PC Ubuntu terhubung sebagai klien WiFi ke RPi3 (IP 192.168.1.22 seperti di atas)

iperf -u -s -i 1

Menjamin penyumbatan setiap 120 detik. Menarik, ini sepertinya tidak terjadi dengan menggunakan TCP
Akhirnya, setelah mengunduh dan melihat kode driver (dan tidak memahami apa pun) saya melihat penyebutan yang mencurigakan

tentukan BRCMF_SCAN_PASSIVE_TIME 120

Yang kemudian digunakan dalam kode driver

Mungkinkah ini terkait, saya kehabisan akal untuk mencoba menyelesaikannya?
Terima kasih

Saya memasukkan yang berikut ini ke /etc/rc.local dan milik saya tampaknya bekerja jauh lebih baik:

Iwconfig wlan0 matikan

PI nol w

Sean

Pada 19 Desember 2017, pukul 3:42, LeeMooreImperas [email protected] menulis:

Mohon maaf jika saya memposting di tempat yang salah, saya mengalami perilaku aneh dengan internal RPi3 (broadcom) wlan saat mengirim paket UDP Unicast di bawah raspbian.
Saya mengirim paket kecil data 2kb sekali setiap detik, di ujung penerima ini diblokir setiap 120 detik selama sekitar 3-4 detik. Tes ini berjalan seperti jarum jam, dan saya dapat mereproduksi dengan iperf melakukan hal berikut

Rpi3

iperf -u -c 192.168.1.22 -i 1 -t 3600

PC Ubuntu terhubung sebagai klien WiFi ke RPi3 (IP 192.168.1.22 seperti di atas)

iperf -u -s -i 1

Menjamin penyumbatan setiap 120 detik. Menarik, ini sepertinya tidak terjadi dengan menggunakan TCP
Akhirnya, setelah mengunduh dan melihat kode driver (dan tidak memahami apa pun) saya melihat penyebutan yang mencurigakan

tentukan BRCMF_SCAN_PASSIVE_TIME 120

Yang kemudian digunakan dalam kode driver

Mungkinkah ini terkait, saya kehabisan akal untuk mencoba menyelesaikannya?
Terima kasih

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Hai Sean
Terima kasih atas perhatiannya, sayangnya, ini tidak diterima oleh perangkat broadcom, saya mengerti

Error for wireless request "Set Power Management" (8B2C) 
    Set failed on device wlan0; Invalid argument

Namun saya DO menggunakan perintah berikut dalam pengaturan saya untuk mencapai tujuan yang sama
$ iw dev wlan0 set power_save off
ini diterima dan jika saya menanyakan pengaturan
$ iwconfig wlan0
saya melihat
Power Management:off

Jadi cukup yakin penghematan daya dimatikan, tetapi tidak menyelesaikan masalah ini
Terima kasih

@LeeMooreImperas Saya menyarankan untuk membuka masalah terpisah untuk ini dan menyediakan setidaknya versi Kernel dan versi firmware Wifi.

Saya mengomentari utas ini sejak lama tetapi kemudian harus berhenti melihatnya karena saya tidak lagi dapat mereproduksinya. Saya punya beberapa data baru dan menurut saya ini sangat menarik.

Saya memiliki dua Raspberry Pi; satu B + V1.2 dan satu Raspberry PI (C) 2011 asli.

Jika saya menjalankan "4.1.19+ # 858 Tue 15 Mar 15:52:03 GMT 2016" pada RaspPi B +, chip Edimax WiFi akan menunjukkan masalah yang telah dilihat orang lain.

Jika saya menjalankan "4.9.27+ # 1 Kamis 11 Mei 17:40:53 UTC 2017" pada RaspPi B + yang sama, chip WiFi Edimax yang sama tidak akan menunjukkan masalah.

Saya sekarang bertanya-tanya apakah ini lebih merupakan ketidakcocokan dengan perangkat keras dan saya juga diingatkan bahwa dengan papan RaspPi yang jauh lebih tua, WiFi USB memerlukan kabel khusus untuk menambah daya + 5V karena daya yang berasal dari papan tidak ' t cukup untuk mengendarainya. Saya akan mengganti kartu SD kembali sehingga mereka menunjukkan masalahnya, lalu lihat apakah kabel jenis ini membantu.

Oke, saya pikir saya salah.

Menjalankan 4.9.27+ pada RaspPi lama akan menunjukkan masalah. Memverifikasi sekarang.

Oke, ini pasti dan sangat menarik.

Menggunakan papan Raspberry Pi asli (sekitar 2011) dan menjalankan Linux 4.9.27+ (dari "uname -a"), saya dapat mereproduksi masalah chip WiFi USB Edimax kehilangan koneksi WiFi, dan dengan demikian alamat IP, setiap saat , dalam beberapa menit.

Menggunakan papan Raspberry Pi asli yang sama dan versi Linux yang sama, tetapi HANYA perubahan hanya menggunakan kabel USB yang memungkinkan saya menambah + 5V ke WiFi USB dari sumber sekunder, sistem stabil.

Jadi, tampaknya ada masalah dengan kartu WiFi USB Edimax tidak mendapatkan cukup daya dalam pengaturan ini. Ini, jelas, tidak membantu mereka yang menggunakan Raspberry Pi dengan WiFi bawaan, tetapi dalam kasus tersebut saya bertanya-tanya apakah mungkin masalah serupa sedang terjadi dan jika mungkin pindah ke adaptor USB yang menghasilkan lebih banyak amp mungkin muncul. sebuah perbedaan?

Ada kemungkinan bahwa adaptor Mains to USB yang memberi daya pada Pi mungkin tidak memberikan 5V bersih dalam beberapa kasus.
Karena AC harus diatur kemudian dihaluskan sebelum menjadi 5V, tetapi Anda masih mendapatkan sedikit riak di DC yang dikeluarkan.
5V dari laptop atau PC lebih mirip bebas riak daripada pengisi daya Listrik ke USB yang murah

Akan menarik untuk meletakkan osiloskop pada catu daya ke chip wifi dalam kondisi berbeda untuk melihat seperti apa riak selama kegagalan / non-kegagalan

Harap simpan masalah ini pada masalah dengan chip nirkabel ONBOARD Brcm pada Pi3 - jika Anda memiliki masalah dengan perangkat lain, gunakan forum untuk mendapatkan saran. Ini hanya agar informasi yang perlu kami sampaikan kepada Cypress tidak terlalu membingungkan.

@Jamal_jogja
@bayu_joo

Hai James, Stefan,
Jadi pesan yang bertentangan di sini, masalah yang saya catat terkait langsung dengan RPi3 BRCM WiFi.
Jadi haruskah ini masuk ke utas yang berbeda (seperti yang disarankan oleh lategoodbye)?
Saya akan berpikir bahwa utas ini secara khusus tentang masalah saya?

Saya senang untuk memindahkan masalah ini

Terima kasih

@LeeMooreImperas Meskipun masalah Anda terkait dengan nirkabel onboard, masalah Anda adalah jeda setiap 2 menit, masalah ini menjelaskan kegagalan penguncian nirkabel lengkap yang terjadi secara acak, jadi sepertinya tidak ada kaitannya. Jadi mungkin ada baiknya membuat masalah lain. Sayangnya saya agak kabur dalam pesan saya sebelumnya.

Menambahkan "aku juga" lainnya pada ini.
Perangkat Keras: Raspberyy Pi 3, Model B.
Kernel: Linux raspberrypi 4.9.70-v7 +
OS: Raspbian GNU / Linux 9 (peregangan)
Gambar yang Dimuat: 2017-11-29-raspbian-stretch.img
Gambar MD5:
SDCard: Tidak yakin pada pabrikannya, itu disertakan dengan kit
File Antarmuka: interfaces.txt
hostapd.conf: hostapd.txt
dmesg output (saat bekerja): dmesg_20171230.txt

Perangkat ini dikonfigurasi sebagai titik akses untuk jaringan nirkabel saya. Router utama saya adalah firmware Linksys EA6400 versi 1.1.40 (build 184085). Baik Linksys dan Pi menawarkan SSID yang sama di saluran yang berbeda. Pi terhubung ke router melalui koneksi kabel dengan sakelar yang tidak dikelola di antaranya.
Beban OS pada perangkat cukup baru. Saya memiliki gambar RetroPie di sistem dan menghadapi masalah yang sama. Saya memuat ulang ke Raspbian untuk melihat apakah itu berfungsi lebih baik.
Saya melihat jembatan putus secara sporadis. Gejala utamanya adalah jaringan nirkabel yang disediakan oleh Pi tampaknya terisolasi dari jaringan kabel. Antarmuka berkabel terus berfungsi normal dan saya dapat mencapai Pi melalui SSH. Jika saya menjalankan tcpdump pada antarmuka nirkabel (wlan0), sementara dalam kondisi tersebut, saya masih dapat melihat lalu lintas ke dan dari perangkat yang terhubung.
Bersepeda koneksi nirkabel (ifdown; ifup) tampaknya tidak memperbaiki masalah. Saya belum mencoba bersepeda antarmuka jembatan (br0). Secara umum saya telah me-reboot perangkat yang memperbaiki masalah.
Saya tidak yakin itu terkait; namun, masalah tersebut tampaknya muncul saat saya mencoba mengontrol ChromeCast 2 saya setelah dijalankan beberapa saat. Misalnya, jika saya memutar acara melalui Netflix di ChromeCast dan kemudian mencoba untuk menjeda pertunjukan, jembatan sepertinya putus pada saat itu. Saya belum bisa menangkap ini melalui tcpdump; Tapi, itu langkah selanjutnya bagi saya.
Saya telah mempertimbangkan bahwa itu mungkin masalah panas; namun, saya memiliki /opt/vc/bin/vcgencmd measure_temp berjalan pada loop 30 detik selama salah satu dropout dan suhu cpu saya berada di kisaran 50C. Tidak yakin bagaimana cara mendapatkan pembacaan suhu pada chip LAN, karena di sanalah mungkin timbul masalah panas.

Saya dengan senang hati menangkap log / pcaps yang diperlukan untuk membantu memecahkan masalah lebih lanjut. Padahal, harap jelaskan dalam instruksi karena saya memiliki beberapa celah dalam pengetahuan saya tentang Linux.

EDIT: baru saja keluar dan melakukan sudo ifdown br0 && sudo ifup br0 dan tampaknya sudah mulai bekerja lagi. Saya akan mengujinya lagi di drop out berikutnya.

EDIT2: Berikut adalah dump dmesg dengan koneksi gagal. sudo ifdown br0 && sudo ifup br0 tampaknya tidak memulihkan koneksi kali ini.
dmesg_20171220_failed.txt
Dari catatan khusus tampaknya kesalahan:
brcmfmac: brcmf_cfg80211_stop_ap: pengaturan mode INFRA gagal -7

EDIT3: Berlari di utas ini tentang masalah serupa yang merujuk kembali ke utas ini. Jalankan perubahan yang diminta ke modul brcmfmac untuk mengaktifkan debugging. Apakah pemicu kegagalan dan menangkap output dmesg:
dmesg_debug_failed.txt
Juga, saya perhatikan menyebutkan ponsel Samsung di utas lainnya juga. Kami telah memperhatikan bahwa masalah jembatan dengan Pi saya tampaknya berputar di sekitar Samsung Galaxy S7 saya. Perangkat Apple istri saya (iPhone dan iPad) tampaknya tidak memicu masalah.

EDIT4: Menjalankan sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000 Diikuti oleh dmesg lagi. Output di bawah ini:
dmesg_debug_failed_reset_driver.txt

Hmm, bukan kesalahan kotak surat yang diharapkan. Saya akan meneruskannya ke pengembang Cypress di tahun baru.

Tidak yakin apakah ini masalah yang sama, tetapi gejala saya adalah nirkabel RPi3 onboard yang terputus-putus; 10 detik ping yang bagus, diikuti dengan 20-30 detik tanpa ping, dan ulangi selamanya. Jika tidak ada ping, host jarak jauh menerima permintaan gema ICMP dan mengirim balasan gema ICMP. Titik akses mengembalikan host ICMP yang tidak dapat dijangkau oleh host jarak jauh.

Prasyarat adalah ethernet dan nirkabel terhubung. Peluang terjadinya hal itu meningkat pesat dengan memulai ulang dhcpcd .

Solusinya adalah mengatur antarmuka jaringan ke mode promiscuous; sudo ifconfig wlan0 promisc . Gejala kembali dalam sepuluh detik ke satu menit sudo ifconfig wlan0 -promisc .

Informasi lebih lanjut tersedia jika diperlukan, tanyakan saja.

@ Sylver-Dragon, bagi saya tcpdump mencegah gejala tersebut, dan mungkin Anda menemukan hal yang sama; coba -p flag, yang mematikan mode promiscuous; itu membiarkan gejala berlanjut.

https://github.com/iiab/iiab/issues/638

@quozl Saya sudah mencoba menjalankan tcpdump pada antarmuka nirkabel dan antarmuka bridge dan mengalami kemacetan saat sedang berjalan. Saya akan mencoba mode promiscuous dan melihat apakah itu membuat perbedaan. Padahal, berdasarkan keluaran debug dari driver antarmuka nirkabel, secara khusus:
wl0: _wlc_bss_update_beacon: dari mem, 0 byte malloced
Saya menduga ini adalah semacam kebocoran sumber daya (memori?) Di pihak pengemudi. Ketika saya memiliki sedikit lebih banyak waktu, saya ingin melakukan pengambilan paket dan menggali saat paket itu terkunci. Saya menduga ponsel saya mengirim semacam paket aneh atau cacat atau serangkaian paket ke perangkat yang memicu penguncian. Jika saya dapat menangkap dan mengisolasi itu, itu akan membantu menginformasikan perbaikan.

Sepertinya ada kesalahan berbeda pada masalah kotak surat yang saat ini kami lacak. Itu menyebalkan. Apakah ponsel Anda Samsung BTW? Masalah kotak surat tampaknya lebih sering dipicu oleh perangkat SS. Jika Anda dapat melacak apa yang pernah menyebabkan masalah, itu akan sangat berguna

Saya berburu yang sama (?) Selama berminggu-minggu sekarang. Saya merasa saya harus membaca setiap laporan tentang ini dan masalah serupa. Berikut beberapa info lagi dari saya:

Saya menggunakan wifi internal dari raspberry pi 3 sebagai jalur akses. Saya menggunakan kernel dan modul raspbian standar (Linux versi 4.9.35-v7 + (dc4 @ dc4-XPS13-9333) (gcc versi 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) # 1014 SMP Jum 30 Jun 14:47:43 BST 2017).

Firmware Wifi adalah: brcmfmac: Versi firmware = wl0: 7 Agustus 2017 00:46:29 versi 7.45.41.46 (r666254 CY) FWID 01-f8a78378

Saya cukup yakin bahwa pengaturan perangkat keras ini dulu berfungsi, tetapi setelah beberapa pembaruan (juga dari kernel) saya yakin, semuanya berjalan ke selatan. Membuat AP berfungsi dengan baik, tetapi setelah menggunakannya untuk beberapa waktu (30 menit atau lebih, tidak sama setiap kali saya pikir), streaming menggunakan Chromecast, koneksi berhenti berfungsi. Bisa jadi (tetapi di sini saya tidak yakin) bahwa ini paling sering terjadi ketika saya menjeda / menghentikan streaming, tetapi jarang terjadi di tengah-tengah menonton. Ketika gagal, koneksi yang ada diputus dan upaya koneksi baru tidak diterima oleh klien mana pun. Memuat ulang hasil hostapd di brcmf_cfg80211_stop_ap: setting INFRA mode failed -7 (tidak dapat menyetel mode ke master). Ini dapat diperbaiki sementara dengan memuat ulang driver: rmmod brcmfmac; modprobe brcmfmac . Hal-hal kemudian bekerja seperti yang diharapkan lagi sampai gagal di lain waktu. Cara lainnya, reboot "memperbaiki" masalah juga.

Satu-satunya hal yang saya dapatkan dalam keadaan gagal (dengan debug yang diaktifkan) di syslog adalah:

kernel: [3615.491795] brcmfmac: brcmf_netdev_wait_pend8021x: Waktu habis menunggu tidak ada paket 802.1x yang tertunda
hostapd: wlan0: STA xx: xx: xx: xx: xx: xx IEEE 802.11: dibatalkan autentikasi karena permintaan pembatalan autentikasi lokal

Pesan kesalahan itu tidak masuk akal bagi saya. Ini adalah waktu habis sambil menunggu 'untuk tidak ada paket yang tertunda'? Bagaimanapun:

Saya memiliki power save off:

iw wlan0 get power_save Power save: off

roam_off disetel ke 1 dan debug diaktifkan:

`systool -a -v -m brcmfmac
Modul = "brcmfmac"

Atribut:
coresize = "222874"
initsize = "0"
initstate = "live"
refcnt = "0"
srcversion = "10E8F4629D109E78E1F506C"
noda = ""
acara =

Parameter:
alternative_fw_path =
debug = "1048576"
roamoff = "1"
`

Saya tidak memiliki ponsel Samsung, tetapi beberapa Android. Tak satu pun dari ini terhubung ke titik akses itu. Klien langsung hanya dua Chromecast (satu video, satu audio saja, plus Tablet Android). Segala sesuatu yang lain masuk melalui antarmuka kabel.

@knarr
Silakan cari halaman ini untuk komentar saya sebelumnya dari 3 minggu yang lalu untuk mendapatkan solusi yang baik.

@Jamal_jogja
Tidak pernah mendapat ack dari Anda. Apakah Anda menyalin / menyampaikan keluaran dmesg yang saya bagikan dari komentar itu 3 minggu yang lalu kepada teman-teman Cypress?

@randyoo : Saya memiliki "rsn_pairwise = CCMP" dan "wpa = 2" di hostapd.conf saya. Tidak membantu dalam kasus saya. Entri non-rahasia dari file saya:
`
antarmuka = ​​wlan0

driver = nl80211
ssid = XXX
hw_mode = g
saluran = 1
ieee80211n = 0
wmm_enabled = 1
ht_capab = [HT40] [RINGKAS-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
`

Juga menjadi jelas bahwa kegagalan sepertinya selalu terjadi pada saya ketika saya mencoba menjeda streaming netflix ke Chromecast (yang tidak berarti selalu gagal ketika saya mencoba ini, hanya saja setiap kali gagal, itulah yang saya lakukan ). Di sisi lain, ini mungkin red herring, karena inilah yang saya lakukan hampir sepanjang waktu dengan jaringan wifi itu. Mungkin saja masalahnya terjadi hanya ketika perangkat mencoba mengautentikasi ke AP (seperti tablet android yang kemungkinan menonaktifkan wifi saat tidur). Lebih banyak pengujian akan ditampilkan. Saya akan mencoba tanpa Chromecast - hanya wifi biasa di tablet, termasuk siklus wifi-sleep.

Sepertinya masalah saya tidak sama dengan masalah ini, jadi saya akan beralih ke mode lurk. ifconfig wlan0 promisc berhasil memperbaikinya untuk @holta (https://github.com/iiab/iiab/issues/638), tetapi tanpa membantu orang lain, kita harus melihat masalah yang berbeda.

Saya dapat mereproduksi ini dengan andal tanpa Netflix atau Chromecast dengan menyambungkan ke jaringan melalui tablet Google, lalu membiarkan tablet tidur, melanjutkan (tablet mencoba menghubungkan kembali), dan pada saat itu AP "mati".

Di mesin Linux, saya mendapatkan ini di syslog ketika mencoba mengasosiasikan (menggunakan kredensial yang benar):

`

[42231.476518] wlan7: kirim auth ke b8: 27: eb: 33: 98: 14 (coba 1/3)
[42231.583434] wlan7: kirim auth ke b8: 27: eb: 33: 98: 14 (coba 2/3)
[42231.694397] wlan7: kirim auth ke b8: 27: eb: 33: 98: 14 (coba 3/3)
[42231.799368] wlan7: otentikasi dengan b8: 27: eb: 33: 98: 14 waktu habis
[42236.585750] wlan7: otentikasi dengan b8: 27: eb: 33: 98: 14
[42236.598833] wlan7: kirim auth ke b8: 27: eb: 33: 98: 14 (coba 1/3)
[42236.602344] wlan7: dikonfirmasi
[42236.603480] wlan7: diasosiasikan dengan b8: 27: eb: 33: 98: 14 (coba 1/3)
[42236.619322] wlan7: RX AssocResp dari b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 bantuan = 1)
[42236.623181] wlan7: terkait
[42236.623325] IPv6: ADDRCONF (NETDEV_CHANGE): wlan7: tautan menjadi siap
[42236.625464] wlan7: Membatasi daya TX hingga 30 (30 - 0) dBm seperti yang diiklankan oleh b8: 27: eb: 33: 98: 14
[42239.730365] wlan7: dibatalkan autentikasi dari b8: 27: eb: 33: 98: 14 (Alasan: 2 = PREV_AUTH_NOT_VALID)
[42241.243434] wlan7: otentikasi dengan b8: 27: eb: 33: 98: 14
[42241.256326] wlan7: kirim auth ke b8: 27: eb: 33: 98: 14 (coba 1/3)
[42241.260724] wlan7: dikonfirmasi
[42241.263403] wlan7: diasosiasikan dengan b8: 27: eb: 33: 98: 14 (coba 1/3)
[42241.279537] wlan7: RX AssocResp dari b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 bantuan = 1)
[42241.282500] wlan7: terkait
[42241.336166] wlan7: Membatasi daya TX hingga 30 (30 - 0) dBm seperti yang diiklankan oleh b8: 27: eb: 33: 98: 14
[42244.392213] wlan7: dibatalkan autentikasi dari b8: 27: eb: 33: 98: 14 (Alasan: 2 = PREV_AUTH_NOT_VALID)
[42253.916626] wlan7: otentikasi dengan b8: 27: eb: 33: 98: 14
[42253.928966] wlan7: kirim auth ke b8: 27: eb: 33: 98: 14 (coba 1/3)
[42253.936020] wlan7: dikonfirmasi
[42253.939533] wlan7: diasosiasikan dengan b8: 27: eb: 33: 98: 14 (coba 1/3)
[42253.943361] wlan7: RX AssocResp dari b8: 27: eb: 33: 98: 14 (capab = 0x411 status = 0 bantuan = 2)
[42253.945415] wlan7: terkait
[42254.035149] wlan7: Membatasi daya TX hingga 30 (30 - 0) dBm seperti yang diiklankan oleh b8: 27: eb: 33: 98: 14
[42257.053762] wlan7: deauthenticated dari b8: 27: eb: 33: 98: 14 (Alasan: 2 = PREV_AUTH_NOT_VALID)
`

b8: 27: eb: 33: 98: 14 adalah RPI3 yang dimaksud, yang lagi-lagi saya dapatkan dmesg-entriesnya:
brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets

Saya tidak begitu mengerti mengapa AP mengirim PREV_AUTH_NOT_VALID sementara saya tampaknya terkait. Saya mendapat kesan bahwa otentikasi datang sebelum asosiasi. Seharusnya tidak ada kasus di mana saya terkait tetapi tidak diautentikasi.

Hai

Saya menggunakan Pi3 sebagai server media, komunikasi melalui WiFi on-board

Pembaruan peningkatan Rasbian Stretch Lite 4.9 (sekarang)
Server Media Plex

Saya mendapatkan ...

kernel: [1958.899715] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012

di dmesg dan syslog saat menghubungkan ke Pi menggunakan klien BubbleUPnp pada Samsung S5 SM_G900F Android 7.1.2 ini cukup terjamin dan memerlukan reboot agar PiWiFi dapat digunakan kembali.

Di Sony Xperia XP Android 6.0.1 lama saya lagi menjalankan BubbleUPnp, sejauh ini berfungsi dengan baik. Ini solusi saya. Namun, jika saya dapat membantu menyelesaikan masalah ini, saya akan dengan senang hati berkontribusi.

John

Ini juga berfungsi di iPad yang menjalankan mConnectLite

@johnthesoftwareathome Silakan tulis email ke James Hughes dari Raspberry Pi sehingga dia dapat mengirimi Anda firmware debug Wifi.

Alamat email diposting melalui halaman kontak Raspberry Pi fao James Hughes

Oke, kami memiliki firmware debug baru dari Cypress yang akan saya uji - ini memiliki lebih banyak debug di dalamnya, tetapi bukan perbaikan, jadi hanya untuk mereka yang senang untuk menguji. Jika Anda telah mengirimi saya alamat email Anda, tunjukkan di sini bahwa Anda ingin melakukan beberapa pengujian dan saya akan mengirimkan firmware, atau hubungi saya melalui PM di forum Pi.

Untuk menyelamatkan orang-orang yang sedang mencari cara untuk menginstal / menjalankan firmware baru.

Salin file firmware debug ke:

/lib/firmware/brcm/

(Anda ingin mencadangkan aslinya terlebih dahulu)

Saya pikir Anda perlu melakukan boot ulang pada tahap ini.

Sekarang restart driver Linux dalam mode debug

sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000

Lakukan kesalahan .. !!

Buang dmesg ke file dan posting di sini.

Untuk menambahkan apa yang James katakan, Anda mungkin lebih suka menghindari urutan rmmod / modprobe dengan menambahkan brcmfmac.debug=0x100000 ke /boot/cmdline.txt .

@ JamesH65 Saya akan dengan senang hati membantu pengujian. Meskipun baru saja mendaftar di Forum Pi, saya tidak dapat mengirim pesan. Menggunakan nama pengguna yang sama di sana, jika itu membantu.

Saya sudah mencoba firmware debug baru kemarin dan juga menambahkan brcmfmac.debug = 0x100000 ke /boot/cmdline.txt.

Namun, anehnya saya tidak melihat output debug di dmesg. Yang lebih aneh lagi, di mana saya dapat dengan andal mereproduksi masalah sebelumnya, itu berhasil sepanjang malam terlepas dari apa yang saya lakukan. Saya tidak memiliki satu masalah pun, dan yang saya lakukan secara berbeda adalah menggunakan file firmware baru (md5 sum ba679a85c1dc76e9775603af45440bc0) alih-alih yang lama dan menambahkan entri ke /boot/cmdline.txt alih-alih menambahkan opsi menggunakan modprobe. Saya tidak punya waktu kemarin untuk kembali ke firmware lama untuk melihat apakah ini kembali ke masalah lama. Saya akan melaporkan kembali setelah saya melakukannya. Sementara itu: apakah semua yang diubah di firmware itu benar-benar "lebih debug"?

Saya pikir itu hanya debug, tetapi akan kembali ke Cypress dengan jelas
sesuatu yang lain telah berubah, Semoga dengan cara yang baik!

Pada 11 Januari 2018 pukul 06:48, Frank Löffler [email protected] menulis:

Saya sudah mencoba firmware debug baru kemarin dan juga menambahkan
brcmfmac.debug = 0x100000 ke /boot/cmdline.txt.

Namun, anehnya saya tidak melihat output debug di dmesg. Bahkan lebih
Anehnya, di mana saya dapat mereproduksi masalah sebelumnya dengan andal, itu berhasil
sepanjang malam terlepas dari apa yang saya lakukan. Saya tidak punya satu masalah, dan
semua yang saya lakukan adalah menggunakan file firmware baru (md5 sum
ba679a85c1dc76e9775603af45440bc0). Saya tidak punya waktu kemarin untuk pergi
kembali ke firmware lama untuk melihat apakah ini kembali ke masalah lama. Saya akan
laporkan kembali setelah saya melakukannya. Sementara itu: apakah semua yang berubah itu
firmware benar-benar "lebih debug"?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-356842102 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHam4jUgDCkSFxMXS-KW4axCLoPZhks5tJa6fgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Pengalaman saya mirip dengan @knarrf , tetapi saya memang melihat pesan debug di dmesg.

Sebelumnya Samsung S5 saya tidak dapat digunakan sebagai klien plexserver, tetapi ketika saya memuat firmware debug itu berfungsi (dengan, seperti yang saya katakan pesan debug di dmesg) jadi saya kembali ke biner asli saya (dicadangkan dan ukuran dicentang) dan masih berfungsi. Jadi saya sekarang menjalankan lagi dengan firmware debug (saya belum mencoba mod cmdline.txt, hanya rmmod / modprobe) dan telah mendengarkan beberapa jam musik tanpa kesalahan. Saya sudah mencoba mengaktifkan sebagian besar dari banyak perangkat WiFi yang saya sebarkan, tidak ada efek.

Saya akan mencoba ini selama beberapa hari untuk melihat apakah terjadi sesuatu kemudian muat ulang yang asli dan coba lagi. Saya mungkin belum mematikan Pi di antara reboot. Saya akan memastikan saya melakukan ini ketika saya kembali untuk melihat apakah itu mungkin semacam retensi daftar.

Malam ini saya mengunggah firmware lama (diambil dari gambar instalasi raspian; info lebih lanjut tentang versi yang saya gunakan di bawah), dan memuat ulang modul dengan itu (dan debug diaktifkan), saya bahkan mem-boot ulang di antaranya. Output singkat di dmesg mengkonfirmasi bahwa versi lama sekarang dimuat. Dan seperti halnya @johnthesoftwareathome , itu terus berfungsi sepanjang malam, meskipun melakukan hal-hal yang akan mematikan wifi beberapa kali di masa lalu.

Jadi, untuk saat ini tugas saya adalah mengembalikannya ke "tidak berfungsi" agar memiliki kesempatan untuk mengetahui apa yang sedang terjadi. Percobaan saya berikutnya, meskipun tidak hari ini lagi, akan melakukan hard reset (menghilangkan daya untuk beberapa waktu daripada hanya menggunakan perintah 'reboot'), dan menggunakan instalasi yang benar-benar baru dari gambar yang baru.

Selain itu, sayangnya saya tidak dapat mengesampingkan kemungkinan bahwa gambar yang mengalami kegagalan adalah versi yang berbeda, karena saya lupa membuat cadangan sebelum menimpanya dengan gambar debug. Mungkin @johnthesoftwareathome dapat memposting gambar persis yang dia gunakan dan punya / bermasalah dengan? Di sisi lain, saya saat itu hanya memperbarui firmware menggunakan paket standar, dan saya menginstal versi paket firmware-brcm80211 (1: 0.43 + rpi6). Meskipun entri terakhir di changelog tidak menentukan versi firmware, entri kedua dari terakhir menentukan: 7.45.41.26, yang lebih lama dari yang ada pada gambar. Dengan asumsi changelog ditulis dengan benar, itu akan menjadi indikasi kuat bahwa firmware tidak diganti sejak gambar dibuat, dan yang saya sebut 'gambar' adalah yang saya gunakan sebelumnya.

Informasi tentang dua file firmware saya (gambar: yang dari gambar instalasi raspbian, debug: yang saya terima langsung dari @ JamesH65 :

debug:
Versi firmware = wl0: 23 Okt 2017 03:55:53 versi 7.45.98.38 (r674442 CY) FWID 01-e58d219f
md5sum: ba679a85c1dc76e9775603af45440bc0
gambar:
Versi firmware = wl0: 7 Agustus 2017 00:46:29 versi 7.45.41.46 (r666254 CY) FWID 01-f8a78378
md5sum: 5f520a38ab4e943bfa1ba102f80fb2a0

@johnthesoftwareathome : seperti apa tampilan keluaran "debug" yang baru? Saya masih tidak mendapatkan apa pun yang bahkan dari jarak jauh terlihat seperti debug ekstensif, terlepas dari bagaimana saya memuat modul. Saya mendapatkan nol entri saat operasi, dan bahkan setelah boot semua tampilan yang agak relevan adalah:

sebagai root: dmesg | grep brcm
[0,000000] Baris perintah kernel: 8250.nr_uarts = 0 bcm2708_fb.fbwidth = 640 bcm2708_fb.fbheight = 480 bcm2708_fb.fbdepth = 16 bcm2708_fb.fbswap = 1 vc_mem.mem_base = 0wc_m_mem_base = 0wc300000 vc_mem0000consol = 0 vc_mf000000dtk , 115200 console = tty1 root = PARTUUID = f8e4f7c2-02 rootfstype = ext4 elevator = deadline fsck.repair = yes rootwait brcmfmac.debug = 0x100000
[3.500135] usbcore: terdaftar brcmfmac driver antarmuka baru
[3.662113] brcmfmac: Versi firmware = wl0: 7 Agustus 2017 00:46:29 versi 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[3.774278] brcmfmac: manajemen daya dinonaktifkan
[4.711443] brcmfmac: manajemen daya dinonaktifkan

Pembaruan kecil: melihat kembali salah satu komentar lama saya di utas ini, saya benar-benar dapat mengonfirmasi bahwa firmware lama yang saya gunakan hari ini ('gambar') adalah salah satu yang bermasalah dengan saya hanya sampai saya mencoba gambar debug yang lebih baru.

Rumah kosong, jadi akhirnya sempat mendengarkan album terakhir Bowie. Semuanya bekerja dengan sempurna (albumnya tidak begitu). Jauh dari rumah sampai besok, aku akan mengambilnya nanti.

Berhasil membuat firmware asli gagal seperti sebelumnya tetapi tidak dapat diandalkan antara menggunakannya dan firmware debug. Saat ini baru saja me-reboot dengan hal-hal debug tanpa kegagalan.

Saya salah mengerti apa yang dimaksud @knarrf tentang keluaran debug dan berasumsi bahwa dia tidak dapat melihat bahwa firmware baru telah diinstal daripada berarti dia mengharapkan semacam aliran debug (yang juga tidak dapat saya lihat). Dia ada benarnya. Jika ini gagal, akankah kita melihat sesuatu atau apakah hex debug salah?

Juga salah satu kegagalan tidak langsung hilang. Itu memungkinkan saya untuk ssh kembali sebelum perlu reboot. Syslog berisi berikut ini ..

13 Jan 08:34:48 kernel plexServer: [46.648630] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
13 Jan 08:35:14 kernel plexServer: [72.161473] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
13 Jan 08:35:14 kernel plexServer: [72.161484] brcmfmac: brcmf_cfg80211_get_channel: chanspec gagal (-110)

Itu adalah sekumpulan pesan kesalahan yang sangat familiar, tetapi tetap berguna untuk mengetahui bahwa Anda mengalami masalah yang sama yang tampaknya mungkin sudah diperbaiki.

Cypress sedang mempersiapkan rilis firmware baru untuk kami - kami akan memposting di sini ketika sesuatu tersedia untuk pengujian. Terima kasih semuanya atas minat, waktu, dan kesabaran Anda.

Baik. Terima kasih untuk pengemudi yang bekerja.

Hal-hal mungkin telah berubah sejak ini ..

https://tech4research.wordpress.com/2014/07/23/brcmfmac-debugging-and-appatible-debug-values/

dan saya menghargai bahwa sakelar debug untuk firmware baru mungkin merupakan tambahan khusus tetapi sakelar ini tampaknya berfungsi untuk firmware asli dan 'debug' dan aliran debug yang diharapkan dimuntahkan.

Mungkin sudah terlihat; tetapi, TPLink mengklaim bahwa perangkat android sedang melakukan perangkat mereka dengan paket MDNS saat mereka bangun dari tidur dan mencoba menyambungkan kembali dengan Chromecast atau perangkat serupa.
Menggali pcap yang saya dapatkan dari putuskan sambungan perangkat saya sendiri, saya dapat melihat ~ 3.500 paket MDNS masuk lebih dari ~ 2,25 detik tepat sebelum koneksi saya mati. Tampaknya cocok dengan pola ini dan mungkin terkait.

Hanya untuk menambahkan / mengkonfirmasi beberapa info dalam masalah ini:

• Mengatur antarmuka wifi ke promiscuous ( ifconfig wlan0 promisc ) tampaknya mengurangi masalah
• Masalahnya tampaknya hanya disebabkan oleh ponsel Android 7.1.2 Galaxy S7 saya (yang saya dapatkan seminggu yang lalu dan inilah saat masalah dimulai)

Saya menjalankan Debian Buster dengan aarch64 di Pi3 saya dan menjalankan server Nextcloud di atasnya. scp'ing file yang lebih besar dari laptop Linux tidak menyebabkan masalah apa pun, begitu pula Nextcloud tidak disinkronkan dari laptop itu, tetapi segera setelah saya mengunggah sekumpulan file dari Galaxy, kesalahan Unknown mailbox data content: 0x40012 akan muncul dan konektivitas Wifi kalah.

Firmware brcmfmac yang saya gunakan adalah 7.45.41.26 (r640327) FWID 01-4527cfab

Sayangnya saya tidak memiliki Android yang lebih lama untuk diuji.

Saya tcpdumped unggahan dari Samsung ke Pi3, tapi kemudian Wifi dalam mode promiscuous dan semuanya bekerja dengan baik. Jika saya menemukan waktu, saya akan melihat pcap dan melaporkan kembali jika saya menemukan sesuatu yang berguna / menarik.

PS: Cast (pelaku utama yang dijelaskan dalam artikel TPLink) tidak aktif (atau setidaknya saya tidak dapat melihatnya di pengaturan konektivitas).

Hai semuanya,

Saya hanya ingin mengonfirmasi bahwa mematikan mode hemat daya dan mengaktifkan mode promiscuis memperbaiki masalah untuk saya: untuk pertama kalinya ia berhasil tetap terhubung selama 24 jam.

sudo iw wlan0 matikan power_save
sudo ifconfig wlan0 promisc

Terima kasih,
Luc

Silakan lihat posting forum ini untuk rincian tentang rilis firmware baru. Siapa pun yang melihat masalah kotak surat, atau memang masalah nirkabel apa pun, harus mencoba ini untuk melihat apakah ini membantu.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508

@Jamal_jogja
Hai James,
Dapatkah Anda memberikan beberapa petunjuk penginstalan, apakah file .bin dalam arsip dapat dijalankan secara mandiri?
Terima kasih
Lee

Instruksi sekarang ada di halaman forum tertaut.

Memeriksa kembali setelah menjalankan firmware baru selama lebih dari seminggu. Sejauh ini solid. Saya telah berulang kali membangunkan perangkat Samsung saya setelah waktu yang lama dan antarmuka nirkabel di Pi saya terus berjalan. Saya percaya bahwa saya memiliki satu contoh di mana itu turun sementara dan kemudian pulih; meskipun, saya belum dapat mereproduksinya. Secara keseluruhan, ini terlihat kokoh. Terima kasih untuk James yang bertahan dengan ini dan untuk tim Cypress yang telah memperbaikinya.

Terima kasih atas laporannya.

Adakah yang bisa memberi tahu saya jika perbaikan firmware sudah berhasil di distribusi Raspbian resmi sehingga dapat diinstal melalui apt update atau jika belum, beri tahu saya setelah itu terjadi?

Dapatkah seseorang memberi tahu saya jika perbaikan firmware telah berhasil di distribusi Raspbian resmi sehingga dapat diinstal melalui pembaruan apt atau jika belum, beri tahu saya setelah itu terjadi?

Iya. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508&start=25#p1270212
Beberapa masalah dilaporkan pada Pi0W setelah umumnya memperbarui, tetapi tidak sepenuhnya jelas apakah itu hanya perubahan firmware atau sesuatu yang lain - https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=204882

Saya telah memperbarui firmware

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.bin
ba679a85c1dc76e9775603af45440bc0  /lib/firmware/brcm/brcmfmac43430-sdio.bin

tetapi masih memiliki masalah yang sama

$ 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

Hal berikut juga tidak menghindari masalah ini

sudo iw wlan0 set power_save off
sudo ifconfig wlan0 promisc

Saya menggunakan RPi3 sebagai titik akses dengan hostapd dan dnsmasq .
Saya selalu dapat mereproduksi masalah saat memulai pengunduhan di aplikasi Spotify di ponsel Android saya.

Apakah saya juga perlu memperbarui file berikut?

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.txt
9a88b55134d9f8f3ad2331b93f4b7b79  /lib/firmware/brcm/brcmfmac43430-sdio.txt

Apakah akan digunakan oleh pengemudi atau dapatkah diabaikan?

Edit:
Iya. Brcmfmac43430-sdio.txt juga diperlukan.
Tetapi saya menggunakan versi terhebat terbaru dari https://github.com/RPi-Distro/firmware-nonfree/tree/927fa8ebdf5bcfb90944465b40ec4981e01d6015/brcm

Saya juga telah memperbarui kernel 4.9.35-v7 + saya menjadi 4.14.18-v7 +.
Tapi masalahnya masih ada.

Mengalami masalah yang sama pada RPi3 saya: Wifi terputus setelah beberapa waktu aktif (misalnya selama malam) dengan hampir tidak ada lalu lintas.
keluaran dmesg hanya menunjukkan:

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

Saya mencoba memuat ulang driver (rmmod & modprobe brcmfmac):

[  +0,100025] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -5
[  +0,000014] brcmfmac: brcmf_cfg80211_get_tx_power: error (-5)
[  +0,519934] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[  +0,000050] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[  +0,000672] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[  +0,000012] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-5)
[  +0,221254] usbcore: deregistering interface driver brcmfmac
[Mär12 21:18] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[  +0,010071] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001
[  +0,000285] usbcore: registered new interface driver brcmfmac
[  +2,649115] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[  +0,005807] brcmfmac: brcmf_c_get_clm_name: retrieving revision info failed (-110)
[  +0,000010] brcmfmac: brcmf_c_process_clm_blob: get CLM blob file name failed (-110)
[  +0,000008] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file failed, -110
[  +0,000007] brcmfmac: brcmf_bus_started: failed: -110
[  +0,000021] brcmfmac: brcmf_sdio_firmware_callback: dongle is not responding

Itu entah bagaimana tidak berhasil - driver dimuat tetapi tidak, saya tidak punya antarmuka
Mencoba lagi:

[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

..dan aku bangun lagi.

Pi3 menjalankan kernel '4.14.24-v7 + # 1097' - firmware adalah yang lebih lama dari 7 Agustus 2017 - gumpalan firmware yang sama yang bekerja dengan sempurna (waktu aktif> 2 bulan) pada Pi Zero W menjalankan kernel '4.9.77+ # 1081'
Kedua Pis terhubung ke router yang sama & ruang terpisah. Keduanya terhubung melalui WiFi saja.

Mungkin layak menggunakan firmware terbaru pada 4.14, karena 4.14 memiliki semua perubahan yang diperlukan untuk bekerja dengan firmware itu.

:) Diperbarui ke fw terbaru (23 Okt 2017 03:55:53 versi 7.45.98.38) kemarin setelah memposting - tampaknya berfungsi atm - mari kita lihat apa yang terjadi ..

Tampaknya raspbian kembali ke paket firmware Agustus 2017. Apakah ada persyaratan baru untuk nirkabel rpi 3B +?

Firmware stretch repo Foundation terbaru rpt3 memiliki versi firmware 23 Oktober 2017 7.45.98.38 untuk Pi3 / Pi0W dan paket lain yang sesuai untuk Pi3 +

Saya juga mendapat masalah dengan wifi sekarat.

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

Ini dengan 4.14.27-v7 + dan dengan
/ sbin / iw dev wlan0 matikan power_save
/ sbin / ifconfig wlan0 promisc
di /etc/rc.local.

pesan kesalahan yang sama seperti @ flok99 - menggunakan firmware terbaru (rpi-update).

Oke, jadi bug yang menurut kami telah diperbaiki Cypress masih ada. Kembali ke
Cypress. Butuh waktu setahun untuk mendapatkan versi ini. Tidak menahan nafas
direkomendasikan.

Namun, harus mengonfirmasi versinya, harap posting konten

dmesg | grep brcmfmac.dll

Pada 18 Maret 2018 pukul 01:44, Rebroad [email protected] menulis:

pesan kesalahan yang sama seperti @ flok99 https://github.com/flok99 - menggunakan terbaru
firmware (update-rpi) pada peregangan.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373966343 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHY1Cmntz_kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

[4.112717] brcmfmac: Tanda tangan F1 terbaca @ 0x18000000 = 0x15264345
[4.119827] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan
brcm / brcmfmac43455-sdio.bin untuk chip 0x004345 (17221) rev 0x000006
[4.120314] usbcore: terdaftar brcmfmac driver antarmuka baru
[4.440371] brcmfmac: brcmf_c_preinit_dcmds: Versi firmware = wl0: Feb
27 2018 03:15:32 versi 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[4.440958] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2
Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Pembuatan: 2018-03-09
18:56:28
[10.911757] brcmfmac: manajemen daya dinonaktifkan
[12.016088] brcmfmac: manajemen daya dinonaktifkan
[2074.090674] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
gagal dengan status -5
[2074.090687] brcmfmac: brcmf_cfg80211_get_tx_power: kesalahan (-5)
[2074.090745] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[2074.090753] brcmfmac: brcmf_link_down: WLC_DISASSOC gagal (-5)
[2074.610583] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[2074.611992] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[2074.613945] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[2074.613971] brcmfmac: brcmf_cfg80211_get_channel: chanspec gagal (-5)
[2074.729716] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[2074.729733] brcmfmac: brcmf_cfg80211_reg_notifier: Kode negara iovar
mengembalikan err = -5
[2074.871693] usbcore: membatalkan pendaftaran driver antarmuka brcmfmac
[2074.929084] brcmfmac: Tanda tangan F1 terbaca @ 0x18000000 = 0x15264345
[2074.936897] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan
brcm / brcmfmac43455-sdio.bin untuk chip 0x004345 (17221) rev 0x000006
[2074.937139] usbcore: terdaftar brcmfmac driver antarmuka baru
[2075.118180] brcmfmac: brcmf_c_preinit_dcmds: Versi firmware = wl0: Feb
27 2018 03:15:32 versi 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2075.118706] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2
Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Pembuatan: 2018-03-09
18:56:28
[2075.215365] brcmfmac: manajemen daya dinonaktifkan
[2075.263751] brcmfmac: manajemen daya dinonaktifkan
[2085.475001] brcmfmac: manajemen daya dinonaktifkan
[2124.380808] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[2124.381146] brcmfmac: brcmf_fil_cmd_data: bus sedang down. kami tidak punya apa-apa
melakukan.
[2124.381156] brcmfmac: brcmf_cfg80211_get_channel: chanspec gagal (-5)
[2124.622345] usbcore: membatalkan pendaftaran driver antarmuka brcmfmac
[2124.705432] brcmfmac: tanda tangan F1 terbaca @ 0x18000000 = 0x15264345
[2124.714194] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan
brcm / brcmfmac43455-sdio.bin untuk chip 0x004345 (17221) rev 0x000006
[2124.716213] usbcore: terdaftar brcmfmac driver antarmuka baru
[2124.929556] brcmfmac: brcmf_c_preinit_dcmds: Versi firmware = wl0: Feb
27 2018 03:15:32 versi 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2124.929993] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2
Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Pembuatan: 2018-03-09
18:56:28
[2125.105218] brcmfmac: manajemen daya dinonaktifkan
[2125.150290] brcmfmac: manajemen daya dinonaktifkan
[8237.434034] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui:
0x40012
[8239.890302] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[8239.890822] brcmfmac: brcmf_sdio_checkdied: firmware trap di dongle
[8239.890835] brcmfmac: brcmf_run_escan: error (-110)
[8239.890845] brcmfmac: brcmf_cfg80211_scan: kesalahan pemindaian (-110)
[8254.280425] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
gagal dengan status -5
[8254.280438] brcmfmac: brcmf_cfg80211_get_tx_power: error (-5)
[8254.280491] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[8254.280498] brcmfmac: brcmf_link_down: WLC_DISASSOC gagal (-5)
[8254.800394] brcmfmac: brcmf_fil_cmd_data: bus sedang down. kami tidak punya apa-apa
melakukan.
[8254.803873] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[8254.808353] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[8254.808370] brcmfmac: brcmf_cfg80211_get_channel: chanspec gagal (-5)
[8254.881402] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[8254.881420] brcmfmac: brcmf_cfg80211_reg_notifier: Kode negara iovar
mengembalikan err = -5
[8255.001550] usbcore: membatalkan pendaftaran driver antarmuka brcmfmac
[8255.071184] brcmfmac: Tanda tangan F1 terbaca @ 0x18000000 = 0x15264345
[8255.077098] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan
brcm / brcmfmac43455-sdio.bin untuk chip 0x004345 (17221) rev 0x000006
[8255.077348] usbcore: terdaftar driver antarmuka baru brcmfmac
[8257.730418] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[8257.751038] brcmfmac: brcmf_c_get_clm_name: mengambil info revisi
gagal (-110)
[8257.751049] brcmfmac: brcmf_c_process_clm_blob: dapatkan nama file blob CLM
gagal (-110)
[8257.751068] brcmfmac: brcmf_c_preinit_dcmds: unduh file blob CLM
gagal, -110
[8257.751076] brcmfmac: brcmf_bus_started: gagal: -110
[8257.751114] brcmfmac: brcmf_sdio_firmware_callback: dongle tidak
menanggapi
[8304.417684] usbcore: membatalkan pendaftaran driver antarmuka brcmfmac
[8304.486099] brcmfmac: Tanda tangan F1 terbaca @ 0x18000000 = 0x15264345
[8304.493613] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan
brcm / brcmfmac43455-sdio.bin untuk chip 0x004345 (17221) rev 0x000006
[8304.494078] usbcore: terdaftar brcmfmac driver antarmuka baru
[8304.686761] brcmfmac: brcmf_c_preinit_dcmds: Versi firmware = wl0: Feb
27 2018 03:15:32 versi 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8304.687203] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2
Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Pembuatan: 2018-03-09
18:56:28
[8304.829994] brcmfmac: manajemen daya dinonaktifkan
[8304.907662] brcmfmac: manajemen daya dinonaktifkan
[8357.441791] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui:
0x40012
[8359.891146] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[8359.891655] brcmfmac: brcmf_sdio_checkdied: firmware trap di dongle
[8359.891668] brcmfmac: brcmf_run_escan: error (-110)
[8359.891677] brcmfmac: brcmf_cfg80211_scan: kesalahan pemindaian (-110)
[8371.731226] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[8371.731731] brcmfmac: brcmf_sdio_checkdied: firmware trap di dongle
[8371.731746] brcmfmac: brcmf_cfg80211_get_channel: chanspec gagal (-110)
[8373.941267] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
gagal dengan status -5
[8373.941280] brcmfmac: brcmf_cfg80211_get_tx_power: error (-5)
[8373.941330] brcmfmac: brcmf_fil_cmd_data: bus sedang down. kami tidak punya apa-apa
melakukan.
[8373.941338] brcmfmac: brcmf_link_down: WLC_DISASSOC gagal (-5)
[8374.461245] brcmfmac: brcmf_fil_cmd_data: bus sedang down. kami tidak punya apa-apa
melakukan.
[8374.461942] brcmfmac: brcmf_fil_cmd_data: bus sedang down. kami tidak punya apa-apa
melakukan.
[8374.463553] brcmfmac: brcmf_fil_cmd_data: bus sedang down. kami tidak punya apa-apa
melakukan.
[8374.463573] brcmfmac: brcmf_cfg80211_get_channel: chanspec gagal (-5)
[8374.564729] brcmfmac: brcmf_fil_cmd_data: bus rusak. kami tidak punya apa-apa
melakukan.
[8374.564750] brcmfmac: brcmf_cfg80211_reg_notifier: Kode negara iovar
mengembalikan err = -5
[8374.702401] usbcore: membatalkan pendaftaran driver antarmuka brcmfmac
[8374.759839] brcmfmac: Tanda tangan F1 terbaca @ 0x18000000 = 0x15264345
[8374.767561] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan
brcm / brcmfmac43455-sdio.bin untuk chip 0x004345 (17221) rev 0x000006
[8374.771137] usbcore: terdaftar brcmfmac driver antarmuka baru
[8377.411255] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[8377.431924] brcmfmac: brcmf_c_get_clm_name: mengambil info revisi
gagal (-110)
[8377.431934] brcmfmac: brcmf_c_process_clm_blob: dapatkan nama file blob CLM
gagal (-110)
[8377.431941] brcmfmac: brcmf_c_preinit_dcmds: unduh file blob CLM
gagal, -110
[8377.431949] brcmfmac: brcmf_bus_started: gagal: -110
[8377.432003] brcmfmac: brcmf_sdio_firmware_callback: dongle tidak
menanggapi
[8424.133114] usbcore: membatalkan pendaftaran driver antarmuka brcmfmac
[8424.229631] brcmfmac: tanda tangan F1 terbaca @ 0x18000000 = 0x15264345
[8424.237210] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan
brcm / brcmfmac43455-sdio.bin untuk chip 0x004345 (17221) rev 0x000006
[8424.239352] usbcore: terdaftar brcmfmac driver antarmuka baru
[8424.460736] brcmfmac: brcmf_c_preinit_dcmds: Versi firmware = wl0: Feb
27 2018 03:15:32 versi 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8424.461174] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2
Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Pembuatan: 2018-03-09
18:56:28
[8424.646993] brcmfmac: manajemen daya dinonaktifkan
[8424.708633] brcmfmac: manajemen daya dinonaktifkan

Pada hari Minggu, 18 Mar 2018 pukul 11:30, James Hughes [email protected]
menulis:

Oke, jadi bug yang menurut kami telah diperbaiki Cypress masih ada. Kembali ke
Cypress. Butuh waktu setahun untuk mendapatkan versi ini. Tidak menahan nafas
direkomendasikan.

Namun, harus mengonfirmasi versinya, harap posting konten

dmesg | grep brcmfmac.dll

Pada 18 Maret 2018 pukul 01:44, Rebroad [email protected] menulis:

pesan kesalahan yang sama seperti @ flok99 https://github.com/flok99 - menggunakan
terbaru
firmware (update-rpi) pada peregangan.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -373966343
,
atau nonaktifkan utasnya
kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5>
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373987387 ,
atau nonaktifkan utasnya
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

@ flok

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 

Sepertinya Anda menggunakan Pi3b + yang lebih baru dan bukan di Pi3 asli: jadi mungkin masalah yang berbeda?

Chip dan firmware yang sepenuhnya berbeda, meskipun driver samping Linux adalah
sama. (brcmfmac).

Pada 19 Maret 2018 pukul 16:26, macmpi [email protected] menulis:

@ flok99 https://github.com/flok99

brcmfmac: brcmf_fw_map_chip_to_name: menggunakan brcm / brcmfmac43455-sdio.bin untuk chip
Versi firmware = wl0: 27 Feb 2018 03:15:32 versi 7.45.154 (r684107 CY) FWID 01-4fbe0b04

Sepertinya Anda menggunakan Pi3b + yang lebih baru dan bukan di Pi3 asli: jadi
mungkin soal berbeda?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-374274045 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ADqrHeP6-sc-P-OSggQFPrl3O8z_B2aRks5tf9wbgaJpZM4HupC5
.

-
James Hughes
Insinyur Perangkat Lunak Utama,
Raspberry Pi (Perdagangan) Ltd

Saya pikir yang terbaik adalah memiliki utas lain untuk masalah Pi3B +, dan merujuk kembali ke utas ini jika diperlukan, jika tidak, akan sangat sulit untuk dilacak. Bisakah @ flok99 membuat masalah baru dengan laporannya, memastikan judulnya mengacu pada 3b +. Saya akan mengubah judul ini untuk mencerminkan hanya untuk Pi3B.

selesai

Apakah ada yang berlangganan masalah ini, menjalankan 3B (bukan plus), masih melihat masalah dengan firmware dan kernel terbaru? Ingin ada laporan tentang kegagalan yang berlanjut - posting terakhir tentang subjek di atas sepertinya menyiratkan bahwa semuanya sekarang berfungsi dengan baik.

3B saya naik sejak 44 hari dengan ini:

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

Tidak ada masalah sejak itu ..

Kabar baik. Kecuali saya mendengar sebaliknya, saya mungkin akan menutup utas ini dalam satu atau dua minggu, meskipun utas ini dapat dibuka kembali kapan saja jika masalah terulang kembali.

Saya mulai mengalami masalah ini sekitar seminggu yang lalu, karena belum pernah mendengarnya sebelumnya. Saya juga paling sering menggunakan pi dengan ponsel samsung sebagai router - milik saya adalah s4. Saya menulis ini terhubung langsung ke s4 dengan usb, yaitu menggunakan rndis. Berikut detail saya dari boot hari ini:
0 ditingkatkan, 0 baru dipasang, 0 untuk menghapus dan 0 tidak ditingkatkan.
thenry @ pi3portable : ~ $ dmesg | grep brcmfmac.dll
[9.965782] brcmfmac: Tanda tangan F1 terbaca @ 0x18000000 = 0x1541a9a6
[9.972059] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan brcm / brcmfmac43430-sdio.bin untuk chip 0x00a9a6 (43430) rev 0x000001
[9.972250] usbcore: terdaftar brcmfmac driver antarmuka baru
[10.147562] brcmfmac: brcmf_c_preinit_dcmds: Versi firmware = wl0: 7 Agustus 2017 00:46:29 versi 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.148507] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Pembuatan: 2014-05-26 10:53:55 Inc Data: 9.10.41 Inc Penyusun: 1.29 .4 Inc ClmImport: 1.36.3 Pembuatan: 2017-08-07 00:37:47
[18.538641] brcmfmac: manajemen daya dinonaktifkan
[30.629545] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
[33.191450] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[33.194850] brcmfmac: brcmf_sdio_checkdied: jebakan firmware dalam dongle
[35.751496] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[35.754898] brcmfmac: brcmf_sdio_checkdied: jebakan firmware dalam dongle
[35.754906] brcmfmac: brcmf_pno_clean: kode gagal -110
[43.271438] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[43.274800] brcmfmac: brcmf_sdio_checkdied: jebakan firmware dalam dongle
[43.274807] brcmfmac: brcmf_do_escan: error (-110)
[43.274811] brcmfmac: brcmf_cfg80211_scan: kesalahan pemindaian (-110)
[7673.758073] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[7673.761437] brcmfmac: brcmf_sdio_checkdied: jebakan firmware dalam dongle
[7673.761454] brcmfmac: _brcmf_set_multicast_list: Pengaturan mcast_list gagal, -110
[7676.328075] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[7676.331449] brcmfmac: brcmf_sdio_checkdied: perangkap firmware dalam dongle
[7676.331466] brcmfmac: _brcmf_set_multicast_list: Pengaturan allmulti gagal, -110
[7678.878084] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[7678.881460] brcmfmac: brcmf_sdio_checkdied: firmware trap di dongle
[7681.448101] brcmfmac: _brcmf_set_multicast_list: Pengaturan BRCMF_C_SET_PROMISC gagal, -110
[7689.118098] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
[7689.118241] brcmfmac: manajemen daya dinonaktifkan
[7691.678100] brcmfmac: brcmf_cfg80211_set_power_mgmt: error (-110)
[7694.238122] brcmfmac: _brcmf_set_multicast_list: Gagal menyetel mcast_list, -110
[7696.798118] brcmfmac: _brcmf_set_multicast_list: Pengaturan allmulti gagal, -110
[7699.358158] brcmfmac: brcmf_do_escan: error (-110)
[7699.358167] brcmfmac: brcmf_cfg80211_scan: kesalahan pemindaian (-110)
[7701.918127] brcmfmac: _brcmf_set_multicast_list: Pengaturan BRCMF_C_SET_PROMISC gagal, -110
[11406.881341] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg gagal dengan status -110
[11406.881352] brcmfmac: brcmf_cfg80211_reg_notifier: Kode negara iovar dikembalikan err = -110
[11579.921479] brcmfmac: _brcmf_set_multicast_list: Pengaturan mcast_list gagal, -110
[11582.491485] brcmfmac: _brcmf_set_multicast_list: Pengaturan allmulti gagal, -110
[11587.611478] brcmfmac: _brcmf_set_multicast_list: Pengaturan BRCMF_C_SET_PROMISC gagal, -110
thenry @ pi3portable : ~ $
thenry @ pi3portable : ~ $ uname -a
Linux pi3portable 4.14.27-v7 + # 1100 SMP Jum 16 Mar 13:51:48 GMT 2018 armv7l GNU / Linux
thenry @ pi3portable : ~ $
Saya menjalankan kernel ini karena saya beralih ke aliran berikutnya ketika saya menguji boot dari usb, dan tidak berubah kembali setelah itu. Kemudian saya mendapat pemberitahuan tentang kernel baru (4.14) jadi memutuskan untuk mencobanya, sekitar sebulan yang lalu. Tidak apa-apa, tidak ada masalah sampai yang ini. Hanya perubahan besar lainnya adalah saya beralih dari NetworkManager ke systemd-networkd beberapa hari yang lalu tetapi itu setelah masalah ini pertama kali muncul.
Salam,
Trevor Henry

Memperbarui:
Setelah saya membaca semua posting terkait saya menemukan firmware terbaru di posting https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=203508
dan ini memperbaiki masalah saya.

versi uji brcmfmas43430-sdio.bin diinstal 250418

versi 7.45.98.38 23 Okt 2017, menggantikan versi 7.45.41.46 7 Agustus 2017

sebelum:

[10.368086] brcmfmac: tanda tangan F1 terbaca @ 0x18000000 = 0x1541a9a6
[10.376702] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan brcm / brcmfmac43430-sdio.bin untuk chip 0x00a9a6 (43430) rev 0x000001
[10.377026] usbcore: terdaftar brcmfmac driver antarmuka baru
[10.599523] brcmfmac: brcmf_c_preinit_dcmds: Versi firmware = wl0: 7 Agustus 2017 00:46:29 versi 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.600577] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Pembuatan: 2014-05-26 10:53:55 Inc Data: 9.10.41 Inc Compiler: 1.29 .4 Inc ClmImport: 1.36.3 Pembuatan: 2017-08-07 00:37:47
[126.642710] brcmfmac: manajemen daya dinonaktifkan
[139.249230] brcmfmac: brcmf_sdio_hostmail: Isi data kotak surat tidak diketahui: 0x40012
[141,751545] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[141.754973] brcmfmac: brcmf_sdio_checkdied: jebakan firmware dalam dongle
[144.311482] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[144.314959] brcmfmac: brcmf_sdio_checkdied: perangkap firmware dalam dongle
[144.314975] brcmfmac: brcmf_pno_clean: kode gagal -110
[151.831564] brcmfmac: brcmf_sdio_bus_rxctl: dilanjutkan tepat waktu
[151.835066] brcmfmac: brcmf_sdio_checkdied: jebakan firmware dalam dongle
[151.835079] brcmfmac: brcmf_do_escan: error (-110)
[151.835084] brcmfmac: brcmf_cfg80211_scan: kesalahan pemindaian (-110)

setelah:

thenry @ pi3portable : ~ $ dmesg | grep brcm
[10.115833] brcmfmac: tanda tangan F1 terbaca @ 0x18000000 = 0x1541a9a6
[10.134926] brcmfmac: brcmf_fw_map_chip_to_name: menggunakan brcm / brcmfmac43430-sdio.bin untuk chip 0x00a9a6 (43430) rev 0x000001
[10.135115] usbcore: terdaftar brcmfmac driver antarmuka baru
[10.367703] brcmfmac: brcmf_c_preinit_dcmds: Versi firmware = wl0: 23 Okt 2017 03:55:53 versi 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[10.368419] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Pembuatan: 2014-05-26 10:53:55 Inc Data: 9.10.39 Inc Penyusun: 1.29 .4 Inc ClmImport: 1.36.3 Pembuatan: 2017-10-23 03:47:14
[18.045308] brcmfmac: manajemen daya dinonaktifkan
thenry @ pi3portable : ~ $

Ini terus bekerja melalui beberapa boot dan saya sekarang menggunakannya, terhubung dengan wifi ke telepon samsung s4.
Terima kasih atas bantuan Anda, salam, Trevor Henry.

Saya pikir firmware terbaru sudah dalam image terbaru, jadi saya berharap bahwa upgrade ke 4.14 akan membawa firmware terbaru masuk Apakah Anda membangun kernel Anda sendiri?

Ya - image Raspbian saat ini memiliki firmware 7.45.98.38 dari 23 Oktober 2017.

Hai, tidak, saya tidak membangun kernel, saya memutakhirkan dengan pembaruan rpi, dan seperti yang Anda lihat, itu masih menjalankan firmware Agustus 2017 setelah pembaruan.

rpi-update hanya meningkatkan kernel, firmware, dan sejumlah kecil utilitas khusus VideoCore. Untuk mengupgrade semuanya, termasuk firmware WiFi, Anda harus menggunakan apt-get upgrade / distupgrade.

Hai,
Jadi saya memiliki masalah ini dan lebih baik dengan FW terbaru, 7.45.98.38, daripada sebelumnya tetapi saya masih memiliki masalah.
Pengamatan
Jika saya mem-boot raspberry tanpa melakukan apa pun, maka WLAN muncul sebagaimana mestinya.
Jika saya mencoba menggunakan keyboard atau mouse bluetooth sebelum WLAN aktif, maka masalah tetap ada, saya tidak mendapatkan koneksi.
Jika saya memiliki koneksi dan menonaktifkan / mengaktifkan jaringan nirkabel maka WLAN tidak terhubung.
Jika saya meninggalkan WLAN pada malam hari maka koneksi berhenti bekerja.
Saya memiliki tiga pengaturan yang identik dan perilakunya sama pada semuanya.
Tidak tahu apakah itu penting tetapi kami menggunakan WPA2 enterprise, PEAP dan MSCHAPv2

Apakah masalah ini hanya terjadi saat perangkat BT terhubung?

Iya! Bluetooth yang dinonaktifkan dan keyboard dan mouse usb yang terhubung serta WLAN yang terhubung lebih cepat dari yang pernah saya lihat sebelumnya.

Masih ada beberapa masalah dengan hidup berdampingan. Kurasa perlu ditandai hingga Cypress.

Sekadar mengecek, apakah Anda menggunakan Raspbian terbaru? Atau sesuatu yang sangat baru?

ping @pelwell

Deskripsi: Raspbian GNU / Linux 9.4 (stretch)
Apakah Anda memerlukan info lebih lanjut?

Itu hang setelah:
14 Mei 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD Vendor EAP 0 metode 25 (PEAP) dipilih

lihat potongan kayu di bawah

14 Mei 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.7887] perangkat (wlan0): status antarmuka pemohon: terputus -> mengasosiasikan
14 Mei 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: Terkait dengan 44: d9: e7: f7: d5: 34
14 Mei 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-STARTED EAP otentikasi dimulai
14 Mei 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.9263] perangkat (wlan0): status antarmuka pemohon: asosiasi -> terkait
14 Mei 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: vendor CTRL-EVENT-EAP-PROPOSED-METHOD = 0 metode = 25
14 Mei 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-METHOD Vendor EAP 0 metode 25 (PEAP) dipilih
14 Mei 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0716] perangkat (wlan0): Aktivasi: (wifi) asosiasi memakan waktu terlalu lama
14 Mei 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0718] perangkat (wlan0): perubahan status: config -> need-auth (alasan 'tidak ada') [50 60 0]
14 Mei 15:44:24 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-DISCONNECTED bssid = 44: d9: e7: f7: d5: 34 reason = 3 local_generated = 1
14 Mei 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0937] perangkat (wlan0): Aktivasi: (wifi) meminta rahasia baru
14 Mei 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0959] sup-iface [0x1c438c0, wlan0]: koneksi terputus (alasan -3)

Saya memiliki masalah yang sama dengan octoPi 0.14 (setiap paket diperbarui, firmware rpi paling lambat, setiap plugin octoprint diperbarui).

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

dengan pengaturan ini, 100% dapat direproduksi. Berdasarkan situs web cetak gurita di pi (akses pertama kali setelah boot) dari samsung s4 saya aktif (android 5.0.1, menggunakan chrome) atau dari samsung tablet 10inch note hal dengan juga android 5.xi tebakan dan chrome membunuh wifi ketika halaman setengah dimuat.
Tidak ada kabel yang terhubung ke Pi3 saya, wifi di saluran 11 dengan wpa2.
Saya mencoba menonaktifkan daya wifi dan beralih ke saluran wifi 6 tanpa hasil (tip dari atas) - namun saya merasa itu sedikit lebih baik dengan saluran 6.

Tapi sekarang muncul petunjuk menarik tentang bug tersebut:
Saya tidak memiliki masalah ketika saya membuka situs octopi / octoprint (di pi) dari mesin windows 10 atau ubuntu 16 saya (menggunakan chrome, koneksi kabel ke router). Dugaan saya sekarang ini adalah bug terkait android, samsung atau wifi ke wifi. Dan saya rasa saya telah membaca sesuatu tentang masalah android / rpi beberapa waktu yang lalu.

Semoga ini membantu. Jika Anda membutuhkan penguji untuk beberapa versi, saya akan mencobanya.

Hanya berpikir saya akan berpadu di sini dan mengatakan kami juga telah melihat apa yang tampak seperti kios pemblokiran terkait WiFi di sekitar driver ini yang mungkin terkait dengan SBC lain. Ini bukan khusus Raspberry PI.

Ini juga terjadi pada saya.

Mempersiapkan

• Pi 3B 1.2 (a02082)
• Inti:

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

Menjalankan Raspbian versi 9.4:

pi<strong i="14">@raspberrypi</strong>:~ $ cat /etc/debian_version
9.4

Versi firmware:

pi<strong i="18">@raspberrypi</strong>:~ $ /opt/vc/bin/vcgencmd version
Jul  9 2018 19:35:54
Copyright (c) 2012 Broadcom
version daa7178a0900fd9a743c019f9dad7889d531e71d (clean) (release)

wlan0 Manajemen daya dimatikan:

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

Saya menggunakan wifi built-in. Tidak ada yang terhubung ke port ethernet.

Sistem telah ditingkatkan menggunakan apt-get upgrade , apt-get dist-upgrade dan rpi-update .

Apa yang saya lihat

Setelah pi dinyalakan selama sekitar satu jam, itu menjadi tidak dapat dijangkau dari jaringan. Saya tidak dapat mencapai Pi dari jaringan lokal saya (ping dan ssh tidak berfungsi).

Dalam dmesg , saya melihat bahwa saya mendapatkan:

brcmfmac: power management disabled
...
snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned

Tapi tidak ada kesalahan.

Sesuatu yang menarik

Saya perhatikan bahwa ketika ini terjadi, jika saya terhubung ke pi secara langsung dan melakukan ping ke laptop saya - semuanya kembali berfungsi. Selain itu, waktu ping agak aneh - sepertinya perlu sedikit waktu untuk membuat hal-hal 'hangat':

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

Jika ada yang membutuhkan informasi lebih lanjut, dengan senang hati saya akan memberikannya.

@ Bugok , apakah pengaturan antarmuka jaringan untuk promiscuous meringankan masalah Anda? ( ifconfig wlan0 promisc ).

@quozl : Itu tidak membantu. Setelah beberapa saat, ping mulai gagal:

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

Melaporkan balik: Masalah saya tampaknya telah teratasi, dan tampaknya tidak terkait dengan masalah di utas ini.

Detail di sini , tetapi intinya adalah saya menetapkan IP statis pada Pi itu sendiri (dalam /etc/dhcpcd.conf ). Setelah menentukan IP statis di router, hapus konfigurasi IP statis dari /etc/dhcpcd.conf dan boot ulang - semuanya tampaknya berfungsi.

Pembaruan cepat: masalah ini (kesalahan "Konten data kotak surat tidak dikenal" disertai dengan penguncian nirkabel lengkap) tetap ada, pada firmware terbaru dengan semua pembaruan diinstal (dist-upgrade).

Mengubah satu baris di file hostapd.conf (sesuai komentar saya sebelumnya) masih menghilangkan masalah bagi saya.

Menggunakan Rpi3B dengan kernel 4.14.52-v7 (raspberrypi-kernel 1.20180703-1) dan (firmware-brcm80211 1: 20161130-3 + rpt4)
Saya juga masih menghadapi masalah di mana wlan macet (90 perangkat di antaranya 2 per hari mengalami masalah). Dalam beberapa kasus, adaptor hilang dan adaptor tidak merespons. Saya tidak menggunakan Pi dalam mode AP, hanya
Saya mencoba untuk membuatnya kembali seperti pada RPi-3B + tetapi tidak berhasil.

Saat ini saya membuat solusi ketika tidak ada koneksi jaringan yang terdeteksi, pi reboot. Namun, ini bukan solusi yang tepat dan setidaknya saya mencoba memuat ulang driver

Saya secara konsisten melihat masalah yang sama ini pada Pi 3. yang sebelumnya berfungsi. Saya menyadari bahwa satu-satunya perubahan yang telah saya buat adalah menyambungkan layar sentuh LCD, menarik daya dari Pi. Ketika saya mencabut layar sentuh, WiFi bekerja dengan benar. Jadi sepertinya itu terkait dengan kekuasaan. Ini menggunakan adaptor AC Raspberry resmi.

Itu poin data yang sangat menarik. Apakah itu salah satu LCD kami?

@ JamesH65 Saya juga mulai mengalami gangguan wifi dan lonjakan latensi setelah saya menginstal https://www.waveshare.com/wiki/5inch_HDMI_LCD , saya memiliki 3b + a rpi cam v2 dan tampilan, terhubung ke 3amp psu, saya jangan dapatkan peringatan daya apa pun ...

Hai teman-teman, ada pembaruan tentang ini? Saya mencoba menggunakan raspivid pada nol W dengan aliran TCP dan setelah beberapa menit Wi-Fi saya hilang, saya kira itu masalah yang sama.

Saya tidak mengalami masalah setidaknya dalam satu tahun atau lebih. Saya mulai semakin berpikir bahwa ini mungkin hanya terkait dengan sumber daya USB yang tidak menyediakan cukup amp, tetapi saya akan menerima bukti bahwa ini bukan masalahnya. Sebagai ujian, coba hubungkan kabel USB Anda ke adaptor amp yang lebih tinggi, terutama jika Anda dapat mereproduksi masalahnya dengan mudah.

Saya cukup yakin ini tidak berhubungan langsung dengan amp karena saya hanya menggunakan sekitar 2amp. kebanyakan charger samsung lama. namun itu bisa berupa riak atau sesuatu dengan catu daya atau perangkat keras pi.Von meinem Samsung Gerät gesendet.

-------- Ursprüngliche Nachricht --------
Von: rajid [email protected]
Tanggal: 07.04.2019 02:15 (GMT + 01: 00)
Sebuah: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , Komentar [email protected]
Betreff: Re: [raspberrypi / linux] wlan membeku di raspberry pi 3 / PiZeroW (Not
3B +) (# 1342)

Saya tidak mengalami masalah setidaknya dalam satu tahun atau lebih. Saya mulai semakin berpikir bahwa ini mungkin hanya terkait dengan sumber daya USB yang tidak menyediakan cukup amp, tetapi saya akan menerima bukti bahwa ini bukan masalahnya. Sebagai ujian, coba hubungkan kabel USB Anda ke adaptor amp yang lebih tinggi, terutama jika Anda dapat mereproduksi masalahnya dengan mudah.

—Anda menerima ini karena memberi komentar. Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utas.
{"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 ":" Open in GitHub "," url ":" https://github.com/raspberrypi/linux "}}," update ": {" snippet ": [{" icon ":" PERSON "," message ":" @rajid di # 1342: Saya tidak mengalami masalah setidaknya dalam setahun atau lebih. Saya Saya mulai semakin berpikir bahwa ini mungkin hanya terkait dengan sumber daya USB yang tidak menyediakan cukup amp, tetapi saya akan menerima bukti bahwa ini bukan masalahnya. Sebagai ujian, coba hubungkan kabel USB Anda ke adaptor amp yang lebih tinggi, terutama jika Anda dapat dengan mudah mereproduksi masalah. "}]," action ": {" name ":" View Issue "," url ":" https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753 "}}}
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753",
"name": "Lihat Masalah"
},
"description": "Lihat Masalah ini di GitHub",
"penerbit": {
"@type": "Organisasi",
"name": "GitHub",
"url": " https://github.com "
}
}
]

Saya masih mengalami masalah, tetapi tidak sesering - mungkin pernah beberapa minggu - dan saya tidak dapat lagi memunculkannya dengan andal dengan menghubungkan dari perangkat android Samsung.

Saya sebenarnya menyalakan Pi zero w dengan catu daya usb 3A dan kabel usb 15cm yang digunakan untuk mengisi daya powerbanks (tidak ada jalur data, hanya saluran listrik)

Jika saya menggunakan koneksi secara teratur (seperti pengguna biasa) maka itu berfungsi dengan baik, tetapi jika saya streaming MJPEG pada 5Mbps itu macet setelah beberapa menit, saya melihat beberapa kotak surat (atau serupa) kesalahan pada journalct (tidak ingat karena saya keluar rumah selama seminggu), ssh berhenti, tidak ada ping, Wi-Fi turun, iwconfig membutuhkan beberapa detik untuk menunjukkan hasil dan hampir kosong.

@vascojdb Jika Anda menggunakan Pi sebagai titik akses (mode AP), maka solusi ini (lihat teks tebal di bawah) akan menyelesaikan masalah Anda.

Beritahu kami?

Tidak, ini tidak dalam mode AP, saya tersambung ke jaringan Wi-Fi 2.4GHz rumah saya

Halo,

Saya memiliki masalah wifi untuk menyinkronkan waktu saat startup dengan server NTP dengan menggunakan LibreELEC pada RPI3B + sejak versi 9.0.0.
Setelah beberapa diskusi dengan beberapa anggota tim LE ( lihat di sini ), masalah telah diperbaiki setelah modifikasi ini.

Namun tampaknya solusi tersebut telah dikembalikan dan masalahnya masih ada.
Apakah mungkin untuk memperbaikinya lagi?

Tidak ada yang menjawab atau mengangkat masalah ini?

Masalah yang sama. Ada berita tentang ini?

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)

Mencoba mematikan manajemen daya untuk saat ini. Apakah ini bug lama yang diperkenalkan kembali?

https://patchwork.kernel.org/patch/9948825/

Masalah yang sama. Ada berita tentang ini?

Pesan ini hanya mengatakan bahwa firmware chip wifi rusak. Tidak ada yang dapat dilakukan kernel Linux selain mengatur ulang. Laporan bug bermanfaat berisi informasi berikut:

Firmware wifi mana yang Anda gunakan?
Bagaimana Anda mengoperasikan wifi (AP, klien, ...)?
Bisakah Anda mereproduksi ini dalam waktu yang ditentukan?
Perangkat wifi lain apa yang terlibat?

itu di komentar terakhir saya karena dapat direproduksi saat itu tetapi itu buruk untuk direproduksi dan berubah dengan perubahan perangkat lunak saat macet.

-------- Ursprüngliche Nachricht --------
Von: Stefan Wahren [email protected]
Tanggal: 01.05.2020 10:21 (GMT + 01: 00)
Sebuah: raspberrypi / linux [email protected]
Cc: "A. Binzxxxxxx" [email protected] , Komentar [email protected]
Betreff: Re: [raspberrypi / linux] wlan membeku di raspberry pi 3 / PiZeroW (Not
3B +) (# 1342)

Masalah yang sama. Ada berita tentang ini?

Pesan ini hanya mengatakan bahwa firmware chip wifi rusak. Tidak ada yang dapat dilakukan kernel Linux selain mengatur ulang. Laporan bug bermanfaat berisi informasi berikut:
Firmware wifi mana yang Anda gunakan?
Bagaimana Anda mengoperasikan wifi (AP, klien, ...)?
Bisakah Anda mereproduksi ini dalam waktu yang ditentukan?
Perangkat wifi lain apa yang terlibat?

—Anda menerima ini karena Anda mengomentarinya. Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.
[
{
"@context": " http://schema.org ",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815",
"name": "Lihat Masalah"
},
"description": "Lihat Masalah ini di GitHub",
"penerbit": {
"@type": "Organisasi",
"name": "GitHub",
"url": " https://github.com "
}
}
]

Masalah yang sama. Ada berita tentang ini?

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)

Mencoba mematikan manajemen daya untuk saat ini. Apakah ini bug lama yang diperkenalkan kembali?

https://patchwork.kernel.org/patch/9948825/

Tidak ada solusi untuk dibicarakan, tetapi saya memiliki masalah yang persis sama pada Rpi4 dengan firmware terbaru yang diinstal. Saya menggulungnya kembali ke gambar kartu SD yang saya buat beberapa bulan yang lalu dan masalahnya hilang. Karena saya menggunakan hostapd, saya yakin salah satu atau kombinasi dari peningkatan ini merusaknya untuk saya:

$ apt list --upgradeable
Daftar ... Selesai
...
hostapd / stable 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u2 armhf [dapat diupgrade dari: 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u1]
firmware-brcm80211 / testing 1: 20190114-1 + rpt6 all [diupgrade dari: 1: 20190114-1 + rpt4]
raspberrypi-kernel / testing 1.20200212-1 armhf [diupgrade dari: 1.20200114-1]
...

Saya juga mencoba mematikan manajemen daya (dan memastikannya mati dengan iwconfig), tetapi tidak berpengaruh saat menjalankan hostapd. Saya harus melepaskan peningkatan firmware sampai diperbaiki, karena kami mengirimkan banyak dari ini dan membutuhkan AP yang stabil untuk pelanggan kami.

Siapa pun yang mengalami jebakan firmware, batas waktu (-110), dll. - harap aktifkan beberapa firmware debugging sehingga kami dapat mengumpulkan beberapa data.

Tambahkan brcmfmac.debug=0x100000 ke /boot/cmdline.txt, simpan dalam satu baris panjang, lalu reboot. Menjalankan dmesg | grep brcmfmac akan menghasilkan keluaran seperti ini:

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

Kemudian lanjutkan seperti biasa. Saat firmware brcmfmac mati, tangkap output dmesg ke file dan lampirkan (atau tautan ke pastebin, dll.) Di sini.

Karena kegagalan tersebut memicu pesan kernel lainnya, ada bahaya bahwa keluaran yang berguna akan hilang sebelum Anda sempat menangkapnya. Cara untuk menghindarinya adalah dengan meninggalkan shell yang terus-menerus menyimpan pesan kernel ke sebuah file:

$ dmesg -w > kernel_log.txt &

Melihat masalah yang sama di sini. Akan mencoba debug yang disebutkan di atas.

Menjalankan hostapd dalam mode AP, wireguard, dan frr. Juga menggunakan topi seluler Sixfab.

[46972.803286] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[46975.363309] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[46975.363322] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[47292.885392] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47295.445423] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47295.445436] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[47602.007429] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47604.567452] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47604.567465] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
[47830.248947] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47838.328989] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
[47887.049300] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON failed -110
[47892.649358] brcmfmac: brcmf_cfg80211_stop_ap: SET SSID error (-110)
[47895.209353] brcmfmac: brcmf_cfg80211_stop_ap: BRCMF_C_DOWN error -110
[47897.769374] brcmfmac: brcmf_cfg80211_stop_ap: setting AP mode failed -110
[47902.889420] brcmfmac: brcmf_cfg80211_stop_ap: BRCMF_C_UP error -110
[47905.449430] brcmfmac: brcmf_set_mpc: fail to set mpc

Linux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux

Saya juga dapat membuat ulang ini di cabang 5.4. FWIW, saya selalu dapat memicu bug ini secara manual dengan melakukan SCP file besar (> 400MB) ke Pi Zero W.

Jika membantu, versi kernel saya adalah pada komit ini - https://github.com/raspberrypi/linux/commit/3c860a6fd128e7cf1c39b3f51258a2a078d1a1a4

# uname -a
Linux pichime-1-c93bb27a 5.4.50 #1 Sun Jul 12 20:53:57 CDT 2020 armv6l GNU/Linux

# dmesg | grep brcmfmac | grep Firmware
[    5.319134] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: May  2 2019 02:39:18 version 7.45.98.83 (r714225 CY) FWID 01-e539531f

Crash Log dengan 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)

Selama crash di atas saya menjalankan ifdown dan ifup yang tidak memulihkan wifi. Satu-satunya solusi adalah dengan mereboot pi, atau rmmod & modprobe brcmfmac.

Perlu dicatat ini terjadi dengan manajemen daya dimatikan, karena saya memiliki ini di file antarmuka saya:

pre-up iwconfig wlan0 power off