EDIMAX EW-7811UN .... هذا يستخدم شرائح rtl8188cus ، IIRC.

إذا لم يكن لديك واحد بالفعل ، فأنشئ /etc/modprobe.d/8192cu.conf ، بالمحتوى ....

تعطيل إدارة الطاقة

الخيارات 8192cu rtw_power_mgnt = 0 rtw_enusbss = 0

يستخدم rpi3 في الواقع برنامج تشغيل brcmfmac لشبكة wifi المدمجة
هناك مشكلة تتطلب إيقاف تشغيل توفير الطاقة / الإدارة

أعتقد أن نواة raspian الأحدث قد قامت بتصحيح هذا بالفعل لتعطيل توفير الطاقة افتراضيًا ولكني لا أعتقد أنه موجود في هذا الفرع 4.5

ما أفعله في الوقت الحالي (تثبيت gentoo) هو ما يلي عند بدء التشغيل لتعطيل توفير الطاقة على بطاقة wifi

iw wlan0 ضبط power_save

يستخدم rpi3 في الواقع برنامج تشغيل brcmfmac لشبكة wifi المدمجة

نعم انا اعرف. حسنا أرى ذلك. لم يعد يستخدم دونجل EDIMAX EW-7811UN بعد الآن. اعتاد استخدامه مع RPi2.

نعم ، لم أعد أستخدم USB wifi ، كيف يمكنني إعداد خط cmd لإيقاف تشغيل إدارة الطاقة؟
كرونتاب
@ reboot iw wlan0 اضبط حفظ power_save

لست متأكدًا من raspian ، لأنني أستخدم gentoo سيكون مختلفًا

جرب هذا: https://gist.github.com/mkb/40bf48bc401ffa0cc4d3

يبدو أنه يعمل منذ أن أوقفت إدارة الطاقة ، ولم أتعرض لتحطم آخر في الشبكة اللاسلكية.

فقط لذكر ذلك ، لإعادة تشغيل شبكة wlan تلقائيًا بعد حدوث عطل ، يساعد هذا هنا:
sudo cp /etc/wpa_supplicant/ifupdown.sh /etc/ifplugd/action.d/ifupdown

راجع للشغل ، أحدث إصدار من apt-get Upgrade kernel تم تعطيل إدارة الطاقة بشكل افتراضي.
@ dh-connect هل يعمل هذا من أجلك إذا قمت بإزالة الحل البديل الحالي؟

لا يزال يتعطل بعد التحديث الأخير ، والآن أتلقى هذا الخطأ في سجل النظام:
brcmfmac: brcmf_sdio_bus_txdata: خارج الحافلة-> txq !!!

عندما تقول إنه يتعطل ، هل هناك أعراض أخرى غير رسالة الخطأ؟

لا ، فقط الذي قمت بنشره هنا ولكنه موجود في السجل عدة مرات

توقف الشبكة اللاسلكية عن العمل ، لا يزال بإمكاني العمل معها ولكن لإعادة تشغيل الشبكة اللاسلكية ، يجب إعادة تشغيلها

شكرًا - أعتقد أن "توقف شبكة WLAN عن العمل" يعد من الأعراض.

لقد جربت بعض الأشياء ، لكن الشبكة اللاسلكية لا تزال تتعطل

للإجابة على السؤال أعلاه عند استعادة التكوين
إيقاف تشغيل لاسلكي في / etc / network / interfaces
وإعادة التشغيل
وتحقق من الإعدادات باستخدام iwconfig
لم يتم تشغيل إدارة الطاقة ، لذا لن أقول بشكل افتراضي أن هذا منفصل لذا سأترك التكوين

لقد جربت ذلك باستخدام kernel 4.1.19 والآن أيضًا مع kernel 4.1.20 ... بدون تغيير

عندما تعطلت شبكة wlan وأحاول إعادة تشغيلها باستخدام ifdown و ifup wlan0 ، أحصل على هذا:
خطأ في الطلب اللاسلكي "تعيين إدارة الطاقة" (8B2C): فشل SET على الجهاز wlan0 ؛ صرف غير صحيح.

لقد حصلت أيضًا على بعض الأخطاء الأخرى في سجل النظام:

dhcpcd [532]: wlan0: xxx: expired option 25

21 مارس 17:29:35 نواة raspberrypi: [6627.337503] brcmfmac: _brcmf_set_multicast_list: فشل إعداد mcast_list ، -52
21 مارس ، 17:29:36 raspberrypi wpa_supplicant [6318]: تمت تهيئة wpa_supplicant بنجاح
21 مارس 17:29:36 raspberrypi dhcpcd [532]: شبكة wlan0: فقد ناقل

21 مارس 17:29:43 نواة raspberrypi: [6635.337616] brcmfmac: _brcmf_set_multicast_list: فشل إعداد mcast_list ، -52

21 مارس 17:29:45 نواة raspberrypi: [6637.337588] brcmfmac: brcmf_do_escan: خطأ (-52)
21 مارس 17:29:45 نواة raspberrypi: [6637.337602] brcmfmac: brcmf_cfg80211_scan: خطأ المسح (-52)

21 مارس 17:29:47 نواة raspberrypi: [6639.337596] brcmfmac: _brcmf_set_multicast_list: Setting allmulti failure، -52
21 مارس 17:29:49 نواة raspberrypi: [6641.337632] brcmfmac: _brcmf_set_multicast_list: إعداد BRCMF_C_SET_PROMISC فشل ، -52

هل هناك أي شيء آخر يمكنني تجربته؟

أيضا هؤلاء:

21:26:55 مارس 21:26:55 raspberrypi dhcpcd [526]: wlan0: xxx: expired option 25
21 مارس 21:28:54 نواة raspberrypi: [1958.899715] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
21 مارس 21:30:16 raspberrypi dhcpcd [526]: wlan0: xxx غير قابلة للوصول ، تنتهي صلاحيتها

لست مندهشًا من أن iwconfig يعتقد أن الجهاز قد تم تمكين توفير الطاقة - لقد قمت بحظره داخل برنامج التشغيل نفسه ، وإما أن الحالة محفوظة في الطبقات العليا أو هناك تغيير آخر مطلوب للإبلاغ عنه بشكل صحيح. في كلتا الحالتين ، الدليل قوي على أننا تجنبنا أخطاء توفير الطاقة ، ولكن لا تزال هناك بعض المشكلات الأخرى.

هل لديك أي أرقام تقريبية للوقت حتى الفشل وما مقدار البيانات التي تم نقلها تقريبًا (من ifconfig)؟

نعم أفعل ذلك ، عندما يكون خادم الويب فقط يعمل مع حركة مرور قليلة (أقل من 100 ميجابايت) ، فإنه يستمر يومًا أو يومين ، عندما أقوم بنقل ملفات البيانات الكبيرة مثل تعطل شبكة wlan بسعة 1 جيجابايت في غضون ساعة واحدة

أي شيء يمكنني تقديمه للمساعدة في العثور على الخطأ؟

إليك بعض الأخطاء من سجل النظام:

29 مارس 14:20:56 raspberrypi dhcpcd [535]: wlan0: xxx: expired option 25
29 مارس 14:30:15 raspberrypi dhcpcd [535]: wlan0: xxx غير قابل للوصول ، تنتهي صلاحيته
29 مارس 17:18:42 نواة raspberrypi: [186148.102420] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
مارس 29 17:18:43 نواة raspberrypi: [186149.101045] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 مارس 17:18:43 نواة raspberrypi: [186149.101145] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 مارس 17:18:44 نواة raspberrypi: [186150.101209] brcmfmac: brcmf_sdio_bus_txdata: out of bus-> txq !!!
29 مارس 17:18:50 raspberrypi wpa_supplicant [478]: wlan0: CTRL-EVENT-DISCONNECTED bssid = xxx reason = 3 local_generated = 1
29 مارس 17:18:50 نواة raspberrypi: [186156.181033] brcmfmac: brcmf_cfg80211_disconnect: خطأ (-52)
29 مارس 17:18:52 نواة raspberrypi: [186158.181028] brcmfmac: send_key_to_dongle: خطأ wsec_key (-52)
29 مارس 17:18:54 نواة raspberrypi: [186160.181046] brcmfmac: send_key_to_dongle: خطأ wsec_key (-52)
29 مارس 17:18:56 نواة raspberrypi: [186162.181048] brcmfmac: send_key_to_dongle: خطأ wsec_key (-52)
29 مارس 17:18:58 نواة raspberrypi: [186164.181049] brcmfmac: send_key_to_dongle: خطأ wsec_key (-52)
29 مارس 17:18:58 نواة raspberrypi: [186164.185477] cfg80211: استدعاء CRDA لتحديث المجال التنظيمي العالمي
29 مارس 17:18:58 raspberrypi dhcpcd [535]: شبكة wlan0: فقد الناقل
29 مارس 17:18:58 raspberrypi wpa_supplicant [7354]: تمت تهيئة wpa_supplicant بنجاح
29 مارس 17:18:58 نواة raspberrypi: [186164.314511] brcmfmac: brcmf_cfg80211_reg_notifier: ليس رمز ISO3166
29 مارس 17:18:58 نواة raspberrypi: [186164.314541] cfg80211: تم تحديث المجال التنظيمي العالمي:
29 مارس 17:18:58 نواة raspberrypi: [186164.314548] cfg80211: منطقة DFS الرئيسية: unset
29 مارس 17:18:58 نواة raspberrypi: [186164.314555] cfg80211: (start_freq - end_freq @ bandwidth)، (max_antenna_gain، max_eirp)، (dfs_cac_time)
29 مارس 17:18:58 نواة raspberrypi: [186164.314565] cfg80211: (2402000 كيلو هرتز - 2472000 كيلو هرتز @ 40000 كيلو هرتز)، (N / A، 2000 ميجا بايت)، (N / A)
مارس 29 ، 17:18:58 نواة raspberrypi: [186164.314573] cfg80211: (2457000 كيلو هرتز - 2482000 كيلو هرتز @ 40000 كيلو هرتز) ، (N / A ، 2000 ميغا بايت) ، (N / A)
29 مارس 17:18:58 نواة raspberrypi: [186164.314581] cfg80211: (2474000 كيلو هرتز - 2494000 كيلو هرتز @ 20000 كيلو هرتز)، (N / A، 2000 ميجا بايت)، (N / A)
29 مارس 17:18:58 نواة raspberrypi: [186164.314592] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz، 160000 KHz AUTO)، (N / A، 2000 mBm)، (N / A)
29 مارس 17:18:58 kernel raspberrypi: [186164.314602] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz، 160000 KHz AUTO)، (N / A، 2000 mBm)، (0 s)
29 مارس 17:18:58 نواة raspberrypi: [186164.314611] cfg80211: (5490000 كيلو هرتز - 5730000 كيلو هرتز @ 160000 كيلو هرتز)، (N / A، 2000 ميجا بايت)، (0 ثانية)
29 مارس 17:18:58 نواة raspberrypi: [186164.314645] cfg80211: (5735000 كيلو هرتز - 5835000 كيلو هرتز @ 80000 كيلو هرتز)، (N / A، 2000 ميغا بايت)، (N / A)
29 مارس 17:18:58 نواة raspberrypi: [186164.314654] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz)، (N / A، 0 mBm)، (N / A)

شكرًا على العرض ، ولكن هذا في يد Broadcom الآن.

أي تحديث من Broadcom إذا كان هذا خطأ وسيتم إصلاحه؟ لدي الآن إعداد وظيفة cron لإخراج wlan0 وأعلى عندما يفشل في اختبار ping.

تحديث سريع من جانبي ، يمكنني الحصول على إصلاح يبدو أنه يتعلق ببرنامج التشغيل ، لقد قمت بتثبيت Ubuntu MATE 16.04 مع kernel 4.4.8 ولم أواجه أي مشاكل مع wifi منذ ذلك الحين

أعني أنهم يعلنون أن "Ubuntu MATE 16.04 لديها أيضًا تقنية Bluetooth وواي فاي تعمل بكامل طاقتها على Raspberry Pi 3" وهذا يبدو صحيحًا

ربما يعمل أيضًا مع إصدار دبيان الجديد ، والذي لا يمكنني تحديده

@ juched78 هل تقوم بتشغيل نواة 4.4؟ إذا لم يكن كذلك ، يرجى تشغيل sudo rpi-update للحصول على أحدث إصدار 4.4.8 ومعرفة ما إذا كان هذا يعاني من نفس المشكلة.

لقد تغيرت برامج تشغيل Broadcom بشكل ملحوظ منذ 4.1 ، وتتضمن شجرة 4.4 الخاصة بنا منافذ خلفية لبعض الإصلاحات التي تم إدخالها في 4.5. لست على دراية بأي أخطاء معلقة بصرف النظر عن فشل الاستيقاظ من السكون (لا تزال إدارة الطاقة معطلة) - يمكن استخدام القناتين 12 و 13 حيثما يُسمح بذلك ، ولا يتعطل وضع Ad Hoc - ولكن قد تظل هناك مشكلات كامنة .

أوه ، هناك خطأ واحد تم الإبلاغ عنه لا يزال في 4.4.8 - يبدو أن الاستخدام المكثف لـ hostapd يمكن أن يؤدي إلى تحذير kernel (انظر https://github.com/raspberrypi/linux/issues/1375).

أنا أجري:
Linux XXX 4.4.8-v7 + # 880 SMP الجمعة 22 أبريل 21:55:04 بتوقيت جرينتش 2016 armv7l GNU / Linux

27 أبريل 2016 11:06:18
حقوق النشر (c) لعام 2012 من Broadcom
الإصدار 9b52ab7b475f4a056658fd2d95d2440b32167390 (نظيف) (إصدار)

مع Netgear R7000 الذي يعمل به Shibby Tomato ، حوالي يومين في قطرات wifi ، وفي سجلات النظام أرى:

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

ثم يبدو أنه لم يتم إعادة الاتصال ...

استخدام sudo ifdown wlan0 متبوعًا sudo ifup wlan0 يعيد الاتصال.

ترقية للتو إلى:
Linux JuchePi 4.4.8-v7 + # 881 SMP السبت 30 أبريل 12:16:50 BST 2016 armv7l GNU / Linux

لست متأكدًا مما هو مختلف تمامًا من الثاني والعشرين إلى الثلاثين. سأراقب الاتصال.

ضرب بلدي RPi 3 أيضًا هذه المشكلة. تلقيت عددًا قليلاً من رسائل kernel المختلفة. بشكل رئيسي واحد من هؤلاء أدناه.
بعد ذلك يمكنني تشغيل شبكة WiFi ، فلن يساعد خفض wlan0 ثم رفعه.

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 من محول الطاقة الأصلي للإصدار 3. أنا أقوم بتشغيل أحدث OSMC:
$ uname -a
Linux osmc 4.4.8-3-osmc # 1 SMP PREEMPT الأحد 1 مايو 18:57:43 بالتوقيت العالمي المنسق 2016 armv7l GNU / Linux

لا يزال الرصد. كان لدي openhab عدم الاتصال بالإنترنت بعد تشغيل 3 أيام ولكن لسبب ما لا يزال بإمكاني الدخول إلى Pi وهو ما لم أستطع عادةً. تم تشغيل الجزء العلوي من الساعة ونص wifi لإسقاط الاتصال وإحضاره ثم إعادة الاتصال بمؤسسة openhab الخاصة بي. غريب. سوف نستمر في المشاهدة.

أواجه أيضًا نفس المشكلة - تتبع dmesg على النحو التالي:

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)

استعمال:

يتم استخدام rp3 كنقطة توجيه / وصول

يبدو طول الاتصال عشوائيًا - لقد مررت بأسبوعين ، وسيئة مثل بضع دقائق. في الآونة الأخيرة كان يخرج كل 20 دقيقة أو نحو ذلك. لا يؤدي إحضار wlan0 إلى أسفل ونسخه احتياطيًا إلى حل المشكلة - يلزم إعادة تشغيل كاملة.

يبدو أن المشكلة تتفاقم أثناء بث Netflix من AppleTV الخاص بي. على الرغم من أن هذا لم يكن الحال عندما كان لدي أسبوعين من الجهوزية.

أنا على الإصدار 4.4.10-v7 +

قمت بتبديل القناة من 13 إلى 6 للتحقق مما إذا كانت هذه هي المشكلة (كانت هناك بعض العيوب حول القنوات العالية) ومنذ ذلك الحين لم يكن لدي WiFi freez. لكن قد يكون ذلك مصادفة ...

لم يساعد تغيير قنوات نقطة الوصول. لا تزال شبكة WiFi معطلة. في المرات القليلة الماضية ، اضطررت إلى إعادة التشغيل عدة مرات متتالية لتشغيله.

أواجه هذه المشكلة على وجه التحديد عندما أحاول إجراء نقل SFTP بين rpi3 وهاتفي Galaxy S5. عندما أحاول إجراء نفس النقل من جهاز الكمبيوتر المحمول ، فإن كل شيء يعمل بسلاسة.

تشغيل أحدث نواة من تحديث rpi:

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

رسالة خطأ من سجل النظام:

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

يبدو أن الحل الوحيد بعد هذا الخطأ هو إعادة التشغيل.

لقد تلقيت بيانات من الشبكة مرتين في الأسبوع الماضي. لأول مرة كنت في عجلة من أمري ، لذا فقط غير موصول وأعيد تشغيله. حدث ذلك مرة أخرى بعد بضعة أيام ، وأعيد تشغيله مرة أخرى ثم شغّل تحديثات النظام بالكامل (بما في ذلك البرامج الثابتة) وستتم مراقبته. قم بتثبيته مع عدم وجود شاشة بالقرب منك ، لذا فإن الحصول على تفاصيل حول الخطأ يحتاج إلى مزيد من الجهد :)

نفس المشكلة هنا. يتم تجميده دائمًا عند نقل الملفات الكبيرة عن طريق sftp. مجرد إعادة التشغيل لحلها

ربما تتعلق هذه المشكلة بـ https://github.com/raspberrypi/linux/issues/1313

يقول من Broadcom أن # 1313 ليس مشكلة ، وأن النواة الأخيرة لم تعد تعرض هذه الرسائل.

لم أتمكن من إعادة إنتاج هذه المشكلة. هل تمكن أي شخص من التقاط أثر حزمة في وقت قريب من الفشل؟

إذا كان لدى أي شخص الوقت لإجراء المزيد من الاختبارات باستخدام وحدة برنامج تشغيل تم تمكين تصحيح الأخطاء فيها ، فسيكون موضع تقدير كبير:

1) قم بتشغيل sudo rpi-update وأعد التشغيل. هذا هو جعل النواة الخاصة بك تصل إلى نفس المستوى الخاص بي بحيث تكون الوحدة متوافقة.

2) قم بتنزيل وتثبيت وحدة برنامج التشغيل المحدثة:

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

أعد التشغيل لتنشيط الوحدات الجديدة.

3) استخدم Pi الخاص بك كالمعتاد ، ثم إذا تجمد WiFi الخاص بك:

dmesg > wifi_freeze.txt

وتحميله إلى موقع اللصق المفضل لديك (أو إنشاء Gist). يجب أن يكون عدد كبير من السجلات واحد أو اثنين.

لاستعادة الإصدار الأصلي للوحدة:

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

شكرا مقدما.

انتظر لحظة بينما نتحقق من تمكين إخراج التصحيح بالفعل.

ستحتاج أيضًا إلى تمكين ميزة تصحيح الأخطاء في برنامج التشغيل:

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

لقد قمت بتعديل التعليمات أعلاه.

بعد إعادة التشغيل ، يجب أن يتضمن إخراج dmesg شيئًا كالتالي:

[   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 بعد تنفيذ تعليماتك لم يعد لدي wifi ...

الجذر @ pi3b : / home / pi # dmesg | grep brcmf
[15.582665] brcmfmac: رمز غير معروف brcmu_dbg_hex_dump (err 0)
[15.613709] brcmfmac: رمز غير معروف brcmu_dbg_hex_dump (Err 0)

جرب هذا:

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

وإعادة التشغيل.

wlan0 لا يقترن.
wireless.txt
(في واحدة من العديد من عمليات إعادة التشغيل ، رأيت ارتباطًا لبضع دقائق على الرغم من ذلك ، لم يتم التقاطه (حتى الآن) في dmesg)

يبدو أنه قد تم حل المشكلة بالنسبة لي عن طريق الترقية من 4.4.11-v7 + إلى 4.4.15-v7 +

حاولت إعادة إنشاء المشكلات التي كنت أواجهها مع عمليات نقل SFTP من هاتف Android ، لكنني لا أرى أي مشاكل في الوقت الحالي.

pelwell بعد انتظار طويل نجح wlan0 في الارتباط ؛ ألحق dmesg بالسجل السابق:
wireless.txt
في انتظار التجميد أو فقدان الارتباط
آمل أن يكون هذا مفيدًا

pelwell سرعان ما فقد الاتصال مرة أخرى ؛ ألحق dmesg بـ:
wireless.txt

شكرا جزيلا. كانت بطيئة بالنسبة لي في المرة الأولى. لقد كنت مشغولًا في الحصول على Raspbian نظيف وتطبيق التصحيحات لمحاولة إعادة إنتاج المشكلة - سأستمر على أي حال.

تضمين التغريدة
wireless.txt
وإعادة إقرانه مرة أخرى: dmesg الملحق مرة أخرى
هل تريد مني الاستمرار؟

pelwell : فقد الارتباط مرة أخرى
الرابط اللاسلكي loss.txt

تضمين التغريدة
يتم تشغيله / إيقاف تشغيله بشكل غير منتظم
الرابط اللاسلكي loss.txt

أعتقد أنه من الأفضل أن تعود الآن قبل أن يفيض بريدي الوارد.

موافق؛ سأعود إلى دونجل MT7601U الخاص بي بقيمة 3 يورو. ؛)

شكرا لمساعدتك حتى الآن ،

لقد وجدت هذه المشكلة لتوي ، فهل يمكنني التأكيد على أنها مشابهة لما أراه؟ لقد قمت بإعداد RPi 3 كنقطة وصول وفي كثير من الأحيان لا أستطيع الاتصال به. أنا قادر على الاتصال عبر الاتصال السلكي وأرى أن wlan0 لا يزال مع عنوان IP الصحيح ولكن الطريقة الوحيدة لجعل نقطة الوصول تعمل مرة أخرى هي إعادة التشغيل. أرى تتبعات مكدس مثل هذا في /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 الخاص بي هو 4.4.13-v7 + ولقد قمت للتو بتشغيل تحديث rpi لأول مرة لذلك لا أعرف حتى الآن ما إذا كان ذلك سيساعد.

أتساءل عما إذا كان هذا قد يكون ذا صلة ، أو ربما قضية منفصلة
https://www.youtube.com/watch؟v=_D_fi_ck9Vo

عمل RPI3 الخاص بي دون أي مشاكل عبر WiFi حتى قمت بترقيته إلى أحدث إصدار ...

الآن ، لم يعد يتصل بعد الآن ...

لقد قمت أيضًا بتثبيت وحدات مصححة من Pelwell لكننا لم ننجح: ببساطة لا تتصل ...

اسمحوا لي أن أعرف إذا كان بإمكاني المساعدة ،

افضل ما فى وسعى،
ميمو

@ dh-connect هل تم حل مشكلتك؟ إذا كان الأمر كذلك ، الرجاء إغلاق هذه المشكلة. شكر.

أنا أعمل مع الشبكة المحلية منذ ذلك الحين ، لم أحاول شبكة wlan

مرحبا،

لدي ما يبدو أنه نفس المشكلة مع rpi 3. لقد عدت إلى استخدام دونجل RPI wifi usb الرسمي الذي يتميز بالصلابة ، لكن wifi المدمج يموت بعد حوالي 20 ساعة من الاتصال بهذا النوع من الرسائل في سجل النظام

brcmfmac: brcmf_cfg80211_reg_notifier: ليس رمز ISO3166
cfg80211: تم تحديث المجال التنظيمي العالمي:
cfg80211: منطقة DFS الرئيسية: unset

هذا على أحدث البرامج الثابتة raspbian

هل من الممكن إعادة فتح هذه القضية؟
لماذا تم إغلاقه؟

أنا أعمل مع الشبكة المحلية منذ ذلك الحين ، لم أحاول شبكة wlan
تم إغلاق dh-connect قبل 13 يومًا

هذا ليس حلاً يستحق إغلاق القضية ...

ما زلت أواجه المشكلة ويمكنني إعادة إنتاج الخطأ.

الجزء الخاص بي من dmesg هو:

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

أواجه نفس مشكلة jrmhaig وتمت

$ 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

قم بإعداد hostapd بجسر.

/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

/ الخ / شبكة / واجهات

# 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

بالنسبة للأشخاص الذين يعانون من مشاكل WiFi ، زودنا Cypress (كان Broadcom) بوحدات تصحيح الأخطاء للمساعدة في تشخيص المشكلات. نظرًا لأن الوحدات النمطية خاصة بإصدار kernel ، فستحتاج أولاً إلى التحديث (أو العودة المحتملة) إلى إصدار برنامج ثابت معين:

sudo rpi-update b0ef6e25679d3612a980708cf4c3907ce6e13e84
sudo shutdown -r now

يمكنك الآن تنزيل وحدات تصحيح الأخطاء وتثبيتها:

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

سيقوم الأمر الأخير بتشغيل نص التثبيت ، الذي ينسخ الوحدات الأصلية إلى جانب واحد قبل استبدالها بإصدارات تصحيح الأخطاء. سيؤدي تشغيل الأمر مرة أخرى إلى العودة إلى الإصدارات الأصلية.

بعد التثبيت ، أعد تشغيل Pi 3 - الآن dmesg | grep brcmfmac سيعرض رسالة تشخيصية مثل هذه:

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

عندما تواجه مشكلة ، استخدم dmesg > wifidbg.txt لالتقاط التتبع إلى ملف ، إلى جانب أي رسائل kernel أخرى ، ثم قم بتحميل الملف في مكان ما (gist ، pastebin ، dropbox ، إلخ.) وانشر رابطًا معه وصفًا لما كنت تفعله عند حدوث الخطأ.

الرجاء تحديث ذاكرتي: ما هو الأمر الذي يجب استخدامه للعودة إلى برامج الحماية المستقرة
إذا قررت التوقف عن التصحيح؟

sudo apt-get update
sudo apt-get upgrade

يجب أن تفعل الحيلة. و sudo ./brcmdbg للرجوع إلى برامج التشغيل غير المصححة.

https://gist.github.com/BenoitSvB/368983f2c09eed2d85a24e6920dc3a50# الملف -201609081547_wifidbg-txt

بدأ التصحيح مطلوب حوالي 5 أو 6 محاولات لربط ؛ لا أعرف لماذا فشلت كل المحاولات عدا الأخيرة ؛ سوف أتركه يعمل حتى أرى فقدان الارتباط وتفريغ dmesg جديد بعد ذلك. كان سلوك الارتباط غير المتسق هو مشكلتي قبل أن أتوقف عن استخدام شبكة wifi على متن الطائرة ، لذا قد يكون هذا في الحال. يرجى إعلامي إذا كان من الممكن أن تكون أي أنشطة إضافية مفيدة.

https://gist.github.com/BenoitSvB/bf8acdbb7b664df90e885603bb4774ce# الملف -201609081628_wifidbg-txt
لا تفعل شيئا سوى الانتظار ؛ هل نرى هنا عدة خسائر / عمليات استرداد مرتبطة؟

شكرا على ذلك. حسنًا - هذه السجلات ليست مفيدة للغاية ، ولكن دعنا نرى ما الذي يأتي به Cypress.

https://gist.github.com/BenoitSvB/98db53ff884e7b1a57bf1475d6106c56
خسارة غير مبررة واستعادة الارتباط ؛ طويلة بما يكفي لرؤيتها في رمز systray.
Accesspoint هو Linksys wrt160n مع البرنامج الثابت: DD-WRT v24-sp2 (08/07/10) std.
أعتقد أنه يمكنني التوقف عن تصحيح الأخطاء في الوقت الحالي والعودة إلى دونجل MT7601U الخاص بي بقيمة 3 يورو ، ولكن أعلمني إذا كان بإمكاني تقديم المزيد من المساعدة.

pelwell لم أر أي استعادة للبرامج الثابتة بعد sudo apt-get update && sudo apt-get Upgrade و sudo rpi-update يعطي
*** البرامج الثابتة الخاصة بك محدثة بالفعل ؛ أعتقد أنني بحاجة إلى تشغيل تحديث rpi مع تجزئة git محددة للعودة إلى البرامج الثابتة الثابتة. هل تعرف أي تجزئة؟

يُظهر سجل الالتزام في RPI-Distro repo أنك تريد الالتزام 390f53ed0fd79df274bdcc81d99e09fa262f03ab من مستودع البرامج الثابتة ، لذا قم بتشغيل:

sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab

pelwell :
root @ pi3b : / home / pi # sudo rpi-update 390f53ed0fd79df274bdcc81d99e09fa262f03ab
** محدث البرامج الثابتة Raspberry Pi بواسطة Hexxeh ، معزز بواسطة AndrewS و Dom* * إجراء التحديث الذاتي
** إعادة التشغيل بعد التحديث* * محدث البرامج الثابتة Raspberry Pi بواسطة Hexxeh ، معزز بواسطة AndrewS و Dom
تم تحديد تجزئة git غير صالحة

آه ، البرامج الثابتة Hexxeh rpi لها معرّفات التزام مختلفة - جرب 569e6611ac20c735647eb0e550484a73935a672d.

أتساءل عما إذا كان https://github.com/raspberrypi/linux/issues/1552 / # 1444 قد يكون مرتبطًا بهذه المشكلة أيضًا.

لقد قمت مؤخرًا بنشر إعداد 40xRPI3 الذي يقوم ببعض عناصر البلوتوث ، وكان علينا الحصول على واجهات USB wifi وإلا فسيتم تجميد شبكة wlan باستمرار .. نستخدم الآن الجهاز bl الداخلي ووحدة wifi الداخلية مدرجة في القائمة السوداء في modprobe.d.

قد يكون من المفيد القيام بـ hcitool name 11:11:11:11:11:11 ومعرفة ما إذا كان هذا يولد أي إدخالات سجل مثيرة للاهتمام أيضًا .. لقد كنت أتابع هذه المشكلة للتو ، ولم يكن لدي الوقت الكافي لإعداد بيئة المعمل الخاصة بي لاختبار أي شيء بنفسي. كان لدينا بعض تجميد wifi دون تمكين BT ولكن الجمع بين wifi + bt يمكن أن يقتل دائمًا شبكة wifi في فترة زمنية قصيرة جدًا .. كان هذا دائمًا قابلاً للتكرار على أي عدد من rpi

تضمين التغريدة
موافق؛ uname -a يعطي Linux pi3b.thuis 4.4.13-v7 + # 894 SMP الاثنين 13 يونيو 13: 13:27 بتوقيت جرينتش 2016 armv7l GNU / Linux
للعلم فقط: أين سيجد أي شخص تجزئة git لإصدار البرنامج الثابت الثابت الفعلي؟

تضمين التغريدة
على الرغم من أن لديّ بلوتوث يعمل ، إلا أنه ليس لدي أي استخدام له في الوقت الحالي. اسم الأداة 11: 11: 11: 11: 11: 11 لا يعيد أي شيء ؛ وهو ، على ما أعتقد ، متوقع لأنني غير متصل بأي جهاز. ربما يجب أن أشتري لي جهاز صوت BT لألعب به.

تعريف مستقرة.

التجزئة التي قدمتها لك (أخيرًا) ستكون لإصدار 20 يونيو للبرامج الثابتة ، والتي ستحصل عليها إذا قمت بتشغيل:

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

لست على دراية بمكان واحد يحتوي على تجزئة أحدث إصدار "مستقر" ، ولكن بالمرور عبر RPI-Distro كما فعلت ، يمكنك الحصول على تجزئات تحديث rpi لأي إصدار تحب. إذا كنت تعتبر إصدار 2016-05-23 مستقرًا لأنه كان جزءًا من آخر إصدار Raspbian كامل ، فأنت تريد التجزئة 3b98f7433649e13cf08f54f509d11491c99c4c0b والتي تُترجم إلى تجزئة تحديث rpi من 2b9c0bfacfc11ee8bb9b30dc9cdb8362896.

BenoitSvB مجرد تشغيل هذا الأمر hcitool من تمهيد جديد دون لمس hci0 مع أي برنامج آخر يتسبب في أن يبدأ wifi في التصرف بشكل سيء في اختباراتنا ، ولا أعرف ما إذا كان هناك أي أجهزة بلوتوث أخرى مهمة ولكن هذا هو أصغر مثال قابل للتكرار يمكنني التفكير في تشغيل مشاكل تجميد wifi.

لقد اختبرت أيضًا bt dongle الخارجي + wifi داخلي ، لكن wifi الداخلي يتوقف أحيانًا حتى عندما لا يتم تحميل برنامج تشغيل bcm الداخلي. كان "الحل" (كما في الإصلاح السريع) بالنسبة لنا هو استخدام محولات USB wifi ، والتي ثبت أنها مستقرة في اختباراتنا واستخدام الإنتاج.

ما زلت أشك في رقم 1313 على أنه متصل.

Op 8-9-2016 om 18:07 schreef توماس فروسمان:

لقد اختبرت أيضًا bt dongle الخارجي + wifi الداخلي ولكن الداخلي
يتوقف wifi أحيانًا حتى عندما لا يكون برنامج تشغيل bcm الداخلي
محمل. كان "الحل" (كما في الإصلاح السريع) بالنسبة لنا هو استخدام USB wifi
المحولات ، التي ثبت أنها مستقرة في اختباراتنا واستخدامات الإنتاج.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245649229 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AFyzObJxRjzQ-uMUlfe8hjRasrfq3nkwks5qoDLXgaJpZM4HupC5.

تضمين التغريدة
في هذه الحالة ، سيكون البرنامج الثابت هو البرنامج الثابت كما تم إصداره بواسطة المؤسسة مع آخر صورة تم نشرها وتم تحديثها بواسطة "sudo apt-get update && sudo apt-get Upgrade" فقط ، لذلك بدون استدعاء تحديث rpi (مع أو بدون بوابة محددة التجزئة ، وهو المقصود كما فهمت للترقية إلى أحدث البرامج الثابتة لأغراض محددة فقط).
وهو ما يقودني إلى السؤال: هل يمكنني قراءة تجزئة البرنامج الثابت التشغيلي الخاص بي قبل تحميل برنامج ثابت جديد للاختبار ، لجعل الاستعادة بعد الاختبار أسهل لأنني لا أثق في إجراء الإسناد الترافقي الذي ذكرته ...

ربما - cat /boot/.firmware_revision تمت كتابته بواسطة تحديث rpi ، لكن
دون أن أجربها لم أستطع إخبارك ما إذا كانت إصدارات Raspbian تكتب أيضًا
عليه.

التمهيد /. مراجعة البرامج الثابتة هو تحديث rpi (
https://www.raspberrypi.org/forums/viewtopic.php؟t=106073&p=732449#p731830)

لكني وجدت مع:

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

الذي أريده بالفعل:

• البرامج الثابتة اعتبارًا من 390f53ed0fd79df274bdcc81d99e09fa262f03ab

أنا أفهم crossref من
https://github.com/RPi-Distro/firmware/commits/debian؟author=popcornmix ل
https://github.com/Hexxeh/rpi-firmware/commits/master مصنوع بعناية
مقارنة التواريخ والأوصاف من الالتزامات.

تعلمت شيئا شكرا :)

8 سبتمبر. 2016 8:28 مساءً schreef "Phil Elwell" [email protected] :

ربما - cat /boot/.firmware_revision تمت كتابته بواسطة تحديث rpi ، لكن
دون أن أجربها لم أستطع إخبارك ما إذا كانت إصدارات Raspbian تكتب أيضًا
عليه.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment -245693018 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AFyzOQ_pfODaEmuBGR6pQVXs2W6LggW8ks5qoFO2gaJpZM4HupC5
.

BenoitSvB : يبدو أن المشكلات - لا تقدم البرامج الثابتة أي أدلة حول سبب قطع الاتصال. قد تحصل على المزيد من القرائن من متلصص حزم مثل WaveShark.

mathieugouin @ درهم كونكت @ juched78maciexduncanmcdowell: لدي مهندس السرو الذي يحرص على معرفة المزيد حول القضايا الخاصة بك. إذا قمت بإرسال بريد إلكتروني إليّ - phil في raspberrypi dot org - يمكنني أن أضعك على اتصال معه. إذا كنت ترغب في تسريع الأمور ، فقم بتثبيت وحدات التصحيح كما هو موضح أعلاه واحفظ إخراج dmesg عندما تسوء الأمور.

