[SOLVED] Probleme hostapd Setup mit Apple Geräten

[schattenfell]

Hallo,

im Moment habe ich in meinem Netzwerk Probleme mit bestimmten Apple Geräten, die ich bisher nicht zuordnen bzw. beheben konnte. Vielleicht hat ja ein Leser dieses Forums bereits ähnliche Erfahrungen gemacht und kann mir den goldenen Hinweis geben. Zunächst zu meinem Setup:

-> Linux Server als Router / Access Point für alle Geräte (Debian wheezy)
-> 2 x TP-Link WDN4800 450Mbps-Wireless-N-Dualband-PCI-Express-Adapter (Atheros 802.11n PCI/PCI-E chipset) als Access Points für 2,4 GHz- und 5 GHz-Band (bridged Setup)
-> hostapd in neuester Version 1.1
-> relativ neuer Linux Kernel 3.6.9
-> Denon RCD-N7 Soundsystem mit Apple Airplay

Die Clients des Netzwerkes sind dabei relativ gemischt, was die Betriebssysteme anbelangt. Windows- und Linux-Rechner haben keinerlei Probleme bei der Internet- oder Intranet-Nutzung (full-speed bis zu 25 MB die Sekunde Datentransfer netto). Auch ein angeschlossenes Apple Macbook läuft stabil. Probleme gibt es jedoch bei folgenden Anwendungen / Clients:

-> versuche ich auf einem iPad 3 einen Radiostream zu hören, puffert dieser 10 Sekunden lang, spielt diesen dann ab und stockt danach (wird derselbe Stream auf einem Macbook oder einem Windows-Rechner gestartet, läuft er ohne Probleme)
-> versucht man Songs per Apple Airplay auf das Denon Soundsystem zu übertragen, klappt dieses wunderbar mit den Windows-Rechnern und dem Macbook, mit dem iPad 3 oder einem iPhone 4S hingegen startet die Anlage den Song für 1 Sekunde und bricht dann sofort ab (laut TCPDump werden per UDP kontinuierlich Datenpakete gesendet)

bisherige Fehlersuche:

-> die Logs (hostapd, syslog, ...) haben bisher keine konkreten Anhaltspunkte geliefert
-> Kernel und hostapd wurden auf die neuesten Versionen aktualisiert ohne Verbesserung
-> die Signalstärke wurde mit extra Antennen verbessert, aktuell haben alle Clients die volle Balkenanzahl im WLAN
-> die Apple Empfehlungen für die Konfiguration des WLAN-Access Points für Airplay wurden getestet, ohne Erfolg

Danach habe ich ich zu Testzwecken einen billigen Hardware-WLAN-Router ausprobiert. Mit diesem war es dann ohne Abbruch möglich, Songs per Apple Airplay zum Denon Soundsystem zu übertragen und das mit jedem der Geräte.

Ich vermute daher die Problematik auf hostapd Seite bzw. der WLAN Karte von TP-Link an sich mit gewissen Apple Produkten. Im Netz finden sich dazu auch diverse Threads, die jedoch nie auf mein Anwendungsszenario gepasst haben und deren Lösungsvorschläge nach Prüfung bei mir auch nichts gebracht haben.

Hat jemand bereits ähnliche Erfahrungen gemacht und vielleicht sogar eine Lösung parat? Oder kann mir jemand Tipps geben, wie man dem Fehlerteufel ggfs. etwas tiefgründiger auf die Spur kommen kann?

Danke im Voraus für alle Antworten!
Beste Grüße
Michael

[wanne]

Also mal ein paar Ideen:
- Es gibt leute, die sagen Apple geräte haben probleme mit APs, die n und g-WLAN anbiten.
- Stell mal die Verrschlüsslung auf wpa-TKIP runter. vielleicht ist das iPAD einfachzu langsam für CCMP.
- Lass hostapd im Fordergrund laufen und guck mal ob es reconnects gibt.
Ruf mal den Stream mit iPAD-Kennung von einem anderen Gerät aus auf. Die meisten Streaminganbieter ändern die Art des Streams wenn sie merken dass ein iPAD da ist. (Meist auf wesentlich kompatiblere Weise. Ich surfe auf diversen streamingseiten nur noch mit iPAD-Kennung.)

[schattenfell]

Hallo,

danke für die Hinweise, dadurch konnte ich das Problem identifizieren .

Also mal ein paar Ideen:
- Stell mal die Verrschlüsslung auf wpa-TKIP runter. vielleicht ist das iPAD einfachzu langsam für CCMP.

Selbiges hatte ich bereits in einem anderen Thread gelesen und getestet, scheinbar aber nicht ausführlich genug.

