GELÖST -> 9.0.0RU2 1781VAW->WiFi->HwBusy no BlockACK state E

Forum zur aktuellen LANCOM Router Serie: LANCOM 1781A, LANCOM 1781AW, LANCOM 1781EW, LANCOM 1781EF, LANCOM 1631E, LANCOM 831A und VPN Gateways: LC-9100 VPN, LC-7100 VPN, LC-8011 VPN, LC-7111 VPN und LC-7011 VPN

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
joeMJ
Beiträge: 358
Registriert: 18 Feb 2005, 22:03
Wohnort: Krefeld/NRW
Kontaktdaten:

GELÖST -> 9.0.0RU2 1781VAW->WiFi->HwBusy no BlockACK state E

Beitrag von joeMJ » 29 Okt 2014, 00:48

Thema ist gelöst. Es liegt (mal wieder) nicht an Lancom, sondern an Apple.

Moin,

eigentlich wollte ich mich gerade um ein Verständnisproblem mit Scripten und um die Hilfe von Alfred diesbezüglich kümmern, aber bei mir knallt's mit der 9.0R2 im WiFi mit OSX auf diversen Geräten. Ich hatte das ja schonmal berichtet. Der WiFi Accesspoint ist im Greenfield auf 5GHz (automatisch) auf Kanal 36 unterwegs.


Der Fehler trat in der 8.84 nicht auf. Mit 8.84 hatte ich nach Dr. Einsteins Anleitung ein wirklich sehr gutes Ergebnis, keine Verbindungsabrisse.

Wenn ein OSX-Gerät in der 9.0.0 RU2 hineinspaziert, wird das Trace geflutet von diesen Meldungen, die ich nicht zuordnen kann:

-> xWLanAggrTxHandle to b8:e8:56:1a:34:16 TID 6 HwBusy no BlockACK state Error

Code: Alles auswählen

[WLAN-AGGREGATION] 2014/10/28 23:43:02,220  Devicetime: 2014/10/28 23:43:02,075
xWLanAggrTxHandle to b8:e8:56:1a:34:16 TID 6 HwBusy no BlockACK state Error
--> BlockACK negotiation failed, send as non-aggregated packet
Zuletzt geändert von joeMJ am 30 Okt 2014, 21:28, insgesamt 6-mal geändert.
Cheers,
Joe

Benutzeravatar
joeMJ
Beiträge: 358
Registriert: 18 Feb 2005, 22:03
Wohnort: Krefeld/NRW
Kontaktdaten:

Re: 9.0R2 1781VAW->WiFi->HwBusy no BlockACK state Error

Beitrag von joeMJ » 29 Okt 2014, 01:24

Anbei mal ein Screenshot aus dem Trace zum Vergleich von zwei unterschiedlichen Geräten.
Dateianhänge
Bildschirmfoto 2014-10-29 um 00.16.08.png
Bildschirmfoto 2014-10-29 um 00.16.08.png (189.42 KiB) 1438 mal betrachtet
Zuletzt geändert von joeMJ am 29 Okt 2014, 03:16, insgesamt 1-mal geändert.
Cheers,
Joe

Benutzeravatar
joeMJ
Beiträge: 358
Registriert: 18 Feb 2005, 22:03
Wohnort: Krefeld/NRW
Kontaktdaten:

Re: 9.0.0RU2 1781VAW->WiFi->HwBusy no BlockACK state Error

Beitrag von joeMJ » 29 Okt 2014, 03:05

Scheint Frame-Aggregation zu sein. Nach Deaktivierung verschwinden die o.g. Fehlermeldungen und die Macs fliegen nicht mehr so schnell raus. Stattdessen bekomme ich nur noch:

Code: Alles auswählen

[WLAN-STATUS] 2014/10/29 02:11:14,637  Devicetime: 2014/10/29 02:11:15,025
WLAN-1: 2 beacon(s) not picked up (XX-------)
Tralala
LastSubmit 100, LastCleanup 184, LastStop 38491, LastStart 38487)
current modem load is 3%
BB hang detect: BB state still changing, no hang, BB panic status 0x00000000
^^Dürfte wohl das Problem für den Terror in Sachen Frame Aggregation sein.
Hrrgs. Auf jeden Fall schon mal besser mit den Apple Produkten. Nachsatz: Ein Amazon Kindle (darf ich melden) macht übrigens den selben Blödsinn.

Fehler trat nicht auf in 8.84
Cheers,
Joe


Benutzeravatar
joeMJ
Beiträge: 358
Registriert: 18 Feb 2005, 22:03
Wohnort: Krefeld/NRW
Kontaktdaten:

Re: 9.0.0RU2 1781VAW->WiFi->HwBusy no BlockACK state Error

Beitrag von joeMJ » 30 Okt 2014, 21:27

Ist definitiv der Fall. Bin gerade erst im HomeOffice angekommen. Der Tag war heute die reinste Hölle.
Deswegen. Bei Ubiquiti ist es noch schlimmer, hier war teilweise Hilfe seitens POE gefragt oder eine Leiter. Und ich muss mich korrigieren, der Fehler tritt auch in 8.84 auf, jedoch seltener bzw. später.

Alfred hatte auf dem Anwendertreffen (wie immer) recht.