pelwell لم تقدم Google الكثير من المعلومات الأساسية على "حزمة الشم Waveshark" ولكن أعتقد أنك تقصد WireShark. حقيقة أن إدراج brcmutil & brcmfmac في القائمة السوداء أثناء استخدام دونجل MT7601U يجعل سلوك الاتصال / قطع الاتصال غير المنتظم يختفي ، جنبًا إلى جنب مع الأحداث المتكررة "خارج الترتيب" (انظر # 1313 ، الآن مخفية ولكن لم يتم حلها) تجعلني أشك في Broadcom / سبب أجهزة السرو.
قد يكون Wireshark مفيدًا ، لكنني سأحتاج إلى مساعدة لإعداد / إجراء جهد جاد في تصحيح الأخطاء في الأجهزة.

نعم ، قصدت wireshark.

يمكنك استخدام الأداة المساعدة dumpcap (جزء من حزمة وضع النص tshark) لتسجيل كل الأنشطة في ملف ، ثم قتلها عندما يتضمن سجل dmesg رسالة مريبة. شيء من هذا القبيل:

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

لاحظ أنه على الرغم من أنه من المفترض أن تتوقف "grep --max-count 1" بعد مباراة واحدة ، يبدو أنها تتطلب سطرًا إضافيًا من الإدخال لإيقافها بالفعل ، ولكن لا ينبغي أن يكون ذلك مشكلة في الممارسة.

إذا أصبح ملف الالتقاط كبيرًا جدًا ، يمكنك الحصول على dumpcap لاستخدام تسجيل لمدة محددة باستخدام الخيار "-b المدة: 60 " (لمدة دقيقة واحدة). هناك احتمال أن تحدث إعادة الالتقاط مثل هذا في وقت سيئ وتفقد الحزم المثيرة للاهتمام ، لكن هذا غير مرجح. يمكنك دائمًا تقليل احتمالية حدوث ذلك عن طريق زيادة المدة.

BenoitSvB يوجد مؤشر ترابط هنا يقترح تعطيل التجوال في برنامج تشغيل Pi3 WiFi كطريقة لتجنب مشكلات الاتصال. يسمح التجوال للجهاز بالتنقل تلقائيًا بين نقاط الوصول التي لها نفس SSID ، ولكن من المحتمل أن يكون ذلك أقل فائدة على جهاز ثابت مثل Pi3 ، وهناك اقتراح بأنه يمكن أن يؤدي في النهاية إلى فقدان الاتصال التام.

هل يمكنك محاولة تمكين معلمة الوحدة النمطية roamoff ؟ تحتاج إلى إنشاء /etc/modprobe.d/brcmfmac.conf يحتوي على ما يلي:

options brcmfmac roamoff=1

pelwell : تعطيل التجوال ليس هو الحل ؛ لكنها تجعلني ألعب بقنوات مختلفة ونقطة وصول ثانية. اكتشفت أن محول wifi الموجود على اللوحة لا يواجه سوى مشاكل مع بعض القنوات (على سبيل المثال 1 ، 5) وفقط على Linksys WRT160N مع البرامج الثابتة DD-WRT. من الغريب أنه على الرغم من عدم مشاركة أي من عملاء wifi الآخرين في هذه المشكلات: سيتصلون دون مشاكل على جميع القنوات المعروضة على كلا نقطتي الوصول. جيد بالنسبة لي ، لدي حل مستقر (عدم استخدام القنوات على متن شبكة wifi بها مشاكل) ولكن لا يوجد وضوح في الأمر.
هل تريد مني إجراء اختبار محدد؟
بالمناسبة نحن بحاجة إلى ضبط المعلمة
options brcmfmac debug = 1
في /etc/modprobe.d/brcmfmac.conf أثناء استخدام برامج تشغيل الاختبار الخاصة؟
وهل تعرف طريقة لقياس وقت تشغيل ارتباط شبكة wifi: عندها يمكنني اختبار جميع القنوات بشكل أكثر منهجية لفترات أطول دون إنشاء ملفات التقاط ضخمة.

لقد تأكدت من تمكين التصحيح المطلوب في برامج تشغيل تصحيح الأخطاء بشكل افتراضي (له نفس تأثير options bcrmfmac debug=0x100000 ) ، لكن لا تتردد في تجربة قيم مختلفة.

لست على دراية بأي طريقة لقياس وقت تشغيل إحدى الجمعيات ، بخلاف الاقتراع المتكرر وآمل في اكتشاف التغيير.

أحد موظفي Cypress على علم بهذا الموضوع ، لكن أرسل لي بريدًا إلكترونيًا (phil at raspberrypi dot org) إذا كنت سعيدًا بتواصلك مباشرة.

مرحبا،

هل هناك أي تقدم في هذه القضية؟ يمكنني الاتصال بشبكة Wi-Fi المفتوحة الخاصة بي ، وبعد فترة عشوائية لدي هذا في سجلاتي:

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

وبعد ذلك لا يمكنني اختبار اتصال جهاز التوجيه.

بعد ifdown wlan0 && ifup wlan0 سيعمل مرة أخرى ، حتى wlan0: carrier lost .

إدارة الطاقة معطلة ، البلوتوث معطل ، التجوال معطل (كما اقترحت) وإصداري هو Linux pi3 4.4.17-v7+ .

لقد حدث ذلك دائمًا عند جسر eth0 مع wlan0 حصلت على نفس المشكلة مثل https://github.com/raspberrypi/linux/issues/1375

لدي نفس المشكلة تمامًا من Pi3 WiFi على متن الطائرة بعد فترة زمنية عشوائية. ifup يعيد تشغيله مرة أخرى فلا مشكلة.

بعد إجراء الكثير من التحقيق ، وجدت أنه كان بسبب وجود ثلاث نقاط وصول (BSSID) مع SSID واحد (واحد لكل قناة 1 و 6 و 11). يدعم هذا الإعداد التجوال السلس ويعمل بشكل مثالي مع جميع عملاء WLAN الآخرين.

يبدو أن تمكين التصحيح / التسجيل باستخدام برنامج التشغيل القياسي يُظهر أنه في مرحلة ما ، يقرر Pi إلغاء المصادقة وحتى إدراج أحد معرّفات BSSID في القائمة السوداء. السبب غير واضح ، ولكن يبدو أنه قرار تم اتخاذه في نهاية Pi.

عندما يكون لدي نفس التكوين تمامًا على Pi ولكن مع BSSID واحد فقط لمعرف SSID ، يمكن لـ Pi البقاء على قيد الحياة لعدة أيام دون وجود عوائق.

لسوء الحظ ، فإن تعطيل التجوال وفقًا لرابط pelwell (http://projectable.me/optimize-my-pi-wi-fi/) ليس ممكنًا حقًا ، فوجود BSSID واحد فقط لكل SSID ليس خيارًا ، وأنا بدلاً من ذلك ، لا يتعين عليك الاعتماد على برنامج نصي يقوم بإجراء ping لبعض المضيفين ثم يقوم بتشغيل ifdown / ifup.

هل يتم إجراء أي تحقيق إضافي لدعم معرّفات BSSID متعددة لكل SSID ، أم يمكنني القيام بشيء خاص لدعم التحقيق؟

شكر!

أواجه هذه المشكلة وشبكتي تشبه
لدي محطة أساسية من Apple ومطار سريع بتكوين شبكة باستخدام WDS.

أواجه هذه المشكلة أيضًا. إذا قمت بنسخ الملفات إلى مشاركة samba ، فسيتم فقد اتصال wifi (Raspberry 3 ، raspbian جديد مثبت).
سجل النظام:
brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012

أواجه نفس المشكلة تمامًا عند تشغيل الموسيقى باستخدام upnp (gmediarender).

أواجه نفس المشكلة عند بدء المكالمات الصوتية على wechat ، مع rpi كـ AP باستخدام hostapd. أحصل على مجموعة من الرسائل غير المرغوب فيها مثل هذا:

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

بآثار مثل هذا:

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

يبدو التتبع مشابهًا بشكل مثير للريبة لـ

لقد حدث هذا مرة أخرى ، وقمت ببعض التصحيح. تلقيت بعض الرسائل المختلفة هذه المرة ، والتي تبدو مثيرة للاهتمام (يبدو أنها نفس الرسائل التي تلقاها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. يبدو أن النظام بأكمله يتجمد عند حدوث ذلك. يؤدي تشغيل while sleep 1; do date; done في حلقة إلى حدوث فجوة عند حدوث التجميد. أتساءل عما إذا كان هذا يعني أن عودة brcmf_proto_bcdc_msg -110 (مهلة) هي مجرد عرض من أعراض المشكلة الحقيقية - فهي تسجل فقط أينما تجمدنا.
2. لقد قمت بقياس درجة الحرارة والفولتية ( vcgencmd ) في وقت التجميد. لا شيء للإبلاغ عنه هناك ، بقدر ما أستطيع أن أقول.
3. نظامي هو AP مع إعادة توجيه إلى مودم ZTE 4G عبر USB (على سبيل المثال client -> wlan0 -> rpi -> usb0 -> 4g . يبدو أن USB0 لا يزال قادرًا على الوصول إلى الإنترنت عند حدوث تجميد wifi.

رد: التعليقات أعلاه ، يحدث هذا في وضع مشاركة NAT بالنسبة لي roamoff=1 . لم يتم إصلاح المشكلة أو التخفيف من حدتها بالنسبة لي.

بعد تعطيل WPA (باستخدام create_ap -w 2 في حالتي لتمكين WPA2 فقط) ، يبدو أن المشكلة قد تم إصلاحها. من غير الواضح لماذا بالرغم من ذلك.

أنا أيضا أواجه القضايا المذكورة هنا. في حالتي ، يحدث ذلك عندما أصل إلى الملفات (عادةً mp3) عبر Samba من مشغل ومشغل ملفات Samsung + ES.

raspberry pi3 الخاص بي هو wifi متصل بنقطة الوصول الخاصة بي. لذلك يُعتقد أن جميع الاتصالات معها هي شبكة wifi. لا يحتوي على أي شاشة ولا لوحة مفاتيح ولا ماوس.

يمكنني إعادة إنتاج الخطأ بسهولة ، لذا إذا أراد أي شخص مني إنشاء ملفات السجل ، فأخبرني كيف يمكنني المساعدة.

أسفل إدخالات سجل النظام الخاصة بي.

27 ديسمبر 16:11:50 نواة raspberrypi: [560.902063] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
27 ديسمبر 16:11:52 نواة raspberrypi: [562.928930] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
27 ديسمبر 16:11:54 نواة raspberrypi: [564.926659] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
27 ديسمبر 16:11:54 نواة raspberrypi: [564.926820] brcmfmac: brcmf_cfg80211_get_station: فشل الحصول على معلومات STA ، -52
27 ديسمبر 16:11:56 نواة raspberrypi: [566.924560] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
27 ديسمبر 16:11:58 نواة raspberrypi: [568.922555] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
27 كانون الأول (ديسمبر) 16:11:58 kernel raspberrypi: [568.928073] brcmfmac: brcmf_cfg80211_get_station: فشل الحصول على معلومات STA ، -52
27 ديسمبر 16:12:00 نواة raspberrypi: [570.920675] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
27 ديسمبر 16:12:02 raspberrypi kernel: [572.918980] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
27 ديسمبر 16:12:02 raspberrypi kernel: [572.924580] brcmfmac: brcmf_cfg80211_get_station: فشل الحصول على معلومات STA ، -52
27 ديسمبر 16:12:04 نواة raspberrypi: [574.917259] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
27 ديسمبر 16:12:06 نواة raspberrypi: [576.915703] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
27 ديسمبر 16:12:06 نواة raspberrypi: [576.921498] brcmfmac: brcmf_cfg80211_get_station: فشل GET STA INFO ، -52
27 ديسمبر 16:12:06 raspberrypi ifplugd (wlan0) [1149]: استخدام وضع الكشف: IFF_RUNNING

تضمين التغريدة
لدي أيضًا نفس المشكلة مع الإعداد نفسه.

الحل بعد ساعات من التصحيح:
قم بإيقاف تشغيل IPv6 على raspberry في /etc/modprobe.d/ipv6.conf:
الاسم المستعار net-pf-10 قبالة
الاسم المستعار ipv6 قبالة
خيارات ipv6 disable_ipv6 = 1

هذا ليس سوى حل بديل إذا كنت لا تستخدم IPv6 في شبكتك.

شكرا @ varl0g أنت بطلي! :)
يبدو أن هذا الحل يعمل بالنسبة لي ، لا يمكن إعادة إنتاج المشكلة بعد الآن.

@ varl0g : لقد

شكرا وسعيد 2017.

حاولت إيقاف تشغيل IPv6. هذا لم يحدث فرقا. حاولت إيقاف تشغيل وضع توفير الطاقة. لا يوجد فرق. ومع ذلك ، عندما قمت بتعيين قناة AP الخاصة بي على 6 (بدلاً من 11) ، كان Raspberry Pi الخاص بي يعمل لمدة يومين دون أي مشاكل!

أود أن أؤكد أن الحل البديل لإيقاف تشغيل IPv6 لا يعمل.
لسوء الحظ ، لدي نفس المشكلة مع جهاز التوجيه RPi3 و Apple Airport Extreme.

rajid ، @ dh-connect
من المثير للدهشة أنها حلت مشكلتي أيضًا عندما قمت بتغيير قناة wifi الخاصة بـ AP إلى 6 بدلاً من تلقائية ، شكرًا

لدي هذا الخطأ أيضًا - brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
أين الإصلاح ؟؟؟؟
أحاول 4.9 kernel، 4.4.41 kernel - كلهم ​​لديهم هذا الخطأ. امدادات الطاقة 2.4a.

يجب أن ألغي تعليقي السابق بخصوص القناة 6. على ما يبدو ، كانت مصادفة أن RPI3 لديّ شبكة WiFi مستقرة لمدة 6 أيام.

فقط أتساءل عما إذا كان أي شخص لديه أي حظ في هذه المشكلة. لقد حاولت تعطيل إدارة الطاقة والبلوتوث وتبديل القنوات. لم ينجح أي شيء حتى الآن. أنا أقوم بتشغيل Octoprint مع كاميرا ويب متصلة. يبدو أنه يحدث في كثير من الأحيان إلى حد ما ، وقد لاحظت أنه يحدث كثيرًا بشكل متكرر عندما يكون لدي أكثر من اتصال http واحد.
خطأ في سجل النظام قبل وضع توفير الطاقة:
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
خطأ في سجل النظام بعد وضع توفير الطاقة:
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 !!!
أدير حاليًا Linux octopi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

أخيرًا حصلت على RaspPi 3 الخاص بي ليكون مستقرًا على شبكة wifi الخاصة بي عن طريق تغيير قناة wifi الخاصة بي 2.4 جيجا هرتز إلى "6". لقد نسيت ما كان عليه من قبل ، 11 أعتقد ولكني لست متأكدًا. لم يعمل ذلك بشكل جيد ووجدت صفحة ويب قالت إنها مشكلة ولكن 6 تعمل بشكل جيد. لقد كان أفضل بكثير منذ أن قمت بتحويل منزلي wifi إلى القناة 6.

/ راج

في 3 آذار (مارس) 2017 ، الساعة 8:39 مساءً ، كتب دانيال < [email protected] [email protected] >:

فقط أتساءل عما إذا كان أي شخص لديه أي حظ في هذه المشكلة. لقد حاولت تعطيل إدارة الطاقة والبلوتوث وتبديل القنوات. لم ينجح أي شيء حتى الآن. أنا أقوم بتشغيل Octoprint مع كاميرا ويب متصلة. يبدو أنه يحدث في كثير من الأحيان إلى حد ما ، وقد لاحظت أنه يحدث كثيرًا بشكل متكرر عندما يكون لدي أكثر من اتصال http واحد.
خطأ في سجل النظام قبل وضع توفير الطاقة:
brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
خطأ في سجل النظام بعد وضع توفير الطاقة:
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 !!!
أقوم حاليًا بتشغيل Linux octopi 4.1.19-v7 + # 858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU / Linux

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-284126948 ، أو تجاهل الموضوع 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

تبدو القناة 6 ، وعرض القناة 20 ميغا هرتز ، مستقرة لأسابيع الآن.

لقد لاحظت نفس المشكلة التي أدى إيقاف تشغيل IPv6 على النحو الذي اقترحه مشكلاتي . أصبح Wifi الآن مستقرًا لأيام وأيام بينما كان يتعطل سابقًا بعد دقائق من بدء التشغيل.

لم يحالفني الحظ في القناة 6 أو 7. لم يؤكد أي شخص آخر على تلك القنوات.
حاولت وميض sd الخاص بي بصورة جديدة والآن لا تحصل وحدات تحكم wifi الخاصة بي على عقود إيجار DHCP المناسبة. إنهم يقومون بالتمهيد باستخدام 169.254.xx.xx ips المحلية ، وليس الشبكة الفرعية من خادم dhcp الخاص بي.

قررت فقط مسحه والذهاب لتثبيت أحدث raspbian وتثبيت octoprint من المصدر. حتى الآن لا توجد مشاكل.

مما يمكنني قوله ، هذه مشكلة في برنامج التشغيل لـ brcm80211 sdio.c نفسه.
السلسلة 0x40012 هي في الحقيقة 0x00040012 ، والتي عند تفسيرها باستخدام الأقنعة والرموز من هنا ~ السطر 55 ، يمكن اعتبارها سلسلة صندوق بريد تشير إلى تغيير التحكم في التدفق إلى DEVREADY. الشيء الغريب هو أن السلسلة لا يتم تفسيرها أبدًا على هذا النحو ، وبالتالي تصل إلى القسم المتوافق مع الإصدارات السابقة من برنامج التشغيل ~ السطر 1127 من ملف sdio.c داخل مصدر brcm80211 / brcmfmac هنا ..

ليس لدي خبرة كبيرة مع السائق ، نفسه ، ولا القدرة على إعادة الترجمة والاختبار (لدي rpi3 واحد فقط ، وأنا أفضل عدم إفساد البيئة التي يعيش فيها حاليًا. أيضًا ، أنا " لست على دراية بإعادة ترجمة / تحديث برامج تشغيل Linux ..) لذلك أنا لست إيجابيًا تمامًا ، ولكن يبدو أنه يتم إرسال رسالتين HMB متتاليتين بسرعة كبيرة ، وليس لدى السائق الوقت الكافي لتفسيرهما .

لأولئك الذين يتساءلون ، أقوم حاليًا بتشغيل Octoprint (بني يدويًا) على rpi3 الخاص بي عبر اللاسلكي (duh ..) باستخدام شاشة اللمس السعوية adafruit 2.8 بوصة ونواة adafruit المخصصة (الإصدار 4.4.27-v7 +) وتكرار المشكلة عند محاولة الوصول إلى دفق الفيديو (Logitech C270) على جهاز Samsung Galaxy S7 الخاص بي عبر PrintDroid pro أو عبر Chrome. يحدث القفل دون فشل في كل مرة يتم فيها إجراء ذلك ، ويحدث فقط على الاتصال اللاسلكي. لقد قمت بترقية مصدر الطاقة ، وقمت بتعطيل ipv6 و إدارة الطاقة ، دون جدوى.

TGYK هل يمكنك التحقق من المشكلة المشار إليها - هل تبدو هي نفسها بالنسبة لك؟ ما هي الرسائل التي تحصل عليها في dmesg؟ كيفنت انخفض؟

تضمين التغريدة لقد قمت بالربط بصفحة Broadcom github الأصلية - هل يمكنك إعطاء بعض الإشارات إلى مكان ظهور المشكلات في شجرة نواة Raspberry Pi هنا؟ من الصعب بعض الشيء تعقب أسطر الكود التي تشير إليها.

يوجد sdio.c هنا في شجرة 4.9 https://github.com/raspberrypi/linux/tree/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac.

@ JamesH65 في صفحة github التي قمت بربطها ، يقع السطر الذي أشير إليه حول 1140-1147. بقدر ما الخطأ dmesg ، الرسالة هي نفس المشكلة كما رأينا أعلاه:
"محتوى بيانات صندوق بريد غير معروف: 0x40012" ، متبوعًا بأخطاء escan (-52).

لا تحدث نفس المشكلة مثل موضوعك المشار إليه ، حيث إنني لا أقوم بتوصيل الواجهات اللاسلكية والسلكية بأي شكل من الأشكال. بقدر ما أستطيع أن أقول ، فإن مشكلتي ومسألة هذا الموضوع تتعلق فقط بالواجهة اللاسلكية.

اشكرك على المعلومات. أعتقد أن المشكلة المرتبطة ربما تكون متشابهة من حيث أنها مشكلة مع برنامج تشغيل Wifi ربما تتلقى رسالة غريبة تسبب المزيد من الغرابة لاحقًا في المكدس ، لكنني ما زلت أحفر.

أواجه نفس المشكلة مع raspberry pi Zero W مع أعراض مشابهة مثلTGYK. في حالتي ، أقوم بتشغيل mpd على الصفر ، والتحكم فيه عبر عميل android على Samsung Galaxy S5. بدون فشل ، إذا وضعت الهاتف في وضع الاستعداد أثناء تشغيل تطبيق وحدة التحكم (على سبيل المثال ، دون العودة إلى الشاشة الرئيسية أولاً) ، فإن wifi الخاص بالصفر ينقطع مع رسالة "محتوى بيانات صندوق البريد غير المعروف". إذا تركت الجهاز في وضع الخمول ، أو كنت حريصًا على إغلاق التطبيق دائمًا قبل ترك هاتفي في وضع السكون ، فسيظل يعمل إلى أجل غير مسمى.

لقد واجهت هذه المشكلة على Raspian والآن OSMC.

غالبًا ما يكون متقطعًا ، ولكن من المثير للاهتمام أن الوصول إلى واجهة الويب Kodi من S7 الخاص بي سيؤدي دائمًا إلى حدوث هذه المشكلة. إن القيام بالشيء نفسه من جهاز iPhone الخاص بزوجتي يعمل بشكل لا تشوبه شائبة ولم يتسبب في حدوث المشكلة مطلقًا.

daedalia : لدي مشكلة مشابهة جدًا مع Samsung Galaxy Tab S. ومع ذلك ، لا يمكنني الوصول إلى جهاز iPhone / iPad لتأكيد ...

يعطل جهاز Samsung الخاص بي شبكة wifi عند محاولة الوصول إلى واجهة الويب tvheadend.

لا يحدث ذلك عند الوصول إليه من متصفح Firefox من جهاز كمبيوتر يعمل بنظام Windows.

سعيد لأنني وجدت هذا الموضوع ، أعتقد أنني كنت الوحيد. أواجه نفس المشكلات مثل الملصقات أعلاه ، وانقطاع wifi على pi3 / osmc الخاص بي عند الوصول إليه من Samsung Galaxy Tab A. يعمل بشكل جيد إذا تم الوصول إليه من جهاز Nexus 7 اللوحي أو هاتف OnePlus أو كمبيوتر محمول Acer ، فقط Samsung هي التي تسبب المشاكل. قابل للتكرار بسهولة. يبدو أن برنامج تشغيل samsung wifi لا يحب واي فاي pi3 المدمج؟ تعد إضافة tp-link wifi dongle إلى pi3 بمثابة حل بديل بالنسبة لي.

philborman لدي فضول ، هل تستخدم متصفح الهاتف المحمول نفسه على Samsung مقابل Nexus؟

كلاهما يعمل بالكروم ، ولكنها ليست مجرد مشكلة في المتصفح. إذا كنت أستخدم Yatse لـ
التحكم في kodi يعمل بشكل جيد من nexus / mobile / laptop لكن pi3 WiFi يسقط
إذا حاولت نفس الشيء من سامسونج. نفس الشيء إذا كنت ssh في ، تعطل مع Samsung
وليس الآخرين. مع ssh يمكنني أن أفعل القليل ، لكن أي نقل ملفات أو
حتى تحرير ملف نصي سيؤدي إلى قطع اتصال wifi.

في الأربعاء ، 12 أبريل 2017 ، الساعة 19:03 ، كتب ماثيو جوين ، [email protected] :

philborman https://github.com/philborman أنا فضولي ، هل تستخدم ملف
متصفح الهاتف المحمول نفسه على Samsung مقابل Nexus؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-293643847 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ALmHOdtJ9AQtpfU7tmeVouI-a4STg2WMks5rvQPJgaJpZM4HupC5
.

هل لدى أي شخص يعلق هنا القدرة على بناء نواة باستخدام رقعة لدي قد تساعد في ذلك؟ هذه تستند إلى 4.9 ولكنها قد تعمل بشكل جيد على 4.4. ملاحظة ، هذه فقط اختبارات ...

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

مرحبا،

لدي نفس المشكلة الموضحة هنا مع واحدة من 2 Pi3. يفقد الاتصال بشبكة Wifi الاتصال بعد مرور بعض الوقت ، ويمكن أن يكون ذلك بين 30 دقيقة وبضع ساعات. لقد جربت كل ما هو مقترح هنا تمامًا ، بما في ذلك تغيير قنوات wifi على AP ، وما إلى ذلك ... دون نجاح. الأمر الغريب للغاية هو أنه في النسخة الثانية من Pi3 (المراجعة 1.2 أيضًا ، هي نفسها تمامًا) ، وبنفس بطاقة SD / التثبيت (Raspbian) التي قمت بالتبديل بينها ، فإن Wifi يكون صخريًا لأيام وأيام ...

هذا غريب حقا. تم تحديث كل من Pi3 بتحديث rpi و kernel 4.9 والبرنامج الثابت رقم 991 ، ولكنه كان هو نفسه بالفعل مع إصدارات kernel / البرامج الثابتة السابقة.

إذا قمت بإجراء تحديث rpi ، فستحصل على التصحيحات المذكورة أعلاه على النحو المقبول من قِبل مطوري kernel - وهذا خاص ببرنامج تشغيل smsc9x وبرنامج تشغيل brcmfmac ، اعتبارًا من الليلة الماضية. هل يمكنك تجربة ذلك؟ إذا استمر فشل ذلك ، فهل يمكنك عمل "dmesg" ومعرفة ما إذا كان هناك أي شيء غريب في سجل النظام؟ على الرغم من أن شكوكي ربما يكون خطأ HW واضحًا حيث ترتفع درجة حرارة الشريحة اللاسلكية نظرًا لأن Pi آخر يعمل بشكل جيد مع نفس البطاقة.

شكر. لقد فعلت ذلك على السبورة المشبوهة ، وانقطع اتصال wifi بعد بضع دقائق.
يعطي dmesg ما يلي:
"
[266.654964] brcmfmac: brcmf_sdio_bus_sleep: خطأ أثناء تغيير حالة سكون الناقل -110
[266.655033] brcmfmac: brcmf_sdio_txfail: خطأ sdio ، أمر إحباط وإطار إنهاء
[266.659215] brcmfmac: brcmf_sdiod_regrw_helper: فشل في كتابة البيانات F1 @ 0x1000d ، err: -110
[266.663346] brcmfmac: brcmf_sdiod_regrw_helper: فشلت قراءة البيانات F1 @ 0x1001a ،
[266.667472] brcmfmac: brcmf_sdiod_regrw_helper: فشلت قراءة البيانات F1 @ 0x10019 ،
[266.671608] brcmfmac: brcmf_sdiod_regrw_helper: فشلت قراءة البيانات F1 @ 0x1001a ،
[266.675736] brcmfmac: brcmf_sdiod_regrw_helper: فشلت قراءة البيانات F1 @ 0x10019 ،
[266.679866] brcmfmac: brcmf_sdiod_regrw_helper: فشلت قراءة البيانات F1 @ 0x1001a ،
[266.683992] brcmfmac: brcmf_sdiod_regrw_helper: فشلت قراءة البيانات F1 @ 0x10019 ،
[269.655049] brcmfmac: brcmf_sdio_bus_sleep: خطأ أثناء تغيير حالة سكون الناقل -110
[272.069378] net_ratelimit: تم منع 35 رد نداء

......... ثم هذه "الحلقة" تحافظ على ملء سجل dmesg عدة مرات في الدقيقة.

تحرير: لقد لمست جميع المكونات الموجودة على السبورة ، فكل شيء ما عدا ساخنة ، أود أن أقول حوالي 30 درجة ، فقط أكثر دفئًا من جلد أصابعي.

حسنًا ، عناصر SDIO هي الواجهة بين Pi والشريحة اللاسلكية - لقد انتهت المهلة (-110). تبدو هذه مشكلة في المخلفات الخطرة - مع تسخين الشريحة ، ربما يكون هناك مفصل لحام سيئ على خطوط واجهة sdio في مكان ما مما يعني قطع اتصال comms.

Ping @ Roger-Thornton - روجر ، هل هناك أي شيء يمكننا القيام به لاختبار هذا؟

Crrispy هل يمكنك التحقق من أن Pi الخاص بك ليس ضعيفًا - ما الذي يشير إليه vcgencmd get_throttled ؟

pelwell : بعد خسارة wifi ، راجعت ،

لا أعتقد أنه خطأ في الجهاز ، فعملية إعادة التشغيل البسيطة تحل المشكلة دائمًا على الفور.

@ JamesH65 لا أعتقد أن هذا يبدو وكأنه مشكلة في تصنيع الأجهزة حيث تعمل جميع الخطوط كما ينبغي. إذا كانت هناك مؤشرات أخرى لمشكلات الأجهزة ، فيمكنني إلقاء نظرة على اللوحة.

لا يبدو أنها نفس مشكلتي. لديّ pi3 واحد فقط وهو
wifi صخري حتى أقوم بالاتصال من جهاز Samsung اللوحي. متصل مع
أي شيء آخر ولا بأس. لا يبدو أن السلطة أو ارتفاع درجة الحرارة
مرتبط لأنه لا بأس به لأيام حتى أتصل من الخطأ
الجهاز اللوحي ويسقط.

أظن أنه يتعلق ببرنامج التشغيل أو البرنامج الثابت ، وهو شيء يخص سامسونج
يرسل السائق أن pi3 لا يحب.

في الخميس ، 27 أبريل 2017 ، الساعة 22:01 ، كتب Crrispy ، [email protected] :

pelwell https://github.com/pelwell : بعد فقدان شبكة wifi ، راجعت و
مخنوق = 0 × 0

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297823068 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ALmHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5
.

كان هناك نوعان من الإصلاحات للتواصل في أحدث إصدارات raspbian -
متى كانت آخر مرة قمت فيها بعمل ملف

sudo apt-get update
sudo apt-get dist-Upgrade

؟
قد يستحق المحاولة لمعرفة ما إذا كان يصلح الأشياء.

في 28 أبريل 2017 الساعة 14:38 ، كتب philborman [email protected] :

لا يبدو أنها نفس مشكلتي. لديّ pi3 واحد فقط وهو
wifi صخري حتى أقوم بالاتصال من جهاز Samsung اللوحي. متصل مع
أي شيء آخر ولا بأس. لا يبدو أن السلطة أو ارتفاع درجة الحرارة
مرتبط لأنه لا بأس به لأيام حتى أتصل من الخطأ
الجهاز اللوحي ويسقط.

أظن أنه يتعلق ببرنامج التشغيل أو البرنامج الثابت ، وهو شيء يخص سامسونج
يرسل السائق أن pi3 لا يحب.

في الخميس ، 27 أبريل 2017 ، الساعة 22:01 ، كتب Crrispy ، [email protected] :

pelwell https://github.com/pelwell : بعد خسارة wifi ، راجعت ،
و
مخنوق = 0 × 0

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
و
أو كتم الخيط
almHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHag08r5c96nB39R3F-mFW772qBbGks5r0evJgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

لدي نفس المشكلة مع raspbery pi zero W. بعد مرور بعض الوقت ، لم أتمكن من التعامل معها. حاولت كل شيء. إحدى الحقائق المضحكة هي ... عندما قمت بتوصيل rpi بجهاز التلفزيون الخاص بي للقيام ببعض استكشاف الأخطاء وإصلاحها بعد أن لن أكون قادرًا على ssh ... كان يعمل لمدة 18 ساعة من الصخور الصلبة. بعد ذلك ، قمت بتبديل HDMI لجهاز آخر وبعد مرور بعض الوقت عندما أردت ssh إلى pi حصلت على معلومات جميلة "لا يوجد طريق للاستضافة". عندما أقوم بتوصيل كابل HDMI مرة أخرى ، تمكنت من استخدام بوابة ping. لا يوجد خطأ في السجلات ، يبدو أن iwconfig جيد. ساعد إعادة تشغيل systemctl الشبكات.

على النحو الوارد أعلاه ، يرجى تجربة أحدث إصدار من Raspbian ، والإبلاغ مرة أخرى إذا كنت لا تزال ترى
المشكلة.

في 28 أبريل 2017 الساعة 19:30 ، كتب frankja2 [email protected] :

لدي نفس المشكلة مع raspbery pi zero W. بعد مرور بعض الوقت لست كذلك
قادرة على ssh لها. حاولت كل شيء. حقيقة واحدة مضحكة هي ... عندما اتصلت
rpi على جهاز التلفزيون الخاص بي للقيام ببعض استكشاف الأخطاء وإصلاحها بعد أن لن أتمكن من ssh
كانت تعمل من أجل 18 ساعة من الصخور الصلبة. ثم قمت بتبديل HDMI للآخر
الجهاز وبعد مرور بعض الوقت عندما أردت ssh to pi حصلت على جميلة "لا
الطريق إلى المضيف "المعلومات. عندما أقوم بتوصيل كابل HDMI مرة أخرى ، تمكنت من إجراء اختبار ping
بوابة. ساعد إعادة تشغيل systemctl الشبكات.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

قد أكون الشخص الوحيد الذي يعاني من مشكلة ما ، لكنني اكتشفت أن رمز البلد الخاص بي لملف wpa_supplicant.conf قد تم تعيينه بشكل خاطئ (فاتني أنه عنصر تكوين منفصل عن خيارات الترجمة الأخرى). لن أقول إن المشكلة اختفت تمامًا ، ولكن بمجرد أن أصلحت ذلك ، توقفت عن فقدان اتصالها بالشبكة في "كل مرة أتصل فيها من سامسونج" بالطريقة التي كانت عليها من قبل.

لقد قمت بالترقية إلى الأحدث (apt-get dist-Upgrade) وهي تبدو متفائلة
كانت ترقيتي السابقة قبل أسبوعين تقريبًا قبل الإبلاغ عن
مشاكل أولية. يعمل بشكل جيد خلال آخر ساعتين ، لا يوجد wifi
المتسربين على الإطلاق. تشكرات!

في 28/04/17 الساعة 15:53 ​​، كتب جيمس هيوز:

كان هناك نوعان من الإصلاحات للتواصل في أحدث إصدارات raspbian -
متى كانت آخر مرة قمت فيها بعمل ملف

sudo apt-get update
sudo apt-get dist-Upgrade

؟
قد يستحق المحاولة لمعرفة ما إذا كان يصلح الأشياء.

في 28 أبريل 2017 الساعة 14:38 ، كتب philborman [email protected] :

لا يبدو أنها نفس مشكلتي. ليس لدي سوى pi3 و
انها
wifi صخري حتى أقوم بالاتصال من جهاز Samsung اللوحي. متصل مع
أي شيء آخر ولا بأس. لا يبدو أن السلطة أو ارتفاع درجة الحرارة
مرتبط لأنه لا بأس به لأيام حتى أتصل من الخطأ
الجهاز اللوحي ويسقط.

أظن أنه يتعلق ببرنامج التشغيل أو البرنامج الثابت ، وهو شيء يخص سامسونج
يرسل السائق أن pi3 لا يحب.

في الخميس ، 27 أبريل 2017 ، الساعة 22:01 ، كتب Crrispy ، [email protected] :

pelwell https://github.com/pelwell : بعد خسارة wifi ، راجعت ،
و
مخنوق = 0 × 0

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub

< https://github.com/raspberrypi/linux/issues/1342#issuecomment -297823068
و
أو كتم الخيط
almHOU6iNCr2w8vYXwveFIS7jcl71Dr9ks5r0PQBgaJpZM4HupC5>

.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub

https://github.com/raspberrypi/linux/issues/1342#issuecomment-297999952 ،
أو كتم الخيط

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

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298003537 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ALmHORKJxKdws0fMKU5tpfoJHJSah0Ffks5r0e9FgaJpZM4HupC5 .

تم إصلاحه بالنسبة لي في أحدث إصدار.

يبدو أن معظم "الإصلاحات" الأخرى قد فاتت فكرة أن نظامي يعمل
بشكل مثالي مع كل شيء باستثناء جهاز لوحي واحد (Samsung) لذلك يبدو أن
كانت المشكلة هي أن سامسونج ترسل شيئًا برنامج التشغيل / البرامج الثابتة pi3 wifi
لا تستطيع التعامل معها.

إذا تم تعيين رمز بلدي بشكل خاطئ ، فلماذا تتسبب سامسونج فقط
مسائل. الأجهزة اللوحية / الهواتف / الكمبيوتر المحمول الأخرى كلها متصلة بشكل جيد.

على أي حال ، تم إصلاحه الآن - على الأقل لم يسقط في السنوات القليلة الماضية
ساعات. المزيد من الوقت سيخبر ...

في 28/04/17 21:09 ، كتب rraszews:
>

قد أكون الوحيد الذي لديه رأس عظمي بما يكفي ليكون هذا هو المشكلة ، ولكن
اكتشفت أن ملف wpa_supplicant.conf الخاص بي يحتوي على رمز البلد المحدد
خطأ (فاتنا أنه عنصر تكوين منفصل عن الآخر
خيارات الترجمة). لن أقول أن المشكلة اختفت
تمامًا ، ولكن بمجرد إصلاح ذلك ، توقف عن فقدان شبكته
اتصال في "كل مرة أتصل من بلدي سامسونج" الطريق
كان من قبل.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298082370 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ALmHOWtM-_MXCz5RoQd8XShI4Mk-4LAyks5r0jlUgaJpZM4HupC5 .

في حالتي تستمر حوالي 19 ساعة. بعد ذلك لم أستطع ssh بعد الآن ...

ما هو الفرق بين rpi-update و dist-Upgrade؟

لأنه بعد تحديث rpi كان لدي 4.9.25+ # 995 ثم قمت بترقية التوزيع وعادت النواة إلى 4.9.24+ # 993. على أي حال بالنسبة لي لا تزال المشكلة غير ثابتة. ما فعلته هذه المرة هو أنني استخدمت rpi0w آخر و PSU مختلفًا: الخطوة الأخيرة هي استخدام بطاقة sd أخرى.

طيب شكرا على المعلومات.

ستحتاج إلى مزيد من المعلومات لمحاولة تكرارها. الإعداد الخاص بك ، ماذا
لقد قمت بالاتصال ونوع حركة مرور الشبكة الجارية ، وأي سجلات dmesg
أو رسائل خطأ أخرى بمجرد توقف sh عن العمل.

شكر.

في 29 أبريل 2017 الساعة 16:16 ، كتب franko [email protected] :

في حالتي تستمر حوالي 19 ساعة. بعد ذلك يمكنني ssh بعد الآن ...

ما هو الفرق بين rpi-update و dist-Upgrade؟

لأنه بعد تحديث rpi كان لدي 4.9.25+ # 995
https://github.com/raspberrypi/linux/pull/995 ثم صنعت
ترقية dist و kernel عادت إلى 4.9.24+ # 993
https://github.com/raspberrypi/linux/pull/993 . على أي حال بالنسبة لي مشكلة
لا يزال غير ثابت.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-298175041 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHQR8cadrEhb55YJj5PV6PP_odmJmks5r01RJgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

مرحبا،

لقد وضعت Pi3 في علبة بها مروحة قوية جدًا ودرجة الحرارة في الغرفة حاليًا 19 درجة مئوية لذا لا يمكن أن تكون مشكلة حرارة. استبدلت مصدر الطاقة بآخر (5 فولت 3 أمبير أيضًا). استخدام بطاقة SD أخرى ، ترقية التوزيع ثم تحديث rpi.
بالأمس كان الأمر لعدة ساعات ، كنت آمل أن يتم إصلاحه ولكن بعد 3-4 ساعات تم فصله (ping -t يعمل من آلة windoze الخاصة بي).
حاول مرة أخرى هذا الصباح ، توقف wifi بعد أقل من 20 دقيقة :-(
لا يزال الخطأ -110 من برنامج تشغيل wifi على sdio (انظر أعلاه) ، والذي يتكرر في حلقة حتى إعادة التشغيل.
و Pi3 الآخر متصل لمدة 3-4 أيام الآن ، لا مشكلة.
لذلك قد يبدو هذا بمثابة فشل في الأجهزة. لكن .. لماذا لا يفشل أبدًا عند بدء التشغيل ، ويعمل دائمًا بعد إعادة التشغيل؟ محير حقا.
لماذا يحاول تغيير "حالة سكون الناقل" نظرًا لتعطيل إدارة الطاقة لـ wlan0؟ (آسف إذا كان السؤال غبيًا).

أنجزت للتو apt-get update; apt-get dist-upgrade . للأسف لا توجد تغييرات بالنسبة لي. من ملاحظتي ، تتعلق المشكلة بتجسير wlan0 عما إذا كان يمكن أن يكون مرتبطًا بالوضع المختلط. لقد تعبت من rpi-update أيضًا للتحقق من 4.9.25

في الواقع إنه أسوأ من ذي قبل حيث يتم فقد الاتصال الآن عادةً في غضون دقائق قليلة ويمكنني رؤية السجلات المعتادة

[  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

"لأنه بعد تحديث rpi كان لدي 4.9.25+ # 995 وبعد ذلك قمت بترقية التوزيع وعادت kernel إلى 4.9.24+ # 993."

هذا غريب. لقد قمت بترقية التوزيع ، وذهبت إلى 4.9.24+ # 993 وعندما أقوم بتحديث rpi الآن ، تقول أن لدي بالفعل أحدث البرامج الثابتة وليس لديها ما تفعله ... لماذا لا تقوم بالترقية إلى 4.9.25 / # 995؟

في الواقع ، يجب أن نقول أن استخدام brcmfmac/wlan0 bridged يبدو أنه يعمل بشكل أكثر استقرارًا من استخدام wlan0 (كل ذلك مع hostapd)

لذا ، هل يمكنك تقديم وصف كامل ودقيق لإعدادك ، بالإضافة إلى
أنواع الأجهزة المتصلة وأي رسائل خطأ dmesg قد تتلقاها
عندما يفشل الاتصال اللاسلكي.

أحتاج حقًا إلى طريقة ما لتكرار المشكلة لا تستغرق ساعات ، لذا
يتم قبول أي معلومات مقدمة يمكن أن تساعد في ذلك بامتنان.

في 1 مايو 2017 الساعة 17:27 ، كتب Szymon Stasik [email protected] :

في الواقع يجب أن نقول أن استخدام brcmfmac / wlan0 bridged يبدو أنه يعمل أكثر
مستقر من مع شبكة wlan0 نقية (كلها مع hostapd)

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

لا أعرف ما إذا كان هذا مرتبطًا على وجه التحديد بهذا الجانب من المشكلة ولكن IIRC I كان قادرًا على إعادة إنتاج طريقة واحدة بالكامل لإسقاط wifi باستخدام أمر hcitool .. ربما لم يعد ممكنًا بعد الآن ، كان مثل العام الماضي الآن و ذهبنا مع usb wifi لحل المشكلة التي عملت مع مجموعة من rpis ...

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

thomasf ما هو إعداد نظامك (جهاز مستقل ، نقطة وصول ، نقطة وصول

@ JamesH65 لقد قابلة للتكرار بأي تكوين ..

عندما تم تشغيل الأمر hcitool على rpi ، فإنه عادة ما يفقد اتصال شبكة (wifi) في غضون ثوان .. IIRC كان من الأسهل إعادة الإنتاج إذا كان هناك بعض حركة مرور الشبكة على الجهاز (مثل نقل الملفات).

بالنظر سريعًا إلى نظام التزويد النهائي لدينا ، كان wpa_supplicant.conf هو آخر نظام استخدمناه .. أعتقد أنه لا يبدو مختلفًا تمامًا عن النظام الذي تسبب في حدوث مشكلات في واجهة wifi الداخلية ،،، أنا متأكد من ذلك بدأنا في استخدام نقطة وصول واحدة فقط بينما لا تزال هناك مشاكل ..

(تم تنقيح أسماء SSID والمفاتيح):

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

لقد عثرت للتو على برنامج نصي يسمى troublemaker.sh في إعادة الشراء الآن ..

إنه أمر صعب للغاية ، أعتقد أنني قمت بتوفيره للتشغيل عند بدء التشغيل ~ مرة واحدة كل بضع دقائق أو نحو ذلك ~~ (تعديل: ربما مرة واحدة فقط لأنه يقوم ببعض الحلقات بمفرده) على مجموعة من rpi لإثارة المشكلات والحصول على بعض السجلات تم الحفظ..

تم استخدام هذا بشكل أساسي قبل أن أفهم المزيد عن المشكلات .. أعتقد أن أوقات اختبار الاتصال وفقدان الحزم كانا يرتفعان لفترة قبل انقطاع اتصال wifi تمامًا ..

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

تشغيل البرنامج النصي المثير للمشاكل على أحدث إصدار ثابت من Raspbian (4.9 kernel) لا يظهر أي أخطاء ، وهذا أمر جيد ، ولكنه سيء ​​لمحاولة تكرار الأخطاء!

ciekawy إذا نظرنا إلى الوراء ، يبدو أنك قادر على تكرار مشكلة لا يمكننا حلها هنا بسهولة. هل يمكن أن تعطيني فكرة عن الإعداد الدقيق الخاص بك ، حتى أتمكن من التحقيق. من المفيد أيضًا الحصول على آخر تحديث لـ rpi حيث كانت هناك بعض الإصلاحات لـ USB والتي قد تكون ذات صلة أو لا تكون ذات صلة (إذا كنت تستخدم إيثرنت). سأحتاج إلى معرفة طوبولوجيا الشبكة الخاصة بك ، وكيفية إعداد Pi ، وما يبدو أنه يحرض على المشكلة. أي شيء فعلي!

@ JamesH65 ، إعدادي الحالي هو:

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

أيضا بالنسبة ل 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

من الجدير بالذكر أن RPI كان يعمل بشكل مستقر لعدة أيام (على الرغم من أن عمليات النقل التي تدوم 10 ميجا بايت في الثانية كانت قادرة على إحداث بعض المشكلات أيضًا) عندما تم تبديل الأدوار وتم استخدام wlan0 brcmfmac للاتصال بالإنترنت وكانت نقطة الوصول المحلية تعمل على wlan2 ath9k. لقد قمت بتغيير التكوين لأنني بحاجة إلى استخدام هوائي متصل بشبكة wlan2 للوصول إلى الإنترنت.

آخر rpi-updated كان في الأول من مايو

لدي نفس المشكلة بالضبط في rpi3 باستخدام Archlinux-ARM.

بعد بضع ساعات من تشغيل create_ap ، توقف عن العمل مع رسائل dmesg التي أبلغ عنها الآخرون بالفعل:
[11418.347554] brcmfmac: send_key_to_dongle: خطأ wsec_key (-110)

يعمل أحيانًا لمدة يوم واحد دون مشكلة ، وأحيانًا يعمل لمدة دقائق قبل حدوث المشكلة.

منبه Linux 4.9.25-2-ARCH # 1 SMP الجمعة 5 مايو 00:46:52 UTC 2017 armv7l GNU / Linux

نفس المشكلة على Pi Zero W ، Raspbian Lite الحالي. بعد مرور بعض الوقت (يختلف من دقيقة إلى ساعات) عروض "dmesg"
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
من هذا الوقت ، انقطع اتصال wifi ولا يمكن إعادة تشغيله إلا عن طريق rmmod'ing و modprob'ing brcmfmac.

لقد عطلت إدارة الطاقة: لا تغيير.
لقد قمت بتحديث كل شيء عبر apt-get Upgrade / dist-Upgrade: لا تغيير
لقد قمت بتحديث الأشياء عبر تحديث rpi: لا تغيير

brcmfmac هو التنصت بالتأكيد. كنت أعاني من نفس المشكلة مع dmesg msg "brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012" وأحيانًا رسائل مختلفة أيضًا ، مثل التي تم الإبلاغ عنها في رسالتي أعلاه.

أنا أستخدم محول tp-link usb wifi ويعمل تطبيقي بشكل جيد الآن.

آمل أن يتمكن Broadcom من إصلاح الخلل في brcmfmac.

أي حل؟

كما ذكرت في وقت مبكر من هذه المحادثة ، قمت بتغيير جهاز توجيه Wifi الخاص بي لاستخدام القناة 6 بدلاً من 11 (التي كانت تستخدمه من قبل) ، وظل rPi يعمل منذ ذلك الحين (من الخلف في يناير وحتى الآن) دون أي مشاكل في الكل.

قد يكون هذا متعلقًا بملاحظة وحدة kernel هذه:

يحتوي هذا الجيل من الرقائق على دعم تنظيمي إضافي مستقل عن السائق. تستخدم الأجهزة مجالًا تنظيميًا عالميًا واحدًا ، مع القنوات 12-14 (نطاق 2.4 جيجا هرتز) والقنوات 52-64 و 100-140 (نطاق 5 جيجا هرتز) مقيدة بالتشغيل السلبي. يتم منع الإرسال على هذه القنوات حتى يتم ملاحظة حركة أخرى مناسبة على تلك القنوات. داخل برنامج التشغيل ، نستخدم رمز البلد الوهمي "X2" لتمثيل هذا المجال التنظيمي العالمي. لا توجد حاليًا واجهة لتكوين مجال مختلف. يقرأ السائق رمز البلد SROM من الشريحة ويسلمه إلى mac80211 كتلميح تنظيمي ، ولكن هذه المعلومات غير مستخدمة مع السائق.
(من هنا: https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211)

أعتقد أن هذا يعني أنه حتى رمز البلد "DE" (الذي يجب أن يسمح بقنوات wifi أعلى) ليس له أي تأثير؟ لكني لست متأكدًا من أن هذا قد يكون له تأثير مشابه لمشكلة Unknown mailbox data content: 0x40012 ...

على الأقل بالنسبة لي ، ليس هناك حل بديل - تم التبديل من القناة 11 إلى القناة 6 اليوم ، بعد ساعتين: Unknown mailbox data content: 0x40012

لقد واجهت هذه المشكلة حتى قمت بزيادة قوة الإشارة بواسطة موسع النطاق.
هل يمكنك اختبار ما إذا كان الاتصال أكثر استقرارًا مع نقل Pi إلى مكان به إشارة أفضل؟

ربما يكون ناتجًا عن طاقة إضافية مطلوبة للعمل في قوة إشارة ضعيفة.

نفس مشكلة Crrispy.

بالنسبة لأولئك الذين يعملون حول هذا الأمر باستخدام محول USB WiFi (تغيير القناة ، وما إلى ذلك ، لم يعمل معي أيضًا) ، يعمل Edimax EW-7811Un على الفور عندما قمت بتوصيله بكابل OTG USB على RPI Zero W. يجب القيام بأي تكوين أو ifconfig - كان على الشبكة على الفور! بالأمس ، سافرت مع TP-Link Archer T1U AC450 لبضع ساعات.

@ b3nj1 - آسف

اخترت نفس الحل - اشتريت محول USB بهوائي خارجي ومجموعة شرائح mt7601 (حوالي 5 يورو) لجهاز Zero W الخاص بي ، ويعمل بشكل لا تشوبه شائبة. كان يجب أن يشتري الشخص غير W في المقام الأول ... هذه المشكلة موجودة منذ أكثر من عام ولا يوجد حل في الأفق.

blacktigersoftware - هذا غريب ، أليس كذلك؟ يعمل Zero W WiFi بشكل رائع. تعمل تقنية Zero W Bluetooth بشكل رائع. ولكن ، إذا كنت أستخدم كلاهما في نفس الوقت ، يصبح النظام بطيئًا بشكل لا يطاق ولا يمكن الوصول إليه في النهاية عبر شبكة wifi.

تم إلقاء نظرة سريعة على مشكلة maibox الموضحة أعلاه. يُظهر Google أن هذا يبدو أنه يحدث قليلاً (وإشارة واحدة على الأقل إلى نظام أساسي غير Pi). يكتشف رمز برنامج التشغيل أن الرسالة القادمة من صندوق البريد (أفترض وجود اتصال بالبرنامج الثابت HW) بها بعض وحدات البت التي لا ينبغي أن تحتوي عليها. ومع ذلك ، فإنه يطبع الرسائل فقط - لا يقوم بأي استرداد أو إرجاع خطأ. نظرًا لأن هذا يبدو أنه قيمة تم إرجاعها من البرنامج الثابت ، فلا يمكنني الوصول إليها لمعرفة ما يحدث بالفعل ، كما أن ورقة البيانات الموجودة على الشريحة غير مفيدة تمامًا. لذلك أعتقد أن هؤلاء بحاجة إلى دفعهم إلى Broadcom / Cypress / linux-wireless للتحقيق.

تجدر الإشارة أيضًا إلى أننا نمتلك على ما يبدو أحدث البرامج الثابتة HW وفقًا لـ https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm. الملفات لها اختلاف واحد أو اثنين بايت في الطول ولكن هذا كل شيء.

تكمن المشكلة في أن خطأ صندوق البريد متبوع بأخطاء أخرى (-52 ، -110 ، إلخ) ، وإعادة تشغيل نظام wifi مرة أخرى للعمل.

-110 هو خطأ مهلة يشير إلى موت شيء آخر ولا يستجيب. -52 هو تبادل غير صالح ، وهو على نفس المنوال. أظن أنه بحلول الوقت الذي حدث فيه خطأ صندوق البريد ، يكون البرنامج الثابت على الشريحة مريضًا ، لذلك تستمر هذه الأخطاء الأخرى من ذلك.

هل يستطيع أي شخص يمكنه تكرار المشكلة إنشاء أحدث إصدار من Pi dev kernel (4.11 ، متاح من github الخاص بنا) ومعرفة ما إذا كان خطأ صندوق البريد لا يزال يحدث. قبل أن أبدأ بالدفع لأعلى ، أود أن أعرف أنه لا يزال يحدث على أحدث نواة ، ولم أتمكن من تكرارها.

يمكنني تأكيد حدوث المشكلة في: Linux alarm 4.9.25-2-ARCH # 1 SMP Fri May 5 00:46:52 UTC 2017 armv7l GNU / Linux

لم أختبر kernel 4.11

برنامج التشغيل المستخدم في اختباراتي: brcmfmac: إصدار البرنامج الثابت = wl0: 15 ديسمبر 2015 18:10:45 الإصدار 7.45.41.23 (r606571) FWID 01-cc4eda9c

@ b3nj1 - واو ، شكرًا على

الجميع - هل يحدث هذا فقط عند تشغيل وحدة معالجة الرسومات؟

تعمل وحدة معالجة الرسومات دائمًا (إلى حد ما) ، في جميع طرازات Pi.

هل تقصد عندما يكون البلوتوث قيد التشغيل؟

@ JamesH65 -

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

شكرا مقدما

تحقق من فرع rpi-4.11.y ، ثم أعد البناء باستخدام الإرشادات التي تريدها
قد ارتبطت بـ.

في 25 مايو 2017 الساعة 05:02 ، كتب b3nj1 [email protected] :

تضمين التغريدة
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=

• سأحاول 4.11. هل أقوم فقط بالاستنساخ / البناء وفقًا لما يلي؟
  عند الاستنساخ وفقًا ، أنا في فرع rpi-4.9.y. هل يجب علي الخروج
  rpi-4.11.y بدلاً من ذلك أو أي شيء آخر؟

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

شكرا مقدما

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

فقط لتكرار بعض المعلومات التي قدمتها في مكان آخر ، قمت باختبار الاتصال اللاسلكي في ظل ظروف طاقة منخفضة. لقد نقلته إلى نقطة تسرب أجهزة USB ، لكن لم أر أي مشكلات في التوصيلات اللاسلكية. في حين أن هذا دليل على أنها ليست مشكلة في الطاقة ، فمن الجدير بالذكر.

لقد وجدت كيفية إعادة إنتاج هذا عن طريق تشغيل sudo memtester 256M 1 عبر SSH باستخدام هاتفي ؛ تموت شبكة wifi بمجرد أن يبدأ memtester بالفيضان بأحرف "التحميل" تلك:

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

شيء غريب ، wifi معلق فقط أثناء القيام بذلك على هاتفي. لقد جربت جهاز الكمبيوتر الخاص بي وباي آخر وجهاز التوجيه الخاص بي دون حظ.

@ JamesH65 - التحديث 2: لقد تمكنت من التمهيد باستخدام 4.11 (لقد أخطأت في تكوين النواة في المرة الأولى).
Linux rpiz 4.11.2+ #2 Thu May 25 21:19:11 PDT 2017 armv6l GNU/Linux

لسوء الحظ ، لا يزال النظام يستجيب للشعير عندما أطرق BT.

عندما أقوم بتوصيل USB WiFi الخارجي وأوصل عنوان هذا المحول ، كل شيء على ما يرام مرة أخرى.

• بنيامين

نواة جديدة تم بناؤها وتثبيتها من الفرع rpi-4.11.y باتباع الإرشادات هنا: 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

لسوء الحظ ، لا يزال wifi معلقًا مع الخطأ نفسه:
brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

إذا كنت تتحكم في عندما يخرج wifi ، فيمكنك إعادة تشغيله. أقوم باختبار برنامج نصي باش الآن لمعرفة ما إذا كان هذا يساعد. سأقوم بتشغيله في كرون. هنا إذا كان أي شخص مهتم.

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

لقد كنت أقوم بتشغيل هذا لمدة يوم وحتى الآن لم ألاحظ انخفاض wifi.

@ jr1994
هل ما زالت تعمل؟
كم مرة تقوم بتشغيله؟
كل دقيقة ؟

سأحاول ذلك في بعض من توت العليق لدي ، لدي العديد من تلك التي أعيد تشغيلها في كل مرة لا أستطيع فيها اختبار جهاز التوجيه

شكرا مقدما

حتى الان جيدة جدا. أنا أتحقق كل دقيقتين.

لاحظ أن آخر مراجعة للبرنامج الثابت لـ brcmfmac قديمة جدًا:

brcmfmac: إصدار البرنامج الثابت = wl0: 15 ديسمبر 2015 18:10:45 الإصدار 7.45.41.23 (r606571) FWID 01-cc4eda9c

semeion لست متأكدًا من البرنامج الثابت الذي تستخدمه - يجب أن يكون البرنامج الحالي "الإصدار: 7.45.41.26 CRC: 5932ca06 التاريخ: الجمعة 2016-05-27 00:15:32 PDT Ucode Ver: 1043.2060 FWID: 01-df77e4a7". هذا هو بشكل فعال نفس الشيء الموجود في repo linux-firmware ، على الرغم من أننا نحصل عليها مباشرة من Brcm.

@ JamesH65 تم إرجاع هذه الرسالة في 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

لكن باستخدام vcgencmd version يظهر:

$ /opt/vc/bin/vcgencmd version

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

هذه ليست البرامج الثابتة لشريحة Wifi ، إنها البرامج الثابتة لشركة SoC ، التي تحصل عليها
يتم تحديثها بشكل متكرر إلى حد ما.

ما زلت غير متأكد من سبب اعتقاد نظامك أنه يحتوي على تلك البرامج الثابتة القديمة. أنت
لديك برنامج ثابت حديث جدًا لشركة SoC ، لذا من المفترض أنك أجريت ترقية apt-get
مؤخرا؟

في 5 يونيو 2017 الساعة 17:55 ، كتب Alexandre Bolelli [email protected] :

تضمين التغريدة
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=
تم إرجاع هذه الرسالة في dmesg. لكن باستخدام إصدار vcgencmd يظهر:
إصدار $ / opt / vc / bin / vcgencmd
نسخة برنامج ثابت

30 مايو 2017 15:23:29
حقوق النشر (c) لعام 2012 من Broadcom
الإصدار b8cdd5ae76f39d9f353dfa8fb48bf7e33b74903c (نظيف) (إصدار)

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

@ JamesH65 كما قلت أعلاه ، أنا أستخدم Archlinux-ARM ، إنه توزيع إصدار متداول ، ونعم يتم تحديث نظامي باستخدام pacman -Syu (pacman -Syu هو مكافئ للترقية / التحديث).

لا توجد فكرة عن سبب كون البرامج الثابتة القديمة قديمة في نظامي. ربما يمكن أن يكون سبب هذا الخطأ. ماذا تعتقد؟

على أي حال ، الخطأ يحدث مع الراسبان ، أليس كذلك؟ تم الإبلاغ عن الخطأ في مارس 2016؟ انه قديم.

ملاحظة. اللغة الإنجليزية ليست هي لغتي الأم ، آسف على بعض الأخطاء / الأخطاء الإملائية.

حسنًا ، لم أدرك أنك تستخدم ARCH. يبدو أنهم لا يزودون
نقطة بيانات ثابتة حديثة لشريحة Wifi. يمكنك تحديثه يدويًا
قد يصلح مشكلتك ، ربما لا - أعتقد أن هناك على الأرجح عدة
أخطاء لاسلكية ، وليس هناك ما يضمن أن الشخص الذي تراه هو
شخص واحد يراه على Raspbian.

يجب عليك الإبلاغ عن البرامج الثابتة القديمة إلى مسؤولي صيانة القوس ، و
ربما يكون الخطأ اللاسلكي أيضًا ، حيث قد يكون ذلك بسبب توزيعة القوس.

لاحظ أننا بشكل عام لا ندعم توزيعات أخرى ، توزيعاتنا الداخلية هي
Raspbian ، لذلك للتحقيق في مشكلة نحتاج إلى أن نكون قادرين على تكرارها
ذلك.

في 5 يونيو 2017 الساعة 23:13 ، كتب Alexandre Bolelli [email protected] :

@ JamesH65 https://github.com/jamesh65 كما قلت أعلاه ، أنا أستخدم
Archlinux-ARM ، هو توزيعة إصدار متداول ، ونعم تم تحديث نظامي
مع pacman -Syu (pacman -Syu مكافئ للترقية / التحديث).

لا توجد فكرة عن سبب كون البرامج الثابتة القديمة قديمة في نظامي. ربما يمكن أن يكون
سبب هذا الخطأ. ماذا تعتقد؟

على أي حال ، الخطأ يحدث مع الراسبان ، أليس كذلك؟ تم الإبلاغ عن الخطأ في
مارس 2016؟ انه قديم.

ملاحظة. اللغة الإنجليزية ليست هي لغتي الأم ، آسف على بعض الأخطاء / الأخطاء الإملائية.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306325452 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHaL4XsN5drPggS8eJDZWme4LyKXWks5sBH2CgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

@ jamesH65 نعم فعلا. سأحاول السؤال في # archlinux-arm عن سبب كون هذه البرامج الثابتة قديمة. على أي حال ، سأتابع هذه المشكلة وأبحث عن حل. سأبلغ هنا عن أي معلومات تم اكتشافها.

شكرا مقدما.

@ JamesH65 أنا قادر على تكرارها باستمرار على Raspbian الخاص بي (RPi 3). إذا كان هناك شيء يمكنني القيام به للمساعدة في ذلك ، فيرجى إبلاغي بذلك!

ما هو الإعداد الخاص بك؟ كيف تكرر القضية؟

في 6 يونيو 2017 الساعة 14:17 ، كتب Dan [email protected] :

@ JamesH65 https://github.com/jamesh65 أنا قادر على تكراره
باستمرار على جهاز Raspbian الخاص بي (RPi 3). إذا كان هناك شيء يمكنني القيام به للمساعدة
بهذا ، اسمحوا لي أن أعرف!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-306483030 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHWyW5cQuS47k3xTmi3UX-QW7ffEYks5sBVF5gaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

ألق نظرة على التعليقات السابقة ، لقد شرحت كيفية إعادة إنتاجها منذ وقت ليس ببعيد.
يتم تشغيل Raspbian بالكامل مع شاشة 3.5 بوصة في الأعلى باستخدام مصدر الطاقة الرسمي. لا شيء رائع ، كل شيء يتم تحديثه مع تحديث rpi والترقية المناسبة.

بعد بضعة أيام ، توقف wifi الداخلي عن العمل بالرسالة التالية في 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

أقوم بتشغيل hostapd على هذه الواجهة ولديها واجهة USB wifi أخرى متصلة بـ Pi. معلومات نظامي:

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

نعم ، وعندما تبين أنك (-110) تحتاج إلى إعادة تشغيل النظام ليعمل مرة أخرى ...

من الجيد معرفة أنه يحدث في Raspbian أيضًا ، فالخطأ مستقل عن التوزيع. يحدث الشيء نفسه في Archlinux.

ومع ذلك ، منذ أن قمت بنقل wifi الخاص بي من القناة 11 إلى القناة 6 بدلاً من ذلك ، لم أر المشكلة منذ ذلك الحين. أرى ، من ردودي السابقة على هذا الموضوع ، أنه كان منذ 7 يناير عندما أجريت التغيير على القناة 6. أنا حاليًا أقوم بتشغيل جهازي RaspPI Zero W و RaspPi 3 ، وكل ذلك بدون مشاكل. يقوم اثنان من RaspPi W بتشغيل DietPi.

لدي أيضًا هذه المشكلة على Raspberry Pi 3. حاولت استخدام قنوات wifi مختلفة بالفعل.
لقد لاحظت أنه إذا قمت بتوصيل منفذ LAN أيضًا ، فسيكون wifi ثابتًا مثل الجحيم. بمجرد أن أقوم بفصل منفذ LAN ، يستمر wifi في الانخفاض طوال الوقت.

هذا غريب حقا ......!

في 15 يونيو 2017 الساعة 23:02 ، كتب macmeck [email protected] :

لدي أيضًا هذه المشكلة على Raspberry Pi 3. حاولت استخدام قنوات wifi مختلفة
سابقا.
لقد لاحظت أنه إذا قمت بتوصيل منفذ LAN أيضًا ، فسيكون wifi ثابتًا مثل الجحيم.
بمجرد أن أقوم بفصل منفذ LAN ، يستمر wifi في الانخفاض طوال الوقت.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-308878043 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHbUKBO9mG3xpKHFK977h4hrFUhrGks5sEantgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

لدي
"brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012"
قضية كذلك في بلدي rpi3. كان الحل الأكثر موثوقية لمنع هذا الخطأ
"wondershaper 9000 9000"
آمل أن يتم تحديد السبب الجذري.

لدي نفس المشكلة بالضبط. لدى pi3 الأعراض التالية عند الاتصال بشبكة WIFI فقط:

1. OUTGOING wifi يعمل بشكل رائع. يمكنني الاتصال بالإنترنت وتنزيل الملفات دون أي مشاكل على pi3.
2. تفشل جميع اتصالات wifi الواردة. مهلة الأصوات ، منفذ 80 http يصل المهلة ، فشل ssh ، كل شيء يفشل INBOUND ONLY.
   ملحوظة:
3. بمجرد توصيل Ethernet بـ pi3 ، فإن wifi يعمل بشكل أفضل ولكنه لا يزال يسقط الحزم.
4. بمجرد إزالة Ethernet مرة أخرى ، يفشل wifi تمامًا في جميع الاتصالات الواردة.
5. بمجرد توصيل Ethernet مرة أخرى بـ pi3 ، يعمل wifi بشكل أفضل ويسمح ببعض الحزم الواردة. لكنه لا يزال يسقط الكثير منهم.

الرجاء إصلاح هذا!

لقد لاحظت ما يلي في ifconfig:

حزم RX: 1613 خطأ: 0 مسقطة: 1074 تجاوز: 0 إطار: 0
حزم TX خطأ: 0 مسقطة: 0 تجاوزات: 0 ناقل: 0
c ollisions: 0 t xqueuelen: 1000

لذا فإن جانب RX من شبكة WIFI الخاصة بـ pi3 هو إسقاط الحزم مثل الجنون. لا عجب لماذا لا تستجيب للاتصالات الواردة. TX يعمل بشكل جيد!

منذ أن قمت بإعداد هذا البرنامج النصي ، لم أواجه أي مشاكل مع wifi على كلا الجهازين
RPI3s.

يوم الأربعاء 21 حزيران (يونيو) 2017 الساعة 4:26 صباحًا ، أرسل إدوارد كانغ [email protected]
كتب:

لقد لاحظت ما يلي في ifconfig:

حزم RX: 1613 خطأ: 0 مسقطة: 1074 تجاوز: 0 إطار: 0
حزم TX خطأ: 0 مسقطة: 0 تجاوزات: 0 ناقل: 0
c ollisions: 0 t xqueuelen: 1000

لذا فإن جانب RX من شبكة WIFI الخاصة بـ pi3 هو إسقاط الحزم مثل الجنون.
لا عجب لماذا لا تستجيب للاتصالات الواردة.

يرجى تصحيح هذا !!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310049620 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AFHmIH6kkxraxahE22_PpstdDkqW8Pgqks5sGP3ggaJpZM4HupC5
.

من الجيد جدًا قول "الرجاء إصلاح هذا" ولكن مثل هذه المشكلات تعتبر من الأوغاد المطلقين للعثور عليهم. استغرق الأمر شهرًا للعثور على خطأ في برامج تشغيل smsc / brcmfmac عند التجسير ، وكنت محظوظًا للعثور عليه ، وأعتقد أن هذا الخطأ نادر ويصعب العثور عليه. إذا تمكن أي شخص من العثور على حالة اختبار قابلة للتكرار تعرض الخطأ بسرعة ، فسيكون ذلك مفيدًا للغاية. يبدو أن بعض الناس يحصلون على خطأ kevent بشكل متكرر ، نادرًا ما أحصل عليه.

بالنسبة لمشكلة الحزم المسقطة ، يتم النظر في هذا عندما يكون لدي فجوات في الجدول الزمني. في الحالة المذكورة أعلاه ، يبدو أنك تقوم بإسقاط جميع الحزم تقريبًا ، وهو الأمر الأكثر غرابة ولا يراه عادةً غالبية الأشخاص. هل يحدث هذا مع جميع الأجهزة المتصلة بـ Pi؟ أو واحد فقط على وجه الخصوص.

آسف جيمس!

لست متأكدًا مما تقصده بكل الأجهزة المتصلة بـ Pi. الحزم التي تم إسقاطها من تنفيذ ifconfig مباشرة على pi. يتم توصيل pi عبر wifi بجهاز توجيه. عندما يكون pi متصلاً بشبكة wifi فقط ، فإنه يتلقى باستمرار الحزم ويسقطها.

@ JamesH65 حسنًا ، أتفق معك ، من الصعب حلها ... ولكن باستخدام Arch Linux-ARM ، تثبيت حزمة "create_ap" وتمكينها (pacman -S create_ap ؛ systemctl start / enable create_ap) ، يمكنك الحصول على - 110 خطأ و "محتوى بيانات صندوق البريد غير معروف: 0x40012" في دقائق قليلة من التشغيل ... ما عليك سوى توصيل هاتفك الذكي و / أو التلفزيون الذكي به أحيانًا وسيظهر الخطأ.

نحن لا ندعم Arch ، Raspbian هو نظام التشغيل المدعوم لدينا وهذا هو I
يجب أن تكون قادرًا على إصلاح المشكلة في. ليس لدي أي فكرة عن إصدار
kernel أو برامج التشغيل التي يستخدمها ARCH ، فقد تكون مختلفة تمامًا عن
منها في Raspbian.

هل لا يزال الأشخاص يرون المشكلة باستخدام Pi كنقطة وصول؟
باستخدام التجسير؟ IPv4 أو IPv6؟ هذا هو نوع المعلومات (لا
حصريًا بالطبع ، مطلوب أكبر قدر ممكن من المعلومات)
لتكرار القضايا.

لاحظ أنه تم إبلاغ Broadcom بخطأ صندوق البريد (إنه شريحتهم
وسائق بالطبع) ، لكن الأشياء تميل إلى التحرك ببطء معهم.

في 21 يونيو 2017 الساعة 18:27 ، أرسل ألكسندر بوليلي إخطارات github.com
كتب:

تضمين التغريدة
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=
حسنًا ، أتفق معك ، من الصعب حلها ... لكن باستخدام Arch Linux-ARM ،
تثبيت حزمة "create_ap" وتمكينها (pacman -S create_ap؛
systemctl / startenable create_ap) ، يمكنك الحصول على خطأ -110 و
"محتوى بيانات علبة البريد غير معروف: 0x40012" في دقائق قليلة من العملية ... فقط
قم بتوصيل هاتفك الذكي و / أو التلفزيون الذكي به أحيانًا والخطأ
تأتي.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

أنا أستخدم ipv4 الثابت على بعض الأجهزة وأواجه نفس المشكلة مثل
الآخرين الذين يستخدمون dhcp

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

نحن لا ندعم Arch ، Raspbian هو نظام التشغيل المدعوم لدينا وهذا هو I
يجب أن تكون قادرًا على إصلاح المشكلة في. ليس لدي أي فكرة عن إصدار
kernel أو برامج التشغيل التي يستخدمها ARCH ، فقد تكون مختلفة تمامًا عن
منها في Raspbian.

هل لا يزال الأشخاص يرون المشكلة باستخدام Pi كنقطة وصول؟
باستخدام التجسير؟ IPv4 أو IPv6؟ هذا هو نوع المعلومات (لا
حصريًا بالطبع ، مطلوب أكبر قدر ممكن من المعلومات)
لتكرار القضايا.

لاحظ أنه تم إبلاغ Broadcom بخطأ صندوق البريد (إنه شريحتهم
وسائق بالطبع) ، لكن الأشياء تميل إلى التحرك ببطء معهم.

في 21 يونيو 2017 الساعة 18:27 ، أرسل ألكسندر بوليلي إخطارات github.com
كتب:

تضمين التغريدة
3A__github.com_jamesh65 & d = DwMFaQ & c = DpyQ_ftY536pf7wCBQXXU58xADDRY77THQz
Ju1OmzOo & r = w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m =
BDIwUx7SC6sTRvRQKgA0QZB_ZlIJDs3bd_wzKoIw_7w & s = o90aBGb27vZvog3BdioLSa2_
MEySix0ymtnTgiNb87c & e =>
حسنًا ، أتفق معك ، من الصعب حلها ... لكن باستخدام Arch Linux-ARM ،
تثبيت حزمة "create_ap" وتمكينها (pacman -S create_ap؛
systemctl / startenable create_ap) ، يمكنك الحصول على خطأ -110 و
"محتوى بيانات علبة بريد غير معروف: 0x40012" في دقائق قليلة من العملية ...
مجرد
قم بتوصيل هاتفك الذكي و / أو التلفزيون الذكي به أحيانًا والخطأ
تأتي.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 => ،
أو كتم الخيط
3A__github.com_notifications_unsubscribe-2Dauth_
ADqrHfDuqt5fcQ3ODkJUFKxuUaWgUpIhks5sGVKfgaJpZM4HupC5 & d = DwMFaQ & c = DpyQ_
ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo & r = w09_
2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek & m = BDIwUx7SC6sTRvRQKgA0QZB_
ZlIJDs3bd_wzKoIw_7w & s = Ojyj5WoAXeLeCsvarhv2rrmQUVoQGkjZmsfPB2lrOUw & e =>
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-310294786 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACeQBFj8ICNkDl7xYwYJcD6TK-k6_4K5ks5sGhJ1gaJpZM4HupC5
.

شيء واحد يجب ملاحظته هو أن شبكة wifi كانت تعمل بشكل مثالي بالنسبة لي من الوقت الذي حصلت فيه على pi3 العام الماضي إلى حوالي 3 أشهر عندما توقف wifi عن العمل.

من الواضح أنه يجب أن يكون هناك نوع من التغيير في البرنامج في ذلك الوقت تقريبًا مما تسبب في توقف wifi عن العمل.

إذا توقفت شبكة wifi عن العمل تمامًا ، فهذا يشير إلى وجود مشكلة في نهايتك (والتي قد تتفاقم بسبب مشكلة في البرنامج بالطبع) ، لأنه بالنسبة لأي شخص آخر ، تعمل Wifi بشكل عام (على الرغم من أنني أرى الحزم المسقطة).

راجع للشغل الخاص بي rpi3 هو ماركة جديدة في المملكة المتحدة.

لقد كنت أحارب هذا أيضًا منذ بضعة أشهر. في بعض الأحيان يستمر لدقائق. في بعض الأحيان أسابيع. القاسم المشترك عندما أفقد الاتصال هو أنني أرى المكالمات لإعادة ضبط المجال التنظيمي العالمي CRDA مباشرة قبل أن يفقد الاتصال. في كل مرة. نقطة وصول Ubiquiti AC ، القناة 11 ، عرض القناة HT40 (الشيء الوحيد الذي قد يكون خاصًا).

28 يونيو 14:19:31 نواة raspberrypi: [980.387378] cfg80211: تم تحديث المجال التنظيمي العالمي:
28 يونيو 14:19:31 raspberrypi kernel: [980.387387] cfg80211: منطقة DFS الرئيسية: unset
28 يونيو 14:19:31 raspberrypi kernel: [980.387396] cfg80211: (start_freq - end_freq @ bandwidth)، (max_antenna_gain، max_eirp)، (dfs_cac_time)
28 يونيو 14:19:31 نواة raspberrypi: [980.387411] cfg80211: (2402000 كيلوهرتز - 2472000 كيلوهرتز @ 40000 كيلوهرتز) ، (N / A ، 2000 ميغا بايت) ، (N / A)
28 يونيو 14:19:31 raspberrypi kernel: [980.387426] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz، 92000 KHz AUTO)، (N / A، 2000 mBm)، (N / A)
28 يونيو 14:19:31 raspberrypi kernel: [980.387439] cfg80211: (2474000 كيلو هرتز - 2494000 كيلو هرتز @ 20000 كيلو هرتز)، (N / A، 2000 ميجا بايت)، (N / A)
28 يونيو 14:19:31 kernel raspberrypi: [980.387453] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz، 160000 KHz AUTO)، (N / A، 2000 mBm)، (N / A)
28 يونيو 14:19:31 نواة raspberrypi: [980.387468] cfg80211: (5250000 كيلوهرتز - 5330000 كيلوهرتز @ 80000 كيلوهرتز ، 160000 كيلوهرتز تلقائي) ، (N / A ، 2000 ميغا بايت) ، (0 ثانية)
28 يونيو 14:19:31 نواة raspberrypi: [980.387481] cfg80211: (5490000 كيلوهرتز - 5730000 كيلوهرتز @ 160000 كيلوهرتز) ، (N / A ، 2000 ميغا بايت) ، (0 ثانية)
28 يونيو 14:19:31 raspberrypi kernel: [980.387493] cfg80211: (5735000 كيلو هرتز - 5835000 كيلو هرتز @ 80000 كيلو هرتز)، (N / A، 2000 ميجا بايت)، (N / A)
28 يونيو 14:19:31 نواة raspberrypi: [980.387505] cfg80211: (57240000 كيلو هرتز - 63720000 كيلو هرتز @ 2160000 كيلو هرتز)، (N / A، 0 ميجا بايت)، (N / A)
28 يونيو 14:19:32 raspberrypi kernel: [981.262521] cfg80211: تم تغيير المجال التنظيمي إلى الدولة: الولايات المتحدة
28 يونيو 14:19:32 raspberrypi kernel: [981.262536] cfg80211: منطقة DFS الرئيسية: FCC
28 يونيو 14:19:32 raspberrypi kernel: [981.262540] cfg80211: (start_freq - end_freq @ bandwidth)، (max_antenna_gain، max_eirp)، (dfs_cac_time)
28 يونيو 14:19:32 نواة raspberrypi: [981.262549] cfg80211: (2402000 كيلو هرتز - 2472000 كيلو هرتز @ 40000 كيلو هرتز) ، (N / A ، 3000 ميجا بايت) ، (N / A)
28 يونيو 14:19:32 raspberrypi kernel: [981.262557] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz، 160000 KHz AUTO)، (N / A، 2300 mBm)، (N / A)
28 يونيو 14:19:32 raspberrypi kernel: [981.262565] cfg80211: (5250000 كيلوهرتز - 5330000 كيلوهرتز @ 80000 كيلوهرتز ، 160000 كيلوهرتز تلقائي) ، (N / A ، 2300 ميغا بايت) ، (0 ثانية)
28 يونيو 14:19:32 raspberrypi kernel: [981.262571] cfg80211: (5490000 كيلو هرتز - 5730000 كيلو هرتز @ 160000 كيلو هرتز) ، (N / A ، 2300 ميجا بايت) ، (0 ثانية)
28 يونيو 14:19:32 نواة raspberrypi: [981.262578] cfg80211: (5735000 كيلوهرتز - 5835000 كيلوهرتز @ 80000 كيلوهرتز) ، (N / A ، 3000 ميغا بايت) ، (N / A)
28 يونيو 14:19:32 raspberrypi kernel: [981.262584] cfg80211: (57240000 كيلوهرتز - 63720000 كيلوهرتز @ 2160000 كيلوهرتز) ، (N / A ، 4000 ميغا بايت) ، (N / A)

آسف لإلقاء الوقود على النار ، ولكن هناك مشكلة مماثلة في Pi Zero W أيضًا ، على ما أعتقد.

عند تبديل wlan0 بين وضع نقطة الوصول (عند استخدام hostapd) ووضع الاتصال العادي (أي الاتصال بجهاز توجيه) ، يفقد wlan0 أحيانًا القدرة على الارتباط بنقطة وصول.

سوف تتعثر في هذه الحالة:

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

ولن يؤدي أي شيء أقل من إعادة التشغيل إلى إصلاحه. لاحظت في dmesg الأخطاء التالية عند حدوث ذلك:

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

ما يقلقني هو أنه عشوائي وعشوائي تمامًا. يمكنني في بعض الأحيان التبديل بين الوضعين لفترة طويلة قبل حدوث المشكلة. لكنها في النهاية تفعل ذلك.

FWIW أعتقد أن إعادة تحميل وحدة wifi kernel (عن طريق إجراء "modprobe -r -v brcmfmac && modprobe brcmfmac") قد أصلحها لذا سأضطر فقط إلى إنشاء برنامج نصي يقوم بذلك كلما كان لدى Pi مشكلات wifi.

هذا بينما الشيء غريب. واجهت هذه الأنواع من المشكلات على Raspberry pi zero & zero W ، لكنها اختفت تمامًا عندما قمت بتبديل القنوات (كما تمت مناقشته سابقًا في هذا الموضوع).

أيضًا ، مؤخرًا كنت أستخدم نظام التشغيل DietPi ولم أواجه أي مشاكل على الإطلاق. قد ترغب في محاولة ذلك.

كنت أرغب حقًا في النظر في المشكلة ، بعد أن رأيتها من قبل ، لكن لا يمكنني الحصول عليها هذه الأيام! :(

/ راج
(مرسل من iPhone)

في 5 تموز (يوليو) 2017 ، الساعة 9:01 صباحًا ، كتب timdonovanuk [email protected] :

FWIW أعتقد أن إعادة تحميل وحدة wifi kernel (عن طريق إجراء "modprobe -r -v brcmfmac && modprobe brcmfmac") قد أصلحها لذا سأضطر فقط إلى إنشاء برنامج نصي يقوم بذلك كلما كان لدى Pi مشكلات wifi.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

كلما زاد عدد الأشخاص الذين يمكنهم النظر إلى هذا كلما كان ذلك أفضل ، فأنا مقيد في ذلك الوقت
يمكنني أن أقضي على هذا في الوقت الحالي بسبب مشاريع أخرى. مشكلة رئيسية واحدة
هي آلية قوية لتكرارها.

في 5 يوليو 2017 الساعة 17:10 ، كتب rajid [email protected] :

هذا بينما الشيء غريب. واجهت هذه الأنواع من المشكلات على Raspberry Pi
صفر وصفر وات ، لكنهما اختفيا تمامًا عندما قمت بتبديل القنوات (مثل
نوقشت في وقت سابق في هذا الموضوع).

أيضًا ، مؤخرًا كنت أستخدم نظام DietPi OS ولم أواجه أي مشاكل فيه
الكل. قد ترغب في محاولة ذلك.

كنت أرغب حقًا في النظر في المشكلة ، بعد أن رأيتها من قبل ، لكنني
فقط لا يمكن أن يحدث هذا في هذه الأيام! :(

/ راج
(مرسل من iPhone)

في 5 تموز (يوليو) 2017 ، الساعة 9:01 صباحًا ، timdonovanuk [email protected]
كتب:

FWIW أعتقد أن إعادة تحميل وحدة wifi kernel (عن طريق عمل "modprobe -r -v
brcmfmac && modprobe brcmfmac ") ، لذا سأضطر إلى إنشاء ملف
البرنامج النصي الذي يقوم بذلك عندما يكون لدى Pi مشكلات wifi.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

timdonovanuk يمكن أن يكون من الجيد مشاركة النص الخاص بك معنا ، وأنا أبحث عن بعض الحلول. ربما بعض نصوص المراقبة تعمل مثل خدمة systemd ... ما رأيك؟

هل هناك طريقة يمكنني من خلالها تشغيل تحديث المجال التنظيمي يدويًا؟ كما قلت ، يبدو أنه متسق جدًا بالنسبة لي كلما تم ذلك ، ينقطع الاتصال. سأكون مهتمًا بتشغيله يدويًا عدة مرات لمعرفة ما إذا كان بإمكاني إعادة الإنتاج بشكل موثوق لك.

rajid ، بالصدفة هل تعمل في عرض القناة 40؟ وهل تتذكر ما إذا كنت ترى تحديثات تنظيمية عالمية مماثلة قبل عمليات السقوط؟ من الغريب ما إذا كان هناك مجموعة حول القناة 11 وعرض القناة العريض الإضافي ... وما نوع جهاز التوجيه / AP الذي تستخدمه؟ أبحث فقط عن أي قواسم مشتركة ، لأنني أرى هذا على القناة 11 أيضًا ، وكذلك الآخرون ... My AP هي Ubiquiti.

الحل البديل للتبديل من القناة التلقائية على Apple المتطرفة إلى القناة 6 لم ينجح بالنسبة لي. سأستخدم الشبكة المحلية أثناء الإجازة.

تحرير: الآن أفقد الاتصال حتى مع شبكة LAN ، يوجد الكثير هنا ، هل هي مشكلة حرارة باستخدام الحالة الرسمية (بدون مروحة)؟

مرحبا،
أواجه مشكلة مشابهة جدًا على Raspberry Pi Zero W.

لقد طورت واجهة برمجة تطبيقات تعمل مع Node.JS على Pi وتم دمجها مع GPIOs.
Pi متصل بشبكة LAN الخاصة بي من خلال Wifi. كل شيء يعمل بشكل رائع عندما يتصل عملاء الكمبيوتر بواجهة برمجة التطبيقات. ومع ذلك ، بمجرد الاستعلام عن واجهة برمجة التطبيقات الخاصة بي باستخدام جهاز Android ، يتعطل Pi. تحدث هذه الأعطال بشكل عشوائي: في بعض الأحيان يمكن استدعاء API بواسطة أجهزة Android عدة مرات وفجأة يحدث التعطل.
ما أعنيه بالتعطل هو خسارة ping لكن Pi لا تزال قيد التشغيل.

استدعاء نفس واجهة برمجة التطبيقات من خلال أجهزة الكمبيوتر لا يؤدي إلى حدوث أي تعطل.

حاولت تغيير قناة Wifi ولكن لم أحصل على نتائج أفضل.

إذا كان بإمكاني تشغيل أي شيء للمساعدة في التشخيص / الحل ، فلا تتردد في السؤال!

أي شيء في هذا المنتدى بعد المساعدة؟

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

في 11 يوليو 2017 الساعة 16:22 ، كتب matthiasbou [email protected] :

مرحبا،
أواجه مشكلة مشابهة جدًا على Raspberry Pi Zero W.

لقد قمت بتطوير API يعمل مع Node.JS على Pi ومتكامل
مع GPIOs.
Pi متصل بشبكة LAN الخاصة بي من خلال Wifi. كل شيء يعمل بشكل رائع عندما يكون الكمبيوتر الشخصي
عملاء استدعاء API. ومع ذلك ، بمجرد الاستعلام عن واجهة برمجة التطبيقات الخاصة بي باستخدام Android
الجهاز ، تعطل Pi. تحدث هذه الأعطال بشكل عشوائي: في بعض الأحيان يمكن لواجهة برمجة التطبيقات
يتم استدعاء أجهزة Android عدة مرات وفجأة يحدث العطل.
استدعاء نفس واجهة برمجة التطبيقات من خلال أجهزة الكمبيوتر لا يؤدي إلى حدوث أي تعطل.

حاولت تغيير قناة Wifi ولكن لم أحصل على نتائج أفضل.

إذا كان بإمكاني تشغيل أي شيء للمساعدة في التشخيص / الحل ، فلا تتردد في السؤال!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314479400 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHYDohQoNRBDcX4oG49rK9e6kwpjjks5sM5MpgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

تضمين التغريدة

ما قلته مثيرًا للاهتمام ، فإن برنامج تشغيل Broadcom الخاص بي يعرض الخطأ -110 (خطأ آخر في بعض الأحيان) ويتعطل تمامًا في اللحظة التي أقوم فيها بتوصيل هاتفي الذكي Motorola X2 (Android). ولكن يحدث نفس الخطأ أيضًا عند توصيل SmartTV الخاص بي. على أي حال ، يمكنني أن أؤكد حدوث العطل في وقت إجراء الاتصال.

تم تعيين بلدي بشكل صحيح ، وتعطيل ipv6 والتجوال = 1 ، وأنا أستخدم القناة 6 ، والمشكلة لا تزال تحدث. وضع توفير الطاقة wifi والبلوتوث معطل بشكل افتراضي في توزيعة الخاص بي.

@ JamesH65 : لقد جربت الحل المثير للاهتمام لتحديد البلد الصحيح (لم يكن الأمر كذلك) ، وتعطيل IPV6 والتجوال ولكن لا يزال لدي نفس المشكلة :(

يتصل Wifi ، ولكن بمجرد أن أبدأ "اللعب" بجهاز Android ، أجري بعض استدعاءات API على Pi Zero W ، بعد فترة ، يتعطل.

لماذا يجب أن يؤدي تعطيل IPv6 إلى إصلاح مشكلة Wifi؟ هل يوجد تفسير معقول لسبب تضمين IPv6 ، وهو قابل للتكرار؟ الشيء الوحيد الذي يمكنني التفكير فيه هو أن IPv6 قد يكون له بعض تحميل الإرسال المتعدد الإضافي الطفيف بسبب RAs.

لما يستحق ، أنا أقوم بتشغيل Pi Zero Ws كجسور IPv6 بين wlan0 المتكامل و eth0 الخارجي ، مع حظر IPv4. wlan0 في وضع AP ولديه خادم ISC dHCPv4 قيد التشغيل. اربط العديد من الأجهزة اللوحية والهواتف الذكية التي تعمل بنظام Android بها. لم ألاحظ أي مشاكل حتى الآن ، لكن ربما أحتاج إلى تركها تعمل لفترات أطول من الوقت. أنا أستخدم القناة 6.

عذرًا ، أنا أستخدم مربع Apple Airport ، وليس هناك إعداد أو ذكر لـ "عرض القناة". لقد قمت ببساطة بتعيين القناة 6 لشبكة 2.3 جيجا هرتز. أنا الآن أستخدم DietPi على أنظمة RaspPi Zero W الصغيرة الخاصة بي. أجهزة RaspPi الأخرى التي قمت بإعدادها منذ فترة طويلة مع Edimax USB ولم تواجه أي مشاكل. أعتقد أن المرة الوحيدة التي رأيت فيها مشاكل كانت مع Raspbian على نظام Zero W. سأضطر إلى تحميل ذلك مرة أخرى ومعرفة ما إذا كان بإمكاني إعادة إنتاجه.

/ راج

في 5 تموز (يوليو) 2017 ، الساعة 3:19 مساءً ، كتب مايكل هالوك < [email protected] [email protected] >:

هل هناك طريقة يمكنني من خلالها تشغيل تحديث المجال التنظيمي يدويًا؟ كما قلت ، يبدو أنه متسق جدًا بالنسبة لي كلما تم ذلك ، ينقطع الاتصال. سأكون مهتمًا بتشغيله يدويًا عدة مرات لمعرفة ما إذا كان بإمكاني إعادة الإنتاج بشكل موثوق لك.

rajid https://github.com/rajid ، بالصدفة هل تعمل بعرض القناة 40؟ وهل تتذكر ما إذا كنت ترى تحديثات تنظيمية عالمية مماثلة قبل عمليات السقوط؟ من الغريب ما إذا كان هناك مجموعة حول القناة 11 وعرض القناة العريض الإضافي ... وما نوع جهاز التوجيه / AP الذي تستخدمه؟ أبحث فقط عن أي قواسم مشتركة ، لأنني أرى هذا على القناة 11 أيضًا ، وكذلك الآخرون ... My AP هي Ubiquiti.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/raspberrypi/linux/issues/1342#issuecomment-313242611 ، أو كتم صوت الموضوع https://github.com/notifications/unsubscribe-auth/AFAlZVdfvh5QzIlsZYtt9sjpXolJqgaWks5s .

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

لقد أجريت للتو المزيد من الاختبارات وغيرت جهاز التوجيه الذي يتصل به Pi.
حتى الآن ، كل شيء يعمل عندما يكون Pi على جهاز توجيه Wifi آخر (لا تغيير على جانب جهاز Android)
تكوين جهاز التوجيه العامل :
القناة 6
WPA PSK
عرض النطاق الترددي 20 ميجا هرتز

تكوين جهاز التوجيه غير العامل (فقدان Wifi بعد بعض الوصول من Android Wifi):
نتغير WNR1000v2
القناة 6
WPA2-PSK [AES]
طول التجزئة 2346
عتبة CTS / RTS 2347

سأقوم بتبديل جهاز التوجيه العامل إلى WPA2-PSK لمعرفة ما إذا كان يمكن إعادة إنتاج المشكلة.

TheDiveO فيما يتعلق بـ IPv6 ، لدى المشغل مسارات رمز مختلفة لـ ipv6 ، كما هو الحال بالنسبة للنواة. يمكن أن يكون هناك خطأ في أي من تلك المسارات غير الموجودة في ipv6 ، أو ، مثل ISTR من خطأ منذ فترة ، هناك شيء ما يدير مسار كود ipv6 عندما يجب تشغيل مسار كود ipv4 أو vica بالعكس. المكدس كله معقد إلى حد ما.

سلوك جديد. تغيير اللغة وإجراء ترقية وتحديث apt-get له الآن السلوك التالي عندما يكون pi3 متصلاً عبر WIFI:

الآن يمكن للأجهزة خارج LAN المحلية الاتصال بـ PI عبر TCP / IP.

لا يزال PI يرفض جميع الاتصالات (TCP / IP) على الشبكة المحلية فقط.

لا يزال بإمكان PI الوصول إلى الإنترنت الخارجي عبر WIFI.

لا يهم. لم يتغير شيء. هذا هو نفس السلوك بالضبط كما كان من قبل. يقوم Pi3 wifi بإسقاط جميع الحزم على شبكة LAN المحلية.

فقط للمتابعة قليلاً ... لقد بدأت تشغيل AP جديد (Linksys E4200 V2) ، والذي كنت أكذب عليه. قمت بإعداده على القناة 11 لـ 2.4 جيجا هرتز ، وتكوين WPA2 شخصي ، و BSSID وكلمة المرور. ثم تكوين هذا على بلدي التوت بي صفر ث. انها متصلة على ما يرام. ثم قمت بنقل نقطة الوصول هذه إلى نفس الغرفة حيث يوجد منزلي العادي AP (الموجود على القناة 6). ثم حصل My RaspPi على ASSOC-REJECT status_code = 16. إعادة AP إلى مكتبي مرة أخرى جعل مساعد RaspPi على ما يرام.

لذا ، يبدو أنه في حالتي ، على الأقل ، تعتبر القناة 11 مشكلة إذا كانت AP في الغرفة الأخرى. أظن أن هذا ربما يشير إلى مشكلة تداخل.

سأقوم هنا أيضًا بنشر صفحة ويب وجدتها والتي تخبرنا بكل أكواد الحالة ورموز الفشل:

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

يوضح هذا أن "status_code = 16" ناتج عن انتهاء المهلة ، لذلك لا يستقبل أحد الأنظمة حزمًا في الوقت المناسب.

لقد ظننت أنني سألقي هذه المعلومات هناك في حالة ما إذا كانت تساعد أي شخص.

عندما أشعل الأضواء على مطبخي ، فإنه يقتل اتصال wifi الخاص بي على
غرفة المعيشة ... لا أعرف لماذا ولكن عندما تحدثت عن التدخل ، أعتقد
أنا لست مجنونا

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

فقط للمتابعة قليلاً ... لقد بدأت تشغيل AP جديد (Linksys E4200 V2) ،
الذي كنت أكذب حوله. قمت بإعداده على القناة 11 لـ 2.4 جيجا هرتز ، مهيأ
WPA2 شخصي ، BSSID وكلمة مرور. ثم تكوين هذا على بلدي التوت
بي صفر ث. انها متصلة على ما يرام. ثم قمت بنقل AP إلى نفس الغرفة
حيث يقع منزلي العادي AP (الموجود على القناة 6). ثم بلدي RaspPi
حصلت على ASSOC-REJECT status_code = 16. إعادة AP إلى مكتبي مرة واحدة
مرة أخرى جعل زميل RaspPi على ما يرام.

لذا ، يبدو أنه في حالتي ، على الأقل ، تعتبر القناة 11 مشكلة إذا كانت AP كذلك
في الغرفة الأخرى. أظن أن هذا ربما يشير إلى تدخل
مشكلة.

سوف أنشر هنا أيضًا صفحة ويب وجدتها تخبرنا بكل ما في
أكواد_الحالة ورموز الفشل هي:

https://supportforums.cisco.com/document/141136/80211-
رموز حالة الارتباط 80211-deauth-reason

يوضح هذا أن "status_code = 16" ناتج عن انتهاء المهلة ، لذا فإن أحد ملفات
الأنظمة ببساطة لا تستقبل الحزم في الوقت المناسب.

لقد ظننت أنني سألقي بهذه المعلومات هناك في حال كانت مفيدة
أي واحد.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-314872003 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACeQBJdfk2zp1sReVVs1wvrilKHXNm53ks5sNR42gaJpZM4HupC5
.

يوجد برنامج WiFi Analyzer رائع حقًا لنظام Android ، والذي يعرض نقاط الوصول من حولك ، إلى جانب المعلومات التفصيلية الخاصة بهم. (أتمنى وجود شيء من هذا القبيل لجهاز iPhone / iPad ، لكن Apple ...)

@ JamesH65 أنت تجعلني غير مرتاح حقًا بالقول إن برنامج تشغيل طبقة ارتباط البيانات (الطبقة 3) يعبث بطبقة الشبكة 3. ربما لا تكون كلمة "Mess" كلمة مناسبة لهذا الموقف أيضًا ...

أنا لا أقول ذلك في الواقع. لست خبيرًا في شبكات Linux
مكدس ، لكن يبدو أنني أتذكر بالتأكيد رؤية بعض عناصر IPv6 المحددة في
سائق في مكان ما.

كل الأشياء موجودة في شجرة النواة ، فنحن نرحب بك لإلقاء نظرة
نفسك لتهدئة عقلك.

في 13 يوليو 2017 الساعة 08:58 ، كتب TheDiveO [email protected] :

@ JamesH65 https://github.com/jamesh65 أنت حقا تجعلني غير مرتاح
يقول أن برنامج تشغيل طبقة ارتباط البيانات (الطبقة 3) يعبث مع
طبقة الشبكة 3. "الفوضى" ربما لا تكون الكلمة المناسبة لهذا
الوضع إما ...

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315002002 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHUSoqqxnhaw4k2ECkzGC9CDkIlhYks5sNc4ngaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

TheDiveO James
SMSC95xx على سبيل المثال يمكن أن يدعم فقط إلغاء تحميل المجموع الاختباري لـ IPv4 بسبب أن IPv6 يتطلب مجموع اختباري من 0x0000 يتم استبداله بـ 0xFFFF. انظر https://github.com/torvalds/linux/commit/fe0cd8ca1b82983db24b173bb8518ea646c02d25. ومن ثم سيتبع IPv6 و IPv4 مسارات رمز مختلفة. لا يوجد شيء مشكوك فيه ، ولكنه متأصل في مكدس الشبكة حيث لا يمكن للأجهزة تغطية جميع المواقف.

أنا متأكد من أن هذا الخطأ موجود في برنامج تشغيل Broadcom ، وليس في النواة.

بكل تأكيد. برنامج تشغيل Brcm هو جزء كبير من التعليمات البرمجية ، والأخطاء
مثل هذا ليس من السهل تصحيحه ، خاصة عندما لا يمكنك تكرارها ...

في 13 يوليو 2017 الساعة 13:04 ، ألكسندر بوليلي [email protected]
كتب:

أنا متأكد من أن هذا الخطأ موجود في برنامج تشغيل Broadcom ، وليس في النواة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315058283 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHbr5SiWPKvQZOY7rN8IbyIIscNfVks5sNgexgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

كلما واجهت هذا الأمر أكثر ، كلما بدأت أتساءل عما إذا كان هذا مرتبطًا بعجز Ubuntu / Debians عن توصيل wlan0 و eth0 بنفس الشبكة الفرعية دون بعض التهيئة الشاملة. سأبحث في هذا أكثر وأرى ما إذا كانت هذه هي المشكلة.

@ JamesH65 هل سيكون من

ربما لا ولكن شكرا على العرض. أميل إلى إجراء تغييرات مخصصة على
السائق والنواة ، مع إجراء تغييرات عدة مرات في اليوم. افعل ذلك
عن بعد غير ممكن. آليات إعادة إنتاج المشكلة بشكل موثوق هي
حقا ما هو مطلوب.

في 13 يوليو 2017 الساعة 13:57 ، أرسل توماس أيراكسينن إخطارات github.com
كتب:

@ JamesH65 https://github.com/jamesh65 هل سيساعدني (أو أي شخص
else) سوف يقوم بإعداد صفر w أو rpi 3 لك في بيئة يكون فيها هذا
قابلة للتكرار بسهولة وتمنحك وصولاً إلى ssh لتتمكن من تصحيحه؟ (أنا
سيحتاج إلى شراء صفر واط إضافي لهذا).

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-315069935 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHeQ1RECH-uIIHWPX6ItvRdVbZG_Xks5sNhRWgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

جوامع،
إذا قمت بإجراء حلقة الاقتراع البسيطة هذه ، فسأرى بسرعة شبكة wifi على متن الطائرة تتدهور إلى حالة غير قابلة للاستخدام. عندما أقوم بإيقاف تشغيل wifi على متن الطائرة واستخدام USB wifi ، فإنه يعمل. لا أتذكر ما إذا كان حساسًا لوجود جهاز BT أو غيابه ، ولا يمكنني التحقق من ذلك بسهولة لبضعة أيام. لقد اقتصرت على 10 دقائق حتى أتمكن من العودة إلى pi صفر w بعد التجربة.

bash# ((t= date +٪ s +600)); while [ تاريخ +٪ s -lt $t ] ; do hcitool name <BTMAC>; done
امل ان يساعد،
بنيامين

هذا القصاصة فقدت القراد على ظهري. الهروب منهم ...

((t = `التاريخ +٪ s` ​​+ 600)) ؛ بينما [`التاريخ +٪ s` ​​-lt $ t] ؛ هل اسم hcitool "insert BT MAC" ؛ فعله

يا الهي. أعتقد أنه تم إصلاحه. شبكة Wifi تعمل عند فصل شبكة إيثرنت. لا يصدق.

أزلت كل إشارة إلى eth0 من ملف / etc / network / interfaces الخاص بي ، واستبدلت allow-hotplug بـ auto ، ثم أجبرت على إيقاف تشغيل الشبكة اللاسلكية على كل من wlan0 و wlan1.

ملفي / etc / network / interfaces:

لو تلقائي
iface lo آينت الاسترجاع

إيقاف تشغيل لاسلكي
wlan0 السيارات
دليل iface wlan0
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

إيقاف تشغيل لاسلكي
wlan1 السيارات
دليل iface wlan1
wpa-conf / etc / wpa_supplicant / wpa_supplicant.conf`

ثم قمت بتنظيف ARP:

ip -s -s neigh flush all

ثم أعيد التشغيل:

sudo reboot now

والآن يعمل wifi الخاص بي. لا يصدق. شكرا لجميع الذين علقوا على هذا الموضوع.

قد يتم حل مشكلة التكوين الخاصة بك ، ولا يزال الخطأ في برنامج تشغيل Broadcom موجودًا.

حسنًا ، كنا نبحث في هذا. كانت مشكلتي الأولى هي أنه عندما دخلت SSH في جهاز الاختبار الخاص بي ، كانت الجلسة تغلق ما لم يتم إدخال كابل ethernet أيضًا. تبين أن ARP يتم التعامل معه بواسطة أي من الواجهتين ، لذلك عندما تم توصيل الإيثرنت ، كانت تستخدم ذلك. يعني عدم اتصاله أنه تم التعامل معه بواسطة شبكة Wifi وتواجه مشكلة. يمكن إصلاح هذه المشكلة عن طريق إيقاف تشغيل QoS / ToS في SSH (انظر هنا https://expresshosting.net/ssh-hanging-authentication/) ، وهذا بدوره يعني أن برنامج تشغيل Broadcom Wifi غير راضٍ جدًا عن TOS (نوع من service) / يتم تعيين حقل DSCP. تمت ملاحظة هذا من قبل في NTP (الإصدار رقم 1519). أظن أن هذا قد يكون سببًا لمشكلات Wifi المتعلقة بهذه المشكلة وسأبحث عن برنامج تشغيل Brcm اليوم لمعرفة ما إذا كان بإمكاني العثور على أي شيء.

تقرير مؤقت. نحن نشهد بالتأكيد مشكلات في بعض قيم حزم TOS مما يؤدي إلى إسقاط الحزم بصمت ، مما يتسبب في عمليات تأمين SSH. لا يوجد شيء واضح حتى الآن في رمز السائق الذي لا يمكن اختراقه ، والذي لا ينبغي أن يلمس TBH هذا الجزء من الحزمة على أي حال ، ولكن من الواضح أن هناك شيئًا ما يحدث. هل هذا له علاقة بالتجميد العام لشبكة wlan المذكورة هنا؟ لا أعرف بعد.

لدي مشكلات مماثلة في Pi Zero W مع raspbian jessie و kernel 4.9.35+
لدي نفس المشكلة التي ذكرها JamesH65 مع SSH و ntpd (TOS). الإصلاح من https://expresshosting.net/ssh-hanging-authentication/ يعمل مع sshd. لدي أيضًا مشكلات انقطاع اتصال wlan0 ، ولكن مع رسائل سجل مطولة إلى حد ما. يبدو ظاهريًا أن الناقل ضاع ، ويفشل wpa_supplicant أحيانًا في إعادة التفاوض. السبيل الوحيد للخروج من ذلك هو إصدار ifdown wlan0 ، انتظر ، ifup wlan0 بالنسبة لي ، ثم يبدأ wlan0 في العمل مرة أخرى. يسعدني توفير السجلات إذا طلبها أي شخص. فقط قل لي أي.

تقرير مؤقت. أردت تدوين بعض الملاحظات قبل نسيانها. لقد قررنا أن الاستجابة من pi المتصل لاسلكيًا هي التي تختفي عند الوصول عبر SSH من جهاز آخر. إذا كان هذا الرد يحتوي على مجموعة حقول TOS ، فسيتم إسقاط الحزمة بصمت - لا تعود إلى مقدم الطلب. يمكننا تكرار هذا باستخدام netcat. لا يبدو أن أمر net cat البسيط من Pi اللاسلكي مع مجموعة أعلام TOS يخرجه من الجهاز.
لذا على PI اللاسلكي ، حاول إرسال حزمة UDP إلى جهاز آخر ...
nc -T 0x10 -u7
لا يبدو أن الجهاز يتلقى الحزمة (كما هو موضح من خلال تشغيل tcpdump على الوجهة)
nc -T 0x00 -u7
سيصل إلى النظام البعيد.
لقد جربنا هذا فقط عبر الشبكة اللاسلكية هنا في المكتب. أحتاج إلى إعداد شبكة Wifi أخرى لمعرفة ما إذا كانت مرتبطة بجهاز التوجيه ، أو مشكلة في برنامج التشغيل.

تصحيح طفيف لأمر netcat أعلاه
nc -T 0x10 -u <dest_ip> 7
تم اختيار منفذ UDP 7 لأنه خدمة الصدى. لا يهم أن هذا لا يعمل على الجهاز البعيد ، على الرغم من أن هذا يؤدي إلى استجابة ICMP المناسبة التي لا يمكن الوصول إليها والتي تعد بمثابة حكاية مفيدة تفيد بأن الطرف البعيد قد تلقى الرسالة.

البدء في التفكير في أن مسألة SSH / ToS ليست ذات صلة في الواقع. لقد تتبعت الحزم وصولاً إلى مستوى HW ولا يهم ما إذا تم تعيين علامات TOS أم لا ، يبدو أن الحزم تصل إلى البرنامج الثابت (أو على الأقل وظيفة brcmf_sdiod_send_pkt التي تجاوزت أي معالجة ذات أولوية في سائق لينكس). مما يشير إلى أن المشكلات موجودة إما في البرنامج الثابت في الشريحة (مصدر مغلق) ، أو في الواقع متعلق بجهاز التوجيه - أي أن الموجه اللاسلكي الذي أستخدمه لا يسمح بمرور علامات TOS غير الصفرية (أو ربما> 0x04). سأحاول استخدام موجه لاسلكي مختلف غدًا لمحاولة تأكيد ذلك.

هل هناك أي فرصة لتحديد موقع القسم المسؤول عن تطوير وحدة brcmfmac بحيث يمكن لأي شخص متابعة هذا الموضوع أو على الأقل الرد في حالة إصدار أي إصلاح لهذه الأخطاء؟

نحن بالفعل على اتصال عبر قائمة بريد لينكس اللاسلكية.

في 19 تموز (يوليو) 2017 ، الساعة 19:06 ، كتب "Alexandre Bolelli" [email protected] :

هل هناك أي فرصة لتحديد موقع القسم المسؤول عن التطوير
وحدة brcmfmac بحيث يمكن لأي شخص متابعة هذا الخيط أو على الأقل
الرد إذا تم إصدار أي إصلاح لهذه الأخطاء؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316469790 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHYtYvpxdKd3SBBynOnlDN-ZXiWs_ks5sPkW9gaJpZM4HupC5
.

نحن بالفعل على اتصال عبر قائمة بريد لينكس اللاسلكية.

... والمزيد من الطرق المباشرة. لطالما كانت المشكلة تتعلق بإمكانية التكاثر - بمجرد أن يكون لدينا طريقة لإظهار المشكلة بوضوح ، يمكننا تقديم ذلك إلى Broadcom / Cypress وحلها. لم أتمكن مطلقًا من رؤية المشكلة باستخدام NTP ، لكن جيمس كان يعاني من فشل ناجح مع SSH لذلك أنا متفائل بأننا سنصل إلى السبب الجذري.

pelwell +1 لمصطلح "_successful failure" _ :)

لدي إصلاح اختراق لمشكلة قفل SSH. يبدو أنها مشكلة في البرامج الثابتة. فيما يلي بعض التفاصيل.

"
لقد كنا نحقق في مشكلة على Raspberry Pi ، حيث SSH و
تفشل جلسات NTP عند تعيين علامة TOS في رأس IPv4.

فيما يلي مقتطف من TOS:

TOS هي 0x08 أو 0x10. يُسمح بضبط واحد فقط من 4 بتات في المرة الواحدة.
0x10 - تقليل التأخير
0x08 - تعظيم الصبيب
0x04 - تعظيم الموثوقية
0x02 - تقليل التكلفة النقدية.
تم حل TOS من الناحية الفنية بواسطة DSCP ، لكنه لا يزال مدعومًا.

يمكننا محاولة إعادة إنشاء هذه المشكلة مع DSCP إذا لزم الأمر بالفعل ، لكنها ليست كذلك
تبدو ذات صلة.

تفاصيل حول مشكلة SSH ، ويمكن العثور على حل بديل هنا https://expresshosting.net/ssh-hanging-authentication/

ومع ذلك ، من الواضح أن هذه مشكلة في مكان ما في الاتصالات
مكدس ، لذلك هذا ما كنا نحقق فيه.

لقد تمكنا من تكرار مثال بسيط باستخدام netcat. أولا،
قم بتوصيل Pi لاسلكيًا بـ AP (PiA) ، بجهاز آخر متصل
إما لاسلكيًا أو عبر إيثرنت لنفس الشبكة (PiB).

على تشغيل PiB

sudo tcpdump -n 'udp port 7' -v -i wlan0 <<<< أو eth0 اعتمادًا على الاتصال

في PiA ،

nc -T 0x10 -u7

يرسل هذا حزمة UDP إلى المنفذ 7 ، مع ضبط علامة TOS على 0x10.

لن يصل هذا (أو في بعض الأحيان يتأخر بشدة - 10 ثوانٍ)

إرسال TOS كـ 0

nc -T 0x0 -u7

سيصل. سيصل 0x02 و 0x04 أيضًا ، ولن يصل 0x8 و 0x10.

يُظهر تشغيل برنامج تشغيل brcmfmac أن الحزمة تحتوي على TOS
يتم إرسال العلامة = 0x10 بشكل صحيح أسفل المكدس إلى HW ، ولكن بعد ذلك
الحزمة مفقودة.

تمكنا من الحصول على الحزمة من خلال اختراق رمز BCDC ،
في وظيفة bcdc.c! brcmf_proto_bcdc_hdrpush ، أولوية
يتم دفع الحزمة أيضًا إلى رأس bcdc. عن طريق تعيين هذا إلى
قيمة ثابتة (والتي يمكن أن تكون أي شيء من 0-7) ، الحزمة هي
أحال. لذلك يبدو أن قيمة ثابتة للأولوية bcdc
يعمل ، ولكن بعد تعيينه على الأولوية على النحو الذي يحدده الوارد
تفشل الأشياء ذات الأولوية skb إذا كانت TOS هي 0x08 أو 0x10. لذلك ، يبدو أن
أن تكون مجموعة من الحزم ذات الأولويات المختلفة التي تسبب
قيم الأولوية الأعلى للفشل ، وليس القيمة نفسها.

نظرًا لأن أولوية رأس BCDC مخصصة للبرامج الثابتة ، فهذا
يبدو أنه مشكلة في البرنامج الثابت نفسه ، وليس في Linux
سائق.

فيما يلي اختلاف في التغيير الذي يبدو أنه يوقف حدوث المشكلة.

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 عظيم. نظرًا لأنني لا أتوقع إصلاح البرامج الثابتة قريبًا ، هل يمكنك نسخ هذا إلى linux-wireless؟

سأنتظر بعض المعلومات من Broadcom / Cypress ، منذ أن أصبحت كذلك
لست متأكدًا من أن هذا الاختراق آمن في جميع الظروف. لقد قمت بإرسال بريد إلكتروني إليهم. ذات مرة
أحصل على بعض الملاحظات سأرسل تصحيحًا إلى linux-wireless.

في 20 يوليو 2017 الساعة 12:41 ، كتب Stefan Wahren [email protected] :

@ JamesH65 https://github.com/jamesh65 عظيم. بما أنني لا أتوقع a
قريبًا إصلاح البرامج الثابتة ، هل يمكنك نسخ هذا إلى linux-wireless؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316678154 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHY3DlxTr9mehRDlxBK3NWbjowxxyks5sPzzqgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

يبدو أن بعض نتائج الاختبارات تشير إلى عدم وجود آثار سيئة من هذا الاختراق. كنت تنقل البيانات ذهابًا وإيابًا ، 500 ميجابايت إلى Wireless Pi ، 3.4 جيجابايت مرسلة. تم إسقاط حزم RX 56 من 794730 ، ولم يتم إسقاط أي حزم TX من 2813930. يبدو الأداء موضعيًا لاتصال 11 ميجابت / ثانية. تبدو مقبولة ، ولكن هذا الاختراق في الواقع يعطل شيئًا ربما يجب تمكينه ، لذلك ليس حلاً طويل المدى.

lategoodbye كنت

تضمين التغريدة
هل تعتقد أنه يمكن دفع هذا إلى ARCH linux-raspberrypi؟

@ JamesH65 بالتأكيد ، الاختراق الخاص بك ليس مناسبًا لجميع طرازات الشرائح. ولكن ليس من واجبك إيجاد حل لكل منهم. أعتقد أن نسخة بسيطة من تعليقك الطويل أعلاه (بما في ذلك الاختراق) ستكون كافية. كان هدفي هو إبلاغ مطور نواة غير برودكوم حول هذه المشكلة. لم أكن أتوقع منك إرسال تصحيح مناسب لهذه المشكلة ، فقط تقرير خطأ.

أقترح إدخاله في الريبو الخاص بنا لإجراء بعض الاختبارات الجادة - ابدأ بـ rpi-4.12.y الذي تستخدمه أحدث إصدارات LibreElec الليلية.

فكر واحد - هل يمكنك جعل التصحيح أكثر انتقائية في ترشيح أولوياته وما زلت تحل المشكلة؟

أنا فقط أستعد للعلاقات العامة من أجل الذهاب إلى Pi repo.

فيما يتعلق بالفحص الانتقائي ، حاولت ببساطة الكشف عن الأولوية
6 (الذي يتم تمريره إلى أسفل المكدس - يتم ترجمته من TOS
لشيء أكثر تحديدًا لمكدس Linux) ، وتعيين ذلك على 0 و
التي يبدو أنها تعمل بالفعل ، لكن شكوكي أنها مزيج من
أولويات مختلفة وليس بالتحديد 6 التي تسبب المشكلة. نحن
تعلم أيضًا أن TOS لـ 0x08 بها مشكلات أيضًا ، وهي IIRC ،
تحولت إلى 2 بحلول الوقت الذي تصل فيه إلى هذه النقطة. يمكننا ببساطة أن نقول ، إذا
إنها 6 أو 2 ، ثم اضبطها على الصفر ، لكنني ما زلت غير متأكد من أن ذلك سيصطاد
كل ما قد يسبب مشاكل. نظرًا لأن القيمة هي 0-7 على أي حال ، فأنا أعتقد ،
لهذا الاختراق ، من الأفضل التعيين على 0 في جميع الحالات. نحن نعلم ذلك
يعمل ، قد لا يكون هو الأمثل بالطبع ، لكنني أعتقد أن جميع الحزم ستكون كذلك
تمر. لاحظ أن هذا الإعداد لا يؤثر على قيمة شروط الخدمة في ملف
حزمة IPv4 - تظل كما هي ، إنها مجرد نظام إرسال ملف
الأولوية للرقاقة وكيفية معالجتها بعد ذلك يبدو غير مستقر.

في 21 يوليو 2017 الساعة 09:35 ، كتب Phil Elwell [email protected] :

فكر واحد - هل يمكنك جعل التصحيح أكثر انتقائية في أولويته
التصفية ومازال لديك حل المشكلة؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

لقد أجريت بعض الاتصالات مع Cypress ، الذين سيحاولون الحصول على هذا
نظرت في اسرع وقت ممكن.

في 21 يوليو 2017 الساعة 10:11 ، كتب جيمس هيوز [email protected] :

أنا فقط أستعد للعلاقات العامة من أجل الذهاب إلى Pi repo.

فيما يتعلق بالفحص الانتقائي ، لقد حاولت الاكتشاف ببساطة
الأولوية 6 (التي يتم تمريرها إلى أسفل المكدس - يتم ترجمتها من
قيمة TOS لشيء أكثر تحديدًا لمكدس Linux) ، وتعيين ذلك على
0 ويبدو أن ذلك نجح ، لكن شكوكي هو أنه مزيج
من الأولويات المختلفة وليس بالتحديد 6 التي تسبب المشكلة.
نعلم أيضًا أن TOS لـ 0x08 به مشكلات أيضًا ، وهي IIRC ،
تحولت إلى 2 بحلول الوقت الذي تصل فيه إلى هذه النقطة. يمكننا ببساطة أن نقول ، إذا
إنها 6 أو 2 ، ثم اضبطها على الصفر ، لكنني ما زلت غير متأكد من أن ذلك سيصطاد
كل ما قد يسبب مشاكل. نظرًا لأن القيمة هي 0-7 على أي حال ، فأنا أعتقد ،
لهذا الاختراق ، من الأفضل التعيين على 0 في جميع الحالات. نحن نعلم ذلك
يعمل ، قد لا يكون هو الأمثل بالطبع ، لكنني أعتقد أن جميع الحزم ستكون كذلك
تمر. لاحظ أن هذا الإعداد لا يؤثر على قيمة شروط الخدمة في ملف
حزمة IPv4 - تظل كما هي ، إنها مجرد نظام إرسال ملف
الأولوية للرقاقة التي تظهر غير مستقر وكيف تتعامل معها بعد ذلك
يبدو غير مستقر.

في 21 يوليو 2017 الساعة 09:35 ، كتب Phil Elwell [email protected] :

فكر واحد - هل يمكنك جعل التصحيح أكثر انتقائية في أولويته
التصفية ومازال لديك حل المشكلة؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

نعلم أيضًا أن TOS لـ 0x08 به مشاكل أيضًا ، وهذا هو ، IIRC ، تم تحويله إلى 2 بحلول الوقت الذي يصل فيه إلى هذه النقطة.

صيح. تم تعيين TOS 0x08 (زيادة الإنتاجية) إلى 2. وهي قيم TC_PRIO_xxx من http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/pkt_sched.h#L19. 6 = تفاعلي ، 2 = كتلة.

أدى الاختبار السابق مع ضبط IPQoS على 8 في sshd_config أو باستخدام netcat باستخدام TOS 8 إلى إسقاط الحزم.
لم يتسبب كل من 0x02 ولا 0x04 في حدوث أي مشكلات ، ولكن هناك القليل من برنامج تشغيل wifi يمكن أن يفعله على اختلاف التكلفة (لا يوجد شيء) أو الموثوقية ، لذلك ربما يتم تجاهلها.
قم بتحرير جدول الخرائط في http://elixir.free-electrons.com/linux/latest/source/net/ipv4/route.c#L177 مع أخذ tos>>1 بتعيين TOS 0x02 و 0x04 إلى TC_PRIO_BESTEFFORT = 0 على أي حال ، وهو ما يفسر سبب عدم وجود أية مشكلات لديهم.

مجرد تقرير سريع. كان Cypress قادرًا على تكرار المشكلة ، وهو كذلك
التحقق من البرامج الثابتة حتى تبدو متفائلة. سار جدا وسرعة الاستجابة
من الرجال هناك.

في 21 يوليو 2017 الساعة 11:07 ، كتب 6by9 [email protected] :

نعلم أيضًا أن TOS لـ 0x08 به مشكلات أيضًا ، وهي IIRC ،
تحولت إلى 2 بحلول الوقت الذي تصل فيه إلى هذه النقطة.

صيح. تم تعيين TOS 0x08 (زيادة الصبيب) إلى 2. وهي TC_PRIO_xxx
القيم من http://elixir.free-electrons.com/linux/latest/source/
تشمل / uapi / linux / pkt_sched.h # L19. 6 = تفاعلي ، 2 = كتلة.

الاختبار السابق إما بإعداد IPQoS على 8 في sshd_config أو مع
نتج عن netcat باستخدام TOS 8 إسقاط الحزم.
لم يتسبب كل من 0x02 ولا 0x04 في حدوث أي مشكلات ، ولكن هناك القليل من برنامج تشغيل wifi
يمكن أن تفعله على فرق التكلفة (لا يوجد) أو الموثوقية كذلك على الأرجح
تجاهلهم (لم أتحقق منها).

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-316962443 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHXTmjzqVW0o4T9IIoYFPprKvEvS7ks5sQHhXgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

أسهل طريقة للتكاثر - استخدم ping! (لقد نسيت أن ping / ICMP كان أعلى من IP - سخيف لي)

ping -Q 0x10 <dest ip addr> على Pi3
وتشغيل tcpdump -n -v -i wlan0 'icmp' على الوجهة.
ينتج عنه> 90٪ من فقدان الحزمة على -Q 0x10 أو -Q 0x08 غالبًا ما يبدأ بشكل جيد مع وصول 4 حزم متسلسلة ، ولكن بعد ذلك يتم بشكل متقطع للغاية.
إنها مفيدة أكثر بقليل من netcat لأنها (أ) تستمر في التكرار ، و (ب) تخبرك عندما تحصل على استجابة.

يوجد حل بديل هنا: https://github.com/raspberrypi/linux/pull/2126
إذا كنت ترغب في اختباره باستخدام 4.9 kernel ، فاستخدم تحديث rpi.
ثم استبدل:
الوحدات / 4.9.39 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko مع هذا
الوحدات / 4.9.39-v7 + / kernel / drivers / net / wireless / broadcom / brcm80211 / brcmfmac / brcmfmac.ko مع هذا

تحرير: يتضمن أحدث إصدار لـ rpi-update kernel الآن التصحيح ، لذا لم يعد تنزيل الوحدات مطلوبًا.

لست متأكدا إذا كانت ذات صلة. ينقطع الاتصال على Broadcom الموجودة على اللوحة على Pi Zero W كل ساعتين عندما تكون الواجهة الثانية wlan1 معطلة rt8192eu / 8192eu dongle. لا يبدو أنها مشكلة في الطاقة لأنها دورية للغاية ، ولدي مجموعة من قطع الاتصال على https://pastebin.com/5hMQHWeW

عندما يكون هذا مستمرًا ، يتخلى wpa_supplicant أحيانًا عن المحاولة دون سبب واضح بخلاف الفشل في المصادقة والطريقة الوحيدة لاستعادة الاتصال على wlan0 هي إصدار ifdown / ifup الذي يعمل بعد ذلك بنسبة 100٪.

الآن لا أعرف ما إذا كانت هذه هي مشكلات وحدة Broadcom kernel ذات الصلة التي تسبب المشكلات ، أو ما إذا كانت عربات التي تجرها الدواب 8192eu أو كليهما. يسعدني تقديم المزيد من سطور السجلات إذا لزم الأمر أو النشر في سلسلة رسائل مختلفة ، ولكن اقترح أحد الأشخاص على #raspbian أن أضيف هذا هنا.

إذا كان بإمكانك التأكد من أن vcgencmd get_throttled بإرجاع 0x0 بعد انقطاع الاتصال الذي سيستبعد مشكلة في الطاقة.

يحدث عادةً عندما أكون نائمًا / لا مع Pi وأجد ذلك في وقت لاحق عندما لا يمكنني الاتصال به بعد الآن (ثم اعتدت الاتصال عبر نقطة الوصول الثانية وإعادة تعيين wlan0). ومع ذلك ، منذ أن تم فصل دونجل 8192eu الآن ، لم يكن هناك حدث. يمكنني توصيل الدونجل الثاني بوحدة عربات التي تجرها الدواب ، ولكن متى بعد قطع الاتصال أحتاج إلى التحقق من الحصول على vcgencmd get_throttled؟

طالما أنك لم تقم بإعادة التشغيل ، ستخبرك البتات العلوية بما إذا كان هناك حدث انخفاض الجهد.

ركضت للتو. بالتأكيد لم يتم إعادة التشغيل منذ قطع الاتصال الأخير. يمكن تأكيد عوائد vcgencmd get_throttled:
مخنوق = 0 × 0

لسوء الحظ ، لن يعمل get_throttled على Pi0 / Pi0w (لا يحتوي على دائرة الكشف عن الجهد المنخفض).

لسبب ما ، لم يعمل نسخ ولصق الفرق من JamesH65 بالنسبة لي. صنع ملف تصحيح يجب تطبيقه على الفور ، وقد يجد الأشخاص المجنون هذا مفيدًا: https://github.com/bortek/EZ-WifiBroadcast/blob/master/kernel/linux-4.9.28-brcmfmac-tos.patch

يقول اسم الملف 4.9.28 ، ولكن يجب أن يطبق على الأقل حتى 4.9.35 (وربما لاحقًا أيضًا).

انسخ هذا الملف إلى الدليل الجذر لشجرة kernel وطبقه باستخدام patch -p1 < linux-4.9.28-brcmfmac-tos.patch

معلومات إضافية (لكن فردية):

إذا كان Pi Zero W متصلاً بشبكة wlan0 ، ولكن لم تفعل شيئًا (فحص برنامج cron النصي كل 15 دقيقة على الأكثر) ، فهناك قطع اتصال متكررة جدًا ، شيء في حدود 1-10 / ساعة يستمر لمدة ثانية على الأكثر لكل منهما.

إذا كان لدي شيء يستخدم الاتصال ، على سبيل المثال ، الخمول على IRC (قنوات كبيرة متعددة) ، فإن الاتصال لا ينقطع مرة واحدة طوال الوقت كله هذا هو الحال.

تبين أن تحميل وحدات النواة 4.9.39 على 4.9.35 لم يكن فكرة جيدة.

تقرير خطأ آخر من المنتدى ، يبدو خطأ صندوق البريد شائعًا.

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

تتضمن أحدث نواة تحديث rpi الآن تصحيح أولوية BCDC.

أعطانا Cypress (كان Broadcom) إصدارات جديدة من البرامج الثابتة WiFi و Bluetooth لاختبارها. يمكنك تنزيل الإصدار التجريبي من هنا . بعد التنزيل على Pi الخاص بك ، قم بتشغيل:

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

سيؤدي هذا إلى استخراج البرنامج الثابت الجديد ثم تثبيته (سيتم نسخ الإصدارات القديمة احتياطيًا أولاً).

للرجوع إلى البرنامج الثابت الأصلي (الذي أوصيك بفعله قبل تثبيت إصدار مناسب):

./brcmfw -u

ما الذي تغير:

1. CVE-2017-9417: إصلاح مشكلة "Broadpwn"
2. أضف سلسلة "CY" في سلسلة الإصدار.
3. إصلاح الجمود لرقم تسلسل AMPDU (إصلاح محتمل لهذه المشكلة)
4. ترقية إصدار CLM
5. CVE-2017-0572: إصلاح تلف الذاكرة

مجرد ملاحظة جانبية - لقد قمت بتعطيل wifi داخلي على أول Pi Zero W وتحولت إلى USB wifi dongle ، وذهبت جميع المشاكل. منذ بضعة أيام قمت بتثبيت Pi Zero W آخر للتحكم في الطابعة ثلاثية الأبعاد (باستخدام OctoPi). لقد فوجئت قليلاً برؤية أن شبكة wifi الداخلية تعمل بشكل لا تشوبه شائبة - ولكن بعد بعض الاختبارات يمكنني أن أؤكد أن wifi ينقطع بمجرد الاتصال من هاتف LG G4 Android (متصفح Chrome). عندما أفكر في الأمر ، أعتقد أن السلوك في Pi الأول كان مشابهًا تمامًا ...
لا يؤدي الاتصال من جهاز الكمبيوتر الخاص بي إلى مثل هذه التأثيرات.

يرجى تجربة البرنامج الثابت الجديد والإبلاغ عن النتائج الخاصة بك.

لقد قمت بتثبيت البرنامج الثابت للمعاينة. ما زلت أحصل على "raspberrypi kernel: brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف:" خطأ ، متبوعًا بفشل wifi.

ما هي حالة الاستخدام الخاصة بك؟

مثل:
https://www.raspberrypi.org/forums/viewtopic.php؟f=28&t=189046

محاولة تكوين العمل نشرت هناك. وسوف أقوم بتحديث.

يرجى تقديم إصدار kernel الخاص بك ، وملخصًا للأجهزة المتصلة ، وسيستغرق الأمر وقتًا طويلاً حتى يظهر الخطأ.

لا يزال خطأ صندوق البريد قيد التحقيق ، ولا أتوقع ذلك
البرامج الثابتة لإصلاحها. هناك المزيد من تصحيح الأخطاء في هذا البرنامج الثابت للمساعدة في التتبع
على الرغم من ذلك. إذا قمت بتمكين تصحيح أخطاء برنامج التشغيل (آسف ، على الهاتف المحمول و
ليس لديك تفاصيل حول كيفية القيام بذلك) وشاهد الخطأ ، ثم قم بإلقاء ملف
التصحيح ونشر التفاصيل هنا عندما تحصل على خطأ صندوق البريد سيكون
مفيد.

في 13 أغسطس 2017 الساعة 21:40 ، كتب "Stefan Wahren" [email protected] :

يرجى تقديم إصدار kernel الخاص بك وملخصًا للأجهزة المتصلة و
يستغرق وقتًا طويلاً حتى يظهر الخطأ.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322062745 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHRwsQyHa-QqOP7ntTqgCfWlgXpEqks5sX1DlgaJpZM4HupC5
.

يتم تعطيل تصحيح الأخطاء افتراضيًا ويحتاج إلى إعادة بناء وحدة نمطية لتمكينها (ربما يتعين علينا تغيير ذلك أثناء هذه التحقيقات). التغييرات المطلوبة هي إضافة BRCMDBG=y إلى .config متبوعًا بإعادة بناء ، ثم أضف brcmfmac.debug=0x???????? إلى /boot/cmdline.txt ، حيث ???????? هو رقم سداسي عشري يتألف من قيم بت موثقة هنا: https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h#L22

حاولت اختبار البرامج الثابتة التي نشرتها pelwell ، لا تزال المشكلة قائمة. يتجمد الاتصال كل ساعة إلى ساعتين. عندما انقطع الاتصال وحاولت إجراء الأمر ping ( ping 8.8.8.8 ) ، فإنه يعمل مرة أخرى _ باختصار_ حتى 8 ping. سلوك ping ثابت عبر التجميد. العمل-> التجميد-> ping 8.8.8.8-> العمل -> ping الثامن -> التجميد بعد ذلك ، أحتاج إلى إعادة تشغيل raspberry pi. لا أعرف ما إذا كانت تساعد بالرغم من ذلك ..

نواة:
Linux raspberrypi 4.9.41-v7 + # 1023 SMP الثلاثاء 8 أغسطس 16:00:15 بالتوقيت الصيفي البريطاني 2017 armv7l GNU / Linux

البرامج الثابتة:
BT: test_170808
صندوق WiFi: test_170808
WiFi txt: test_170808

أي شيء ذي صلة في dmesg عندما يحدث؟

في 14 آب (أغسطس) 2017 ، الساعة 13:16 ، إرسال "GIlang Charismadiptya" [email protected]
كتب:

حاولت اختبار البرامج الثابتة التي نشرتها pelwell ، لا تزال المشكلة قائمة.
يتجمد الاتصال كل ساعة إلى ساعتين. عندما انقطع الاتصال وأنا
حاول ping (ping 8.8.8.8) ، فهو يعمل مرة أخرى لفترة وجيزة حتى 8
بينغ. بعد ذلك ، أحتاج إلى إعادة تشغيل raspberry pi.

نواة:
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 الثلاثاء 8 أغسطس 16:00:15 بتوقيت جرينتش 2017 armv7l GNU / Linux

البرامج الثابتة:
BT: test_170808
صندوق WiFi: test_170808
WiFi txt: test_170808

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

كلا ، لا شيء مثير للاهتمام. ربما لأنني لم أعد بناء الوحدة بدعم تصحيح الأخطاء. كيف افعلها؟ أو هل ستوفر الوحدة المترجمة؟ شكر.

تم إرفاق سجلات 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
`

راجع منشور Phil أعلاه للحصول على تفاصيل حول وحدة التصحيح. نحن على وجه الخصوص
مهتم بتتبع التصحيح عند حدوث خطأ صندوق البريد.

في 14 آب (أغسطس) 2017 ، الساعة 17:52 مساءً ، تم إرسال إشعارات "GIlang Charismadiptya"github.com
كتب:

كلا ، لا شيء مثير للاهتمام. ربما لأنني لم أعد بناء الوحدة مع
دعم التصحيح. كيف افعلها؟ أو هل ستوفر الوحدة المترجمة؟
شكر.

مرفق أدناه سجل dmesg:

` pi @ raspberrypi : ~ $ sudo dmesg

[4.654722] brcmfmac: إصدار البرنامج الثابت = wl0: 7 أغسطس 2017 00:46:29 إصدار
7.45.41.46 (r666254 CY) FWID 01-f8a78378
[5.752968] smsc95xx 1-1.1: 1.0 eth0: الأجهزة غير قادرة على التحكم عن بعد
استيقظ
[5.753285] IPv6: ADDRCONF (NETDEV_UP): eth0: الرابط غير جاهز
[6.206530] IPv6: ADDRCONF (NETDEV_UP): wlan0: الرابط غير جاهز
[6.206577] brcmfmac: تعطيل إدارة الطاقة
[7.088933] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: أصبح الرابط جاهزًا
[7.340040] IPv6: ADDRCONF (NETDEV_CHANGE): eth0: الرابط يصبح جاهزًا
[7.340841] smsc95xx 1-1.1: 1.0 eth0: ارتباط ، 100 ميجا بت في الثانية ، ازدواج كامل ، lpa
0xCDE1
[7.431235] إضافة 102396k مقايضة على / var / swap. الأولوية: -1 نطاقات: 4
عبر: 217088k SSFS
[10.182342] IPv6: ADDRCONF (NETDEV_UP): wlan0: الرابط غير جاهز
[10.182357] brcmfmac: إدارة الطاقة معطلة
[10.872838] IPv6: ADDRCONF (NETDEV_UP): wlan0: الرابط غير جاهز
[10.872903] brcmfmac: إدارة الطاقة معطلة
[11.594201] IPv6: ADDRCONF (NETDEV_CHANGE): wlan0: أصبح الرابط جاهزًا
[14.128592] ip_tables: (C) 2000-2006 Netfilter Core Team
[14.172268] إصدار nf_conntrack 0.5.0 (15360 حاوية ، 61440 كحد أقصى)
[54.604680] عشوائي: تم تنفيذ crng init

pi @ raspberrypi : ~ $ sudo dmesg -l err
[4.501055] raspberrypi-touchscreen 3f700000.dsi.0: برنامج Atmel الثابت غير معروف
المراجعة: 0xfa
"

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-322228992 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHXuy3Eo5PqPAP8FfSFiYWMUQL7fAks5sYG1HgaJpZM4HupC5
.

تمكّن نواة تحديث rpi الأخيرة BRCMDBG والتي يجب أن تسمح بخيار سطر الأوامر brcmfmac.debug=0x???????? الذي اقترحه pelwell سابقًا.

Errrr ..... فقدته Pi3 التي كانت قوية جدًا مع شبكة wifi الآن أيضًا منذ أن قمت بالترقية إلى أحدث raspbian منذ بضعة أيام :-(

ما هي الاعراض؟ لا أتوقع حدوث تراجع في البرامج الثابتة ، أو
في الواقع السائق نفسه.

في 24 أغسطس 2017 الساعة 20:07 ، كتب Crrispy [email protected] :

Errrr ..... لقد فقدت Pi3 التي كانت صلبة مع شبكة wifi الآن أيضًا منذ أن كنت
تمت ترقيته إلى أحدث إصدار من raspbian قبل بضعة أيام :-(

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-324728431 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHUxvLV3OzKGpcmEMGEoSad_piujBks5sbcoHgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

تضمين التغريدة
جرب هذا:
أزلت كل إشارة إلى eth0 من ملف / etc / network / interfaces الخاص بي ، واستبدلت allow-hotplug بـ auto ، ثم أجبرت على إيقاف تشغيل الشبكة اللاسلكية على كل من wlan0 و wlan1.

ملفي / etc / network / interfaces:

auto lo
iface lo inet loopback

wireless-power off
auto wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

wireless-power off
auto wlan1
iface wlan1 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf`

ثم قمت بتنظيف ARP:

ip -s -s صهيل مسح الكل

ثم أعيد التشغيل:

sudo إعادة التشغيل الآن

أنا متأكد من أنني أواجه هذا الخطأ بشكل منتظم. تشغيل hostapd ، باستخدام Broadcom wifi الداخلية لاستضافة نقطة وصول ، وتوجيه العملاء الذين يتصلون بها من خلال USB wifi dongle الذي يعمل كعميل لاسلكي. أجهزة متعددة متصلة ، ولكن بمجرد أن أحمل Pi خارج نطاق الأجهزة المتصلة ، يبدو أن تعطل شبكة wlan يحدث. كما هو الحال مع الآخرين ، فإن جهاز wlan الداخلي فقط هو الذي ينخفض: تظل شبكة ethernet والشبكة اللاسلكية الأخرى غير متأثرة. أتلقى أيضًا خطأ "صندوق البريد" في سجل النظام:

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

(مزيد من تفاصيل السجل على https://pastebin.com/NPB00ZEq)

لقد لاحظت أن إخراج iwconfig لم يعد يُظهر قيمة Tx_Power عندما يكون جهاز wlan في حالته الفاشلة ، لذلك استخدمت ذلك لبرمجة إعادة تشغيل تلقائية كحل بديل في هذه الأثناء.

لقد قمت للتو بالتحديث إلى آخر تحديث لـ rpi ، وقمت بتثبيت برامج تشغيل اختبار wifi المشار إليها أعلاه ، وأضفت علامة تصحيح الأخطاء إلى cmdline.txt ، باستخدام القيمة السداسية لـ BRCMF_TRACE_VAL: bcrmfmac.debug=0x00000002

إذا تمكنت من الحصول على خطأ صندوق البريد بانتظام ، فسنكون ممتنين للنتائج من برنامج تشغيل التصحيح. عندما تحصل على خطأ في صندوق البريد ، يرجى القيام بشيء من هذا القبيل للحصول على الأدلة الجنائية ونشر النتائج هنا ، ويمكنني نقلها إلى Cypress الذي يحقق في المشكلة.

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

حسنًا ، ما كانت مشكلة مستنسخة بسهولة لم أعد قادرًا على تكرارها ، منذ تشغيل تحديث rpi. قد أكون قادرًا على تحقيق ذلك من خلال الرجوع إلى إصدار جديد من تثبيت Raspbian اعتبارًا من 21 يونيو 2017 ، إذا كان ذلك مفيدًا.

تضمين التغريدة
تمكنت من التقاط الأدلة الجنائية التي طلبتها (بعد خطأ صندوق البريد) ، ولكن لكي نكون واضحين ، هذا بعد الرجوع إلى kernel المتضمن في 21 June Raspbian build. ربما تم حلها بالفعل ، لأنني لم أكرر المشكلة بعد بعد تثبيت البرنامج الثابت للاختبار الذي نشرته pelwell منذ حوالي أسبوعين ، وتشغيل تحديث rpi.

إليك رابط للطب الشرعي:
https://pastebin.com/VVqVQ8FW

آمل أن يكون هذا مفيدًا ...

حتى مع البرامج الثابتة القديمة أظن. نحن نأمل في الحصول على الطب الشرعي ل
البرنامج الثابت الجديد الذي يحتوي على رسائل إضافية (على ما يبدو) تهدف إلى التتبع
أسفل قضية صندوق البريد. هذا يجعلني أعتقد أن Cypress لا تزال تعتقد أن
ستكون مشكلة صندوق البريد موجودة ، حتى بعد الإصلاحات الأخرى. سيتم تمرير البيانات على أي حال فقط في حال كان ذلك مفيدًا.

من الجيد معرفة أن تكرار الأخطاء أصعب بكثير!

في 29 أغسطس 2017 الساعة 15:51 ، كتب randyoo [email protected] :

تضمين التغريدة
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=
تمكنت من التقاط الأدلة الجنائية التي طلبتها ، ولكن لكي أكون واضحًا ،
هذا بعد خفض التصنيف إلى النواة المدرجة في 21 يونيو Raspbian
بناء. ربما تم حلها بالفعل ، لأنني غير قادر على ذلك
قم بتكرار المشكلة بعد تثبيت البرنامج الثابت للاختبار المنشور بواسطة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=
منذ حوالي أسبوعين.

إليك رابط للطب الشرعي:
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=

آمل أن يكون هذا مفيدًا ...

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

هذا يجعلني أعتقد أن Cypress لا تزال تعتقد أن
ستكون مشكلة صندوق البريد موجودة ، حتى بعد الإصلاحات الأخرى.

نعم ، هذا ما أفهمه أيضًا.

randyoo شكرا على ردود الفعل الإيجابية.

تضمين التغريدة
حسنًا ، حدث ذلك مرة أخرى ، هذه المرة على أحدث البرامج الثابتة لتحديث rpi ، وباستخدام البرنامج الثابت للاختبار المنشور بواسطة pelwell . لسوء الحظ ، تبدو مخرجات الطب الشرعي مطابقة لتلك الموجودة في المنشور السابق. (لست متأكدًا من سبب عدم تلقي معلومات مختلفة / أكثر تفصيلاً في ملف تفريغ الطب الشرعي ، حيث تم تمكين تصحيح الأخطاء في ملف cmdline.txt الخاص بي ، وفقًا لمشاركتي السابقة)

لقد تقدمت وأفرغت محتويات عناصر / sys / kernel / debug الأخرى أيضًا. ها هو: https://pastebin.com/pdFUPBxN

في آخر تجميد لشبكة wlan ، يبدو أن تتبع سجل kernel أكثر تفصيلاً. انظر الرابط:
https://pastebin.com/KTxbgpYV

امل ان يساعد.

هل كان هناك المزيد من التفاصيل في الأدلة الجنائية للبرامج الثابتة؟ أعتقد أن هذا هو
يهتم بت Cypress حقًا عند حدوث خطأ في صندوق البريد.

في 31 أغسطس 2017 الساعة 21:56 ، كتب randyoo [email protected] :

في آخر تجميد لشبكة wlan ، يبدو أن تتبع سجل kernel أكثر تفصيلاً.
انظر الرابط:
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=

امل ان يساعد.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

صحيح ، آسف. تمكنت من الحصول على لقطة للطب الشرعي ، ونعم ، يبدو أن هناك المزيد من التفاصيل:
https://pastebin.com/qypfAfAp

نظرًا لأن وجود حالات جديدة يساعدني أحيانًا ، أحصل عليه أيضًا من وقت لآخر:

pi @ jempi : ~ $ grep "brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012" / var / log / syslog
14 أغسطس 22:16:23 jempi kernel: [501.247242] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
17 أغسطس 20:26:20 jempi kernel: [509.684277] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
24 أغسطس 23:57:37 jempi kernel: [573.652189] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
29 أغسطس 23:50:16 jempi kernel: [5052.517999] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
30 أغسطس 00:02:18 jempi kernel: [170.978988] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
30 أغسطس 23:58:03 jempi kernel: [8254.502431] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
2 سبتمبر 00:33:28 jempi kernel: [5979.773944] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012

أنا أستخدم شبكة wifi الداخلية (wlan0) كنقطة وصول وقمت بتوصيل دونجل (wlan1) للاتصال بجهاز التوجيه الخاص بي:
pi @ jempi : ~ $ ifconfig wlan0
غلاف ارتباط wlan0
آينت العنوان: 10.3.141.1 البث: 10.3.141.255 القناع: 255.255.255.0
inet6 addr: fe80 :: 6b56: 4657: 75cd: a501 / 64 النطاق: الرابط
تشغيل البث المتعدد MTU: 1500 متري: 1
حزم RX أخطاء: 0 مسقطة: 0 تجاوزات: 0 إطار: 0
حزم TX خطأ: 0 مسقطة: 0 تجاوزات: 0 ناقل: 0
c ollisions: 0 t xqueuelen: 1000
بايت RX بايت TX

pi @ jempi : ~ $ ifconfig wlan1
غلاف ارتباط wlan1
آينت العنوان : 192.168.1.74 البث: 192.168.1.255 القناع: 255.255.255.0
inet6 addr: fe80 :: 260: b3ff: fedb: 8a4a / 64 النطاق: الرابط
تشغيل البث المتعدد MTU: 1500 متري: 1
حزم RX خطأ: 0 مسقطة: 2 تجاوزات: 0 إطار: 0
حزم TX خطأ: 0 مسقطة: 0 تجاوزات: 0 ناقل: 0
c ollisions: 0 t xqueuelen: 1000
بايت RX بايت TX

كان لدي kernel 4.9.35-v7 + وقمت بترقيته بالأمس إلى 4.9.46-v7 + (مع تحديث rpi) ولكنه لا يساعد. الإدخال من سجل النظام عند إخفاقه:

2 سبتمبر 00:33:28 jempi kernel: [5979.773944] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
سبتمبر 2 00:34:00 jempi kernel: [6011.624839] brcmfmac: brcmf_netdev_wait_pend8021x: مهلة انتظار عدم وجود حزم 802.1x معلقة
2 سبتمبر 00:34:02 jempi kernel: [6014.184823] brcmfmac: send_key_to_dongle: خطأ wsec_key (-110)
2 سبتمبر 00:34:05 jempi kernel: [6016.744833] brcmfmac: brcmf_cfg80211_del_station: SCB_DEAUTHENTICATE_FOR_REASON فشل -110
سبتمبر 2 00:34:06 نواة jempi: [6017.704831] brcmfmac: brcmf_netdev_wait_pend8021x: انتهت المهلة في انتظار عدم وجود حزم 802.1x معلقة
سبتمبر 2 00:34:08 jempi kernel: [6020.264850] brcmfmac: send_key_to_dongle: خطأ wsec_key (-110)
سبتمبر 2 00:34:11 jempi kernel: [6022.824903] brcmfmac: brcmf_cfg80211_change_station: فشل إعداد تفويض SCB (de-) ، -110

إعادة تشغيل واجهة wlan0 باستخدام sudo ifconfig wlan0 لأسفل ثم لأعلى لم يساعد.

bulrog يرجى أيضًا تقديم الطب الشرعي كما أوضح جيمس أعلاه.
ما هو برنامج التشغيل الذي يستخدمه wlan1؟ هل ما زالت هذه المشكلة تحدث مع دونجل غير موصول؟

يلتقط عدد قليل من الأدلة الجنائية:
https://pastebin.com/vqh3UcF3

في حال كان هذا يساعد Cypress في البحث في المنطقة الصحيحة: لقد واجهت هذه المشكلة عدة مرات الآن ، ويبدو أنها تظهر نفسها كلما حاول الجهاز الاتصال. لقد حدث ذلك عدة مرات بعد السير في نطاق AP ، أو عند إيقاظ جهاز النوم.

لقد احتفظت بهذا التكوين لفترة كافية لالتقاط الأدلة الجنائية ، وإذا كان هناك أي تفاصيل أخرى يمكنني تقديمها ، فسأكون سعيدًا للقيام بذلك ، لكن أعطال الشبكات اللاسلكية تحدث الآن بشكل متكرر بحيث تجعل جهازي عديم الفائدة. أنوي استخدام دونجل USB wifi آخر لاستبدال الراديو الداخلي ، من أجل تحقيق الموثوقية.

لقد قمت بإرسال أحدث تحاليل جنائية لك إلى Cypress - شكرًا على الوقت الذي قضيته في ذلك.

أردت فقط التناغم. لدي نفس المشكلة بالضبط على ثلاثة RPI3s تقوم بتشغيل أحدث البرامج الثابتة. أنا أستخدم Octopi على الثلاثة وأصل إليهم عبر Printoid.

bcrmfmac.debug يجب أن يكون brcmfmac.debug (شكرًا لك على اكتشافMilhouseVH)
سوف أقوم بتحرير المشاركات السابقة.

يجب أن يكون bcrmfmac.debug هو brcmfmac.debug (شكرًا لك على اكتشافMilhouseVH)
سوف أقوم بتحرير المشاركات السابقة.

بناءً على ذلك ، افترضت أن الأدلة الجنائية التي التقطتها لم تكن كاملة.

لقد كررت التقاط الطب الشرعي ، ويمكن الاطلاع عليه على عنوان URL التالي:
https://pastebin.com/ha5rd7SW

بالإضافة إلى ذلك ، يبلغ حجم ملف /var/log/kern.log الخاص بي 200 ميغا بايت تقريبًا ، ويتكون معظمه من إدخالات متشابهة جدًا. حددت موقع خطأ صندوق البريد في 00:53:19 ، وقمت بقصه قبل الخطأ وبعده بثانيتين. نأمل أن يساعدك ، شاهده هنا:
https://pastebin.com/JcE0zstS

لذلك أعتقد أنني وجدت نفس المشكلة ، راجع https://www.raspberrypi.org/forums/viewtopic.php؟f=28&t=192735

يمكنني إعادة إنتاجه في غضون 5 دقائق. أنت بحاجة إلى قدر كبير من حركة المرور عبر wifi (واجهة الويب للكاميرا) وإشارة wifi منخفضة جدًا. لدي صفر pi وهو كافٍ لوضع إصبعك / يديك حول الهوائي الموجود على اللوحة للحصول على الإشارة إلى الصفر تقريبًا (يظهر جهاز التوجيه الخاص بي إشارة 15-20 ٪). بعد حوالي دقيقة واحدة في هذه الحالة ، تعطل wifi

lategoodbye بعد أسبوع من الخروج ، قمت بتشغيل pi ولا توجد مشكلة طالما لم يستخدم أي شيء AP وبعد فترة من الوقت واجهت مشكلة عند الاتصال بهاتفي إلى wlan0. أقوم بتشغيل الأمر ويمكن العثور على النتيجة هنا: https://pastebin.com/77tGfRcU

بالنسبة إلى wlan1 ، استخدمت دونجل قديمًا جدًا. لا يمكنني تذكر برنامج التشغيل الذي كان عليّ تثبيته لتشغيله ولكن هذا ما يقدمه lsusb لـ HW الذي أستخدمه:

Bus 001 Device 005: ID 0 cde: 0008 Z-Com XG-703A 802.11g Wireless Adapter [Intersil ISL3887]

لا أعرف ما إذا كان ذلك يساعد ولكن هذه هي تجربتي:

اشتريت Pi3 واختبرته لبضعة أيام باستخدام wifi داخلي (ليس بعيدًا عن AP) ، ويبدو أنه يعمل بشكل جيد (لم أكن أتوقع معدلات بت عالية ، لقد كان مفيدًا لقذيفة بعيدة عبر ssh ).

بعد وضعه في علبة من الألومنيوم ، لا يزال يبدو جيدًا أولاً ، ولكن بعد ذلك ظل wifi غير قابل للاستخدام بشكل عشوائي. ما يصل إلى دقائق من عدم وصول الأمر ping. كانت لا تزال هناك حالات عملت فيها بشكل جيد جدًا لبضع ثوان ولكنها تحولت إلى تجربة "ضغطة واحدة في الثانية" مرة أخرى أو توقفت عن العمل تمامًا.

يبدو أنه لا يوجد اتصال "بطيء ولكن قابل للاستخدام" ممكن فقط "اتصال جيد جدًا" أو "غير صالح للاستخدام". قد يكون هذا بسبب خطأ في البرامج الثابتة. ليس لدي أي فكرة وبصراحة فقدت الصبر واستخدمت دونجل USB صغير جدًا بدلاً من ذلك يعمل بثبات 100٪.

هل وجد أي شخص حلاً لكشف المشكلة (في وضع AP) وإعادة تعيين جهاز wlan برمجيًا؟

ليس هذا ما رأيت ، إعادة تشغيل الواجهة لم يساعد. بالنسبة لي ، كان الاحتواء هو شراء جهاز wifi USB خارجي وهو يعمل مثل السحر ولكنه أمر مثير للشفقة حيث قمت الآن بإيقاف تشغيل wifi الخاص بـ pi (تنهد!)

هل تقصد مشكلة صندوق البريد؟ لا يزال هذا قيد التحقيق في Cypress.

في 21 سبتمبر 2017 الساعة 08:38 ، كتب "morel jerome" [email protected] :

ليس هذا ما رأيت ، إعادة تشغيل الواجهة لم يساعد. بالنسبة لي الاحتواء
كان لشراء جهاز wifi usb خارجي وهو يعمل مثل السحر ولكنه كذلك
مثير للشفقة الآن لقد قمت بإيقاف تشغيل wifi الخاص بـ pi (تنهد!)

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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= ،
أو كتم الخيط
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=
.

نعم قضية صندوق البريد. آمل أن يتم إصلاحه ولكن كاحتواء كان علي التبديل إلى جهاز خارجي.

موافق. نحن تحت رحمة Cypress في هذا الأمر - إنها مشكلة في البرامج الثابتة ، وهم الوحيدون الذين يمكنهم الوصول. سأستمر في تذكيرهم ... قد نحتاج إلى المزيد من الطب الشرعي ، لكننا سننشر هنا إذا كان هذا هو الحال.

قطع اتصال شبكة wlan الخاصة بي وإعادة الاتصال بعد بضع ثوانٍ من عدم النشاط (أفترض أن هذا هو توفير الطاقة ، على الرغم من أنني قمت بتعطيله باستخدام iw ، أو ربما تدخل). لست متأكدًا مما إذا كانت هذه هي نفس المشكلة التي تمت مناقشتها هنا (حيث يتم إعادة الاتصال على الفور).

إذا اتصلت بـ ssh -o ServerAliveInterval 5 ... فلن يتم قطع الاتصال بعد الآن.

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

asssaf ،
ليست المشكلة ، إذا تمت إعادة الاتصال ، فستكون مشكلة وقت الاستجابة فقط بشكل عام ، ولكن عند التشغيل بلا رأس عبر شبكة WiFi (إحدى الميزات الرئيسية المحتملة لـ PiZero-W) عندما تنقطع شبكة WiFi ولا تتم إعادة الاتصال تلقائيًا ، فإن النظام قد تعطل لجميع الأغراض العملية.

حتى لو كان لدي HDMI ، والماوس ، ولوحة المفاتيح تحت أحمال شبكة ثقيلة مثل Motioneye ، فإن الطريقة الوحيدة في بعض الأحيان للتعافي هي دورة الطاقة.

لقد كررت تثبيت وتكوين Motioneye على Pi2 باستخدام دونجل WiPi USB WiFi وحتى الآن يعمل بشكل مثالي مع الأحمال التي قتلت PiZero-W بشكل موثوق في غضون ساعات قليلة. بالنسبة لي ، يبدو أن هذا يؤكد مشكلة رقاقة / برنامج تشغيل WiFi وليس مشكلة في Raspbian-stretch.

@ PeterTheMaster1randyoojoshfria

حسنًا ، رسالة لأي شخص يرى مشكلة صندوق البريد بانتظام ، وسيكون قادرًا على اختبار شيء ما لي.

لدينا برنامج ثابت للتشخيص من Cypress ، والذي قد يساعد في تعقب المشكلة. إذا كان أي شخص لديه مشكلة في صندوق البريد على استعداد لتشغيل هذه البرامج الثابتة ، وعندما تحدث مشكلة صندوق البريد ، قم بتفريغ الأدلة الجنائية ، ونشر النتائج هنا ، فسيكون ذلك مفيدًا للغاية. لاحظ أنه لا ينبغي استخدام هذه البرامج الثابتة لأي شيء آخر ولكن هذا الاختبار سيكون "غير مثالي"! يرجى التعليق هنا إذا كنت قادرًا على إجراء الاختبار ، وسأتصل بالبرنامج الثابت والتعليمات.

iurly : لقد كتبت نصًا من شأنه اكتشاف المشكلة ، ثم إعادة التشغيل ، نظرًا لأن خفض الواجهة لأعلى ولأسفل لم يساعد ... Bu ثم تمت إعادة التشغيل كثيرًا ، بحيث لم أتمكن من الحصول على جهاز مفيد إلا من خلال أخذها خارج وضع AP (وتعيين واجبات AP إلى دونجل USB الخاص بي)

@ JamesH65 : سأكون سعيدا للمساعدة ، كما كان من قبل. هل هو إصدار جديد من البرامج الثابتة للتشخيص؟ لقد قمت بنشر لقطة للطب الشرعي منذ 3 أسابيع (في صفحة المشكلة هذه) باستخدام البرنامج الثابت للتشخيص / تصحيح الأخطاء المنشور مسبقًا في هذه الصفحة.

نعم ، البرامج الثابتة الجديدة من Cypress اعتبارًا من يوم الاثنين 25 سبتمبر. لديها المزيد
التشخيص فيه. تم تضييق نطاق الأدلة الجنائية السابقة التي قدمتها
المشكلة ، فهم بحاجة إلى مزيد من التفاصيل بالرغم من ذلك. كنت أقوم بتشغيل آلة
لمدة 24 ساعة حتى الآن مع عدم وجود خطأ في صندوق البريد ، لذا يتعذر حاليًا نسخه
نفسي.

هل يمكنك مراسلتي عبر البريد الإلكتروني على جيمس. [email protected] ويمكنني الحصول على البرامج الثابتة لك. لا أريد نشره عالميًا لأنه في الحقيقة مخصص لأغراض الاختبار فقط.

في 27 سبتمبر 2017 الساعة 14:48 ، كتب randyoo [email protected] :

iurly https://github.com/iurly : لقد كتبت نصًا من شأنه أن يكتشف
المشكلة ، ثم إعادة التشغيل ، منذ خفض الواجهة وأعلى
لم يساعد ... Bu ثم تم إعادة التشغيل كثيرًا ، بحيث يمكنني فقط الحصول على ملف
جهاز مفيد عن طريق إخراجه من وضع AP (وتعيين واجبات AP إلى
دونجل USB)

@ JamesH65 https://github.com/jamesh65 : يسعدني تقديم المساعدة ، كما
قبل. هل هو إصدار جديد من البرامج الثابتة للتشخيص؟ لقد نشرت
التقاط الطب الشرعي قبل 3 أسابيع (في صفحة هذه المشكلة) باستخدام ملف
البرامج الثابتة للتشخيص / تصحيح الأخطاء المنشورة مسبقًا في هذه الصفحة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332526471 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHW_vEVuxFD-9RuxE003QZc_2NoFaks5smlIjgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

@ JamesH65 إذا كنت تفضل توفير رابط للبرنامج الثابت الجديد ، يمكنني تثبيته ومحاولة التقاط الأدلة الجنائية مرة أخرى ، كما طلبت.

للأسف ، توفير رابط هنا يعني أنه متاح للجمهور ، و
نظرًا لأن هذا هو برنامج اختبار ثابت إلى حد كبير ، فأنا أفضل ألا يفلت منه
البرية. ومن ثم طلب القيام بذلك عبر البريد الإلكتروني. إذا كانت هذه مشكلة ، سأقوم بالتحميل
في مكان ما ويمكنه نشر ارتباط.

في 27 سبتمبر 2017 الساعة 15:56 ، كتب randyoo [email protected] :

@ JamesH65 https://github.com/jamesh65 إذا كنت تفضل ذلك
توفير ارتباط إلى البرنامج الثابت الجديد ، يمكنني تثبيته ومحاولة التقاطه
الطب الشرعي مرة أخرى ، كما طلبت.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-332548884 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHbVhHD2rk_hp3kG51WBY0R0IQzL3ks5smmIbgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

@ JamesH65 أعلم أن لدي

أنا أقوم بتشغيل البرامج الثابتة المشحونة مع kernel 4.4.50 (ولا يمكنني فعلاً الترقية إلى الإصدار 4.9 الأحدث بسبب الانحدار ، انظر # 2197) ، هل سيُظهر هذا الإصدار هذه الرسالة أم تمت إضافته في مرحلة لاحقة؟

شكر!

@ iurly لقد قلت شيئًا واحدًا صحيحًا ، تحدث مشكلة التعطل في برامج تشغيل Broadcom في وضع AP ، ولا أعرف ما إذا كان هذا مرتبطًا بخطأ صندوق البريد. يبدو أن هناك أكثر من خطأ واحد هنا ، ربما يكون هناك خطأ في الأجهزة نظرًا لوقت وجود المشكلة ولم يتم العثور على حل.

ما يزعجني حقًا هو عدم وجود حل بديل ، باستثناء إعادة تشغيل النظام بأكمله.
أعني ، ليس هناك حتى طريقة لإعادة ضبط الأجهزة الطرفية وإعادة تشغيل hostapd؟!؟

@ iurly لقد قلت شيئًا واحدًا صحيحًا ، تحدث مشكلة التعطل في برامج تشغيل Broadcom في وضع AP ، ولا أعرف ما إذا كان هذا مرتبطًا بخطأ صندوق البريد. يبدو أن هناك أكثر من خطأ واحد هنا ، ربما يكون هناك خطأ في الأجهزة نظرًا لوقت وجود المشكلة ولم يتم العثور على حل.

فقط لمعلوماتك ، أواجه مشكلات في وضع العميل / المحطة أيضًا. تشغيل LEDE master ، 4.9 kernel واستخدام البرامج الثابتة 7.45.41.46.

تضمين التغريدة
افهم الرغبة في منع نشر البرامج الثابتة للاختبار. سيكون البريد الإلكتروني على ما يرام ، لكنني لا أريد نشر عنواني هنا علنًا أيضًا ، ولا أرى طريقة لإرسال الرسائل على github.

استخدم عنوان pi أعلاه لإرسال بريد إلكتروني إلي وسأرسل لك البرنامج الثابت.

إعادة. وضع AP
كانت هناك بعض الإصلاحات منذ 4.4 ، لذا تستحق تجربة أحدث امتداد
لمعرفة ما إذا كانت هذه المشكلة لا تزال تحدث.

آه ، عندما تقوم بتحرير تعليق ، لا يتم إرسال تحديث بالبريد الإلكتروني ، وقد قمت بتحريره في البريد الإلكتروني Pi الخاص بي إلى الإدخال أعلاه ، لذلك ربما لم يتم تحديثك. استخدم موقع جيثب لمعرفة أين تريد مراسلتي عبر البريد الإلكتروني.

@ JamesH65 أرسل إليك بريدًا إلكترونيًا. سعيد لسماع أن القبض على الطب الشرعي السابق ساعد في تضييق نطاقه ، على الأقل ... يبدو أن الكثير من الناس سيكونون سعداء عندما يتم حل هذه المشكلة.

تضمين التغريدة
إليك لقطة من البرنامج الثابت الذي أرسلته عبر البريد الإلكتروني: https://pastebin.com/zdB36ttj
آمل أن يساعد.

رائع ، سوف ينتقل إلى Cypress. شكرا لفعل ذلك.

لدي pi في الإعداد الآن حيث يبدو أنه يمكنني إعادة إنتاج هذا في الإرادة. إذا كان جمع المزيد من الأدلة الجنائية مفيدًا ، فأعلمني بذلك. خطأ صندوق البريد هو كل ما يمكنني رؤيته في السجلات.

بعد أن استبدلت بطاقة microSD في جهاز Zero W ، تم توصيله لمدة 7 أيام دون مشكلة. لا أعتقد أنه قد نجا من أي وقت مضى. يبدو غريبًا أن بطاقة SD يمكن أن تؤثر على شبكة WiFi ، ولكن نظرًا لأن كلاهما متصل بحافلة SDIO ، فمن الممكن أن يؤثر أحدهما على الآخر.

كانت البطاقة التي استخدمتها من قبل (ربما رخيصة) فئة 4 غيغابايت متجاوزة تأتي مع لوحة UDOO Quad الخاصة بي. الآن إنه Samsung EVO 32GB. قد يرغب الأشخاص الذين يواجهون مشاكل في المحاولة إذا كان استخدام بطاقة مختلفة مفيدًا.

@ stintel مثير للاهتمام ، ولكن ربما كانت هناك مشكلة في إعداد البرنامج على بطاقة microSD الأخرى ، أو حتى microSD التالف.

هل يمكن أن يكون ذلك متعلقًا بالسلطة؟ ربما البطاقة الرخيصة استمدت الكثير من الطاقة من الحافلة للحظات؟

لقد قمت بتحميل البرامج الثابتة المنشورة من Pelwell وشهدت تحسنًا كبيرًا. في السابق ، كان SSH في Pi 0W يشبه الاتصال بمحطة بمودم 2400 باود وخط هاتف سيء. الآن ، يمكنني تشغيل X عن بُعد وهو يعمل بشكل رائع.

شكر!

لدي نفس المشكلة. عن طريق نقل كمية ضخمة من أسماء الملفات (sync-over-ftp) من raspberryPi3-internal-wifi إلى Galaxy S5 wifi ، توقف عن العمل. لكن في بعض الأحيان يعمل ...

واجهت نفس مشكلة رسالة صندوق البريد مع RPi3 WiFi AP ، لكنني وجدت حلاً في هذا المنتدى ، وقد نجح معي. كان الحل هو تغيير المعلمات التالية في /etc/hostapd/hostapd.conf

wpa = 3 تغيرت إلى wpa = 2auth_algs = 3 تغيرت إلى auth_algs = 1

لقد اختبرت ذلك لمدة أسبوع واحد ولم يعد يُظهر مشكلات في صندوق البريد بعد الآن.

لست متأكدًا مما إذا كان سيعمل معكم جميعًا ، ولكن يمكنك تجربته ونشره هنا إذا كان يعمل.

هذا هو hostapd العامل ، أسيوط:

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

أي تعديل حدث في هذه القضية؟ أو هل هناك أي حل بديل معروف؟

لا تزال تواجه هذا الأمر على Pi Zero W تم شراؤه مؤخرًا بأحدث stretch-lite و rpi-update اعتبارًا من أمس.

باستخدام RPi لدفق موجز الكاميرا عبر RTSP (udp) يمكنني رؤية الاتصال يزداد سوءًا بشكل كبير قبل انقطاع اتصال WiFi ، وبعد ذلك لا يتعافى اتصال WiFi ولا بد لي من تشغيل دورة Pi0W.

يظهر فقط A dmesg > dmesg.log :

brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

إذا قمت بتحريك Pi0W بالقرب من نقطة الوصول الخاصة بي ، فلن تحدث المشكلة.

أنا لا أستخدم Pi0W كنقطة وصول ، إنه مجرد عميل. لقد جربت مصادر طاقة مختلفة.

ننتظر حاليًا Cypress ، مزودي الشريحة اللاسلكية ،
للتقدم في هذه القضية. سأقوم باختبار اتصالهم مرة أخرى.

في 25 أكتوبر 2017 الساعة 14:02 ، Matthias Urhahn [email protected]
كتب:

أي تعديل حدث في هذه القضية؟ أو هل هناك أي حل بديل معروف؟

لا تزال تواجه هذا الأمر على Pi Zero W تم شراؤها مؤخرًا مع الأحدث
امتداد لايت وتحديث rpi اعتبارًا من أمس.

باستخدام RPi لدفق موجز الكاميرا عبر RTSP (udp) يمكنني رؤية ملف
ساء الاتصال بشكل كبير قبل انقطاع اتصال WiFi ،
بعد ذلك ، لا يتعافى اتصال WiFi مطلقًا ولا بد لي من تشغيل دورة
Pi0W.

يظهر dmesg> dmesg.log فقط:

brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012

إذا قمت بتحريك Pi0W بالقرب من نقطة الوصول الخاصة بي ، فلن تحدث المشكلة.

أنا لا أستخدم Pi0W كنقطة وصول ، إنه مجرد عميل. لقد حاولت
مصادر طاقة مختلفة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-339322153 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHRlPhJBGXc3JFWbpw_Tf4_EKmgAeks5svzFQgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

حسنًا ... لقد قمت بالترقية إلى أحدث برنامج kernel / firmware (apt-get Upgrade ثم rpi-update) ، والآن ، حتى Pi3 الذي كان يحتوي على شبكة wifi صلبة يفقده أيضًا بعد بضع ساعات !! أعلم ، إذا لم يتم كسرها ، فلا تقم بإصلاحها ... ما كان يجب أن تتم ترقيتها ، ولكن بما أنني أقوم بإجراء اختبارات من وقت لآخر في Pi3 الثاني بنفس بطاقة SD ..

FWIW ، يمكنني أيضًا إعادة إنتاج هذه المشكلة حسب الرغبة. لقد أنشأت منشورًا في منتدى Raspberry Pi يشرح المشكلة:

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

ملاحظة: أنا لا أستخدم Pi كـ AP. يمكنني المساعدة في الطب الشرعي أو اختبار البرامج الثابتة التجريبية وما إلى ذلك إذا كان ذلك يساعد.

نفس المشكلة هنا. قمت بإعداد ownCloud ويمكنني نقل الملفات من الكمبيوتر المحمول الخاص بي دون أي مشكلة.
ولكن بمجرد أن أقوم بنقل الملفات باستخدام جهاز Samsung Galaxy S7 wifi الخاص بي فواصل و
raspberrypi kernel: [ 962.273390] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012 :
يبدو.

جهاز التوجيه الخاص بي هو FRITZ! Box 7490.

شكرًا srinathava على

هل يمكن للأشخاص الذين اختبروا البرنامج الثابت للاختبار ، تجربة ما يلي - مزيد من معلومات التصحيح المطلوبة بواسطة Cypress.

1. عند إجراء insmod ، أضف "التصحيح = 0x100000"
2. بمجرد حدوث المشكلة ، احفظ إخراج "dmesg"

شكر.

طلب آخر للمساعدة في هذا واحد.

هل يمكن للأشخاص الذين اختبروا البرنامج الثابت للاختبار (انظر أعلاه) ، يرجى تجربة ما يلي - مزيد من معلومات التصحيح المطلوبة بواسطة Cypress.

عند إجراء insmod ، أضف "التصحيح = 0x100000"
بمجرد حدوث المشكلة ، احفظ إخراج "dmesg" - هذا هو الشيء الذي نهتم به.

شكر.

@ JamesH65 فقط لإعلامك ، أحاول الآن جمع المعلومات ، لكن المشكلة لم تظهر نفسها بعد. لقد أجريت بعض التغييرات الصغيرة فقط على ملف /etc/hostapd/hostapd.conf ، ولكن ربما تكون هذه التغييرات قد نجحت عن غير قصد في حل هذه المشكلة. إذا لم تظهر المشكلة في غضون أيام قليلة ، فسأعيد هذه التغييرات في محاولة لتكرار المشكلة وجمع بيانات تصحيح الأخطاء.

شكرا للمساعدة في هذا الشأن.

سيكون من المثير للاهتمام رؤية تلك التغييرات التي أجريتها على hostapd إذا كان ذلك يدور حول المشكلة.

بعد 4 أيام من الاستقرار ، أعدت تغييراتي إلى الملف /etc/hostapd/hostapd.conf ، وبعد بضع ساعات فقط ، تكررت المشكلة. هذا هو الإخراج من 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

أنا أقوم بتشغيل حزمة برامج تسمى RaspAP ، وأنا متأكد من أنها قامت بتكوين ملف hostapd.conf نيابة عني ، على الرغم من أنني لست متأكدًا بنسبة 100٪.

على أي حال ، بالتعليق خارج هذا السطر في /etc/hostapd.conf: واستبدالها بهذا: كانت لدي عملية مستقرة لمدة 4 أيام متتالية ، بينما كانت تتعطل في غضون ساعات قليلة ، أو أحيانًا حتى دقائق!

أتمنى أن يساعد كل هذا.

أعتذر إذا قمت بالنشر في المكان الخطأ ، فأنا أواجه سلوكًا غريبًا مع شبكة WLAN الداخلية RPi3 (broadcom) عند إرسال حزم UDP Unicast ضمن raspbian.
أرسل حزمة صغيرة من البيانات 2 كيلو بايت مرة في الثانية ، في نهاية جهاز الاستقبال يتم حظر هذا كل 120 ثانية لمدة 3-4 ثوانٍ تقريبًا. يعمل هذا الاختبار كالساعة ، ويمكنني التكاثر باستخدام iperf للقيام بما يلي

Rpi3

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

كمبيوتر Ubuntu متصل كعميل WiFi بـ RPi3 (IP 192.168.1.22 على النحو الوارد أعلاه)

iperf -u -s -i 1

نضمن حدوث انسداد كل 120 ثانية. مثير للاهتمام ، لا يبدو أن هذا يحدث باستخدام TCP
أخيرًا ، بعد تنزيل رمز برنامج التشغيل والنظر إليه (ولم أفهم أي شيء) لاحظت إشارة مريبة لـ

حدد BRCMF_SCAN_PASSIVE_TIME 120

والذي يتم استخدامه بعد ذلك في كود السائق

هل يمكن أن يكون هذا مرتبطًا ، فأنا في نهاية الأمر أحاول حله؟
شكرا

أضع ما يلي في /etc/rc.local ويبدو أن عملي أفضل بكثير:

Iwconfig wlan0 إيقاف

بي صفر ث

شون

في 19 كانون الأول (ديسمبر) 2017 ، الساعة 3:42 صباحًا ، كتب LeeMooreImperas [email protected] :

أعتذر إذا قمت بالنشر في المكان الخطأ ، فأنا أواجه سلوكًا غريبًا مع شبكة WLAN الداخلية RPi3 (broadcom) عند إرسال حزم UDP Unicast ضمن raspbian.
أرسل حزمة صغيرة من البيانات 2 كيلو بايت مرة في الثانية ، في نهاية جهاز الاستقبال يتم حظر هذا كل 120 ثانية لمدة 3-4 ثوانٍ تقريبًا. يعمل هذا الاختبار كالساعة ، ويمكنني التكاثر باستخدام iperf للقيام بما يلي

Rpi3

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

كمبيوتر Ubuntu متصل كعميل WiFi بـ RPi3 (IP 192.168.1.22 على النحو الوارد أعلاه)

iperf -u -s -i 1

نضمن حدوث انسداد كل 120 ثانية. مثير للاهتمام ، لا يبدو أن هذا يحدث باستخدام TCP
أخيرًا ، بعد تنزيل رمز برنامج التشغيل والنظر إليه (ولم أفهم أي شيء) لاحظت إشارة مريبة لـ

حدد BRCMF_SCAN_PASSIVE_TIME 120

والذي يتم استخدامه بعد ذلك في كود السائق

هل يمكن أن يكون هذا مرتبطًا ، فأنا في نهاية الأمر أحاول حله؟
شكرا

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

مرحبا شون
شكرًا على التنبيه ، للأسف ، لم يتم قبول هذا بواسطة جهاز Broadcom ، أحصل عليه

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

ومع ذلك ، استخدم الأمر التالي في الإعداد الخاص بي لتحقيق نفس الهدف
$ iw dev wlan0 set power_save off
هذا مقبول وإذا قمت بالاستفسار عن الإعدادات
$ iwconfig wlan0
فهمت
Power Management:off

تأكد من إيقاف تشغيل توفير الطاقة ، لكنه لا يحل هذه المشكلة
شكرا

LeeMooreImperas أقترح فتح مشكلة منفصلة لهذا وتقديم إصدار Kernel وإصدار برنامج Wifi الثابت على الأقل.

لقد علقت على هذا الموضوع منذ وقت طويل ولكن بعد ذلك اضطررت إلى التوقف عن النظر إليه لأنني لم أعد قادرًا على إعادة إنتاجه. حسنًا ، لدي بعض البيانات الجديدة وأجدها مثيرة جدًا للاهتمام.

لدي اثنين من Raspberry Pi. واحد B + V1.2 وواحد أصلي Raspberry PI (C) 2011.

إذا قمت بتشغيل "4.1.19+ # 858 الثلاثاء مارس 15:52:03 GMT 2016" على RaspPi B + ، فستعرض شريحة Edimax WiFi المشكلة التي شاهدها الآخرون.

إذا قمت بتشغيل "4.9.27+ # 1 Thu May 11 17:40:53 UTC 2017" على نفس RaspPi B + ، فلن تظهر نفس شريحة Edimax WiFi المشكلة.

أنا الآن أتساءل عما إذا كان الأمر أكثر تعارضًا مع الأجهزة ، وقد تم تذكيرنا أيضًا أنه مع لوحات RaspPi الأقدم كثيرًا ، احتاج USB WiFi إلى كابل خاص لزيادة طاقة + 5V لأن الطاقة القادمة من اللوحة لم تكن ' ر ما يكفي لقيادتها. سأقوم بتبديل بطاقات SD مرة أخرى بحيث تظهر المشكلة ، ثم معرفة ما إذا كان هذا النوع من الكابلات يساعد.

حسنًا ، أعتقد أن ذلك غير صحيح.

سيؤدي تشغيل 4.9.27+ على RaspPi الأقدم إلى ظهور المشكلة. التحقق الآن.

حسنًا ، هذا نهائي ومثير للاهتمام للغاية.

باستخدام لوحة Raspberry Pi الأصلية (حوالي عام 2011) وتشغيل Linux 4.9.27+ (من "uname -a") ، يمكنني إعادة إنتاج مشكلة شريحة Edimax USB WiFi التي تفقد اتصال WiFi ، وبالتالي عنوان IP ، في كل مرة في غضون بضع دقائق.

باستخدام نفس لوحة Raspberry Pi الأصلية ونفس إصدار Linux ، ولكن التغيير الوحيد لمجرد استخدام كبل USB الذي يسمح لي بزيادة + 5V إلى USB WiFi من مصدر ثانوي ، فإن النظام مستقر.

لذلك ، يبدو أن هناك بالتأكيد مشكلة في عدم حصول بطاقة Edimax USB WiFi على طاقة كافية في هذا الإعداد. من الواضح أن هذا لا يساعد أولئك الذين يستخدمون Raspberry Pi مع شبكة WiFi مدمجة ، ولكن في هذه الحالات أتساءل عما إذا كانت هناك مشكلة مماثلة قد تحدث وإذا كان الانتقال إلى محول USB ينتج المزيد من الأمبير قد يظهر فرق؟

من المحتمل أن يكون محول التيار الرئيسي إلى USB الذي يشغل Pi قد لا يعطي 5 فولت نظيفًا في بعض الحالات.
نظرًا لأنه يجب تنظيم التيار المتردد ثم تنعيمه قبل أن يصبح 5 فولت ، لكنك لا تزال تحصل على القليل من التموج في التيار المستمر الناتج.
من المرجح أن يكون 5V من جهاز كمبيوتر محمول أو كمبيوتر شخصي خالي من التموج من شاحن التيار الكهربائي الرخيصة إلى USB

سيكون من المثير للاهتمام وضع مرسمة الذبذبات على مصدر الطاقة لشريحة wifi في ظل ظروف مختلفة لمعرفة شكل التموج أثناء الفشل / عدم الفشل

يرجى إبقاء هذه المشكلة في حل مشاكل شريحة ONBOARD Brcm اللاسلكية على Pi3 - إذا كانت لديك مشكلات مع الأجهزة الأخرى ، فيرجى استخدام المنتدى للحصول على المشورة. هذا ببساطة حتى لا يتم الخلط بين المعلومات التي نحتاجها لنقلها إلى Cypress.

تضمين التغريدة
تضمين التغريدة

مرحبا جيمس ، ستيفان ،
الرسائل المتضاربة هنا ، كانت المشكلة التي قمت بتسجيلها مرتبطة مباشرة بـ RPi3 BRCM WiFi.
فهل يجب أن يتم ذلك في موضوع مختلف (كما اقترحه lategoodbye)؟
كنت سأفكر في أن هذا الموضوع يتعلق على وجه التحديد بمشكلتي؟

أنا سعيد لتحريك القضية

شكرا

LeeMooreImperas على الرغم من أن إلا أن

مضيفا آخر "أنا أيضا" على هذا.
المعدات: Raspberyy Pi 3 ، الموديل B.
النواة: Linux raspberrypi 4.9.70-v7 +
نظام التشغيل: Raspbian GNU / Linux 9 (امتداد)
الصورة المحملة: 2017-11-29-raspbian-stretch.img
صورة MD5:
بطاقة SDCard: لست متأكدًا من الشركة المصنعة ، فقد جاءت مع المجموعة
ملف الواجهات :
hostapd.conf: hostapd.txt
إخراج dmesg (أثناء العمل): dmesg_20171230.txt

تم تكوين الجهاز كنقطة وصول لشبكتي اللاسلكية. جهاز التوجيه الأساسي الخاص بي هو إصدار البرنامج الثابت 1.1.40 من Linksys EA6400 (الإصدار 184085). يقدم كل من Linksys و Pi نفس SSID على قنوات مختلفة. Pi متصل بجهاز التوجيه عبر اتصال سلكي بمفتاح غير مُدار بينهما.
تحميل نظام التشغيل على الجهاز جديد إلى حد ما. كانت لدي صورة RetroPie على النظام وواجهت نفس المشكلات. أعدت التحميل إلى Raspbian لمعرفة ما إذا كان يعمل بشكل أفضل.
أرى تسربات متفرقة من الجسر. يتمثل العَرَض الأساسي في أن الشبكة اللاسلكية التي يوفرها Pi تبدو معزولة عن الشبكة السلكية. تستمر الواجهة السلكية في العمل بشكل طبيعي ويمكنني الوصول إلى Pi عبر SSH. إذا قمت بتشغيل tcpdump على الواجهة اللاسلكية (wlan0) ، بينما في هذه الحالة ، لا يزال بإمكاني رؤية حركة المرور من وإلى الأجهزة المتصلة.
لا يبدو أن تشغيل الاتصال اللاسلكي (ifdown ؛ ifup) يصلح المشكلة. لم أحاول بعد استخدام واجهة الجسر (br0) بعد. بشكل عام ، لقد قمت بإعادة تشغيل الجهاز الذي يعمل على حل المشكلة.
لست متأكدًا من أنها مرتبطة ؛ ومع ذلك ، يبدو أن المشكلة تظهر عندما أحاول التحكم في جهاز ChromeCast 2 بعد أن كان يعمل لفترة من الوقت. على سبيل المثال ، إذا كنت ألعب عرضًا عبر Netflix على ChromeCast ثم حاولت إيقاف العرض مؤقتًا ، فيبدو أن الجسر قد توقف في ذلك الوقت. لم أتمكن من التقاط هذا عبر tcpdump حتى الآن ؛ لكن هذه هي الخطوة التالية بالنسبة لي.
لقد اعتبرت أنه قد يكون مشكلة حرارة ؛ ومع ذلك ، كان لدي /opt/vc/bin/vcgencmd measure_temp يعمل في حلقة مدتها 30 ثانية أثناء إحدى حالات التسرب وكانت درجة حرارة وحدة المعالجة المركزية الخاصة بي في نطاق 50 درجة مئوية. لست متأكدًا من كيفية الحصول على قراءة لدرجة الحرارة على شريحة LAN ، فقد يكون هذا هو المكان الذي تنشأ فيه مشكلة الحرارة.

يسعدني التقاط السجلات / أجهزة الكمبيوتر الشخصية حسب الحاجة للمساعدة في استكشاف المشكلة وإصلاحها بشكل أكبر. على الرغم من ذلك ، يرجى أن تكون صريحًا في التعليمات لأن لديّ فجوات قليلة في معرفتي بنظام Linux.

تحرير: كان للتو قد انسحب وأجرى sudo ifdown br0 && sudo ifup br0 ويبدو أنه بدأ العمل مرة أخرى. سأختبر مرة أخرى في المرة القادمة التي تركتها.

EDIT2: هنا تفريغ dmesg مع فشل الاتصال. لا يبدو أن sudo ifdown br0 && sudo ifup br0 يستعيد الاتصال هذه المرة.
dmesg_20171220_failed.txt
ملاحظة خاصة يبدو أن الخطأ:
brcmfmac: brcmf_cfg80211_stop_ap: فشل إعداد وضع INFRA -7

EDIT3: ركض عبر هذا الموضوع حول مشكلة مماثلة تشير إلى هذا الموضوع. شغّل التغيير المطلوب إلى وحدة brcmfmac لتمكين تصحيح الأخطاء. كان مشغل الفشل واستولت على إخراج dmesg:
dmesg_debug_failed.txt
أيضًا ، لاحظت ذكر هاتف Samsung في الخيط الآخر أيضًا. لقد لاحظنا أن مشاكل الجسر مع Pi الخاص بي يبدو أنها تدور حول جهاز Samsung Galaxy S7. لا يبدو أن أجهزة Apple الخاصة بزوجتي (iPhone و iPad) تسبب المشكلة.

EDIT4: ركض a sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000 متبوعًا بـ dmesg مرة أخرى. الإخراج أدناه:
dmesg_debug_failed_reset_driver.txt

حسنًا ، ليس الخطأ المتوقع في علبة البريد. سوف أنقله إلى مطوري Cypress في العام الجديد.

لست متأكدًا مما إذا كانت هذه هي نفس المشكلة ، ولكن عرضي هو المتقطع اللاسلكي RPi3 على متن الطائرة ؛ 10 ثوانٍ من الأصوات الجيدة ، تليها 20-30 ثانية من عدم وجود أصوات ، وكرر ذلك إلى الأبد. في حالة عدم وجود اختبار pings ، يتلقى المضيف البعيد طلبات ارتداد ICMP ويرسل ردود ارتداد ICMP. تعيد نقطة الوصول مضيف ICMP غير قابل للوصول إلى المضيف البعيد.

الشرط المسبق متصلان بشبكة إيثرنت ولاسلكية. تحسنت فرصة حدوث ذلك بشكل كبير عن طريق إعادة تشغيل dhcpcd داعٍ.

الحل هو تعيين واجهة الشبكة إلى الوضع المختلط ؛ sudo ifconfig wlan0 promisc . تعود الأعراض في غضون عشر ثوانٍ إلى دقيقة sudo ifconfig wlan0 -promisc .

مزيد من المعلومات المتاحة إذا لزم الأمر ، فقط اسأل.

@ Sylver-Dragon ، بالنسبة لي tcpdump حال دون ظهور الأعراض ، وربما وجدت الشيء نفسه ؛ جرب العلم -p ، والذي يقوم بإيقاف تشغيل الوضع المختلط ؛ دع الأعراض تستمر.

https://github.com/iiab/iiab/issues/638

quozl لقد حاولت تشغيل tcpdump على كل من الواجهة اللاسلكية وواجهة الجسر وكان لدي قفل أثناء تشغيله. سأعطي الوضع المختلط لقطة وأرى ما إذا كان يحدث فرقًا. رغم ذلك ، استنادًا إلى إخراج التصحيح لبرنامج تشغيل الواجهة اللاسلكية ، على وجه التحديد:
wl0: _wlc_bss_update_beacon: خارج الميم ، 0 بايت مضافًا إليه
أظن أن هذا نوع من تسرب الموارد (الذاكرة؟) من جانب السائق. عندما يكون لدي المزيد من الوقت ، أريد أن أقوم بالتقاط الحزمة والبحث في اللحظة التي يتم قفلها فيها. أظن أن هاتفي يرسل نوعًا من الحزم الفردية أو المشوهة أو سلسلة من الحزم على الجهاز مما يؤدي إلى تشغيل القفل. إذا كان بإمكاني التقاط ذلك وعزله ، فمن المفترض أن يساعد في إبلاغ الإصلاح.

يبدو أنه خطأ مختلف في مشكلة صندوق البريد التي نتتبعها حاليًا. وهو أمر مزعج. هل هاتفك هو Samsung BTW؟ يبدو أن مشكلة صندوق البريد يتم تشغيلها في كثير من الأحيان بواسطة أجهزة SS. إذا تمكنت من تعقب ما يسبب المشكلات ، فسيكون ذلك مفيدًا للغاية

أنا أصطاد نفس (؟) لأسابيع الآن. أشعر أنني يجب أن أقرأ كل تقرير عن هذا وقضايا مماثلة. إذن هنا بعض المعلومات الإضافية مني:

أستخدم شبكة wifi الداخلية لجهاز Raspberry pi 3 كنقطة وصول. أستخدم نواة ووحدات raspbian القياسية (إصدار Linux 4.9.35-v7 + (dc4 @ dc4-XPS13-9333) (إصدار مجلس التعاون الخليجي 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) # 1014 SMP الجمعة 30 يونيو 14:47:43 بتوقيت جرينتش 2017).

برنامج Wifi الثابت هو: brcmfmac: إصدار البرنامج الثابت = wl0: 7 أغسطس 2017 00:46:29 الإصدار 7.45.41.46 (r666254 CY) FWID 01-f8a78378

أنا متأكد تمامًا من أن إعداد الأجهزة هذا كان يعمل ، ولكن بعد بعض التحديثات (أيضًا للنواة) أعتقد ، سارت الأمور جنوبًا. يعمل إنشاء AP بشكل جيد ، ولكن بعد استخدامه لبعض الوقت (30 دقيقة أو نحو ذلك ، ليس هو نفسه في كل مرة أفكر فيها) ، والبث باستخدام Chromecast ، يتوقف الاتصال عن العمل. قد يكون الأمر (لكنني لست متأكدًا هنا) من أن هذا يحدث غالبًا عندما أوقف البث مؤقتًا / أوقفه ، ولكن نادرًا ما يحدث ذلك في منتصف المشاهدة. عندما يفشل ، يتم إسقاط الاتصالات الحالية ولا يقبل أي عميل محاولات الاتصال الجديدة. ينتج عن إعادة تحميل hostapd brcmf_cfg80211_stop_ap: setting INFRA mode failed -7 (لا يمكن ضبط الوضع على الوضع الرئيسي). يمكن إصلاح ذلك مؤقتًا عن طريق إعادة تحميل برنامج التشغيل: rmmod brcmfmac; modprobe brcmfmac . ثم تعمل الأشياء كما هو متوقع مرة أخرى حتى تفشل في المرة القادمة. بدلاً من ذلك ، تؤدي إعادة التشغيل إلى "إصلاح" المشكلة أيضًا.

الشيء الوحيد الذي أحصل عليه في الحالة الفاشلة (مع تمكين التصحيح) في سجل النظام هو:

kernel: [3615.491795] brcmfmac: brcmf_netdev_wait_pend8021x: انتهت مهلة انتظار حزم 802.1x المعلقة
hostapd: wlan0: STA xx: xx: xx: xx: xx: xx IEEE 802.11: تم إلغاء المصادقة بسبب طلب مصادقة محلي

رسالة الخطأ هذه ليست منطقية بالنسبة لي. هل حان الوقت في انتظار "عدم وجود حزم معلقة"؟ على أي حال:

لدي توفير الطاقة:

iw wlan0 get power_save Power save: off

تم ضبط roam_off على 1 وتم تمكين التصحيح:

`systool -a -v -m brcmfmac
الوحدة النمطية = "brcmfmac"

السمات:
حجم النواة = "222874"
initsize = "0"
initstate = "مباشر"
refcnt = "0"
srcversion = "10E8F4629D109E78E1F506C"
تلطيخ = ""
uevent =

المعلمات:
Altern_fw_path =
تصحيح = "1048576"
roamoff = "1"
"

ليس لدي هاتف Samsung ، ولكن بعض هواتف Android. لم يتم توصيل أي من هذه بنقطة الوصول هذه. العملاء المباشرون الوحيدون هم جهازي Chromecast (فيديو واحد ، صوت واحد فقط ، بالإضافة إلى جهاز Android اللوحي). يأتي كل شيء آخر عبر الواجهة السلكية.

تضمين التغريدة
الرجاء البحث في هذه الصفحة عن تعليقي السابق منذ 3 أسابيع للحصول على حل جيد.

تضمين التغريدة
لم أحصل على ack منك. هل قمت بنسخ / ترحيل إخراج dmesg الذي شاركته من هذا التعليق قبل 3 أسابيع إلى رجال السرو؟

randyoo : لدي كل من "rsn_pairwise = CCMP" و "wpa = 2" في hostapd.conf الخاص بي. لا يساعد في حالتي. غير سري يستتبع من ملفي:
"
الواجهة = wlan0

سائق = nl80211
ssid = XXX
hw_mode = g
قناة = 1
ieee80211n = 0
wmm_enabled = 1
ht_capab = [HT40] [SHORT-GI-20] [DSSS_CCK-40]
macaddr_acl = 0
auth_algs = 1
ignore_broadcast_ssid = 0
wpa = 2
wpa_key_mgmt = WPA-PSK
wpa_passphrase = XXX
rsn_pairwise = CCMP
"

يتضح أيضًا أن الفشل يبدو أنه يحدث دائمًا بالنسبة لي عندما أحاول إيقاف بث Netflix مؤقتًا إلى Chromecast (وهذا لا يعني أنه دائمًا ما يفشل عندما أحاول ذلك ، فقط عندما يفشل ، هذا ما كنت أفعله ). من ناحية أخرى ، قد يكون هذا بمثابة رنجة حمراء ، لأن هذا هو ما أفعله طوال الوقت تقريبًا مع شبكة wifi هذه. قد تكون المشكلة تحدث ببساطة عندما يحاول الجهاز المصادقة على AP (مثل جهاز Android اللوحي الذي من المحتمل أن يعطل wifi أثناء النوم). سيظهر المزيد من الاختبارات. سأحاول بدون Chromecast - فقط wifi عادي على الجهاز اللوحي ، بما في ذلك دورات wifi-sleep.

لا يبدو أن مشكلتي هي نفسها هذه المشكلة ، لذلك سأنتقل إلى الوضع الكامن. لقد أصلحها ifconfig wlan0 promisc لـ holta (https://github.com/iiab/iiab/issues/638) ، ولكن بدون مساعدة أي شخص آخر ، يجب أن ننظر إلى مشكلة مختلفة.

يمكنني إعادة إنتاج هذا بشكل موثوق بدون Netflix أو Chromecast عن طريق الاتصال بالشبكة عبر جهاز Google اللوحي ، ثم السماح للجهاز اللوحي بالنوم واستئنافه (يحاول الجهاز اللوحي إعادة الاقتران) ، وفي تلك اللحظة يكون AP "ميتًا".

على جهاز Linux ، أحصل عليها في سجل النظام عند محاولة الربط (باستخدام بيانات الاعتماد الصحيحة):

"

[42231.476518] wlan7: أرسل المصادقة إلى b8: 27: eb: 33: 98: 14 (جرب 1/3)
[42231.583434] wlan7: أرسل المصادقة إلى b8: 27: eb: 33: 98: 14 (جرب 2/3)
[42231.694397] wlan7: أرسل المصادقة إلى b8: 27: eb: 33: 98: 14 (جرب 3/3)
[42231.799368] wlan7: انتهت مهلة المصادقة مع b8: 27: eb: 33: 98: 14
[42236.585750] wlan7: مصادقة مع b8: 27: eb: 33: 98: 14
[42236.598833] wlan7: أرسل المصادقة إلى b8: 27: eb: 33: 98: 14 (جرب 1/3)
[42236.602344] wlan7: مصدق
[42236.603480] wlan7: اقتران بـ b8: 27: eb: 33: 98: 14 (جرب 1/3)
[42236.619322] wlan7: RX AssocResp من b8: 27: eb: 33: 98: 14 (capab = حالة 0x411 = 0 مساعدة = 1)
[42236.623181] wlan7: مرتبط
[42236.623325] IPv6: ADDRCONF (NETDEV_CHANGE): wlan7: أصبح الرابط جاهزًا
[42236.625464] wlan7: تحديد قدرة الإرسال على 30 (30 - 0) ديسيبل ميلي واط كما هو معلن بواسطة b8: 27: eb: 33: 98: 14
[42239.730365] wlan7: deauthenticated من b8: 27: eb: 33: 98: 14 (السبب: 2 = PREV_AUTH_NOT_VALID)
[42241.243434] wlan7: المصادقة مع b8: 27: eb: 33: 98: 14
[42241.256326] wlan7: أرسل المصادقة إلى b8: 27: eb: 33: 98: 14 (جرب 1/3)
[42241.260724] wlan7: موثق
[42241.263403] wlan7: اقتران بـ b8: 27: eb: 33: 98: 14 (جرب 1/3)
[42241.279537] wlan7: RX AssocResp من b8: 27: eb: 33: 98: 14 (capab = حالة 0x411 = 0 مساعدة = 1)
[42241.282500] wlan7: مرتبط
[42241.336166] wlan7: تحديد قدرة الإرسال على 30 (30 - 0) ديسيبل ميلي واط كما هو معلن بواسطة b8: 27: eb: 33: 98: 14
[42244.392213] wlan7: deauthenticated من b8: 27: eb: 33: 98: 14 (السبب: 2 = PREV_AUTH_NOT_VALID)
[42253.916626] wlan7: مصادقة مع b8: 27: eb: 33: 98: 14
[42253.928966] wlan7: أرسل المصادقة إلى b8: 27: eb: 33: 98: 14 (جرب 1/3)
[42253.936020] wlan7: موثق
[42253.939533] wlan7: اقتران بـ b8: 27: eb: 33: 98: 14 (جرب 1/3)
[42253.943361] wlan7: RX AssocResp من b8: 27: eb: 33: 98: 14 (capab = حالة 0x411 = 0 مساعدة = 2)
[42253.945415] wlan7: مرتبط
[42254.035149] wlan7: تقييد قدرة الإرسال على 30 (30 - 0) ديسيبل ميلي واط كما هو معلن بواسطة b8: 27: eb: 33: 98: 14
[42257.053762] wlan7: deauthenticated من b8: 27: eb: 33: 98: 14 (السبب: 2 = PREV_AUTH_NOT_VALID)
"

b8: 27: eb: 33: 98: 14 هو RPI3 المعني ، والذي أحصل عليه مرة أخرى إدخالات dmesg:
brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets

لا أفهم تمامًا سبب إرسال AP PREV_AUTH_NOT_VALID بينما أنا مرتبط على ما يبدو. لدي انطباع بأن المصادقة تأتي قبل الارتباط. لا ينبغي أن تكون هناك حالة مرتبطة بي ولكن لم تتم مصادقيتها.

مرحبا

أنا أستخدم Pi3 كخادم وسائط ، وتتم الاتصالات عبر شبكة WiFi الداخلية

تحديث ترقية Rasbian Stretch Lite 4.9 (الآن)
خادم Plex Media

انا احصل...

kernel: [1958.899715] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012

في dmesg و syslog عند الاتصال بـ Pi باستخدام عميل BubbleUPnp على Samsung S5 SM_G900F Android 7.1.2 ، هذا مضمون إلى حد كبير ويتطلب إعادة تشغيل لـ PiWiFi لتصبح قابلة للاستخدام مرة أخرى.

على جهاز Sony Xperia XP Android 6.0.1 القديم الذي يعمل بنظام BubbleUPnp مرة أخرى ، يعمل بشكل جيد حتى الآن. هذا هو الحل الخاص بي. ومع ذلك ، إذا كان بإمكاني تقديم أي مساعدة للوصول إلى الجزء السفلي من هذا ، فسيسعدني المساهمة.

يوحنا

كما أنه يعمل على جهاز iPad الذي يعمل بنظام mConnectLite

johnthesoftwareathome يرجى كتابة بريد إلكتروني إلى James Hughes من Raspberry Pi حتى يتمكن من إرسال برنامج تصحيح أخطاء Wifi إليك.

تم نشر عنوان البريد الإلكتروني من خلال صفحة الاتصال Raspberry Pi fao James Hughes

حسنًا ، لدينا برنامج ثابت جديد لتصحيح الأخطاء من Cypress أود أن يختبره الأشخاص به - يحتوي هذا على المزيد من التصحيح ، ولكن ليس إصلاحات ، لذلك فقط لأولئك الذين يسعدهم الاختبار. إذا كنت قد أرسلت بالفعل عنوان بريدك الإلكتروني ، فأشر هنا إلى أنك ترغب في إجراء بعض الاختبارات وسأرسل البرنامج الثابت ، أو اتصل بي عبر PM في منتديات Pi.

لإنقاذ الأشخاص الذين يبحثون عن كيفية تثبيت / تشغيل البرامج الثابتة الجديدة.

انسخ ملف تصحيح البرامج الثابتة إلى:

/lib/firmware/brcm/

(سترغب في عمل نسخة احتياطية من الأصل أولاً)

أعتقد أنك بحاجة إلى إعادة التشغيل في هذه المرحلة.

الآن أعد تشغيل برنامج تشغيل Linux في وضع التصحيح

sudo rmmod brcmfmac && sudo modprobe brcmfmac debug=0x100000

اجعلها تسوء .. !!

تفريغ dmesg في الملف والنشر هنا.

للإضافة إلى ما يقوله جيمس ، قد تفضل تجنب تسلسل rmmod / modprobe عن طريق إضافة brcmfmac.debug=0x100000 إلى /boot/cmdline.txt .

@ JamesH65 سأكون سعيدًا للمساعدة في الاختبار. على الرغم من التسجيل الآن في Pi Forum ، إلا أنني غير قادر على إرسال الرسائل. استخدام نفس اسم المستخدم هناك ، إذا كان ذلك يساعد.

لقد جربت البرنامج الثابت الجديد للتصحيح بالأمس وأضفت أيضًا brcmfmac.debug = 0x100000 إلى /boot/cmdline.txt.

ومع ذلك ، من الغريب أنني لم أر أي إخراج تصحيح في dmesg. والأكثر غرابة ، حيث تمكنت من إعادة إنتاج المشكلة بشكل موثوق من قبل ، عملت طوال المساء بغض النظر عما فعلته. لم يكن لدي مشكلة واحدة ، وكل ما فعلته بشكل مختلف هو استخدام ملف البرنامج الثابت الجديد (md5 sum ba679a85c1dc76e9775603af45440bc0) بدلاً من القديم وإضافة الإدخال إلى /boot/cmdline.txt بدلاً من إضافة الخيار باستخدام modprobe. لم يكن لدي وقت أمس للعودة إلى البرامج الثابتة القديمة لمعرفة ما إذا كان هذا سيعود إلى المشاكل القديمة. سأبلغ مرة أخرى عندما فعلت. في غضون ذلك: هل كل ما تغير في تلك البرامج الثابتة "مزيد من التصحيح" حقًا؟

اعتقدت أنه كان مجرد تصحيح ، لكنني سأعود إلى Cypress بوضوح
شيء آخر قد تغير ، نأمل بطريقة جيدة!

في 11 كانون الثاني (يناير) 2018 الساعة 06:48 ، كتب Frank Löffler [email protected] :

لقد جربت البرنامج الثابت الجديد للتصحيح بالأمس وأضفته أيضًا
brcmfmac.debug = 0x100000 إلى /boot/cmdline.txt.

ومع ذلك ، من الغريب أنني لم أر أي إخراج تصحيح في dmesg. أكثر من ذلك
بشكل غريب ، حيث تمكنت من إعادة إنتاج المشكلة بشكل موثوق من قبل ، نجحت
طوال المساء بغض النظر عما فعلته. لم يكن لدي مشكلة واحدة ، و
كل ما فعلته هو استخدام ملف البرنامج الثابت الجديد (md5 sum
ba679a85c1dc76e9775603af45440bc0). لم يكن لدي وقت أمس للذهاب
العودة إلى البرامج الثابتة القديمة لمعرفة ما إذا كان هذا يعود إلى المشاكل القديمة. سوف
تقرير مرة واحدة فعلت. في غضون ذلك: هل تغير كل ما في ذلك
البرامج الثابتة حقا "مزيد من التصحيح"؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-356842102 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHam4jUgDCkSFxMXS-KW4axCLoPZhks5tJa6fgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

كانت تجربتي مشابهة لتجربةknarrf فيما عدا أنني رأيت رسائل تصحيح الأخطاء في dmesg.

في السابق ، كان Samsung S5 غير قابل للاستخدام كعميل plexserver ، ولكن عندما قمت بتحميل البرنامج الثابت لتصحيح الأخطاء ، كان يعمل (كما قلت رسائل تصحيح الأخطاء في dmesg) لذا عدت إلى ملفي الثنائي الأصلي (تم نسخه احتياطيًا والتحقق من الحجم) ولا يزال يعمل. لذلك أنا الآن أعمل مرة أخرى مع البرنامج الثابت لتصحيح الأخطاء (لم أجرب تعديل cmdline.txt ، فقط rmmod / modprobe) واستمعت إلى بضع ساعات من الموسيقى بدون أخطاء. لقد حاولت تنشيط معظم أجهزة WiFi العديدة التي قمت بتفريقها حولها ، دون أي تأثير.

سأحاول ذلك لبضعة أيام لمعرفة ما إذا حدث أي شيء ثم أعد تحميل النسخة الأصلية وحاول مرة أخرى. ربما لم أقم بإيقاف تشغيل Pi بين عمليات إعادة التشغيل. سأتأكد من القيام بذلك عندما أعود مرة أخرى لمعرفة ما إذا كان نوعًا من الاحتفاظ بالسجل.

الليلة قمت بتحميل البرامج الثابتة الأقدم (مأخوذة من صورة تثبيت raspian ؛ مزيد من المعلومات حول الإصدارات التي أستخدمها أدناه) ، وأعدت تحميل الوحدة مع ذلك (وتم تمكين التصحيح) ، حتى أنني أعيد تشغيلها بينهما. يؤكد الإخراج القصير في dmesg أن الإصدار القديم قد تم تحميله الآن. وكما هو الحال مع johnthesoftwareathome ، فقد استمر في العمل طوال المساء ، على الرغم من القيام

لذا ، يبدو أن مهمتي الآن هي إعادتها إلى "لا تعمل" للحصول على فرصة لمعرفة ما يجري. محاولتي التالية ، على الرغم من أنها لم تعد موجودة اليوم ، ستتمثل في إعادة ضبط الجهاز (إزالة الطاقة لبعض الوقت بدلاً من مجرد استخدام أمر "إعادة التشغيل") ، واستخدام تثبيت جديد تمامًا من صورة حديثة.

أيضًا ، للأسف لا يمكنني استبعاد احتمال أن الصورة التي تعرضت للفشل كانت نسخة مختلفة ، حيث نسيت عمل نسخة احتياطية قبل الكتابة فوقها مع صورة تصحيح الأخطاء. ربما يستطيع johnthesoftwareathome نشر الصورة الدقيقة التي

معلومات حول ملفي البرنامج الثابت (الصورة: واحد من صورة تثبيت raspbian ، التصحيح: الملف الذي تلقيته مباشرة من @ JamesH65 :

تصحيح:
إصدار البرنامج الثابت = wl0: 23 أكتوبر 2017 03:55:53 الإصدار 7.45.98.38 (r674442 CY) FWID 01-e58d219f
md5sum: ba679a85c1dc76e9775603af45440bc0
صورة:
إصدار البرنامج الثابت = wl0: 7 أغسطس 2017 00:46:29 الإصدار 7.45.41.46 (r666254 CY) FWID 01-f8a78378
md5sum: 5f520a38ab4e943bfa1ba102f80fb2a0

johnthesoftwareathome : كيف يبدو إخراج "التصحيح" الجديد؟ ما زلت لا أحصل على أي شيء يبدو حتى عن بعد وكأنه تصحيح أخطاء شامل ، بغض النظر عن كيفية تحميل الوحدة. أحصل على صفر إدخالات أثناء العملية ، وحتى بعد التمهيد ، كل ما يبدو مناسبًا إلى حد ما هو:

كجذر: dmesg | grep brcm
[0.000000] سطر أوامر Kernel: 8250.nr_uarts = 0 bcm2708_fb.fbwidth = 640 bcm2708_fb.fbheight = 480 bcm2708_fb.fbdepth = 16 bcm2708_fb.fbswap = 1 vc_mem.mem_000=00 = 0x30000 ، 115200 وحدة التحكم = tty1 root = PARTUUID = f8e4f7c2-02 rootfstype = ext4 Elevator = الموعد النهائي fsck.repair = yes rootwait brcmfmac.debug = 0x100000
[3.500135] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[3.662113] brcmfmac: إصدار البرنامج الثابت = wl0: 7 أغسطس 2017 00:46:29 الإصدار 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[3.774278] brcmfmac: تعطيل إدارة الطاقة
[4.711443] brcmfmac: إدارة الطاقة معطلة

تحديث صغير: بالنظر إلى إحدى تعليقاتي القديمة في سلسلة الرسائل هذه ، يمكنني في الواقع تأكيد أن البرنامج الثابت القديم الذي استخدمته اليوم ("صورة") هو البرنامج الذي واجهت مشكلة معه حتى جربت صورة تصحيح الأخطاء الأحدث.

منزل فارغ ، لذا انتقلت أخيرًا إلى الاستماع إلى ألبوم بوي الأخير. كل شيء يعمل بشكل مثالي (الألبوم ليس كذلك). بعيدًا عن المنزل حتى الغد ، سألتقط هذا بعد ذلك.

تمكنت من جعل البرنامج الثابت الأصلي يفشل كما كان من قبل ولكن ليس بشكل موثوق بين استخدامه والبرامج الثابتة لتصحيح الأخطاء. حاليًا ، يتم إعادة التشغيل فقط باستخدام عناصر تصحيح الأخطاء مع عدم وجود إخفاقات حتى الآن.

لقد أساءت فهم ما يعنيه knarrf بشأن إخراج التصحيح وافترضت أنه لا يمكنه رؤية أن البرنامج الثابت الجديد قد تم تثبيته بدلاً من المعنى أنه توقع نوعًا من دفق التصحيح (والذي لا يمكنني رؤيته أيضًا). لديه وجهة نظر. في حالة حدوث هذا الفشل ، هل سنرى أي شيء أم أن تصحيح الأخطاء hex خاطئ؟

كما أن إحدى حالات الفشل لم تنجح على الفور. سمح لي بإعادة التشغيل قبل الحاجة إلى إعادة التشغيل. يحتوي سجل النظام على ما يلي ..

13 كانون الثاني (يناير) 08:34:48 نواة plexServer: [46.648630] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
13 كانون الثاني (يناير) 08:35:14 نواة plexServer: [72.161473] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
13 كانون الثاني (يناير) 08:35:14 نواة plexServer: [72.161484] brcmfmac: brcmf_cfg80211_get_channel: فشل chanspec (-110)

هذه مجموعة مألوفة جدًا من رسائل الخطأ ، ولكن لا يزال من المفيد معرفة أنك تواجه نفس المشكلة التي يبدو الآن أنه قد تم إصلاحها.

تستعد Cypress لإصدار برنامج ثابت جديد لنا - سننشر هنا عندما يتوفر شيء ما للاختبار. شكرا للجميع على اهتمامك ووقتك وصبرك.

موافق. شكرا لسائق العمل.

قد تكون الأمور قد تغيرت منذ ذلك الحين ..

https://tech4research.wordpress.com/2014/07/23/brcmfmac-debugging-and- appropriate-debug-values/

وأنا أقدر أن مفتاح التصحيح للبرنامج الثابت الجديد قد يكون إضافة خاصة ولكن يبدو أن هذه المفاتيح تعمل مع كل من البرنامج الثابت الأصلي و "تصحيح الأخطاء" ويتم إطلاق التدفق المتوقع للتصحيح.

ربما تمت رؤيته بالفعل ؛ لكن TPLink تدعي أن أجهزة Android تقوم بتوصيل أجهزتها بحزم MDNS عندما تستيقظ من وضع السكون وتحاول إعادة الاتصال بـ Chromecast أو الأجهزة المماثلة.
عند الحفر في pcap حصلت على فصل واحد من جهازي الخاص ، يمكنني رؤية حوالي 3500 حزمة MDNS تأتي في حوالي 2.25 ثانية قبل أن يموت الاتصال مباشرة. يبدو أنه يتناسب مع هذا النمط وقد يكون مرتبطًا.

فقط لإضافة / تأكيد بعض المعلومات في هذا العدد:

• يبدو أن تعيين واجهة wifi على منحل ( ifconfig wlan0 promisc ) يخفف من المشكلة
• يبدو أن المشكلة ناتجة فقط عن هاتفي الذي يعمل بنظام التشغيل Android 7.1.2 Galaxy S7 (الذي حصلت عليه منذ أسبوع وكان هذا هو الوقت الذي بدأت فيه المشكلات)

أقوم بتشغيل Debian Buster بـ aarch64 على Pi3 الخاص بي وتشغيل خادم Nextcloud عليه. scp'ing ملفات أكبر من كمبيوتر محمول Linux لا يسبب أي مشاكل ولا مزامنة Nextcloud من هذا الكمبيوتر المحمول ، ولكن بمجرد أن أقوم بتحميل مجموعة من الملفات من Galaxy ، سيظهر الخطأ Unknown mailbox data content: 0x40012 وسيظهر اتصال Wifi ضائع.

برنامج brcmfmac الثابت الذي أستخدمه هو 7.45.41.26 (r640327) FWID 01-4527cfab

لسوء الحظ ، ليس لدي Android أقدم لاختباره.

لقد قمت بتفريغ تحميل من Samsung إلى Pi3 ، ولكن بعد ذلك كان Wifi في وضع مختلط وعمل كل شيء على ما يرام. إذا وجدت الوقت ، فسألقي نظرة على pcap وأبلغ مرة أخرى إذا وجدت أي شيء مفيد / مثير للاهتمام.

ملاحظة: Cast (الجاني الرئيسي الموضح في مقالة TPLink) غير نشط (أو على الأقل لا يمكنني رؤيته في إعدادات الاتصال).

أهلا بالجميع،

أريد فقط أن أؤكد أن إيقاف تشغيل وضع powerafe وتمكين وضع الاختلاط حل المشكلة بالنسبة لي: لأول مرة تمكنت من البقاء على اتصال لمدة 24 ساعة.

تعيين sudo iw wlan0 power_save
sudo ifconfig wlan0 promisc

شكر،
لوك

يرجى الاطلاع على منشور المنتدى هذا للحصول على تفاصيل حول إصدار برنامج ثابت جديد. يجب على أي شخص يرى مشكلة في صندوق البريد ، أو في الواقع أي مشاكل لاسلكية ، تجربة ذلك لمعرفة ما إذا كان ذلك مفيدًا.

https://www.raspberrypi.org/forums/viewtopic.php؟f=63&t=203508

تضمين التغريدة
مرحبا يا جيمس،
هل يمكنك تقديم بعض إرشادات التثبيت ، هل ملف .bin في الأرشيف قابل للتنفيذ ذاتي التثبيت؟
شكرا
لي

التعليمات الآن على صفحة المنتدى المرتبطة.

التحقق مرة أخرى بعد تشغيل البرنامج الثابت الجديد لما يزيد قليلاً عن أسبوع. حتى الآن ، كانت صلبة. لقد أيقظت جهاز Samsung الخاص بي مرارًا وتكرارًا بعد فترات طويلة واستمرت الواجهة اللاسلكية على Pi الخاص بي في العمل. أعتقد أن لدي حالة واحدة حيث سقطت مؤقتًا ثم تعافت ؛ رغم ذلك ، لم أتمكن من إعادة إنتاج ذلك. الكل في الكل ، يبدو متينًا. شكرًا لك على كل من جيمس لالتزامه بهذا وللفريق Cypress لإصلاحه.

شكرا على التقرير.

هل يمكن لأي شخص أن يخبرني ما إذا كان إصلاح البرنامج الثابت قد تم بالفعل في توزيع Raspbian الرسمي بحيث يمكن تثبيته عبر apt update أو إذا لم يكن الأمر كذلك ، فأبلغني بعد أن كان الأمر كذلك؟

هل يمكن لأي شخص أن يخبرني ما إذا كان إصلاح البرنامج الثابت قد تم بالفعل في توزيع Raspbian الرسمي بحيث يمكن تثبيته عبر التحديث المناسب أو إذا لم يكن كذلك ، أبلغني بعد أن كان الأمر كذلك؟

نعم. https://www.raspberrypi.org/forums/viewtopic.php؟f=63&t=203508&start=25#p1270212
بعض المشكلات التي يتم الإبلاغ عنها على Pi0W بعد التحديث بشكل عام ، ولكن ليس من الواضح تمامًا ما إذا كان مجرد تغيير في البرنامج الثابت أو أي شيء آخر - https://www.raspberrypi.org/forums/viewtopic.php؟f=63&t=204882

لقد قمت بتحديث البرامج الثابتة

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.bin
ba679a85c1dc76e9775603af45440bc0  /lib/firmware/brcm/brcmfmac43430-sdio.bin

ولكن لا يزال لديك نفس المشكلة

$ 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

ما يلي أيضًا لا يتجنب هذه المشكلة

sudo iw wlan0 set power_save off
sudo ifconfig wlan0 promisc

أنا أستخدم RPi3 كنقطة وصول مع hostapd و dnsmasq .
يمكنني دائمًا إعادة إظهار المشكلة عند بدء التنزيل في تطبيق Spotify على هاتف Android.

هل أحتاج إلى تحديث الملف التالي أيضًا؟

$ md5sum /lib/firmware/brcm/brcmfmac43430-sdio.txt
9a88b55134d9f8f3ad2331b93f4b7b79  /lib/firmware/brcm/brcmfmac43430-sdio.txt

هل سيستخدمها السائق أم يمكن تجاهله؟

تعديل:
نعم. مطلوب أيضًا ملف brcmfmac43430-sdio.txt.
لكني أستخدم أحدث الإصدارات من https://github.com/RPi-Distro/firmware-nonfree/tree/927fa8ebdf5bcfb90944465b40ec4981e01d6015/brcm

لقد قمت أيضًا بتحديث 4.9.35-v7 + kernel إلى 4.14.18-v7 +.
لكن القضية لا تزال قائمة.

واجهت نفس المشكلة على RPi3 الخاص بي: تم إسقاط Wifi بعد بعض وقت التشغيل (على سبيل المثال خلال الليل) مع عدم وجود حركة مرور تقريبًا.
يظهر إخراج dmesg فقط:

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

حاولت إعادة تحميل برنامج التشغيل (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

لم ينجح ذلك بطريقة ما - تم تحميل برنامج التشغيل ولكن لم يكن لدي أي واجهة
حاول مرة أخرى:

[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

.. وأنا مرة أخرى.

يقوم Pi3 بتشغيل kernel '4.14.24-v7 + # 1097' - البرنامج الثابت هو الأقدم من 7 أغسطس 2017 - نفس كتلة البرامج الثابتة التي تعمل بلا عيب (وقت التشغيل> شهرين) على نواة التشغيل Pi Zero W '4.9.77+ # 1081'
كلاهما متصلان بنفس جهاز التوجيه وغرفة منفصلة. كلاهما متصل عبر شبكة WiFi فقط.

ربما يستحق استخدام أحدث البرامج الثابتة على 4.14 ، نظرًا لأن 4.14 يحتوي على جميع التغييرات المطلوبة للعمل مع تلك البرامج الثابتة.

:) تم التحديث إلى أحدث إصدار (أكتوبر 23 2017 03:55:53 الإصدار 7.45.98.38) أمس بعد النشر - يبدو أنه يعمل في أجهزة الصراف الآلي - لنرى ما سيحدث ..

يبدو أن raspbian عاد إلى حزمة البرامج الثابتة لشهر أغسطس 2017. هل هناك متطلبات جديدة لـ rpi 3B + wireless؟

أحدث البرامج الثابتة لاستعادة البيانات من Foundation's-brcm80211 1: 20161130-3 + حزمة

لدي أيضًا هذه المشكلة مع wifi dying.

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

هذا مع 4.14.27-v7 + ومع
/ sbin / iw dev wlan0 ضبط power_save
/ sbin / ifconfig wlan0 promisc
في /etc/rc.local.

نفس رسائل الخطأ مثل @ flok99 - استخدام أحدث البرامج الثابتة (تحديث rpi) على امتداد.

حسنًا ، لذا فإن الخطأ الذي اعتقدنا أن Cypress قد أصلحه لا يزال موجودًا. ارجع الى
يذهب السرو. استغرقت سنة للحصول على هذا الإصدار. لا حبس النفس
موصى به.

يجب تأكيد الإصدار بالرغم من ذلك ، يرجى نشر محتويات

dmesg | grep brcmfmac

في 18 مارس 2018 الساعة 01:44 ، كتب Rebroad [email protected] :

نفس رسائل الخطأ مثل @ flok99 https://github.com/flok99 - باستخدام الأحدث
البرامج الثابتة (تحديث rpi) على امتداد.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373966343 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHY1Cmntz_kn9pvrZdgy32mTignlmks5tfbvwgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

[4.112717] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x15264345
[4.119827] brcmfmac: brcmf_fw_map_chip_to_name: استخدام
brcm / brcmfmac43455-sdio.bin للرقاقة 0x004345 (17221) rev 0x000006
[4.120314] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[4.440371] brcmfmac: brcmf_c_preinit_dcmds: إصدار البرنامج الثابت = wl0: فبراير
27 2018 03:15:32 الإصدار 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[4.440958] brcmfmac: brcmf_c_preinit_dcmds: إصدار CLM = API: 12.2
البيانات: 9.10.105 المترجم: 1.29.4 ClmImport: 1.36.3 الإنشاء: 2018-03-09
18:56:28
[10.911757] brcmfmac: تعطيل إدارة الطاقة
[12.016088] brcmfmac: إدارة الطاقة معطلة
[2074.090674] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
فشل مع الحالة -5
[2074.090687] brcmfmac: brcmf_cfg80211_get_tx_power: خطأ (-5)
[2074.090745] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[2074.090753] brcmfmac: brcmf_link_down: فشل WLC_DISASSOC (-5)
[2074.610583] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[2074.611992] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[2074.613945] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[2074.613971] brcmfmac: brcmf_cfg80211_get_channel: فشل chanspec (-5)
[2074.729716] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[2074.729733] brcmfmac: brcmf_cfg80211_reg_notifier: رمز الدولة iovar
عاد يخطئ = -5
[2074.871693] usbcore: إلغاء تسجيل برنامج تشغيل الواجهة brcmfmac
[2074.929084] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x15264345
[2074.936897] brcmfmac: brcmf_fw_map_chip_to_name: استخدام
brcm / brcmfmac43455-sdio.bin للرقاقة 0x004345 (17221) rev 0x000006
[2074.937139] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[2075.118180] brcmfmac: brcmf_c_preinit_dcmds: إصدار البرنامج الثابت = wl0: فبراير
27 2018 03:15:32 الإصدار 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2075.118706] brcmfmac: brcmf_c_preinit_dcmds: إصدار CLM = API: 12.2
البيانات: 9.10.105 المترجم: 1.29.4 ClmImport: 1.36.3 الإنشاء: 2018-03-09
18:56:28
[2075.215365] brcmfmac: إدارة الطاقة معطلة
[2075.263751] brcmfmac: إدارة الطاقة معطلة
[2085.475001] brcmfmac: إدارة الطاقة معطلة
[2124.380808] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[2124.381146] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[2124.381156] brcmfmac: brcmf_cfg80211_get_channel: فشل chanspec (-5)
[2124.622345] usbcore: إلغاء تسجيل برنامج تشغيل الواجهة brcmfmac
[2124.705432] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x15264345
[2124.714194] brcmfmac: brcmf_fw_map_chip_to_name: استخدام
brcm / brcmfmac43455-sdio.bin للرقاقة 0x004345 (17221) rev 0x000006
[2124.716213] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[2124.929556] brcmfmac: brcmf_c_preinit_dcmds: إصدار البرنامج الثابت = wl0: فبراير
27 2018 03:15:32 الإصدار 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[2124.929993] brcmfmac: brcmf_c_preinit_dcmds: إصدار CLM = API: 12.2
البيانات: 9.10.105 المترجم: 1.29.4 ClmImport: 1.36.3 الإنشاء: 2018-03-09
18:56:28
[2125.105218] brcmfmac: إدارة الطاقة معطلة
[2125.150290] brcmfmac: إدارة الطاقة معطلة
[8237.434034] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف:
0x40012
[8239.890302] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[8239.890822] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[8239.890835] brcmfmac: brcmf_run_escan: خطأ (-110)
[8239.890845] brcmfmac: brcmf_cfg80211_scan: خطأ المسح (-110)
[8254.280425] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
فشل مع الحالة -5
[8254.280438] brcmfmac: brcmf_cfg80211_get_tx_power: خطأ (-5)
[8254.280491] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8254.280498] brcmfmac: brcmf_link_down: فشل WLC_DISASSOC (-5)
[8254.800394] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8254.803873] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8254.808353] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8254.808370] brcmfmac: brcmf_cfg80211_get_channel: فشل التغيير (-5)
[8254.881402] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8254.881420] brcmfmac: brcmf_cfg80211_reg_notifier: رمز الدولة iovar
عاد يخطئ = -5
[8255.001550] usbcore: إلغاء تسجيل برنامج تشغيل الواجهة brcmfmac
[8255.071184] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x15264345
[8255.077098] brcmfmac: brcmf_fw_map_chip_to_name: استخدام
brcm / brcmfmac43455-sdio.bin للرقاقة 0x004345 (17221) rev 0x000006
[8255.077348] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[8257.730418] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[8257.751038] brcmfmac: brcmf_c_get_clm_name: استرداد معلومات المراجعة
فشل (-110)
[8257.751049] brcmfmac: brcmf_c_process_clm_blob: الحصول على اسم ملف blob CLM
فشل (-110)
[8257.751068] brcmfmac: brcmf_c_preinit_dcmds: تنزيل ملف blob CLM
فشل ، -110
[8257.751076] brcmfmac: brcmf_bus_started: فشل: -110
[8257.751114] brcmfmac: brcmf_sdio_firmware_callback: الدونجل ليس كذلك
يستجيب
[8304.417684] usbcore: إلغاء تسجيل برنامج تشغيل الواجهة brcmfmac
[8304.486099] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x15264345
[8304.493613] brcmfmac: brcmf_fw_map_chip_to_name: استخدام
brcm / brcmfmac43455-sdio.bin للرقاقة 0x004345 (17221) rev 0x000006
[8304.494078] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[8304.686761] brcmfmac: brcmf_c_preinit_dcmds: إصدار البرنامج الثابت = wl0: فبراير
27 2018 03:15:32 الإصدار 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8304.687203] brcmfmac: brcmf_c_preinit_dcmds: إصدار CLM = API: 12.2
البيانات: 9.10.105 المترجم: 1.29.4 ClmImport: 1.36.3 الإنشاء: 2018-03-09
18:56:28
[8304.829994] brcmfmac: إدارة الطاقة معطلة
[8304.907662] brcmfmac: إدارة الطاقة معطلة
[8357.441791] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف:
0x40012
[8359.891146] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[8359.891655] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[8359.891668] brcmfmac: brcmf_run_escan: خطأ (-110)
[8359.891677] brcmfmac: brcmf_cfg80211_scan: خطأ المسح (-110)
[8371.731226] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[8371.731731] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[8371.731746] brcmfmac: brcmf_cfg80211_get_channel: فشل chanspec (-110)
[8373.941267] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
فشل مع الحالة -5
[8373.941280] brcmfmac: brcmf_cfg80211_get_tx_power: خطأ (-5)
[8373.941330] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8373.941338] brcmfmac: brcmf_link_down: فشل WLC_DISASSOC (-5)
[8374.461245] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8374.461942] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8374.463553] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8374.463573] brcmfmac: brcmf_cfg80211_get_channel: فشل التغيير (-5)
[8374.564729] brcmfmac: brcmf_fil_cmd_data: الحافلة معطلة. ليس لدينا شيء
لكى يفعل.
[8374.564750] brcmfmac: brcmf_cfg80211_reg_notifier: رمز الدولة iovar
عاد يخطئ = -5
[8374.702401] usbcore: إلغاء تسجيل برنامج تشغيل الواجهة brcmfmac
[8374.759839] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x15264345
[8374.767561] brcmfmac: brcmf_fw_map_chip_to_name: استخدام
brcm / brcmfmac43455-sdio.bin للرقاقة 0x004345 (17221) rev 0x000006
[8374.771137] usbcore: برنامج تشغيل الواجهة الجديد المسجل brcmfmac
[8377.411255] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[8377.431924] brcmfmac: brcmf_c_get_clm_name: استرداد معلومات المراجعة
فشل (-110)
[8377.431934] brcmfmac: brcmf_c_process_clm_blob: الحصول على اسم ملف blob CLM
فشل (-110)
[8377.431941] brcmfmac: brcmf_c_preinit_dcmds: تنزيل ملف blob CLM
فشل ، -110
[8377.431949] brcmfmac: brcmf_bus_started: فشل: -110
[8377.432003] brcmfmac: brcmf_sdio_firmware_callback: الدونجل ليس كذلك
يستجيب
[8424.133114] usbcore: إلغاء تسجيل برنامج تشغيل الواجهة brcmfmac
[8424.229631] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x15264345
[8424.237210] brcmfmac: brcmf_fw_map_chip_to_name: استخدام
brcm / brcmfmac43455-sdio.bin للرقاقة 0x004345 (17221) rev 0x000006
[8424.239352] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[8424.460736] brcmfmac: brcmf_c_preinit_dcmds: إصدار البرنامج الثابت = wl0: فبراير
27 2018 03:15:32 الإصدار 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[8424.461174] brcmfmac: brcmf_c_preinit_dcmds: إصدار CLM = API: 12.2
البيانات: 9.10.105 المترجم: 1.29.4 ClmImport: 1.36.3 الإنشاء: 2018-03-09
18:56:28
[8424.646993] brcmfmac: إدارة الطاقة معطلة
[8424.708633] brcmfmac: إدارة الطاقة معطلة

يوم الأحد 18 مارس 2018 الساعة 11:30 صباحًا ، جيمس هيوز [email protected]
كتب:

حسنًا ، لذا فإن الخطأ الذي اعتقدنا أن Cypress قد أصلحه لا يزال موجودًا. ارجع الى
يذهب السرو. استغرقت سنة للحصول على هذا الإصدار. لا حبس النفس
موصى به.

يجب تأكيد الإصدار بالرغم من ذلك ، يرجى نشر محتويات

dmesg | grep brcmfmac

في 18 مارس 2018 الساعة 01:44 ، كتب Rebroad [email protected] :

نفس رسائل الخطأ مثل @ flok99 https://github.com/flok99 - باستخدام
آخر
البرامج الثابتة (تحديث rpi) على امتداد.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
< https://github.com/raspberrypi/linux/issues/1342#issuecomment -373966343
و
أو كتم الخيط
kn9pvrZdgy32m علامة تجارية 5tfbvwgaJpZM4HupC5>
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-373987387 ،
أو كتم الخيط
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

تضمين التغريدة

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 

يبدو إلى حد كبير أنك تستخدم أحدث Pi3b + وليس على Pi3 الأصلي: فربما يكون الأمر مختلفًا؟

الرقاقة والبرامج الثابتة مختلفة تمامًا ، على الرغم من أن برنامج التشغيل الجانبي Linux هو
نفسه. (بركمفماك).

في 19 مارس 2018 الساعة 16:26 ، كتب macmpi [email protected] :

@ flok99 https://github.com/flok99

brcmfmac: brcmf_fw_map_chip_to_name: استخدام brcm / brcmfmac43455-sdio.bin للشريحة
إصدار البرنامج الثابت = wl0: 27 فبراير 2018 03:15:32 الإصدار 7.45.154 (r684107 CY) FWID 01-4fbe0b04

يبدو أنك تستخدم أحدث Pi3b + وليس على Pi3 الأصلي: لذا
ربما مسألة مختلفة؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/raspberrypi/linux/issues/1342#issuecomment-374274045 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADqrHeP6-sc-P-OSggQFPrl3O8z_B2aRks5tf9wbgaJpZM4HupC5
.

-
جيمس هيوز
مهندس برمجيات رئيسي ،
Raspberry Pi (Trading) Ltd

أعتقد أنه من الأفضل أن يكون لديك موضوع آخر لمشكلات Pi3B + ، والرجوع إلى هذا الموضوع عند الضرورة ، وإلا فسيكون من الصعب جدًا تتبعه. Can @ flok99 يرجى إنشاء مشكلات جديدة بتقاريره ، مع التأكد من أن العنوان يشير إلى 3b +. سأغير عنوان هذا ليعكسه لـ Pi3B فقط.

فعله

هل لا يزال أي شخص مشترك في هذه المشكلة ، بتشغيل 3B (وليس زائد) ، يرى مشاكل أحدث البرامج الثابتة والنواة؟ هل ترغب في أي تقارير عن استمرار الفشل - يبدو أن المشاركات الأخيرة حول الموضوع أعلاه تشير إلى أن الأمور تعمل الآن بشكل جيد.

3B الخاص بي منذ 44 يومًا مع هذا:

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

لا مشاكل منذ ذلك الحين ..

أخبار جيدة. ما لم أسمع خلاف ذلك ، من المحتمل أن أغلق هذا الموضوع في غضون أسبوع أو أسبوعين ، على الرغم من أنه يمكن إعادة فتحه في أي وقت إذا تكررت المشاكل.

لقد بدأت أواجه هذه المشكلة منذ حوالي أسبوع ، ولم أسمع بها من قبل. أنا أيضًا أستخدم pi في أغلب الأحيان مع هاتف samsung كموجه - لي هو s4. أكتب هذا متصل مباشرة بـ s4 باستخدام USB ، أي باستخدام rndis. إليكم التفاصيل الخاصة بي من حذاء اليوم:
0 تمت ترقيته ، 0 مثبت حديثًا ، 0 للإزالة و 0 لم تتم ترقيته.
thenry @ pi3portable : ~ $ dmesg | grep brcmfmac
[9.965782] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x1541a9a6
[9.972059] brcmfmac: brcmf_fw_map_chip_to_name: استخدام brcm / brcmfmac43430-sdio.bin للرقاقة 0x00a9a6 (43430) rev 0x000001
[9.972250] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[10.147562] brcmfmac: brcmf_c_preinit_dcmds: إصدار البرنامج الثابت = wl0: 7 أغسطس 2017 00:46:29 الإصدار 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.148507] brcmfmac: brcmf_c_preinit_dcmds: إصدار CLM = API: 12.2 البيانات: 7.11.15 المترجم: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.41 Inc مترجم: 1.29 .4 Inc Clm الاستيراد: 1.36.3 الإنشاء: 2017-08-07 00:37:47
[18.538641] brcmfmac: تعطيل إدارة الطاقة
[30.629545] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
[33.191450] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[33.194850] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[35.751496] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[35.754898] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[35.754906] brcmfmac: brcmf_pno_clean: الكود الفاشل -110
[43.271438] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[43.274800] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[43.274807] brcmfmac: brcmf_do_escan: خطأ (-110)
[43.274811] brcmfmac: brcmf_cfg80211_scan: خطأ المسح (-110)
[7673.758073] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[7673.761437] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[7673.761454] brcmfmac: _brcmf_set_multicast_list: فشل إعداد mcast_list ، -110
[7676.328075] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[7676.331449] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[7676.331466] brcmfmac: _brcmf_set_multicast_list: تعيين allmulti فشل ، -110
[7678.878084] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[7678.881460] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[7681.448101] brcmfmac: _brcmf_set_multicast_list: فشل إعداد BRCMF_C_SET_PROMISC ، -110
[7689.118098] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
[7689.118241] brcmfmac: إدارة الطاقة معطلة
[7691.678100] brcmfmac: brcmf_cfg80211_set_power_mgmt: خطأ (-110)
[7694.238122] brcmfmac: _brcmf_set_multicast_list: فشل إعداد mcast_list ، -110
[7696.798118] brcmfmac: _brcmf_set_multicast_list: تعيين allmulti فشل ، -110
[7699.358158] brcmfmac: brcmf_do_escan: خطأ (-110)
[7699.358167] brcmfmac: brcmf_cfg80211_scan: خطأ المسح (-110)
[7701.918127] brcmfmac: _brcmf_set_multicast_list: فشل إعداد BRCMF_C_SET_PROMISC ، -110
[11406.881341] brcmfmac: brcmf_proto_bcdc_query_dcmd: فشل brcmf_proto_bcdc_msg w / status -110
[11406.881352] brcmfmac: brcmf_cfg80211_reg_notifier: رمز البلد iovar عاد Err = -110
[11579.921479] brcmfmac: _brcmf_set_multicast_list: فشل إعداد mcast_list ، -110
[11582.491485] brcmfmac: _brcmf_set_multicast_list: تعيين allmulti فشل ، -110
[11587.611478] brcmfmac: _brcmf_set_multicast_list: فشل إعداد BRCMF_C_SET_PROMISC ، -110
thenry @ pi3portable : ~ $
thenry @ pi3portable : ~ $ uname -a
Linux pi3portable 4.14.27-v7 + # 1100 SMP الجمعة 16 مارس 13:51:48 GMT 2018 armv7l GNU / Linux
thenry @ pi3portable : ~ $
أقوم بتشغيل هذه النواة لأنني غيرت إلى الدفق التالي عندما كنت أختبر التمهيد من USB ، ولم أتغير مرة أخرى بعد ذلك. ثم تلقيت إشعارًا بشأن النواة الجديدة (4.14) ، لذا قررت تجربة ذلك ، منذ حوالي شهر. لقد كان على ما يرام ، ولا توجد مشاكل حتى هذا واحد. التغيير الرئيسي الآخر فقط هو أنني قمت بالتبديل من NetworkManager إلى systemd-networkd منذ عدة أيام ولكن هذا بعد أن ظهرت هذه المشكلة لأول مرة.
مع تحياتي،
تريفور هنري

تحديث:
بعد أن قرأت جميع المنشورات ذات الصلة ، وجدت أحدث البرامج الثابتة في المنشور https://www.raspberrypi.org/forums/viewtopic.php؟f=63&t=203508
وهذا أصلح مشكلتي.

نسخة تجريبية من brcmfmas43430-sdio.bin مثبتة 250418

الإصدار 7.45.98.38 23 أكتوبر 2017 ، تم استبدال الإصدار 7.45.41.46 في 7 أغسطس 2017

قبل:

[10.368086] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x1541a9a6
[10.376702] brcmfmac: brcmf_fw_map_chip_to_name: استخدام brcm / brcmfmac43430-sdio.bin للرقاقة 0x00a9a6 (43430) rev 0x000001
[10.377026] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[10.599523] brcmfmac: brcmf_c_preinit_dcmds: إصدار البرنامج الثابت = wl0: 7 أغسطس 2017 00:46:29 الإصدار 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[10.600577] brcmfmac: brcmf_c_preinit_dcmds: إصدار CLM = API: 12.2 البيانات: 7.11.15 المترجم: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.41 Inc مترجم: 1.29 .4 Inc Clm الاستيراد: 1.36.3 الإنشاء: 2017-08-07 00:37:47
[126.642710] brcmfmac: إدارة الطاقة معطلة
[139.249230] brcmfmac: brcmf_sdio_hostmail: محتوى بيانات صندوق بريد غير معروف: 0x40012
[141.751545] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[141.754973] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[144.311482] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[144.314959] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[144.314975] brcmfmac: brcmf_pno_clean: الكود الفاشل -110
[151.831564] brcmfmac: brcmf_sdio_bus_rxctl: يُستأنف عند انتهاء المهلة
[151.835066] brcmfmac: brcmf_sdio_checkdied: مصيدة البرامج الثابتة في الدونجل
[151.835079] brcmfmac: brcmf_do_escan: خطأ (-110)
[151.835084] brcmfmac: brcmf_cfg80211_scan: خطأ المسح (-110)

بعد:

thenry @ pi3portable : ~ $ dmesg | grep brcm
[10.115833] brcmfmac: قراءة توقيع F1 @ 0x18000000 = 0x1541a9a6
[10.134926] brcmfmac: brcmf_fw_map_chip_to_name: استخدام brcm / brcmfmac43430-sdio.bin للرقاقة 0x00a9a6 (43430) rev 0x000001
[10.135115] usbcore: برنامج تشغيل واجهة جديد مسجل brcmfmac
[10.367703] brcmfmac: brcmf_c_preinit_dcmds: إصدار البرنامج الثابت = wl0: 23 أكتوبر 2017 03:55:53 الإصدار 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[10.368419] brcmfmac: brcmf_c_preinit_dcmds: إصدار CLM = API: 12.2 البيانات: 7.11.15 المحول البرمجي: 1.24.2 ClmImport: 1.24.1 الإنشاء: 2014-05-26 10:53:55 Inc Data: 9.10.39 Inc مترجم: 1.29 .4 Inc Clm الاستيراد: 1.36.3 الإنشاء: 2017-10-23 03:47:14
[18.045308] brcmfmac: إدارة الطاقة معطلة
thenry @ pi3portable : ~ $

لقد استمر في العمل من خلال العديد من الأحذية وأنا الآن أستخدمها ، متصلاً بواسطة wifi بهاتف Samsung s4.
شكرا لمساعدتك ، تحياتي ، تريفور هنري.

اعتقدت أن أحدث البرامج الثابتة موجودة بالفعل في أحدث الصور ، لذا كنت أتوقع أن تؤدي الترقية إلى 4.14 إلى جلب أحدث البرامج الثابتة. هل قمت ببناء النواة الخاصة بك؟

نعم - تحتوي صور Raspbian الحالية على برامج ثابتة 7.45.98.38 من 23 أكتوبر 2017.

مرحبًا ، لا ، لم أقم ببناء النواة ، لقد قمت بالترقية باستخدام تحديث rpi ، وكما ترى ، كان لا يزال يعمل على البرنامج الثابت لشهر أغسطس 2017 بعد التحديث.

يقوم تحديث rpi فقط بترقية kernel والبرامج الثابتة وعدد صغير من الأدوات المساعدة الخاصة بـ VideoCore. لترقية كل شيء ، بما في ذلك برنامج WiFi الثابت ، يجب عليك استخدام apt-get Upgrade / distupgrade.

مرحبا،
إذن لدي هذه المشكلة وهي أفضل مع أحدث إصدار ، 7.45.98.38 ، مما كانت عليه ولكن لا يزال لدي مشاكل.
ملاحظات
إذا قمت بتشغيل التوت دون القيام بأي شيء ، فستظهر شبكة WLAN كما ينبغي.
إذا حاولت استخدام لوحة مفاتيح أو ماوس البلوتوث قبل تشغيل شبكة WLAN ، فستستمر المشكلة ، ولا أحصل على اتصال.
إذا كان لدي اتصال وقمت بتعطيل / تمكين الشبكة اللاسلكية ، فإن شبكة WLAN لا تتصل.
إذا تركت شبكة WLAN طوال الليل ، فسيتوقف الاتصال عن العمل.
لدي ثلاثة إعدادات متطابقة والسلوك هو نفسه في كل منهم.
لا تعرف ما إذا كان الأمر مهمًا ولكننا نستخدم WPA2 enterprise و PEAP و MSCHAPv2

هل تحدث هذه المشكلات فقط عند توصيل أجهزة BT؟

نعم! بلوتوث معطل ولوحات مفاتيح USB وفأرة متصلة وشبكة WLAN متصلة بشكل أسرع مما رأيته من قبل.

لا تزال بعض المشاكل مع التعايش بعد ذلك. سأحتاج إلى الإبلاغ عن Cypress على ما أعتقد.

فقط للتحقق ، أنت تستخدم أحدث إصدار من Raspbian؟ أو شيء جديد؟

تضمين التغريدة

الوصف: Raspbian GNU / Linux 9.4 (امتداد)
هل تريد المزيد من المعلومات؟

يتوقف بعد:
14 مايو 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: تم تحديد wlan0: CTRL-EVENT-EAP-METHOD بائع EAP الطريقة 25 (PEAP)

انظر سجل القصاصة أدناه

14 مايو 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.7887] الجهاز (wlan0): حالة واجهة الطلب: غير متصل -> إقران
14 مايو 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: مقترن بـ 44: d9: e7: f7: d5: 34
14 مايو 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: بدأت مصادقة CTRL-EVENT-EAP-STARTED EAP
14 مايو 15:43:58 hwlab1_gul_rpi NetworkManager [2745]:[1526305438.9263] الجهاز (wlan0): حالة واجهة الملحق: اقتران -> مرتبط
14 مايو 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD مزود = 0 طريقة = 25
14 مايو 15:43:58 hwlab1_gul_rpi wpa_supplicant [445]: تم تحديد wlan0: CTRL-EVENT-EAP-METHOD بائع EAP الطريقة 25 (PEAP)
14 مايو 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0716] الجهاز (wlan0): التنشيط: استغرق اقتران (wifi) وقتًا طويلاً
14 مايو 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0718] الجهاز (wlan0): تغيير الحالة: config -> need-auth (السبب 'لا شيء') [50 60 0]
14 مايو 15:44:24 hwlab1_gul_rpi wpa_supplicant [445]: wlan0: CTRL-EVENT-DISCONNECTED bssid = 44: d9: e7: f7: d5: 34 السبب = 3 محليا_ولدت = 1
14 مايو 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0937] جهاز (wlan0): التنشيط: (wifi) يسأل عن أسرار جديدة
14 مايو 15:44:24 hwlab1_gul_rpi NetworkManager [2745]:[1526305464.0959] sup-iface [0x1c438c0، wlan0]: الاتصال غير متصل (السبب -3)

لدي نفس المشكلة مع octoPi 0.14 (تم تحديث كل حزمة ، البرامج الثابتة rpi على أبعد تقدير ، تم تحديث كل مكون إضافي من Octoprint).

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

مع هذا الإعداد ، يمكن استنساخه بنسبة 100٪. الاستيلاء على موقع الويب octoprint على pi (الوصول لأول مرة بعد التمهيد) من جهاز samsung s4 النشط (android 5.0.1 ، باستخدام chrome) أو من جهاز Samsung اللوحي 10 بوصة الخاص بي مع ملاحظة android 5.xi و chrome يقتل wifi عندما يقتل تم تحميل نصف الصفحة.
لا يوجد كابل متصل بـ Pi3 ، wifi على القناة 11 مع wpa2.
لقد حاولت تعطيل شيء طاقة wifi والتحول إلى قناة wifi 6 دون أي حظ (تلميحات من الأعلى) - ومع ذلك شعرت أنه كان أفضل قليلاً مع القناة 6.

ولكن الآن يأتي الدليل المثير للاهتمام على الخطأ:
ليس لدي أي مشكلة عندما أفتح موقع octopi / octoprint (على pi) من جهاز windows 10 أو ubuntu 16 (باستخدام chrome ، اتصال الكابل بجهاز التوجيه). تخميني الآن هو أنه Android أو samsung أو wifi لخلل متعلق بشبكة wifi. وأعتقد أنني قد قرأت شيئًا عن مشكلات android / rpi منذ فترة.

أتمنى أن يساعدك هذا. إذا كنت بحاجة إلى جهاز اختبار لبعض الإصدارات ، فسأجربه.

لقد ظننت أنني سأتناغم هنا وأقول إننا رأينا أيضًا ما يبدو وكأنه أكشاك حظر مرتبطة بشبكة WiFi حول برنامج التشغيل هذا والتي قد تكون مرتبطة بـ SBC آخر. إنها ليست خاصة بـ Raspberry PI.

وهذا ما يحدث لي أيضا.

نصب

• Pi 3B 1.2 (a02082)
• نواة:

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

تشغيل إصدار راسببيان 9.4:

pi<strong i="14">@raspberrypi</strong>:~ $ cat /etc/debian_version
9.4

نسخة برنامج ثابت:

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 تم إيقاف تشغيل إدارة الطاقة:

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

أنا أستخدم wifi المدمج. لا شيء متصل بمنفذ إيثرنت.

تمت ترقية النظام باستخدام apt-get upgrade و apt-get dist-upgrade و rpi-update .

ما أراه

بعد مرور ساعة تقريبًا على تشغيل pi ، يتعذر الوصول إليه من الشبكة. لا يمكنني الوصول إلى Pi من شبكتي المحلية (لا يعمل ping و ssh).

في dmesg ، أرى أنني أحصل على:

brcmfmac: power management disabled
...
snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned

لكن لا توجد أخطاء.

شيء مثير للاهتمام

لقد لاحظت أنه عندما يحدث هذا ، إذا قمت بالاتصال بـ pi مباشرة وقمت باختبار جهاز الكمبيوتر المحمول - ستعود الأشياء إلى العمل. أيضًا ، أوقات ping غريبة بعض الشيء - يبدو أن الأمر يستغرق بعض الوقت لتسخين الأشياء:

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

إذا احتاج أي شخص إلى مزيد من المعلومات ، فسيسعدني توفيرها.

bugok ، هل إعداد واجهة الشبكة للتخفيف من حدة المشكلة بالنسبة لك؟ ( ifconfig wlan0 promisc ).

quozl : لم يساعد. بعد فترة ، بدأ اختبار ping بالفشل:

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

إعادة الإبلاغ: يبدو أن مشكلتي قد تم حلها ، ويبدو أنها لا علاقة لها بالمشكلة في سلسلة الرسائل هذه.

التفاصيل هنا ، ولكن الجوهر هو أنني قمت بتعيين IP ثابت على Pi نفسه (في /etc/dhcpcd.conf ). بعد تحديد IP الثابت في جهاز التوجيه ، وإزالة تكوين IP الثابت من /etc/dhcpcd.conf وإعادة التشغيل - يبدو أن الأمور تعمل.

تحديث سريع: استمرت هذه المشكلة (خطأ "محتوى بيانات صندوق البريد غير المعروف" مصحوبًا بإقفال لاسلكي كامل) ، على أحدث البرامج الثابتة مع تثبيت كافة التحديثات (ترقية التوزيع).

لا يزال تغيير سطر واحد في ملف hostapd.conf (حسب تعليقي السابق) يحل المشكلة بالنسبة لي.

استخدام Rpi3B مع kernel 4.14.52-v7 (raspberrypi-kernel 1.20180703-1) و (firmware-brcm80211 1: 20161130-3 + rpt4)
ما زلت أواجه أيضًا مشكلة تجميد wlan (90 جهازًا منها 2 في اليوم بها مشكلة). في بعض الحالات يكون المحول مفقودًا وفي حالات أخرى لا يستجيب. أنا لا أستخدم Pi في وضع AP ، فقط
حاولت إعادة ربطه كما في

لقد قمت حاليًا بإنشاء حل عند اكتشاف عدم وجود اتصال بالشبكة ، يتم إعادة تشغيل pi. ومع ذلك ، هذا ليس حلاً مناسبًا وعلى الأقل أحاول إعادة تحميل برنامج التشغيل

كنت أرى هذه المشكلة باستمرار على Pi 3. كان يعمل سابقًا وأدركت أن التغيير الوحيد الذي أجريته هو توصيل شاشة تعمل باللمس LCD ، وسحب الطاقة من Pi. عندما قمت بفصل شاشة اللمس ، عملت WiFi بشكل صحيح. لذلك يبدو بالتأكيد أنه مرتبط بالسلطة. كان هذا باستخدام محول التيار المتردد Raspberry الرسمي.

هذه نقطة بيانات مثيرة للاهتمام للغاية. هل كانت إحدى شاشات LCD الخاصة بنا؟

@ JamesH65 لقد بدأت أيضًا في تجربة أعطال wifi https://www.waveshare.com/wiki/5inch_HDMI_LCD ، لديّ 3b + a rpi cam v2 والشاشة ، موصولة بـ 3amp psu ، i لا تحصل على أي تحذيرات الطاقة ...

مرحبا شباب ، أي تحديث على هذا؟ كنت أحاول استخدام raspivid على صفر وات مع دفق TCP وبعد بضع دقائق اختفت شبكة Wi-Fi ، أعتقد أنها نفس المشكلة.

لم أواجه المشكلة منذ عام على الأقل أو نحو ذلك. لقد بدأت أفكر بشكل متزايد أنه قد يكون مرتبطًا ببساطة بمصدر طاقة USB لا يوفر مكبرات صوت كافية ، لكنني أرحب بإثبات أن هذا ليس هو الحال. كاختبار ، حاول توصيل كبل USB بمحول أمبير أعلى ، خاصةً إذا كان يمكنك بسهولة إعادة إظهار المشكلة.

أنا متأكد تمامًا من أنها ليست مرتبطة مباشرة بالأمبير لأنني أستخدم فقط حوالي 2 أمبير. في الغالب شواحن سامسونج القديمة. ومع ذلك ، يمكن أن يكون تموجًا أو شيء ما مع مزود الطاقة أو جهاز pi.Von meinem Samsung Gerät gesendet.

-------- Ursprüngliche Nachricht --------
فون: rajid [email protected]
التاريخ: 07.04.2019 02:15 (GMT + 01: 00)
ج: raspberrypi / linux [email protected]
نسخة إلى: "A. Binzxxxxxx" [email protected] ، تعليق [email protected]
Betreff: Re: [raspberrypi / linux] تجمد شبكة wlan في raspberry pi 3 / PiZeroW (ليس
3B +) (# 1342)

لم أواجه المشكلة منذ عام على الأقل أو نحو ذلك. لقد بدأت أفكر بشكل متزايد أنه قد يكون مرتبطًا ببساطة بمصدر طاقة USB لا يوفر مكبرات صوت كافية ، لكنني أرحب بإثبات أن هذا ليس هو الحال. كاختبار ، حاول توصيل كبل USB بمحول أمبير أعلى ، خاصةً إذا كان يمكنك بسهولة إعادة إظهار المشكلة.

- أنت تتلقى هذا لأنك علّقت. قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو كتم صوت سلسلة المحادثات.
{"api_version": "1.0"، "publisher": {"api_key": "05dde50f1d1a384dd78767c55493e4bb"، "name": "GitHub"}، "الكيان": {"external_key": "github / raspberrypi / linux"، "العنوان ":" raspberrypi / linux "،" العنوان الفرعي ":" مستودع GitHub "،" main_image_url ":" https://github.githubassets.com/images/email/message_cards/header.png "،" avatar_image_url ":" https: //github.githubassets.com/images/email/message_cards/avatar.png "،" action ": {" name ":" Open in GitHub "،" url ":" https://github.com/raspberrypi/linux "}}،" updates ": {" snippets ": [{" icon ":" PERSON "،" message ":" rajid in # 1342: لم أعاني من المشكلة منذ عام أو نحو ذلك. أنا لقد بدأت أفكر بشكل متزايد أنه قد يكون مرتبطًا ببساطة بمصدر طاقة USB لا يوفر مكبرات صوت كافية ، لكنني أرحب بإثبات أن هذا ليس هو الحال. كاختبار ، حاول توصيل كابل USB بمحول أمبير أعلى ، خاصة إذا كان يمكنك إعادة إظهار المشكلة بسهولة. "}] ،" الإجراء ": {" الاسم ":" عرض المشكلة "،" url ":" https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753 "}}}
[
{
"context": " http://schema.org "،
"type": "EmailMessage"،
"المحتملة": {
"type": "ViewAction"،
"الهدف": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753" ،
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -480547753"،
"الاسم": "عرض المشكلة"
} ،
"الوصف": "عرض هذه المشكلة على GitHub"،
"الناشر": {
"type": "Organization"،
"الاسم": "جيثب"،
"url": " https://github.com "
}
}
]

ما زلت أواجه المشكلة ، ولكن ليس كثيرًا - ربما بضعة أسابيع - ولم يعد بإمكاني تحفيزها بشكل موثوق من خلال الاتصال من أجهزة Samsung android.

أقوم بالفعل بتشغيل Pi zero w باستخدام مصدر طاقة 3A USB وكابل USB مقاس 15 سم يُستخدم لشحن powerbanks (لا توجد خطوط بيانات ، فقط خطوط طاقة)

إذا كنت أستخدم الاتصال بانتظام (مثل مستخدم عادي) ، فإنه يعمل بشكل جيد ، ولكن إذا قمت ببث MJPEG بسرعة 5 ميجابت في الثانية ، فإنه يتعطل بعد بضع دقائق ، وأرى بعض خطأ في صندوق البريد (أو ما شابه) في دفتر اليومية (لا أتذكر أنني خارج المنزل لمدة أسبوع) ، توقف ssh ، لا يوجد ping ، يسقط Wi-Fi ، يستغرق iwconfig بضع ثوانٍ لإظهار النتائج وهي فارغة تقريبًا.

vascojdb إذا كنت تستخدم Pi كنقطة وصول (وضع AP) ، فيجب أن يحل هذا الحل البديل (انظر النص الغامق في الأسفل) مشكلتك.

دعنا نعرف؟

لا ، ليس في وضع AP ، أنا متصل بشبكة Wi-Fi المنزلية بتردد 2.4 جيجا هرتز

مرحبا،

لدي مشكلة في wifi لمزامنة الوقت عند بدء التشغيل مع خادم NTP باستخدام LibreELEC على RPI3B + منذ الإصدار 9.0.0.
بعد بعض المناقشات مع بعض أعضاء فريق LE ( انظر هنا ) ، تم إصلاح المشكلة بعد هذا التعديل .

ولكن يبدو أنه تم التراجع عن هذا الحل وما زالت المشكلة قائمة.
هل من الممكن إصلاحه مرة أخرى؟

لا أحد للإجابة أو تصعيد هذه القضية؟

المشكلة نفسها. أي أخبار عن هذا؟

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)

حاولت إيقاف تشغيل إدارة الطاقة في الوقت الحالي. هل هذه حشرة قديمة أعيد تقديمها؟

https://patchwork.kernel.org/patch/9948825/

المشكلة نفسها. أي أخبار عن هذا؟

هذه الرسالة تقول فقط أن البرنامج الثابت لشريحة wifi قد تعطل. لا يوجد شيء يمكن لـ Linux kernel القيام به باستثناء إعادة التعيين. يحتوي تقرير خطأ مفيد على المعلومات التالية:

ما هي البرامج الثابتة wifi التي تستخدمها؟
كيف تقوم بتشغيل الواي فاي (AP ، العميل ، ...)؟
هل يمكنك إعادة إنتاج هذا في غضون وقت محدد؟
ما هي أجهزة wifi الأخرى المعنية؟

إنه في تعليقي الأخير لأنه كان قابلاً للتكرار في ذلك الوقت ، لكن من السيئ إعادة إنتاجه والتغييرات مع تغييرات البرامج عند تعطله.

-------- Ursprüngliche Nachricht --------
فون: Stefan Wahren [email protected]
التاريخ: 01.05.2020 10:21 (GMT + 01: 00)
ج: raspberrypi / linux [email protected]
نسخة إلى: "A. Binzxxxxxx" [email protected] ، تعليق [email protected]
Betreff: Re: [raspberrypi / linux] تجمد شبكة wlan في raspberry pi 3 / PiZeroW (ليس
3B +) (# 1342)

المشكلة نفسها. أي أخبار عن هذا؟

هذه الرسالة تقول فقط أن البرنامج الثابت لشريحة wifi قد تعطل. لا يوجد شيء يمكن لـ Linux kernel القيام به باستثناء إعادة التعيين. يحتوي تقرير خطأ مفيد على المعلومات التالية:
ما هي البرامج الثابتة wifi التي تستخدمها؟
كيف تقوم بتشغيل الواي فاي (AP ، العميل ، ...)؟
هل يمكنك إعادة إنتاج هذا في غضون وقت محدد؟
ما هي أجهزة wifi الأخرى المعنية؟

- أنت تتلقى هذا لأنك علّقت. قم بالرد على هذا البريد الإلكتروني مباشرةً ، أو قم بعرضه على GitHub ، أو قم بإلغاء الاشتراك.
[
{
"context": " http://schema.org "،
"type": "EmailMessage"،
"المحتملة": {
"type": "ViewAction"،
"الهدف": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815" ،
"url": " https://github.com/raspberrypi/linux/issues/1342#issuecomment -622296815"،
"الاسم": "عرض المشكلة"
} ،
"الوصف": "عرض هذه المشكلة على GitHub"،
"الناشر": {
"type": "Organization"،
"الاسم": "جيثب"،
"url": " https://github.com "
}
}
]

المشكلة نفسها. أي أخبار عن هذا؟

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)

حاولت إيقاف تشغيل إدارة الطاقة في الوقت الحالي. هل هذه حشرة قديمة أعيد تقديمها؟

https://patchwork.kernel.org/patch/9948825/

لا يوجد حل للتحدث عنه ، لكن لدي نفس المشكلة تمامًا على Rpi4 مع تثبيت أحدث البرامج الثابتة. أعدتها مرة أخرى إلى صورة بطاقة SD التي قمت بإنشائها قبل بضعة أشهر واختفت المشكلة. نظرًا لأنني أستخدم hostapd ، أعتقد أن إحدى هذه الترقيات أو مجموعة منها أدت إلى كسرها بالنسبة لي:

قائمة $ apt - قابلة للترقية
القائمة ...
...
hostapd / Stable 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u2 armhf [قابل للترقية من: 2: 2.7 + git20190128 + 0c1e29f-6 + deb10u1]
firmware-brcm80211 / testing 1: 20190114-1 + rpt6 all [قابل للترقية من: 1: 20190114-1 + rpt4]
raspberrypi-kernel / test 1.20200212-1 armhf [قابل للترقية من: 1.20200114-1]
...

حاولت أيضًا إيقاف تشغيل إدارة الطاقة (وأكدت أنها معطلة مع iwconfig) ، لكن لم يكن لها أي تأثير عند تشغيل hostapd. سأضطر إلى التخلي عن ترقيات البرامج الثابتة حتى يتم إصلاحها ، لأننا نرسل العديد منها ونحتاج إلى نقاط وصول ثابتة لعملائنا.

أي شخص يواجه اعتراضات البرامج الثابتة ، والمهلة (-110) وما إلى ذلك - يرجى تمكين بعض تصحيح أخطاء البرامج الثابتة حتى نتمكن من جمع بعض البيانات.

أضف brcmfmac.debug=0x100000 إلى /boot/cmdline.txt ، واحتفظ به في سطر واحد طويل ، ثم أعد التشغيل. يجب أن يؤدي تشغيل dmesg | grep brcmfmac إلى إخراج مثل هذا:

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

ثم استمر كالمعتاد. عندما يموت البرنامج الثابت brcmfmac ، التقط ناتج dmesg إلى ملف وأرفقه (أو رابط إلى pastebin ، وما إلى ذلك) هنا.

نظرًا لأن الفشل يؤدي إلى تشغيل رسائل kernel الأخرى ، فهناك خطر من فقدان الإخراج المفيد قبل أن تتاح لك فرصة التقاطه. هناك طريقة لتجنب ذلك وهي ترك shell يحفظ رسائل kernel باستمرار في ملف:

$ dmesg -w > kernel_log.txt &

رؤية نفس المشكلة هنا. سيحاول التصحيح المذكور أعلاه.

تشغيل hostapd في وضع AP و wireguard و frr. أيضا باستخدام قبعة 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

أنا قادر أيضًا على إعادة إنشاء هذا في الفرع 5.4. FWIW ، يمكنني دائمًا تشغيل هذا الخطأ يدويًا عن طريق SCPing ملف كبير (> 400 ميجابايت) إلى Pi Zero W.

إذا كان ذلك مفيدًا ، فإن إصدار kernel الخاص بي هو من هذا الالتزام - 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

سجل الأعطال مع التصحيح:

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

أثناء الانهيار أعلاه ، قمت بتشغيل ifdown و ifup الذي لم يستعيد wifi. الحل الوحيد هو إما إعادة تشغيل pi ، أو rmmod & modprobe brcmfmac.

تجدر الإشارة إلى أن هذا يحدث مع إيقاف تشغيل إدارة الطاقة ، نظرًا لأن لديّ هذا في ملف واجهاتي:

pre-up iwconfig wlan0 power off