Multicasts werden zeitweise nicht mehr übertragen

[thomasgiger]

Wir haben hier im Office eine "Testbasisstation" bestehend aus einem L54ag im 5.4 GHz, die seit Anfang letzter Woche mit der FW 6.10 betrieben wird.

In dieser Zeit passierte es nun 2x, dass das L54ag das OSPF Multicast IP Protokoll 89 nicht mehr übertragen hat. Der Effekt scheint zeitlich begrenzt zu sein, denn beim ersten Mal verschwand er nach etwa einer Stunde, ohne dass wir das L54ag als Schuldigen entlarven konnten.

Heute hielt der Effekt dagegen lang genug an, dass wir alle anderen Fehlerquellen ausschalten konnten und letztlich nur mehr das L54ag übrig blieb. Ein Warm-Boot über das Webinterface machte das L54ag wieder für OSPF Multicasts durchgängig, was an sich schon Beweis genug ist.

Ich würde ja gerne auch traces etc. beisteuern, aber das kann erst bei einer Wiederholung passieren und wenn ich genau weiss, was eingefangen werden soll.

[thomasgiger]

Noch ein Hinweis: Mit der FW 5.04, die wir lange am L54ag laufen hatten, ist das OSPF Multicast Problem übrigens nie aufgetreten. Mit der FW 6.06 auch nicht, aber die war nicht besonders lange im Einsatz.

[alf29]

Moin,

sind auf der anderen Seite Clients oder P2P-Partner?

Bei P2P-Strecken würde mich so etwas ziemlich wundern, denn dort
laufen alle Pakete (egal ob Unicast oder Multicast) WLAN-mäßig als
Unicasts und sind damt durch Retries zumindest einigermaßen gesichert.

Bei Verbindungen zu Clients hingegen gehen Multicasts wirklich als
solche aufs Funkmedium, und damit entfällt sowohl die Sicherungsschicht
durch Retries als auch eine automatische Senderatenanpassung.
Aussetzer bei Verschlechterung des Funkkanals (wie lang ist so ein
OSPF-Paket eigentlich?) können daher nicht kompensiert werden. Daß
es nach einem Reboot wieder geht, könnte schlicht daran liegen, daß
das Gerät sich wegen DFS einen anderen Kanal gesucht hat. Einen
unmittelbaren Zusammenhang mit der Firmware-Version sehe ich nicht,
das sind WLAN-Basics...

Gruß Alfred

[thomasgiger]

Das ist durchaus eine Erklärung. Dieser AP arbeitet ausschließlich mit Clients, kein P2P. Die OSPF Multicasts sind kürzer als 200 Byte. Interessanterweise kamen sie vom Client über den AP zu den OSPF Partnern am LAN-Interface des AP durch, aber nicht vom LAN ins WLAN - und zwar nicht ein einziges.

Letzteres spricht doch etwas gegen die Erklärung, denn um das herauszufinden, habe ich mich über das WLAN auf einen der (Linux) Clients eingeloggt und ein tcpdump gemacht. Diese TELNET Session besteht zwar aus Unicasts, lief aber ohne Probleme im WLAN ... damit meine ich, dass falls Multicasts mit 200 Bytes wegen schlechter Verbindung NIE durchkommen, man das auch in der TCP Session mit Unicasts an deutlichen "Hängern" merken sollte (üblicherweise).

Eine Idee hätte ich aber noch: Der AP und die Clients verwenden AES. War da nicht etwas in der Richtung, dass Broadcasts (und Mutlicasts?) einen anderen Schlüssel benutzen als Unicasts? Könnte der unabhängig vom Unicast-Schlüssel gestört gewesen sein?

[alf29]

Moin,

Interessanterweise kamen sie vom Client über den AP zu den OSPF Partnern am LAN-Interface des AP durch, aber nicht vom LAN ins WLAN - und zwar nicht ein einziges.

Multicasts, die von einem Client ausgehen, werden WLAN-mäßig als Unicasts an den AP
geschickt, und der spiegelt sie als Multicasts wieder in die Funkzelle zurück (sofern die
Kommunikation von Clients untereinander nicht abgeschaltet ist). Paßt also
schon ins Bild...