-> http://www.johnlose.de/?p=3124
Cheers,
Joe

Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6020
Registriert: 07 Nov 2004, 20:33
Wohnort: Aachen
Kontaktdaten:

Re: GELÖST -> 9.0.0RU2 1781VAW->WiFi->HwBusy no BlockACK sta

Beitrag von alf29 » 31 Okt 2014, 15:51

Moin,

Diese Meldungen im WLAN-Aggregation Trace bedeuten schlicht, daß die Gegenseite die Benutzung von Frame-Aggregierung abgelehnt hat und das LCOS fürderhin bis zum Ende der Verbindung alle Pakete auf dieser Prio-Stufe weiterhin als einfache, nicht aggregierte Pakete schickt. Wäre die Frame Aggregierung erfolgreich ausgehandelt worden, dann würde man auch pro Paket eine Meldung in diesem Trace bekommen, nur eine andere ;-)

Frame-Aggregierung ist bei 802.11n eine optionale Eigenschaft, eine Gegenstelle kann die Verwendung auch ablehnen. Üblicherweise unterstützt sie aber jedes 802.11n-Gerät, weil ohne sie der Overhead pro Paket so hoch ist, daß eine 11n-Verbindung kaum schneller ist als eine mit 54 MBit. Ob in diesem Fall der Client den Request vom LANCOM echt abgelehnt hat oder schlicht keine Antwort kam, kann ich nicht sagen.

Die Meldungen mit den Beacons sind ein anderes Thema und in der Tat ein unerfreuliches, weil das eigentlich nur ein Symptom ist und verschiedenste Ursachen haben kann. Störungen auf dem Medium sind eines, irgendwelche kaputten Pakete, die den WLAN-Chip zum Absturz bringen, ein anderes. Hier aus der Ferne eine Empfehlung zu geben, woran es liegt, ist leider sehr schwierig. Man kann mal probieren, in den Radio-Einstellungen PHY-Restarts auszuschalten, der Osprey (AR93xx) ist dafür bekannt, sich bei so etwas bisweilen zu verschlucken. Ist aber wie gesagt nur eine von vielen Möglichkeiten.
Der WiFi Accesspoint ist im Greenfield auf 5GHz (automatisch) auf Kanal 36 unterwegs.
Wie ich an anderer Stelle schon geschrieben hatte, packt LCOS 9.x im Greenfield-Modus ein bestimmtes Protokollelement in die Beacons, mit dem laut Standard den Clients gesagt wird, daß 11n-Support für Anmeldung an dieser Funkzelle erforderlich ist. Leider kennen nicht alle Clients dieses Element und es kann sich lohnen, anstatt des Greenfield-Modus mal 11an-mixed bzw. 11gn-mixed zu probieren. Irgendwelche Performance-Einbußen für 11n-Verbindungen ergeben sich daraus nicht, da das nicht wie seinerzeit bei der Koexistenz von 11b/11g irgendwelche teuren Protection-Mechanismen einschaltet. Greenfield ist eher etwas, wenn man aus irgendwelchen 'politischen' Gründen keine 54MBit-Clients mehr haben will.
Alfred hatte auf dem Anwendertreffen (wie immer) recht.
Wenn das der Fall wäre, würde ich nicht mehr hier sitzen ;-)

Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015

Benutzeravatar
joeMJ
Beiträge: 358
Registriert: 18 Feb 2005, 22:03
Wohnort: Krefeld/NRW
Kontaktdaten:

Re: GELÖST -> 9.0.0RU2 1781VAW->WiFi->HwBusy no BlockACK sta

Beitrag von joeMJ » 31 Okt 2014, 19:00

Du hast mit dem Thema Greenfield übrigens auch recht... Nur mal so ;-)

Die Lancom-Hotspots haben sie ja gotseidank nicht zum Absturz gebracht, jedoch den "Mitbewerber"... Da wird übrigens nach der Aktion von gestern getauscht, POE kommt da dann auch. Ich werde nicht noch einmal mit meinem Gewicht auf wackelige Leitern klettern.
Cheers,
Joe

Benutzeravatar
maiki
Beiträge: 261
Registriert: 12 Jul 2006, 20:50
Wohnort: zu Hause
Kontaktdaten:

Re: GELÖST -> 9.0.0RU2 1781VAW->WiFi->HwBusy no BlockACK sta

Beitrag von maiki » 31 Okt 2014, 22:06

Guten Abend an alle,

wie in einem anderen Thread schon geschrieben, gibt es seit heute gibt es die 9.00RU3 auf dem FTP Server. Wir können also kräftig testen...

Grüße

Maik

Benutzeravatar
joeMJ
Beiträge: 358
Registriert: 18 Feb 2005, 22:03
Wohnort: Krefeld/NRW
Kontaktdaten:

Re: GELÖST -> 9.0.0RU2 1781VAW->WiFi->HwBusy no BlockACK sta

Beitrag von joeMJ » 31 Okt 2014, 22:57

Können wir den hier schließen und auf den anderen Thread verweisen?
-> http://www.lancom-forum.de/aktuelle-lan ... 13784.html
LG
Joe
Cheers,
Joe

Antworten
  • Vergleichbare Themen
    Antworten
    Zugriffe
    Letzter Beitrag

Zurück zu „aktuelle LANCOM Router Serie“

Wer ist online?

Mitglieder in diesem Forum: sunny9999 und 5 Gäste