Zunächst habe ich noch einmal in der Kombination WPA2/AES mit TCPDump auf dem WLAN Interface den Airplay Traffic mitgesnifft, einmal von einem Windows-Rechner, wo alles funktionierte und einmal von einem iPhone 4S, wo es Probleme gab. Dabei fiel mir auf, dass viel weniger UDP Pakete vom iPhone 4S in Richtung Soundsystem geschickt wurden, als ob es mit der Verarbeitung nicht hinterherkam.

Daraufhin habe ich noch einmal auf TKIP umgestellt und et voilà, nun ging es auch mit dem iPhone 4S. Meines Wissens erzeugt TKIP im Vergleich zu CCMP (AES) jedoch keine so gesteigerte Prozessorlast, die zu solchen Problemen führen könnte. In Folge dessen stieß ich auf einen Bugreport bei Apple, der seit iOS6 Probleme mit AES bescheinigte, die auf mein Szenario passen (iPhone 4S und iPad 3 sind beide auf iOS6, leider habe ich kein iOS 5 Gerät mehr für einen Gegentest).

Zusammenfassend heißt das nun, als workaround zunächst über eine weitere SSID einen Access Point anzubieten, der nur auf TKIP fußt oder TKIP bei den betroffenen Clients zu erzwingen beim Handshake (AES und TKIP anbieten): natürlich mit all den Nachteilen von TKIP (maximal 54 MBit/s, reduzierte Sicherheit). Bis ein entsprechender Patch von Apple verfügbar ist, kann ich mit diesem Status quo durchaus leben.

Beste Grüße
Michael

[wanne]

Meines Wissens erzeugt TKIP im Vergleich zu CCMP (AES) jedoch keine so gesteigerte Prozessorlast, die zu solchen Problemen führen könnte.

CCMP ist wesentlich Rechenaufwendiger als TKIP. Beises wird aber meist zu großen Teilen nicht auf dem Prozessor sondern auf eigens dafür gebauter HW berechnet. Vielleicht ist schlicht die zu langsam. Ich glaube der wpa_supplicant kann ein solches Verhalten unterdrücken und alles auf der CPU-Rechen vielleicht geht das auch irgendwie auf dem iPAD.

(maximal 54 MBit/s, reduzierte Sicherheit).

ZUmindest die 54 MBit/s Grenze ist nur durch den Standard vorgegeben. Das kann der hosapd ignorieren. (Ob dann auch das iPAD damit umgehen kann weiß ich nicht.)

[ingoh]

Hallo,

... endlich mal jemand, der das gleiche Problem hat wie ich. Der Fehler tritt definitiv erst mit dem 6er IOS auf: Dauernde Verbindungsabbrüche, reconnect erst nach gut zureden, Videos können nicht abgespielt werden etc. Mit dem 5er IOS hat hier bei gleicher Hard- und Softeare auf dem AP alles wunderbar funktioniert.

Sobald ich das 11n abschalte läuft alles problemlos, aber halt mit max. 54MBit. Hardware ist ein ALIX mit AR922X (lt. lspci) und Voyage-Linux (hostapd 0.7.3).

Schöne Feiertage
Ingo

[ingoh]

Ich habe es jetzt ohne zweite SSID und mit CCMP zum Laufen bekommen

Probiere mal die folgenden Einstellungen in der hostapd.conf (Dank an OpenWrt):

Code: Alles auswählen

wmm_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
tx_queue_data3_aifs=7
tx_queue_data3_cwmin=15
tx_queue_data3_cwmax=1023
tx_queue_data3_burst=0
tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data2_burst=0
tx_queue_data1_aifs=1
tx_queue_data1_cwmin=7
tx_queue_data1_cwmax=15
tx_queue_data1_burst=3.0
tx_queue_data0_aifs=1
tx_queue_data0_cwmin=3
tx_queue_data0_cwmax=7
tx_queue_data0_burst=1.5

[schattenfell]

Super, bei mir geht es so auch wieder . An welchem speziellen Parameter lag es am Ende (rein interessehalber)?

[ingoh]

Super, bei mir geht es so auch wieder . An welchem speziellen Parameter lag es am Ende (rein interessehalber)?

Interessieren würde es mich auch - aber das habe ich nicht probiert. Da es sich um QoS Einstellungen handelt, sollte man es vielleicht auch global sehen...

Ich hatte gestern mal OpenWrt auf identischer Hardware installiert und als AP konfiguriert. Damit liefen die IOS6-Geräte einwandfrei. Dann halt die hostapd.conf von OpenWrt mit der auf dem Debian verglichen. Da ich erstmal nicht das QoS als Fehlerquelle vermutet hätte, habe ich die Einträge natürlich zuletzt übernommen.

[ZeroOne]

Vielen Dank hat bei mir auch funktioniert