Eine Idee hätte ich aber noch: Der AP und die Clients verwenden AES. War da nicht etwas in der Richtung, dass Broadcasts (und Mutlicasts?) einen anderen Schlüssel benutzen als Unicasts? Könnte der unabhängig vom Unicast-Schlüssel gestört gewesen sein?

Das ist korrekt, Multicasts benutzen den vom AP festgelegten Gruppenschlüssel. Von
derartigen Störungen habe ich aber bisher nichts gehört. Ich denke, ohne einen
WLAN-Trace in dieser Situation ist alles weitere nur Spekulation.

Gruß Alfred

[stefan.winter]

Das ist korrekt, Multicasts benutzen den vom AP festgelegten Gruppenschlüssel. Von
derartigen Störungen habe ich aber bisher nichts gehört. Ich denke, ohne einen
WLAN-Trace in dieser Situation ist alles weitere nur Spekulation.

Hallo,

hatte in den letzten Tagen mehrfach ein ganz ähnliches Problem mit Multicasts. L-54g, 6.06, WPA2-Enterprise-AES. Am AP hängen nur Clients, keine P2Ps.
Beim Besuch von einigen (unabhängig voneinander) Multicast TV-Programmen (jeweils ca. 1.5 MBit/s Bandbreite) taucht ein seltsames Phänomen auf: ein Teil der Pakete geht durch, es langt immer für den Audioteil und ab und zu mal ein Bildchen (Diashow-mäßig); der meiste Teil der Daten geht aber verloren. Nach etwa 10s leuchtet dann die WLAN Data Statusleuchte am L-54g _konstant_, für etwa eine Minute lang. In der Zeit geht gar nix mehr. Noch nicht mal über Telnet vom LAN aus - keine Reaktion. Nach etwa einer Minute geht er dann wieder, die Verbindung zum Stream ist gekappt, manchmal werden die Clients disassociated.

Sieht für mich so aus, als ob der größere Teil der Pakete irgendwo im AP in einer Queue hängenbleibt und diese verstopft.

Ein trace + wlan kann ich gerne liefern, zumindest bis zu dem Moment wo der AP noch nicht mal mehr auf Telnets reagiert. Ist ein reproduzierbares Problem.

Andere Fehlerquellen sind ziemlich ausgeschlossen, wenn man den Client direkt an den Switch hängt wo sonst der AP hängt geht alles einwandfrei.

Grüße,

Stefan Winter

[alf29]

Moin,

Die Datenrate, mit der Multicasts in die Funkzelle übertragen
werden, steht defaultmäßig bei 2 MBit (aus Kompatibilitäts-
gründen). Ein Multicast-Stream mit 1,5 MBit/s frißt fast die
gesamte Nettodatenrate auf, die man bei 2MBit brutto
erreicht (knapp über 1,6 MBit/s) - damit ist das Medium
dann aber auch quasi zu und daß kaum noch etwas anderes
funktioniert, ist kein großes Wunder - da laufen nach
und nach alle Queues voll...

Eine schnelle Abhilfe könnte sein, die Basic-Rate im AP
auf 11MBit hochzustellen, 2MBit-Clients wird man in den
meisten Netzen heute wohl nicht mehr finden. Aber wenn
die Multicast-Rate in den Bereich von 5MBit/s kommt, gehen
die Probleme wieder los...

Gruß Alfred

[joeMJ]

Hi Alf,
könnte das der Grund sein dass mir teilweise fehlendes DHCP an manchen L54AG oder am 1821 das Leben schwer macht? -> Gleiche FW oder 6.14 auf 1821.

[alf29]

Moin,

das hängt davon ab, ob DHCP-Antworten als Broadcasts an die Clients gehen. LANCOMs
verschicken die Antworten defaultmäßig immer als Broadcast, um Fehler in einigen Windows-
Versionen zu umgehen, dafür gibt es aber einen Schalter im DHCP-Setup. Die Clients können
aber immer noch explizit Broadcast-Antworten anfordern.

Gruß Alfred