WLAN Lancom <> Apple

[Avalanche]

Gibt es im Moment Bestrebungen, die Kompatibilität zwischen Lancom APs und Apple Geräten zu verbessern? Es gab in letzter Zeit ja einige Threads (1, 2 und 3) zu diesem Thema, allerdings sind mindestens unsere Probleme durch die Konfigurationsempfehlungen nicht vollständig behoben.

Durch diese Einstellungen ist die Situation schon wesentlich besser geworden aber die Probleme immer noch nicht vollständig behoben. Zusätzlich steht natürlich im Raum, wie sich die Änderungen (z.B. Frame Aggregation) auf die Performance der WLAN-Verbindung oder den Stromverbrauch der Geräte (Powersave) auswirken. In unregelmäßigen Abständen bricht bei Clients die WLAN-Verbindung ab. Am Laptop/iPad/iPhone wird WLAN-Empfang angezeigt und auch die Layer3 Konfiguration sieht gut aus (DHCP, Routen, usw.) dennoch ist keine Datenübertragung möglich. Erst nach einem Trennen und Neuverbinden des WLANs funktioniert es wieder. Letztens ist dies z.B. bei einem Laptop passiert, das über Nacht auf einem Schreibtisch stand. Das ist natürlich sehr unbefriedigend und durch das unregelmäßige Auftreten schwer zu diagnostizieren. Die in [3] beschriebenen Probleme sind hier glücklicherweise noch nicht aufgetreten, da noch kein 10.10 im Einsatz ist. Das wird sich in den nächsten Wochen sicherlich noch ändern. Wie kann ich vorgehen, um der Ursache auf die Spur zu komen?

Lancom Hardware ist nicht gerade im Billigsegment angesiedelt, solche Unverträglichkeiten dürften also eigentlich nicht vorkommen. Sind Apple Geräte für Lancom kein Thema?

[alf29]

Moin,

sind sie schon, aber ohne Nachstellmöglichkeit hier bei LANCOM sind diese Probleme kaum zu adressieren - wenn irgendein Kunde etwas von abreißenden oder hängenden Verbindungen mit diesen oder jenen (Apple-)Clients erzählt, kann ich als Entwickler, der diese Clients nicht hat, damit wenig machen.

Auch wir haben in den letzten Wochen mit den Apple-Clients rumprobiert, die wir da haben, und ein, zwei Probleme identifiziert und gelöst, die im nächsten LCOS-RU berücksichtigt werden. Ob das alle Apple-Probleme löst, möchte ich bezweifeln, ein nennenswerter Teil der Probleme scheint nicht auf LCOS-Seite zu liegen. Ich selber habe privat als einzigen Apple-Client ein IPad 3 an einem 1781AW, und das läuft ohne Probleme - ich habe aber bisher auch jegliche Upgrades auf IOS 8 abgelehnt...

Gruß Alfred

[Avalanche]

Testhardware sollte ja für einen Hersteller wir Lancom kein Problem sein. Apple Geräte sind ja doch recht verbreitet, so dass ihr doch die gängigsten Geräte in Euren Tests vermutlich eh schon abdecken solltet.

Um es etwas konkreter zu machen: Wie könnte ich die Probleme weiter eingrenzen? Ich würde gerne mehr als diese vage Aussagen liefern, aber leider sind sie nicht auf Knopfdruck reproduzierbar...

[alf29]

Moin,

Testhardware sollte ja für einen Hersteller wir Lancom kein Problem sein. Apple Geräte sind ja doch recht verbreitet, so dass ihr doch die gängigsten Geräte in Euren Tests vermutlich eh schon abdecken solltet.

