Hallo zusammen! Um die Reichweite des WLANs zu erhöhen, habe ich mir eine weitere WLAN Basisstation zugelegt. Die zusätzliche Basisstation ist als Access Point konfiguriert, d.h. es besteht eine Kabelverbindung zum Router. Die WLAN Einstellungen (SSID, Verschlüsselung, etc.) sind - bis auf den Kanal - identisch. Dennoch funktioniert das WLAN nicht zufriedenstellend, was mich zu meinen Fragen bringt: 1) Wie sehe ich, dass tatsächlich ein Handover von einer Basisstation zur anderen erfolgt? Dass das Unterscheidungsmerkmal der Kanal ist ist klar, aber Windows zeigt mir nicht an, wann der Wechsel stattfindet, oder?! Programme wie Inssider/Netstumbler helfen mir hier auch nicht. 2) Wann entscheidet sich ein Endgerät von einer Funkzelle in die andere zu wechseln? Hauptkriterium ist sicher die Signalstärke - lässt sich da ein Schwellenwert festlegen? Wenn ja, wo: Auf dem Endgerät oder auf den Basisstationen? Viele Grüße, Fabi
Fabi schrieb: > Wann entscheidet sich ein Endgerät... Es gibt ja auch nur ein einziges Endgerät! Was du da treibst ist doch schon zig mal durchgekaut.
Max Mustermann schrieb: > Was du da treibst ist doch schon zig mal durchgekaut. Und eben deswegen habe ich ja die Hoffnung, dass mir da jemand einen Tipp geben kann. P.S. Vielen Dank für die hilfreiche Antwort!
Die Basisstationen entscheiden wenn du einfach 2 normale APs hast nix, das macht alles das Endgerät (bei teureren Lösungen kommunizieren die APs und versuchen sowas dann zu beeinflussen, aber das spielt hier keine Rolle). Und einen Standard gibt es dafür meines wissens nicht. Was heißt denn "funktioniert nicht zufriedenstellend"?
Max Mustermann schrieb: > Was du da treibst ist doch schon zig mal durchgekaut. Und? Hast dann auch eine Lösung parat?
Fabi schrieb: > Hauptkriterium ist sicher die Signalstärke Das kann man nicht so pauschal sagen. Ich kenne mich mit WLAN nicht aus, aber beim Mobilfunk z.B. gibt es eine ganze Reihe von Problemen, die von der Signalstärke unabhängig sind. Das Kriterium ist hier deshalb eher die max. Bitfehlerrate, die die Kanalkodierung noch ausgleichen kann. Zu deinem Problem: Soweit mir bekannt, ist Handover im WLAN-Standard nicht vorgesehen, sondern, wenn es funktioniert, eine proprietäre Erweiterung der Hersteller.
Ein Computer Spezialist hat mir mal gesagt, dass es Probleme geben kann, wenn beide WLAN Namen und Schlüssel die gleichen sind. Also vergebe mal beiden unterschiedliche Namen und Schlüssel. So kannst du auch den Wechsel nachvollziehen...
Hubert Mueller schrieb: > Ein Computer Spezialist hat mir mal gesagt, dass es Probleme geben kann, > wenn beide WLAN Namen und Schlüssel die gleichen sind. NEIN. Das ist ja sinn und zweck von dem Ganzen. scheinbar war es kein Spezialist.
Fabi schrieb: > Dennoch funktioniert das WLAN nicht zufriedenstellend, was mich zu > meinen Fragen bringt: was geht denn genau nicht? Hast du mal abwechselnd die AP abgeschaltet, verbindet er sich dann mit dem anderen? Intel hat recht viele Tools für ihre Netzwerkkarten, bestimmt kann man dort die MAC-Adresse vom AP ablesen.
Anbei mal eine verwandte Frage bzw. ein Gedanke, der mir beim Lesen gekommen ist: Soweit ich das richtig verstanden habe setzen wir im Unternehmen sog. WLAN Controller ein. An diese Controller sind Access Points angeschlossen, die selbst keine Intelligenz haben und lediglich das Signal ausstrahlen. In einem solchen Szenario müsste ein Handover doch möglich sein, da der Controller die offenen Verbindungen verwaltet und Endgeräte, dessen Signal zu schwach ist, einfach aus der Funkzelle entfernt, sodass sich das Endgerät mit der nächsten, stärker sendenden Funkzelle verbindet. Ob dieses Handover-Verfahren jetzt das beste ist sei mal dahingestellt. Ist der Gedankengang so richtig? Wie funktioniert sowas in der Praxis?
Funkamateur schrieb: > In einem solchen Szenario müsste ein Handover doch möglich sein, da der > Controller die offenen Verbindungen verwaltet und Endgeräte, dessen > Signal zu schwach ist, einfach aus der Funkzelle entfernt, sodass sich > das Endgerät mit der nächsten, stärker sendenden Funkzelle verbindet. > Ob dieses Handover-Verfahren jetzt das beste ist sei mal dahingestellt. Handover war nie wirklich vorgesehen. Wenn jetzt der AP den Client einfach so rausschmeißt kann es, je nach Treiber, dazu führen das Verbindungen geschlossen werden. (Windows schließt alle Sockets wenn das Interface Down is). Die Clients fragen regelmäßig die Umgebung nach APs ab, die AP können dabei ihre Antwort etwas verzögern. der Client wählt dann oft den AP der am schnellsten antwortet.
Peter II schrieb: > Hubert Mueller schrieb: >> Ein Computer Spezialist hat mir mal gesagt, dass es Probleme geben kann, >> wenn beide WLAN Namen und Schlüssel die gleichen sind. > scheinbar war es kein Spezialist. Naja, vielleicht schon, aber hatte sowas im Auge... Funkamateur schrieb: > Soweit ich das richtig verstanden habe setzen wir im Unternehmen sog. > WLAN Controller ein. ...denn da geht das problemlos. > In einem solchen Szenario müsste ein Handover doch möglich sein Ist es auch. Ob das unterbrechungsfrei abläuft, wie das für IP-Telefonie nötig ist, oder ob man das doch kurz merkt, das hängt auch davon ab, welche Protokolle der Client drauf hat: http://en.wikipedia.org/wiki/IEEE_802.11r-2008.
:
Bearbeitet durch User
A. K. schrieb: > Ist es auch. Ob das unterbrechungsfrei abläuft, wie das für IP-Telefonie > nötig ist, oder ob man das doch kurz merkt, das hängt auch davon ab, > welche Protokolle der Client drauf hat: > http://en.wikipedia.org/wiki/IEEE_802.11r-2008. Das heißt also selbst wenn die WLAN Infrastruktur bestens konfiguriert ist, dass komplette Haus ausgeleuchtet ist und keine anderen Störquellen (DECT, Mikrowelle o.ä.) vorhanden sind liegt es schlicht und ergreifend daran, ob der Client diese Spezifikation kennt?
Hubert Mueller schrieb: > Ein Computer Spezialist hat mir mal gesagt, dass es Probleme geben > kann, > wenn beide WLAN Namen und Schlüssel die gleichen sind. Also vergebe mal > beiden unterschiedliche Namen und Schlüssel. So kannst du auch den > Wechsel nachvollziehen... Das ist Unsinn. Gleiche SSIDs, Verschlüsselungsverfahren und Passwörter. Alle APs müssen im gleichen Ethernet Segment sein. Kanäle nicht überlappend. Dann funktioniert das Roaming ganz prima.
Funkamateur schrieb: > (DECT, Mikrowelle o.ä.) vorhanden sind liegt es schlicht und ergreifend > daran, ob der Client diese Spezifikation kennt? Das Tempo der Übergabe, ja. Im verlinkten Artikel steht auch eine Motiv dafür: Durch zunehmende Komplexität der 802.11 Protokolle stieg die Anzahl von Messages für die Übernahme so sehr an, dass man eine Abkürzung brauchte, sonst wäre VoIP Roaming ein Problem. Wenn man bloss mit dem Schleppi durch die Gegend rennt ist das weniger problematisch. Nicht einmal hartgekochte Nerds werden routinemässig durch die Gänge laufen, während sie auf den Schirm gucken und das Touchpad bedienen. Und Phone/Tablet-Freaks mit Nackenbeugesymndrom müssen ohnehin kleinere Stolperer verkraften können. Irgendwo bei Cisco gibts auch ein hübsches Bild über Möglichkeiten und Ablauf beim Roaming, und irgendwo auch ein Beispiel für den Message-Austausch. Wie überhaupt Cisco sehr schreibfreudig ist und das auch nicht hinter irgendwelchen Mauern verbirgt. Es kann sich lohnen, da mal zu stöbern.
:
Bearbeitet durch User
kaese schrieb: > Hubert Mueller schrieb: >> Ein Computer Spezialist hat mir mal gesagt, dass es Probleme geben >> kann, >> wenn beide WLAN Namen und Schlüssel die gleichen sind. Also vergebe mal >> beiden unterschiedliche Namen und Schlüssel. So kannst du auch den >> Wechsel nachvollziehen... > > Das ist Unsinn. Gleiche SSIDs, Verschlüsselungsverfahren und Passwörter. > Alle APs müssen im gleichen Ethernet Segment sein. Kanäle nicht > überlappend. > > Dann funktioniert das Roaming ganz prima. Das Roaming funktioniert nur dann ganz Prima wenn ALLE Beteiligten, also die AP's, der oder die Clients das Protokoll IEEE_802.11r-2008 kennen UND richtig implementiert haben. Da Fabi leider keine detailierten Infos über seine Hardware mitgeteilt hat ist diese Aussage... gewagt. Glenn
Glenn Müller schrieb: > Das Roaming funktioniert nur dann ganz Prima wenn ALLE Beteiligten, also > die AP's, der oder die Clients das Protokoll IEEE_802.11r-2008 kennen > UND richtig implementiert haben. Der Client kann jederzeit einen anderen AP auswählen und sich dort einbuchen. Ohne das Protokoll dauert das eventuell etwas länger was aber nur bei VoIP auffällt. Bei normales Webseiten oder Downloads gibt es kein Probleme wenn mal kurzzeitig keine Daten übertragen werden. Das Problem ist das bei WLAN der Client entscheidet wo er sich einbucht. die AP können das nicht direkt beeinflussen.
> Wie sehe ich, dass tatsächlich ein Handover von einer Basisstation > zur anderen erfolgt? Dass die MAC (BSSID) des APs eine andere ist. Bei einigen APs (u.a. Fritzbox, TP-Link) gibts auch eine Liste der assozierten Clients.
Glenn Müller schrieb: > Das Roaming funktioniert nur dann ganz Prima wenn ALLE Beteiligten, also > die AP's, der oder die Clients das Protokoll IEEE_802.11r-2008 kennen > UND richtig implementiert haben. > > Da Fabi leider keine detailierten Infos über seine Hardware mitgeteilt > hat ist diese Aussage... gewagt. Das kann man so nicht sagen. Damit Verbindungen nicht sofort abreißen muss man sich eben auf die höheren Protokollschichten verlassen. In diesem Fall wohl TCP. Gut klar, SIP und andere zeitkritischen Protokolle hassen das natürlich. Letzterem braucht man, wie du schon gesagt hast, Spezialprotokolle. Sofern das Betriebssysteme zu dumm ist und bei einem Disconnect gleich das ganze Interface resettet, kann man wohl wenig helfen. Das es bei WLAN kein Soft-Roaming wie bei WCDMA (aka. UMTS) gibt, sollte einem aber technologiebedingt klar sein.
bvf schrieb: > Sofern das Betriebssysteme zu dumm ist und bei einem Disconnect gleich > das ganze Interface resettet, kann man wohl wenig helfen. nein, das ist sogar sehr sinnvoll damit keine Verbindungen ewig auf Timeout warten. Dann wenn das Interface nach den Connect eine neue IP bekommt, können die Antworten nicht mehr zugestellt werden. Sieht man schön bei wget ( ja auch unter Linux!) wenn die DSL Leitung nach 24 stunden neu verbunden wird. wget bleibt dann für ewig hängen. Um das zu verhindert müsste man TCP-Keepalive aktivieren. Der Treiber muss einfach dafür sorgen, das das Interface nicht als DOWN gemeldet wird wenn ein reconnect auf einen anderen AP erfolgt.
Max Mustermann schrieb: > Fabi schrieb: >> Wann entscheidet sich ein Endgerät... > > Es gibt ja auch nur ein einziges Endgerät! > > Was du da treibst ist doch schon zig mal durchgekaut. ... und er hat sich nie wieder gemeldet. Sehr kompetent....... Wir setzen auf der Arbeit auch WLAN Controller ein, und im Enterprise Umfeld geht's - entgegen aller anderen Meinungen - auch nicht anders.
Funkamateur schrieb: > Max Mustermann schrieb: >> Fabi schrieb: >>> Wann entscheidet sich ein Endgerät... >> >> Es gibt ja auch nur ein einziges Endgerät! >> >> Was du da treibst ist doch schon zig mal durchgekaut. > > ... und er hat sich nie wieder gemeldet. Sehr kompetent....... Und was hat der TO in diesem Tread erfahren was nicht schon in zig Treads im Netz zum gleichen Tema zu lesen wäre?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.