Einige Erklärungen zum WLAN-Linktest

Forum: LANCOM FAQ-Bereich

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Einige Erklärungen zum WLAN-Linktest

Beitrag von alf29 »

Moin,

ab und zu tauchen Fragen zum Linktest auf, den LANCOM-APs über
die Web- bzw. CLI-Oberfläche anbieten. Hier einmal eine kurze
(?) Erklärung, wie dieser Test funktioniert und wie die Ausgaben
zu interpretieren sind.

Der Linktest basiert auf dem WMP (Wireless Message Protocol), das
ursprünglich von Agere Systems für ihre 2/11-MBit-Karten
definiert wurde. Dieses Protokoll definiert eine ganze Reihe von
Nachrichten bzw. Pakettypen, für den Linktest interessieren aber
nur zwei Nachrichen (ich habe ehrlich gesagt bisher keine
Anwendung gesehen, die etwas anderes als diese beiden
WMP-Nachrichten benutzt hätte...):

- Link Request
- Link Response

Man kann diese Pakete mit dem ICMP Echo Request/Response
vergleichen, den das Ping-Kommando nutzt, jedoch mit zwei
wichtigen Unterschieden:

- Es ist nicht IP-basiert, sondern läuft auf MAC-Ebene. Deshalb
funktioniert der Linktest auch noch, wenn die IP-Konfiguration
nicht stimmt, es ist lediglich eine auf Layer 2 'stehende'
Verbindung erforderlich.

- Ein Link Response enthält nicht einfach die zurückgespiegelten
Daten des zugehörigen Requests, der Empfänger ergänzt bzw.
ersetzt die (Dummy-)Daten durch nützliche Informationen.

Konkret sieht das so aus, daß der Empfänger eines Link Requests
die folgenden Informationen in die Antwort hineinsteckt:

- seinen Stationsnamen. Bei LANCOMs ist das der Name, den man
unter Setup->Name konfiguriert hat, bei einem (Windows-)PC
häufig der Systemname.

- Betriebsart, also Access Point oder Client

- Einige Informationen über seine WLAN-Konfiguration (AP-Dichte,
Power-Management, Verschlüsselung...). Da diese Informationen
von vielen Gegenstellen jedoch nicht eingetragen werden und auch
für sich genommen nur begrenzten Wert haben, werden sie vom
Linktest ignoriert.

- Informationen über die WLAN-Eigenschaften des empfangenen
Requests, nämlich Signalstärke, lokaler Rauschpegel unmittelbar
vor Empfang des Requests und Datenrate.

Diese Informationen werden an die anfragende Station als Link
Response zurückgeschickt. Diese wiederum hält zu jedem Link
Response dessen WLAN-Eigenschaften (also Datenrate, Signal- und
Rauschpegel) fest. Im Ergebnis ist damit der Übertragungskanal
in beide Richtungen getestet worden, und diese Informationen
werden vom Linktest auch paarweise dargestellt:

- in der ersten Zeile Signalwerte und Datenrate, mit der die
Gegenstelle(n) Pakete vom Anfrager sehen;

- in der zweiten Zeile Signalwerte und Datenrate, mit der die
anfragende Station Pakete von den (antwortenden) Gegenstellen
sieht - diese Zeile ist dementsprechend als 'lokal gesehen'
gekennzeichnet.

Aus diesem Ausführungen sollte klar sein, daß so ein Linktest
immer nur eine Momentaufnahme der Funkverbindung darstellt, die
sich aus dem Austausch von genau zwei Paketen ergibt. Die vom
LANCOM z.B. in der Stationstabelle aufgeführten Signalstärken
haben mit den Ausgaben des Linktests damit erstmal nichts zu tun,
auch wenn sich bei einer stabilen Verbindung zumindest ähnliche
SNR-Werte einstellen sollten.

Insbesondere im Zusammenhang mit der Datenrate ergeben sich immer
wieder Fragen, wieso die Ausgaben des Linktests von denen in der
Stationstabelle abweichen. Dazu ist es wichtig zu verstehen,
in welcher Form WMP-Pakete verschickt werden können:

- Link Requests können gerichtet verschickt werden, um eine
bestimmte Gegenstelle anzusprechen, sie können aber auch
als Multicast verschickt werden, um bei allen Teilnehmern
in einer Funkzelle gleichzeitig anzufragen.

- Link Responses sind immer gerichtet, nämlich an die Station,
die den Link Request gestellt hat.

Andererseits definiert WLAN gemäß IEEE 802.11 für die Übertragung
von Datenpaketen zwei Strategien:

- An eine bestimmte Station gerichtete Pakete müssen vom
Empfänger mit einem ACK-Paket bestätigt werden. Über das
Ausbleiben solcher ACKs ist es möglich, die bei dieser
Gegenstelle verwendete Datenrate automatisch der Qualität
der Funkstrecke anzupassen.

- Multicasts und Broadcasts sind an eine je nach Betriebsart
nicht genauer definierte/bekannte Anzahl von Gegenstellen
gerichtet, es ist daher nicht möglich, mit Bestätigungen
zu arbeiten. Multicasts und Broadcasts werden mit einer
(üblicherweise niedrigen) fixen Datenrate verschickt, die
bei LANCOMs als 'Basic-Rate' einstellbar ist.

