Posted: Wed Jul 05, 2006 11:36 Post subject: Ich verstehs einfach nicht: STA und WET
Tag!
Es gibt das Schichtenmodell. Ethernet z.B. weiss nix von TCP/IP. Das ist auch sehr gut so.
802.11b Traffic liegt NOCH eine Ebene unter Ethernet (ist also ein Untersatz für Ethernet, der für die drahtlose Kommunikation zuständig ist).
Nun will ich ein WLAN Netzwerk aufbauen und will einen *echten* Ethernet Layer haben. Mit echt meine ich hier, dass es dem Accesspoint nicht nur egal sein kann, welche (IP-, ...) Pakete er transportiert, nein, es MUSS ihm sogar egal sein!
Kann mir jemand erklären, WIESO es bei so einer schönen Schichtenabstraktion möglich ist, dass man im WLAN Treiber einstellen muss, ob man "bridged" Modus (wet) oder (IP) Routed (STA) nimmt?
Ich erwarte mir von eth1 (dem WLAN Interface meines APs) dass es mir die Ethernet Schnittstelle so abstrahiert wie jede anderes andere Netzwerkinterface. Ob ich es dann bridge (brctl) oder eben route, das muss dich mir überlassen sein. Wieso interessiert sich der Treiber dafür, wobei ihn das absolut gar nichts angehen kann?
Oder hab ich was komplett falsch verstanden??
Soweit ich Computernetzwerke verstehe, will ich, dass mein AP als WLAN Client fungiert, DAS regelt der Treiber und stellt mir dann eine Ethernetschnittstelle zu Verfügung. Dann bin ich glücklich weil alles so funktioniert wie es soll.
Warum ich aber absolut unglücklich bin, ist, dass ich wet verwende und der Treiber offenbar Sachen anrührt, die ihn ABSOLUT nichts angehen! Ich hab zentral einen Accesspoint stehen und verschiedene DD-WRTs als wet Clients konfiguriert. An einem Client befindet sich ein Router ins Internet. Dieser Client kommt selbst ins Internet. Aber anderen Stationen ist es nicht möglich ins Internet zu kommen!
Offenbar filtert da irgendwas - obwohl es eine *Brücke* eine Ebene tiefer ist (!) IP Sachen....und zwar die, die nicht zum gleichen Subnet gehören. Mit dem alten D-Link 900AP+ als Client hat das funktioniert.
Ich habe mittels tcpdump getestet, es ist definitiv, dass der wet Client die IP Pakete nicht weiterleitet! Ich habe es mittels tcpdump überprüft, am AP selbst, am Router. Alle Routen sind richtig gesetzt. Schalte ich auf WDS um geht es.
Zudem scheint der AP im Clientmodus sehr instabil zu sein. Woran könnte das Problem liegen? WDS mag ich dauerhaft nicht einsetzen, eine Routinglösung kommt nicht in Frage, weil es ein Ethernetnetz sein soll und kein IP Netz (was ich ja genau nicht checke, denn was hat das eine mit dem anderen zu tun??)
Posted: Wed Jul 05, 2006 13:28 Post subject: Re: Ich verstehs einfach nicht: STA und WET
divB wrote:
Oder hab ich was komplett falsch verstanden??
JA ;-)
es könnte dir sicher leichter geholfen werden wenn du mal in knappen verständlichen worten schreiben würdest was du überhaupt erreichen willst.
Wenn ich aus dem ganzen überhaupt irgendwas rauslesen kann, dann dass du an einem der Client-Rechner einen Router hängen hast der die Verbindung zum Internet bereitstellt und dich nun wunderst warum die anderen Clienten die da irgendwie über WRT's im bridgemode Wireless angebunden sind kein Internetverbindung haben.
So ungefähr richtig?
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Wed Jul 05, 2006 13:40 Post subject:
weil das "ethernet" protokoll von 802.11 nur eine mac addresse unterstützt. und damit dein lan netzwerk arp technisch nicht visible ist
nur mit WDS ist "echtes" bridging möglich. wenn auch im wet modus kannst du nur einen pc ohne probleme hinter die bridge klemmen _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Juhuu, es gibt echt Leute die das Problem kennen? Ich grase das Internet ab und fand praktisch NICHTS, bei OpenWRT konnte man mir nicht helfen [...]
(Anm: Ich will hier keinen !DD-WRT Support, ich setze beide Firmwares ein, der Fehler trat bei beiden auf)
Sorry die etwas gereizte Schreibweise aber z.Z. geht mir da einfach viel durch den Strich Liegt aber glaub ich an *gr* 802.11b und nicht an DD-WRT.
Was ich erreichen will (1): Zu verstehen, wieso es die Aufgabe des Low-Level WLAN Treibers ist zu entscheiden, ob ich ein bridged oder ein routet Netzwerk haben will. Nach meinem Netzwerkverständnis darf der Netzwerktreiber nicht einmal eine Ahnung haben, dass da *vielleicht* TCP/IP drüber lauft. Wie ich schon gesagt habe, find ich im Internet nichts, was mir die ganze Technik wirklich erklärt. Ich würde 802.11b gerne *verstehen* weil ich dann sicher einige Probleme weniger habe. Auch beim WDS Verstädnis haperts noch ein bisschen.
Also wenn du das erklären kannst oder Links zu guten Docs hast (nicht die üblichen oberflächlichen ) wäre ich sehr dankbar!
Was ich erreichen will (2): Fast richtig. Also vor kurzem bestand das ganze WLAN Netz nur aus D-Link Komponenten (DWL900AP+) z.B. Bei einem zentralern Punkt ist ein AP als AP konfiguriert, sternförmig verbinden sich APs im Clientmodus, bei einigen befinden sich weitere gebridge Netze dahinter mit weiteren APs. An einer Station hängt ein Netz mit einem Router ins Internet.
Zu D-Link Zeiten hat das alles funktioniert, wenn auch schlecht. Dann haben wird einen neuen D-Link gekauft und auf einmal das Phänomen: Es wurde nicht mehr ins Internet "geroutet"! Sobald der neue D-Link AP als Client konfiguriert war, war vom gesamten WLAN aus das Internet nicht mehr erreichbar. Defaultrouten etc richtig gesetzt. WDS ging auch.
Oke, Linksys musste her, endlich Linux auf den Dingern, endlich den Überblick, und dort geht sicher alles wie ich will Nunja, jetzt gibt es exakt das gleiche Problem! Ich hoffe der Aufbau ist so ca klar. Jetzt würde mich interessieren wie man das Problem umgehen könnte.
Es mag sich jetzt blöd anhören, aber ich hab echt Tage gebraucht bis ich ansatzweise Gründe finden konnte: [1] und [2]
Trotzdem verstehe ich noch nicht, was genau das Problem dabei sein soll, wieso die Brücke draufkommt, MACs zu NATen, wieso man das überhaupt Brücke nennt und wieso es beim alten D-Link "funktioniert" hat.
Hi Brian, auch dir danke für deine Antwort. Ein bisschen einleuchtend ist es mir schon, aber gibt es eine Erklärung wie das die alten D-Links gemacht haben?
Könnte es eventuell eine Lösung mittels ProxyARP geben?
Was wäre die eleganteste Lösung des Problems? Es ist wie oben beschrieben ja ein Netz dass nicht "dezentral" im Sinne von Funkfeuer etc ist, sondern es sind 2 bis 3 "schöne" Infrastrukturnetze, die untereinander gebridged sind.
Aus diversen Gründen hätte ich einfach gerne ein Ethernet Netz und damit eine IP Range.
Wie könnte man dieses Problem am elegantesten lösen?
a) gar nicht
b) WDS (was mir nicht so gefällt da die Bandbreite bei jeder Station halbiert wird und die Antennen sind sowieso so angebracht, dass ein "schöner" Infrastrukturmodus möglich ist
c) jedes Subnet eigene IP Range (bitte nicht )
d) Ad Hoc Modus
c) ....
Posted: Wed Jul 05, 2006 14:40 Post subject: wds und geschwindigkeitsverlust
Naja es stimmt nicht gant das du bei WDS einen Geschwindigkeitsverlust hast.
Früher hatte ich Wireless Bridge als Modus im Einsatz und nach und nach haben sich probleme ereignet die ich mir nicht erklöären konnte. NAchdem Brain mir es so eklärt hatte wurde mir einiges klar.
So habe ich meine "Backbone" Funkstrecken auf WDS Betrieb laufen und siehe da an meinem Router kommen alle MAc adressen korrekt an und nicht die "Proxy Arp" Adresse der Bridge.
Also Ob du eine Funkstrecke die Daten zwischen A und B austauschst im Bridge Betrrieb oder WDS Modus laufen läst ist egal , da hat man die gleiche Geschwindigkeit.
Zum Geschwindigkeitsverlust kommt es nur wenn man mehr als 2 Geräte zusammen im WDS Modus laufen läst. Da agiert dann der mittlere als eine Art repeater. Da du aber ja gesagt hast das du sowieso 2 Richtifunkstrecken hast ist der WDS Modus die bessere Wahl.
Empfehlen kann ich dir die Geschwindigkeit im WDS Modus zu testen und dann die beiden Geräte auf eine feste Geschwindigkeit einstellen. Dann läuft das WDS wunderbar. Und der Vorteil wie gesagt am WDS ist die Transparenz. Jede MAC ADresse wird weitergegeben und der Router kommt nicht durcheinander mit den MAC Adressen.
Nachdem das Netz nicht gerade das unkomplizierteste ist, hab ich es kurz szizziert. Prinzipiell ist das gute daran, dass alle Antennen bereits für perfekten Infrastrukturmodus ausgerichtet sind/funktionieren und ich gar kein WDS benötigen würde.
Wie man sieht gibts einen "Haupt-AP" in der Mitte und einen zweiten AP in einem Subnetz. Bis jetzt waren diese zwei Geräte als AP konfiguriert und der Rest als D-Link Wireless Clients. Hat so recht und schlecht funktioniert.
Die weiteste Strecke ist von HauptAP zum anderen Subnetz.
Damit es fürs erste geht, hab ich WDS aktiviert und zwar zwischen den grün strichlierten Geräten.
Wie du jetzt aber beschrieben hast, wäre es nett wenn die beiden "dezitierten" Accesspoints über WDS verbunden wären. Aber ich brauche WDS ja gerade für den einen Client an dem das Internet hängt! Schließe ich alle drei zu einem WDS zusammen dann halbiert sich bereits die Bandbreite....oder?
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Wed Jul 05, 2006 16:30 Post subject:
divB wrote:
Hi Brian, auch dir danke für deine Antwort. Ein bisschen einleuchtend ist es mir schon, aber gibt es eine Erklärung wie das die alten D-Links gemacht haben?
Könnte es eventuell eine Lösung mittels ProxyARP geben?
Was wäre die eleganteste Lösung des Problems? Es ist wie oben beschrieben ja ein Netz dass nicht "dezentral" im Sinne von Funkfeuer etc ist, sondern es sind 2 bis 3 "schöne" Infrastrukturnetze, die untereinander gebridged sind.
Aus diversen Gründen hätte ich einfach gerne ein Ethernet Netz und damit eine IP Range.
Wie könnte man dieses Problem am elegantesten lösen?
a) gar nicht
b) WDS (was mir nicht so gefällt da die Bandbreite bei jeder Station halbiert wird und die Antennen sind sowieso so angebracht, dass ein "schöner" Infrastrukturmodus möglich ist
c) jedes Subnet eigene IP Range (bitte nicht )
d) Ad Hoc Modus
c) ....
mfg,
Niki
kann ich dir sagen. der 900AP+ wurde aus unserem bürgernetz auf alle zeiten gebannt weil er nicht 802.11 konform im client modus arbeitet. nicht nur das. er stört sogar aktiv echte 802.11 konforme ap's und setzt diese außer betrieb
die beste lösung ist Ad-hoc oder WDS. die aussage das sich die bandbreite bei WDS halbiert ist schlichtweg falsch. im point to point modus ist der AP nicht aktiviert und auch so würde sich die bandbreite nur halbieren wenn jemand am ap eingebucht wäre
die beste methode die auch am sicheresten ist, (da ich dir ein bridge netzwerk mit nem dhcp request flood locker außer betrieb setze da die broadcasts durch komplette netz rennen)
ist definitiv routing. wir haben hier ca. 2000 wireless entgeräte auf diese weise in der stadt angebunden und zahlreiche accesspoints versteht sich. jeder hat sein eigenes subnet und es gibt keinerlei ausfälle. seit 6 jahren _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Ich habs nämlich leider noch immer nicht verstanden.
Angenommen ich hab ein "wired Network" mit 192.168.1.1 als Router.
Nun füge ich einen AP im *Bridged client mode* mit IP 192.168.1.10 hinzu.
Ein AP diesmal als AP konfiguriert (IP 192.168.1.20) verbindet nun zu diesem AP.
Resultat:
Von 192.168.1.10 ist alles erreichbar.
Von 192.168.1.20 ist alles was 192.168.1.* ist erreichbar. Aber nichts anderes!
Angenommen ich starte einen ping von 192.168.1.20 auf www.google.at. Dann sehe ich den ping Request in der bridge von 192.168.1.10 noch aber nicht mehr im lokalen Interface!
Und das kann und will ich nicht verstehen! Wir befinden uns bei einer Bridge auf Layer2. Deswegen muss es egal sein, ob ich nun ein Paket an 192.168.1.1 oder direkt an google schicke weil ja durch das IP Routing die Ethernetpakete in beiden Fällen an 192.168.1.1 adressiert werden!
Die einzige Erklärung für mich ist, dass die Clientbridge unberechtigt auf Layer 3 zugreift und dort die IP Range abcheckt. Das darf aber nicht sein. Was ist, wenn ich ein anderes Protokoll über die Bridge laufen lassen wollen würde?
Joined: 06 Jun 2006 Posts: 731 Location: Erlangen, Germany
Posted: Mon Aug 11, 2008 12:54 Post subject:
Die Betriebsart "client bridge" ist keine Bridge.
Auch wenn sie -- irreführenderweise -- so heißt.
(Warum Brainslayer sie trotzdem so nennt, weiß nur er alleine.)
Sie ist kein "drahtloses Ethernet-Kabel", und sie arbeitet
nicht protkolluanbhängig.
Und obwohl das alles hier schon x-mal durchgekaut wurde, fallen
immer noch Newbies auf diese irreführende Bezeichnung rein,
denn eine Doku, die die Fähigkeiten von WRT-DD vollständig und
vor allem korrekt beschreibt, existiert ja nicht.
Zum technischen Hintergrund empfehle ich, in Google-Groups nach
der Msg-ID <87vendhzhi.fsf@ibh.de> zu suchen und diese sowie
die darauffolgenden Beiträge im betr. Diskussionsfaden zu lesen.
Ok, vielen Dank für deine Antwort, ich habs nun sogar 2x gelesen. Allmälich fange ich an zu verstehen. Dass das Forwarding für andere IP Ranges nicht geht rührt vermutlich daher, dass der WRT durch das L2-NAT durcheinander kommt. Nun ist mir auch (fast) klar wieso es in Layer3 greifen muss: Weil es die Infos fürs Connectiontracking braucht und das ganze in Wirklichkeit kein einheitlicher Ethernetlayer ist.
Quote:
denn eine Doku, die die Fähigkeiten von WRT-DD vollständig und
vor allem korrekt beschreibt, existiert ja nicht.
Falls das ironisch war, kann ich es nicht nachvollziehen. Dann bitte ich um Quellen. Falls nicht geh ich dir absolut recht. Vor diesem Posting habe ich praktisch das ganze Wochenende aufgewendet um Infos dazu zu finden. Gefunden hab ich rein gar nichts.
Was ich allerdings noch nicht im Detail verstehe: Wieso braucht man überhaupt L2-NAT?
Ist folgende Aussage richtig? "Ein AP der 802.11 konform arbeitet, schickt nur Ethernetframes weg, dessen Ziel MAC sich in der Liste seiner assoziierten Clients befindet".
Ist diese Aussage korrekt, verstehe ich zwar nicht wieso es der Standard so will, aber damit ist zumindest klar wieso "geNATet" werden muss.
Wieso aber trotzdem? Angenommen ich hab einen AP an dem hängen 3 Clients und an den 3 Clients jeweils Netzwerke, wobei die MACs nicht geNATtet werden.
Schickt nun ein Rechner vom Netz des ersten Clients ein Frame zu einem Rechner im Netz des dritten Clients, so wird der Ethernetframe ja durch die Funknatur sowieso "rundum" vom AP abgestrahlt. Und der Client, der den Zielrechner in seinem Netz hat, könnte das Frame einfach annehmen und weiterleiten. So bräuchten sich die 802.11-Clients nur merken, welche MACs sich in ihrem Netz befinden und alle Frames aufnehmen und an den 802.3 Ports ausgeben...
Da ich nun zumindest ein bisschen mehr Einblick habe wärs noch sehr interessant zu wissen, was nun die Unterschiede an den folgenden Betriebsmodi sind:
Also ich nehme einmal an dass "Client" einfach "sta" entspricht, also einem einfachen Client der L2 terminiert. Korrekt?
Und die "Client bridge" die "Brücke" die L2-NATed.
Aber was genau ist dann WDS und wieso ist es kein expliziter Betriebsmodus?
Mein Versuch einer Erklärung: WDS ist der Versuch, zwei Infrastruktur Netze (also APs) miteinander zu verbinden. In diesem Zustand tauschen die beiden dann gegenseitig ihre MAC Listen aus und entsprechen einer transparenten Bridge. Richtig soweit?
Aber wieso bedeutet WDS Bandbreitenhalbierung pro Station? Und gilt das nun auch schon bei 2 Stationen oder erst bei >3?
Und was ist dann technisch der Repeater bzw. der Repeater Bridge Modus?
Joined: 06 Jun 2006 Posts: 731 Location: Erlangen, Germany
Posted: Mon Aug 11, 2008 23:01 Post subject:
divB wrote:
Quote:
denn eine Doku, die die Fähigkeiten von WRT-DD vollständig und
vor allem korrekt beschreibt, existiert ja nicht.
Falls das ironisch war, [...]
War es nicht. Es war ernst gemeint.
Ok, mir ist jetzt klar, inwieweit mein Beitrag missverständlich war.
Also nochmal:
Wer hier schon länger mitliest, der sollte mitbekommen haben, dass
client bridge keine Bridge ist. Was diese Betriebsart aber wirklich
leistet und was nicht, das kann -- mangels Doku -- nur ein Experte
wissen (der den Quellcode studiert hat), aber kein normaler Anwender
und erst recht kein Newbie.
Liegt aber glaub ich an *gr* 802.11b und nicht an DD-WRT.
)