Tja, sollte man meinen, ist aber nicht zwingend so. Jedesmal wenn Apple ein halbes Dutzend neuer Geräte rausbringt, die alle zu kaufen, geht schon ziemlich ins Geld und gibt Gezeter von Management, was das alles wieder kostet. Ich würde grob schätzen, in der QS-Abteilung von LANCOM gibt's vielleicht 2..3 Macbooks. Mit Thinkpads dagegen können wir werfen, das sind die Notebooks, die hier firmenintern in der Breite eingesetzt werden, genauso wie Blackberries als Dienst-Handys. Bei IOS sieht das durch Privatgeräte vielleicht etwas besser aus, ist aber auch weit davon entfernt, das Apple-Portfolio irgendwie systematisch abzudecken.

Und das müßte ja irgendjemand in der QS auch noch regelmäßig testen. Die Leute sind auch schon so zu 150% zu...

Mir privat geht Apple übrigens ziemlich am Allerw... vorbei. Apple macht nette und stabile Hardware, aber mit diesem 'Goldenen-Käfig'-Ansatz der Software bin ich als Linux-Benutzer ganz und gar nicht einverstanden. Ich hatte mal einen Macbook zum Testen bekommen, auf den habe ich im Urlaub mal versucht, eines meiner privaten Programmierprojekte zu portieren. Dabei habe ich einen derartigen Haß auf OSX bekommen, daß das Gerät in die QS gewandert ist (wer ein bisserl im Netz sucht, wird der Erfahrungsbericht finden). Das IPad habe ich auch nur, weil ich's geschenkt bekommen habe. Selber würde ich nie und nimmer einige Hunderter für ein Gerät ausgeben, das ich nur über ein proprietäres ITunes-Gedöns mit Inhalten füllen kann, anstatt es einfach an den PC zu klemmen, wo es sich dann schlicht als USB-Massenspeicher meldet..

Um es etwas konkreter zu machen: Wie könnte ich die Probleme weiter eingrenzen? Ich würde gerne mehr als diese vage Aussagen liefern, aber leider sind sie nicht auf Knopfdruck reproduzierbar...

Üblicherweise sammelt der Support vom Kunden im Fehlerfall möglichst viele Informationen (Statustabellen, Traces) ein und jemand versucht dann hier, sich auf die Sache einen Reim zu machen. Wenn man dann etwas findet, was das LANCOM nicht richtig macht, kann man das fixen und dann geht's in die nächste Iteration. Gerade bei dem Apple-Thema landet man aber öfters an dem Punkt, wo man auch nach mehrmaligem Studium der Traces einfach sagen muß, das LANCOM verhält sich nach den Regeln des IEEE802.11-Standards korrekt und daß keine Daten laufen, liegt einfach daran, daß der Apple-Client die Daten nicht abholt oder sie sogar bei ihm ankommen, aber dann wohl irgendwo im IOS versacken...

Gruß Alfred

[joeMJ]

Ich kann mir momentan schwer vorstellen, dass Lancom hier etwas falsch macht, da wir die Probleme auch mit anderen Lösungen hatten. Die sind teilweise sogar abgeschmiert, Lancom nicht. Hauptsächlich half bei uns Frame-Aggregation abzuschalten und die U-APSD/WMM Funktion zu deaktivieren. Die ehemalige Geschwindigkeit kriegen die Anwender jedoch nicht zurück. Da fehlt mir bis jetzt eine Lösung. Bei mir hat sich das dummerweise mit dem Update auf 9 überschnitten.

BTW ich hab' hier noch ein MacBook Pro über, das fahre ich sogar gerne höchstpersönlich nach Würselen

[maiki]

Guten Abend an alle,

seit heute gibt es die 9.00RU3 auf dem FTP Server. Wir können also kräftig testen...

Grüße

Maik

[joeMJ]

RU3:

Es hilft jetzt nicht mehr, die Frame-Aggregation auszuschalten. Die Macs funken 10 Sekunden und dann geht's los. Fehler jetzt mit und ohne Frame Aggregation. Allerdings ist am Wochenende mein Testfeld kleiner. Ich habe nur einen 1781VAW und keinen WLC samt jeder Menge Accesspoints...

[joeMJ]