Wenn von einem LANCOM ein Link Request verschickt wird, so
erfolgt dies immer als Multicast, um mit einer Anfrage auf
einen Schlag Antworten von allen Gegenstellen zu erhalten.
Damit erklärt sich, warum eingebuchte Clients bei einem
Linktest, der von einem AP aus verschickt wird, immer die
niedrigste Rate (z.B. 6 MBit auf einer 5GHz-Verbindung)
melden - diese ist schlicht die Rate, mit der sie den
Multicast-LinkRequest vom AP empfangen haben. Dies
bedeutet in keinster Weise, daß sonstige (gerichtete)
Kommunikation mit diesen Clients so langsam abläuft, die
für gerichtete Pakete ermittelte Senderate kann man in der
Stationstabelle des APs nachsehen.

Dies erklärt aber noch nicht, warum dieser Effekt nicht
auftritt, wenn man den Linktest von der Client-Seite her
anstößt. Der Grund ist, daß ein Multicast von 802.11
nicht immer als solcher übertragen wird:

Wer sich schon einmal einen WLAN-Frame in einem Sniffer
angesehen hat, wird feststellen, daß diese im Gegensatz
zu z.B. Ethernet-Paketen bis zu vier verschiedene
MAC-Adressen enthalten können. Der Grund liegt einfach
darin, daß (wie oben beschrieben) gerichtete Pakete im
WLAN bestätigt werden müssen, so daß z.B. bei einer
Punkt-zu-Punkt-Verbindung insgesamt vier Parteien an
der Übertragung beteiligt sind:

(1) der sendende Rechner im Quell-LAN

(2) der sendende Access Point der P2P-Strecke. An
diesen muß die Bestätigung geschickt werden

(3) der empfangende Access Point der P2P-Strecke.
An diesen ist das Paket im WLAN adressiert, denn
von ihm wird die Bestätigung erwartet.

(4) der Paketempfänger im Ziel-LAN.

Geht es nur um Paketübertragung von/zu einem 'einfachen'
Mobilclient, so sind (1) und (2) bzw. (3) und (4) identisch,
so daß WLAN-Frames mit nur drei Adressen genutzt werden.

Ob ein Paket vom WLAN als gerichtetes Paket oder Multi/Broadcast
betrachtet wird, wird an Adresse (3) festgemacht. Wird also ein
Link Request über eine P2P-Strecke übertragen, so ist dies zwar
ein Multicast, die Multicast-Adresse steht jedoch in Adresse (4)
und nicht in (3), so daß der Link Request von WLAN wie ein
gerichtetes Paket übertragen wird. Ähnliches gilt, wenn von
einem Client aus ein Multicast verschickt wird, dieser wandert
im WLAN erstmal gerichtet an den AP, der ihn dann als Multicast
auf seinem LAN verbreitet und u.U. auch wieder in die Funkzelle
zurückspiegelt, damit ihn andere Stationen in der gleichen
Funkzelle bekommen.

Der einzige Fall, in dem ein Multicast auch auf dem WLAN ein
solcher bleibt, sind neben von einem AP an alle Clients
ausgestrahlten Paketen Multicasts in einer sogenannten
Adhoc-Funkzelle, die ganz ohne Access Point auskommt.

Ein LANCOM, das im sogenannten 'Client-Bridge-Modus'
arbeitet, verwendetet zum Datenaustausch mit dem (LANCOM-)AP
4-Adreß-Frames und verhält sich dementsprechend wie eine
P2P-Strecke.

Wer so ein WMP-Paket mal im Detail sehen möchte, schalte in der
CLI folgenden Trace ein:

Code: Alles auswählen

  trace + wlan @ wmp (LCOS < 7.x)
  trace + wlan-data @ wmp (LCOS >= 7.x)
Wie bereits erwähnt, ist der Linktest ursprünglich eine Erfindung
von Agere. WLAN-Karten mit Agere-Chipsatz erledigen die Antwort
auf Link Requests direkt in der Kartenfirmware, bei LANCOMs mit
2MBit- oder 54/108MBit-WLANs übernimmt dies die Firmware im
Access Point selber. Leider hat WMP keine darüber hinaus gehende
Verbreitung bei anderen Herstellern gefunden und die
IEEE-Standards haben bisher auch kein Protokoll mit ähnlichen
Eigenschaften definiert. Dies bedeutet, daß bei Gegenstellen mit
Fremdchipsätzen lediglich 'keine Antwort' als Ergebnis kommt und
ein LANCOM-AP ersatzweise die Daten der zuletzt von dieser
Gegenstelle empfangenen Pakete ausgibt. Die Zeile mit den
'entfernten Werten' muß mangels Antwort aber leer bleiben.

Zu diesem 'WMP-Verweigerern' gehören leider auch alle von LANCOM
gelieferten AirLancer-Clientadapter mit 2 bzw. 54/108 MBit, weil
dort die Behandlung im Windows-Treiber erfolgen müßte, den LANCOM
aber lediglich von den Chipsatzherstellern (Z-Com bzw. Atheros)
übernimmt und OEMisiert. Ein Windows-Dienst, der diese
WMP-Pakete oberhalb des Treibers aufsammelt und behandelt, ist
zwar denkbar, aber es gibt keine Pläne von LANCOM, so etwas
anzubieten.
Antworten