العتاد وبرامج التشغيل.
هل بطاقتك قادرة أصلاً؟
الوحدة الأهمّ عملياً. كل النظرية تتحوّل إلى سؤال واحد حاسم: هل شريحة Wi-Fi لديك قادرة على المشاركة في AWDL؟ الجواب يعتمد على قدرتين عتاديتين فقط: Active Monitor Mode و Frame Injection.
طيف أوضاع الواجهة اللاسلكية
| الوضع | يستقبل كل الإطارات؟ | يرسل؟ | يردّ ACK تلقائياً؟ | صالح لـ AWDL؟ |
|---|---|---|---|---|
| Managed (Station) | لا (الموجّهة له فقط بعد association) | نعم | نعم (لكن بعد association) | NO |
| Passive Monitor | نعم (كل ما في الهواء) | لا | لا | NO |
| Active Monitor | نعم | نعم | نعم | YES ✓ |
| IBSS / Ad-hoc | جزئياً | نعم | نعم (ضمن خلية ad-hoc) | NO |
Passive Monitor — لماذا لا يكفي
- يلتقط كل إطارات 802.11 على القناة، حتى غير الموجّهة له. ممتاز للتنصّت والتحليل.
- لكنه لا يرسل ACK أبداً — عملية استقبال محضة.
- النتيجة: أيّ إطار يُرسَل لجهازك المُحاكى لن يُؤكَّد، فيعيد المرسل إرساله ثم يسقطه ويعتبرك غير موجود (راجع CSMA/CA في الوحدة 0). عديم الفائدة للمشاركة الحقيقية.
Active Monitor — الحدّ الأدنى المطلوب
- توسعة لوضع المراقبة: العتاد يرسل ACK عند استقباله إطاراً موجّهاً لعنوان MAC الخاص به، رغم عدم وجود association.
- هذا هو الشرط الأدنى لمشاركة برمجية (software-defined) في AWDL. بدونه يعتبرك الـ Master والأقران «غير قابل للوصول» ويتجاهلونك.
Frame Injection — حقن الإطارات
- القدرة على بثّ إطارات 802.11 اعتباطية (Data و Action) في أوقات دقيقة.
- لـ AWDL: يجب أن يكون الحقن قادراً على إرسال إطارات بـ BSSID المخصّص وترويسة AWDL الملحقة بإطارات البيانات، واحترام الفواصل الزمنية بين الإطارات.
معضلة SIFS — لماذا «لا بد» أن يكون من العتاد
هذه أهمّ فكرة في الوحدة كلّها. كما رأينا في 0.5، فجوة SIFS = 16 µs (5 GHz) هي المهلة القصوى بين نهاية الإطار المستلَم وبداية الـ ACK.
ميزانية الـ 16 ميكروثانية يجب أن تتّسع لكل هذا:
لماذا يستحيل على CPU عام تحقيق هذا؟
Interrupt latency
من وصول الإطار حتى تنبيه المعالج قد يستغرق وحده عشرات الميكروثانيات.
DMA round-trip
نقل الإطار من الشريحة لذاكرة النظام، ثم عودة الـ ACK — رحلتان عبر الناقل.
Scheduler non-determinism
تبديل سياق نظام التشغيل وجدولة المهام = عدم حتمية زمنية.
توليد الـ ACK بتوقيت SIFS لا بد أن يحدث داخل firmware/MAC processor الشريحة. لا يمكن لأي ترقيع في الـ driver أن يضيف هذه القدرة إن لم تكن آلات الحالة والمؤقتات موجودة في السيليكون نفسه.
معمارية Linux اللاسلكية (cfg80211 / mac80211 / nl80211)
لفهم «لماذا بطاقة تعمل وأخرى لا»، افهم هذه الطبقات:
- SoftMAC (مثل
ath9k): معظم منطق MAC في برنامج النواة عبرmac80211→ تحكّم دقيق منخفض المستوى، مناسب للحقن و active monitor. - FullMAC (مثل
iwlwifi،brcmfmac): منطق MAC مخبوء داخل الـ firmware → النواة «تطلب» ولا «تتحكّم»، وغالباً لا يُعرّض active monitor. - nl80211: واجهة netlink التي تستخدمها أدوات userspace (مثل
iw) للتخاطب معcfg80211.
الراية الحاسمة: NL80211_MNTR_FLAG_ACTIVE
في واجهة nl80211، يضبط السائق راية NL80211_MNTR_FLAG_ACTIVE فقط إذا كان العتاد يدعم active monitor.
عند غيابها:
- النواة لن تمرّر للجهاز أي إعداد يستدعي ACK في وضع المراقبة.
- محاولة حقن إطارات مع توقّع ACK (راية
IEEE80211_TX_CTL_REQ_TX_STATUS) ستفشل غالباً.
وجود هذه الراية في مخرجات iw phy لواجهتك = مؤشّر قاطع على توافق العتاد مع AWDL.
root@audit: ~ · check your card
# اعرض قدرات الـ PHY كاملةً
$ iw phy
# ابحث عن دعم active monitor تحديداً
$ iw phy | grep -A4 "Supported interface modes"
$ iw list | grep -i "active monitor"
# جرّب إنشاء واجهة مراقبة فعّالة (تنجح فقط إن كان العتاد يدعمها)
$ sudo iw phy phy0 interface add mon0 type monitor flags active
$ sudo ip link set mon0 up
# إن فشل إنشاء الواجهة بعلم `active`، فالعتاد غالباً غير مؤهّل.
مسح الشرائح — ما يعمل وما لا
Atheros AR9280 / ath9k
منصّة OWL المرجعية. السائق ath9k والعتاد AR9280 يطبّقان واجهة قريبة من SDR: يمكن أمر الشريحة بالبقاء في active monitor فتردّ ACK لأي إطار يطابق عنوانها بصرف النظر عن الـ association.
- Active monitor: YES
- Injection: YES
- كل تحكّم منخفض المستوى مفهوم وموثّق علناً.
Intel AX200 (مثال عام)
سائق iwlwifi لا يضبط NL80211_MNTR_FLAG_ACTIVE، والـ firmware لا يولّد ACK في وضع المراقبة. سيليكون Intel مصمّم لأدوار client/AP مع آلات حالة 802.11 كاملة، لا للتحكّم الخام.
- Active monitor: NO
- Injection: PARTIAL
- firmware مغلق.
Broadcom BCM4387 (Apple Silicon)
لا يعرّض active monitor لا تحت macOS ولا تحت Linux (Asahi). تحت Asahi: السائق المهندَس عكسياً ما زال مبكّراً ويفتقر لدعم المراقبة، فضلاً عن active monitor أو الحقن.
- M1/M2: NO ACTIVE MON
- M3/M4/M5: قيد bring-up.
- لا تعوّل على Wi-Fi المدمج في أجهزة Apple Silicon.
Broadcom + Nexmon (Raspberry Pi)
إطار Nexmon (من مختبر SEEMOO/TU Darmstadt — نفس فريق OWL) يرقّع firmware شرائح Broadcom المغلقة ليفعّل monitor mode والحقن على شرائح مدمجة.
- monitor + injection: CHECK
- active monitor + توقيت ACK: محلّ اختبار.
- تحقّق بالاختبار العملي (lab في الوحدة 5).
ابحث عن بطاقة ath9k-based (شرائح Atheros AR92xx/AR93xx) مع تأكيد دعم active monitor وinjection.
هي الخيار الأكثر ضماناً وتوثيقاً لمحاكاة AWDL.
مصفوفة قرار سريعة
| الشريحة / السائق | Active Monitor | Injection | AWDL Ready? | الملاحظة |
|---|---|---|---|---|
| Atheros AR9280 · ath9k | YES | YES | PRIMARY | المنصّة المرجعية |
| Atheros AR9380 · ath9k | YES | YES | YES | بديل ممتاز |
| Qualcomm ath10k | PARTIAL | PARTIAL | TEST | يعتمد على الـ firmware |
| MediaTek mt76 | PARTIAL | YES | TEST | تحسّن مستمر |
| Intel AX200/AX210 · iwlwifi | NO | PARTIAL | NO | FullMAC مغلق |
| Broadcom BCM4387 (M1/M2) | NO | NO | NO | Asahi غير ناضج |
| Broadcom BCM43455 + Nexmon | CHECK | YES | TEST | Raspberry Pi مدمج |
نقاط ارتكاز الوحدة 3
- شرطان عتاديان للمشاركة في AWDL: Active Monitor + Frame Injection.
- Passive monitor = تنصّت فقط (لا ACK) = لا مشاركة.
- معضلة SIFS (16 µs) تفرض أن يكون توليد ACK في firmware لا في CPU.
- SoftMAC (ath9k) = تحكّم دقيق؛ FullMAC (iwlwifi/brcmfmac) = غالباً مغلق.
- راية
NL80211_MNTR_FLAG_ACTIVEفيiw phy= اختبار الحقيقة لتوافق بطاقتك. - المنصّة المرجعية: Atheros AR9280 + ath9k.
تمارين الوحدة 3
- على جهازك، شغّل
iw phyوiw list، ووثّق: هل بطاقتك تدعم monitor؟ active monitor؟ الحقن؟ - اشرح بالأرقام لماذا حلقة برمجية في userspace لا يمكنها توليد ACK خلال 16 µs (قدّر زمن مقاطعة نموذجي على Linux).
- قارن SoftMAC و FullMAC من حيث: مرونة التحكّم، الأمان، استهلاك المعالج، ملاءمتهما لمحاكاة AWDL.