... Hab' dann nochmal die 8.84 reingeworfen... Yosemite Problem lässt sich mit Deaktivieren von W/MM und Frame-Aggregation lösen, aber - Ich bekomme jetzt wieder vollen Bumms...

[alf29]

Moin,

Es hilft jetzt nicht mehr, die Frame-Aggregation auszuschalten.

Also wenn Du die Trace-Meldungen in dem Bild kriegst, dann hast Du Frame-Aggregation offensichtlich nicht abgeschaltet - die fraglichen Teile im LCOS, die solchen Meldungen erzeugen, werden nämlich gar nicht mehr angesprungen, wenn Frame Aggregation in Senderichtung aus ist...wichtig - es gibt zwei Schalter für die Aggregierung: einen für die Senderichtung (soll das LANCOM Aggregate an andere schicken) und einen für die Empfangsrichtung (soll das LANCOM Aggregate von anderen annehmen).

Die von Dir hervorgehobene Meldung ist völlig normal. Das heißt einfach nur, daß das LANCOM keine Veranlassung sieht, Aggregierung in Senderichtung auszuhandeln, weil zu wenig Durchsatz ansteht. Ein paar Zeilen später steht dann 'HwQue busy', da steht dann genug Traffic an und das LANCOM versucht, die Aggregierung auszuhandeln. Das ist dann offensichtlich schief gegangen, und der zeitliche Anstand ist so kurz, daß der Apple-Client die Aggregierung wohl hart abgelehnt und nicht einfach gar nicht geantwortet hat. So eine Ablehnung kommt üblicherweise mit einem Fehlercode, den sieht man aber nur im WLAN-Data-Trace, als Statuscode des sog. ADDBA Response.

Ich bin übrigens die nächsten zwei Woche in Urlaub. Meine Vertretung (siehe Foto) wird vermutlich nicht allzuviel an dem Thema tun - sie besticht mehr durch ihr gutes Aussehen und ihre Fähigkeit zum Zuhören...



Gruß Alfred

[marsbewohner]

Moin,

also ein Testupload auf einem L-460agn hat es das Device erst mal ins Nirwana geschossen, ohne Power-Reboot ging da nichts mehr... leider zeigt das Boot-Log nichts, ich werde das mal ein bisschen beobachten...

Gruß,

@Alfred: schönen Urlaub!

[joeMJ]

@Alfred 1. Schönen Urlaub! 2. Ja, das war der Trace mit Frame Aggregation...

... Habe mich dann heute morgen mal in die Nähe von ein paar betreuten Accesspoints bewegt... um das mal zu testen.

Was mir in meiner Konfiguration noch aufgefallen ist: Das Fehlverhalten kann ich schneller provozieren, wenn ich mit ALT auf das WiFi Symbol beim Mac klicke, um mir die erweiterten Informationen anzuzeigen. Das schräge ist auch noch: Das Problem entsteht wesentlich schneller, wenn in den gleichen Hotspot noch iOS Geräte eingebucht sind. Da ich das aber jetzt nunmal überhaupt nicht mehr nachvollziehen kann (Magie? Wetterfühligkeit? Schlecht geschlafen?) - Warum beeinflussen die iOS Geräte das denn jetzt? Hat das was mit diesem neuen Feature für Facetime und Nachrichten zu tun?

Egal. Inzwischen habe ich eine halbwegs stabile Konfiguration mit RU3 und einem einzelnen 321 gefunden, allerdings nicht mit der Performance wie zuvor in 8.84. Dabei begrenze ich die Kanäle auf die oberen 52-64. Die Frame Aggregation und U-APSD -> und STBC und LDPC ist aus.

Ich habe dieses physikalische Profil jetzt so noch nicht in den WLCs angelegt, da hier Kanäle physikalisch Kanäle schon vordefiniert sind und ich nicht weiß, ob er das so übernimmt oder wieder überschreibt. Hier muss ich mich noch einlesen, wieso da Kanäle schon drinstehen. So lange beschäftige ich mich ja noch nicht mit den WLC's.

Bin jetzt wieder zurück in Krefeld und probiere das an meinem VAW mit RU3 aus, und siehe da, es funktioniert - leider mit der gleichen "mauen" Geschwindigkeit... aber immerhin.

Der Client empfängt jetzt mit 54M und sendet mit deutlich mehr.Jetzt schreibt Alfred ja, dass man zwei Schalter für Frame-Aggregation hat, einmal in Senderichtung und einmal in Empfangsrichtung. Ich finde jedoch nur einen Schalter im Webconfig und Lanconfig. Wo genau ist der andere Schalter?

Damit kann ich erst mal leben. So viele Macs haben wir ja selber nicht (nur ich), jedoch teilweise unsere Kunden. Gottseidank können viele noch gar nicht auf Yosemite aktualisieren, da viele Treiber von RME, AVID und Motu ja auch noch nicht verfügbar sind.

[alf29]

Moin,

Was mir in meiner Konfiguration noch aufgefallen ist: Das Fehlverhalten kann ich schneller provozieren, wenn ich mit ALT auf das WiFi Symbol beim Mac klicke, um mir die erweiterten Informationen anzuzeigen. Das schräge ist auch noch: Das Problem entsteht wesentlich schneller, wenn in den gleichen Hotspot noch iOS Geräte eingebucht sind. Da ich das aber jetzt nunmal überhaupt nicht mehr nachvollziehen kann (Magie? Wetterfühligkeit? Schlecht geschlafen?) - Warum beeinflussen die iOS Geräte das denn jetzt? Hat das was mit diesem neuen Feature für Facetime und Nachrichten zu tun?

keine Ahnung, was das OSX macht, wenn man da drückt...zumindest früher auf dem MacBook konnte man ziemlich viel Ärger provozieren, wenn man während einer Übertragung die Dropdown-Liste verfügbarer Netze aufgerufen hat. Dann hat der Client auch mitten in einer vollen Übertragung dem AP gesagt, er würde jetzt schlafen gehen und der AP möge die in der Zwischenzeit auflaufenden Pakete doch zwischenpuffern...was bei einem mit 450 Mbit laufenden Download auch nur für einen Sekundenbruchteil sämtliche Puffer im AP sprengt...

Jetzt schreibt Alfred ja, dass man zwei Schalter für Frame-Aggregation hat, einmal in Senderichtung und einmal in Empfangsrichtung. Ich finde jedoch nur einen Schalter im Webconfig und Lanconfig. Wo genau ist der andere Schalter?

Auf der CLI bzw. dem LCOS-Menübaum direkt neben dem ersten. Der fürs Empfangen von Aggregaten hat es wohl bisher nicht ins LANconfig geschafft. Der fürs Schalten der Empfangsrichtung wird in der Praxis auch eher selten gebraucht.

Schönen Urlaub!

Danke!

Gruß Alfred

[fildercom]

@ Alfred:
Schönen Urlaub und erhol' dich gut vom alltäglichen "WLAN-Stress"!

[maiki]

also ich habe mit der 9.00RU3 folgender Erkenntnisse gesammelt:

L320agn 5GHz -> IOS 8.1 und MacOS X 10.10 -> o.k

L1310acn 2,4GHz-> IOS 8.1 und MacOS X 10.10 -> o.k.

L1310acn 5GHz-> IOS 8.1 und MacOS X 10.10 -> nicht o.k.

[Nachtrag]
1780EW-4G 5GHz -> IOS 8.1 und MacOS X 10.10 -> o.k

ich werde es weiter beobachten ...

Grüße Maik

[joeMJ]

Maiki, welche Geschwindigkeit hast Du jeweils in der Empfangs- und Senderichtung auf dem OSX Client und welche Einstellungen hast Du am 320er gemacht?

@Alfred - Danke und 2. Du hast Urlaub