L54g-Client (isolated) mit NAT -- es klemmt!

[Tillomar]

Moin allseits,

ich versuche hier eine ganz einfache Konfiguration, aber offensichtlich fehlt mir sogar dafür das nötige Wissen (das es mit dem IP-Routing hapert, hatte ich ja schon früher bewiesen...). Also wäre ich mal wieder für Hilfe dankbar...

Mein L54g soll sich als Client mit dem AP des Nachbarn verbinden; er soll im isolated Mode laufen, damit ich mein Lan per NAT verstecken kann (und nicht alle meine Geräte umkonfigurieren muß).

Das Wlan-Interface und die Verschlüsselung habe ich bereits eingestellt, und die Geräte sind lt. Status assoziiert.

Ich habe jetzt die Intranet-IP aus meinem eigenen Netz gewählt (192.168.100.x) und an das LAN-Interface gebunden. Die DMZ-IP habe ich aus dem Netz des APs (192.168.2.x) gewählt (mit dem Notebook getestet) und an das WLAN-Interface gebunden. (Später möchte ich eigentlich, daß diese DMZ-IP per DHCP vom AP kommt, damit der Nachbar nicht auf meine feste IP Rücksicht nehmen muß... geht das überhaupt, oder nur beim Aushandeln einer PPPoE-Verbindung?).

Ist das so richtig??

Als Default-Route habe ich angegeben: * -> 192.168.2.1 (AP, gleichzeitig Default-Gateway; das sollte eigentlich später zusammen mit DNS-IP auch per DHCP vom AP kommen). Unter IP-Maskierung habe ich "Intranet und DMZ" eingestellt.

Der Trace zeigt leider, daß alle Paket für die DMZ an das lokale LAN-Interface geschickt werden und dort natürlich niemanden erreichen. -- Was mache ich falsch?

Oder -- falls jemand eine solche Konfiguration fix und fertig am laufen hat (vielleicht sogar mit DHCP und lokalem DNS?) und mir zukommenlassen mag, ist das natürlich auch sehr hilfreich (die IPs und die WLan-Sachen kriege ich dann auch noch eingestellt).

Danke und bis denn,
Tillomar

PS: Als Ziel in der Default-Route gibt es nur den Eintrag "DEFAULT" (den ich aber mit der IP des AP/Gateway überschrieben habe) -- woran liegt das? Vielleicht, weil ich unter "Kommunikation" keine Gegenstellen habe (mangels DSL-Verbindung)?

[Jirka]

Hallo Tillomar,

> ich versuche hier eine ganz einfache Konfiguration

Mit dem Client-Modus verlässt man die ganz einfachen Konfigurationen ...

Im Client-Modus maskieren die LANCOMs hinter der WLAN-MAC, was auch eine gute Sache ist. Aber auf der IP-Ebene sind alle Clients am LANCOM im Client-Modus im LAN des gegenüberliegenden APs.
Somit funktioniert erst mal alles, aber Du hast noch nicht Dein NAT.

Alfred hatte mir mal den Tipp gegeben, dass man das am besten folgendermaßen löst:
Client-Modus einrichten und konfigurieren (hier ohne Anleitung, isolierten Modus brauchst Du nicht!)
LANconfig -> Schnittstellen -> WAN -> Interface-Einstellungen -> DSLoL -> ...
- aktivieren
- Modus: Exclusiv
- LAN-Interface: WLAN-1
LANconfig -> Kommunikation -> Gegenstellen -> Gegenstellen (DSL) -> Hinzufügen -> ...
- Name: INET_NACHBAR
- Haltezeit: 9999
- Layer: DHCPoE
LANconfig -> IP-Router -> Routing -> Routing-Tabelle -> Default-Route auf INET_NACHBAR setzen (IP-Maskierung Standard)
LANconfig -> TCP/IP -> Allgemein -> Intranet IP-Adresse auf die IP für den LANCOM in Deinem LAN setzen
DHCP einschalten, DNS einschalten

Ich hoffe ich habe nichts vergessen.

Viele Grüße,
Jirka

[Tillomar]

Moin Jirka,

Danke für Deine Hilfe. Das hier:

> Im Client-Modus maskieren die LANCOMs hinter der WLAN-MAC,
> was auch eine gute Sache ist. Aber auf der IP-Ebene sind alle
> Clients am LANCOM im Client-Modus im LAN des
> gegenüberliegenden APs. Somit funktioniert erst mal alles, aber
> Du hast noch nicht Dein NAT.

...habe ich schlicht nicht verstanden. Falls Du Lust und Zeit hast, kannst Du Dich ja noch etwas darüber verbreitern...

In der Zwischenzeit habe ich Deinen bzw. Alfreds Vorschlag umgesetzt; es erscheint mir zwar etwas "getrickst", aber es ist andererseits klar, daß mit dem Aufbau einer volatilen Verbindung im Regelfall der Bezug einer IP (plus Std.-Gateway- u. DNS-IP) einhergeht, es also diesen Teil meines Problems lösen sollte. Was das bzgl. Deiner obigen Aussage verbessert, ist natürlich noch unklar, ich entnehme ihr nur soviel, daß die vorgeschlagene Konstellation keine Probleme bzgl. NAT machen sollte.

Leider funktioniert es noch nicht so ganz: Der Verbindungsstatus der WAN-Verbindung NACHBAR steht dauerhaft auf "Protokollverhandlung mit NACHBAR" (mit kurzen Unterbrechungen; für den Test habe ich unter
Kommunikation -> Gegenstellen -> Polling-Liste
ein 60s-Ping auf den AP des Nachbarn gesetzt). Im Web-Status sehe ich folgendes:

Experten-Konfiguration -> Status -> DSL

DSLoL
IP-Konfiguration Ungueltig
IP-Netzwerk 0.0.0.0
IP-Netzmaske 0.0.0.0
Gateway-IP 0.0.0.0
Gateway-MAC 000000000000
DHCP-Ueberwachung ja
Exclusiver Modus ja

Also scheint der WAN-Port (auf dem WLan-Interface) noch keine IP zugewiesen zu bekommen...

In diesem Zusammenhang ist mir unklar, warum ich den DHCP-Server einschalten soll: Setze ich ihn in den Client Mode, verpaßt er dem Lancom eine neue Intranet-IP; lasse ich ihn im Server Moder laufen, kann er selbst IPs vergeben (zumindest, wenn ich ihm einen Rang gegeben hätte), nur braucht das niemend. -- Ich muß dazusagen, daß der DHCP-Server auf allen Ports aktiv ist; es macht aber keinen Unterschied, nur den WLan-Port einzuschalten und dann den DHCP-Server in den Client Mode zu schalten.

Bei meinem ISDN-Router brauche ich den DHCP-Server nur für meine Intranet-Clients, aber schließlich wird dort der Verbindungsaufbau ja auch über PPP erledigt, was definitiv nichts mit DHCP zu tun hat, und hier im Wlan-Client habe ich als Layer3 ja explizit DHCPoL angegeben...

Bin also etwas ratlos. Hast Du noch eine Idee?

So long,
Tillomar

[alf29]

Moin,

...habe ich schlicht nicht verstanden. Falls Du Lust und Zeit hast, kannst Du Dich ja noch etwas darüber verbreitern...

Das ist auch leider keine ganz einfache Sache und ohne einen halbstündigen
Grundlagenvortag über WLAN-Paketformate nicht zu erklären...

In der Zwischenzeit habe ich Deinen bzw. Alfreds Vorschlag umgesetzt; es erscheint mir zwar etwas "getrickst", aber es ist andererseits klar, daß mit dem Aufbau einer volatilen Verbindung im Regelfall der Bezug einer IP (plus Std.-Gateway- u. DNS-IP) einhergeht, es also diesen Teil meines Problems lösen sollte.

Wenn Du NAT/Maquerading haben willst, geht es nur über DSLoL, weil LCOS
Masquerading nur in Richtung eines WAN-Netzes unterstützt - Intranet
und DMZ sind beides 'LAN-Adressen' und dazwischen kann man einfach nicht
maskieren.

Also scheint der WAN-Port (auf dem WLan-Interface) noch keine IP zugewiesen zu bekommen...

Offensichtlich nicht. Mit einem WLAN-Trace erfährt man vielleicht etwas mehr:

Code: Alles auswählen

trace # wlan @ bootp

In diesem Zusammenhang ist mir unklar, warum ich den DHCP-Server einschalten soll:

Den brauchst Du nur, wenn das LANCOM in Deinem privaten Netz
DHCP-Server spielen soll.

Ich muß dazusagen, daß der DHCP-Server auf allen Ports aktiv ist; es macht aber keinen Unterschied, nur den WLan-Port einzuschalten und dann den DHCP-Server in den Client Mode zu schalten.

In den Moment, in dem das DSLoL auf dem WLAN eine Verbindung
hochzieht, greift es sich das WLAN-1 exklusiv (wenn man das so einstellt, was
hier aber der Fall ist) - alle anderen LAN-basierten Dienste (wie auch
der DHCP-Server) sind dann davon abgekoppelt.

Gruß Alfred

[backslash]

Hi Tillomar

Also scheint der WAN-Port (auf dem WLan-Interface) noch keine IP zugewiesen zu bekommen...

hat denn dein Nachbar überhaupt einen DHCP-Server laufen? Wenn nein, dann mußt du die notwendigen Parameter unter Kommunikation -> Protokolle -> IP-Parameter für die Gegenstelle NACHBAR manuell einstellen

Gruß
Backslash

[Jirka]

Hallo Tillomar,

Was das bzgl. Deiner obigen Aussage verbessert, ist natürlich noch unklar, ich entnehme ihr nur soviel, daß die vorgeschlagene Konstellation keine Probleme bzgl. NAT machen sollte.

Genauso ist es.

Leider funktioniert es noch nicht so ganz:

Was hat der Nachbar denn für einen Access Point / WLAN-Router?

für den Test habe ich unter
Kommunikation -> Gegenstellen -> Polling-Liste
ein 60s-Ping auf den AP des Nachbarn gesetzt

Was soll das bringen? Sollten die Einträge in der Polling-Tabelle nicht erreichbar sein, wird die WAN-Verbindung ab- und wieder neu aufgebaut.

Also scheint der WAN-Port (auf dem WLan-Interface) noch keine IP zugewiesen zu bekommen...

Aber die WLAN-Verbindung steht, ja?

Viele Grüße,
Jirka

[Tillomar]

Moin Alfred, Backslash und Jirka,

sorry, daß es so lange gedauert hat: ich habe nach Euren Fragen erstmal versucht, das Problem etwas einzukreisen.

Alfred Erklärungen zur Funktionsweise des LCOS im Allgemeinen und DHCP im Besonderen waren erhellend, vielen Dank. Ich habe jedenfalls jetzt soviel verstanden, daß hier eine Art Standardkonfiguration nötig ist mit einer "Einwahlverbindung" auf der WAN-Seite, und da mein WAN bereits pures IP ist, brauche ich als Protokoll eben nur IP+DHCP, schon bekommt die WAN-Seite eine eigene IP, und damit haben wir dann auch die Grundlage für NAT...

Backslash, Jirka: Ja, der Nachbar-AP hat DHCP laufen, mein Laptop bekommt einwandfrei seine Verbindung und seine Konfig.-Daten... Es ist ein Linksys (genaues Modell ist unbekannt) unter OpenWRT (white russian 6).

Der Trace hat die ganz normalen DHCP-Requests gezeigt, sie wurden nur schlicht nicht beantwortet.

Später am Nachmittag (ich war in der Zwischenzeit anderweitig beschäftigt) hatte ich in der LanMonitor-Anzeige dann plötzlich eine IP zugewiesen bekommen... aber sonst ging nichts. Ich habe dann einen kont. Ping auf der Telnet-Session gestartet, die aber nahezu alle unbeantwortet blieben -- aber hin und wieder bekam ich mal einen "Schwung" von ACKs -- da wurde mein Verdacht dann auf die Verbindungsqualität gelenkt. Tatsächlich waren Client und AP assoziiert, aber die Verbindung ging andauernd wieder verloren, und der Key-Handshake wurde nur alle Jubeljahre erfolgreich abgeschlossen.

Also bin ich wieder auf den Dachboden geklettert und habe mit den Antennen gespielt -- bingo! Zumindest die Adressvergabe mittels DHCP lief dann, ein Ping ins internet jedoch nicht. Der WLAN-Link-Status war immer mies, oder der AP wurde nicht mal angezeigt. Das hat mich doch kollossal verwundert, denn mein Notebook bekommt im Haus noch 18 MBit hin, und da ist die Antenne einfach ein Draht im Deckel... und der Lancom soll den AP nicht mal sehen???

Ich habe dann schon an einen Hardware-Defekt gedacht (man hört ja so einiges über langsame immer schlechter werdende Atheros-Module...) und den Lancom ausgetauscht, aber ohne Erfolg. Also habe ich den (neuen) Lancom komplett zurückgesetzt, die neuest Firmware hochgeladen und die Konfig nochmal "from scratch" aufgebaut. Noch die beiden 9dBi Richtantennen aus dem Fenster gehängt, dann ging es...

Die WLAN-Led habe ich für die Client-Link-Feldstärke programmiert -- vorher hatte sie immer nur geflackert (sehr schnell geblinkt), jetzt blinkt sie gleichmäßig (und leider recht langsam), und mit (direkt) angestecktem Notebook (und Lancom-Netzteil) konnte ich sogar surfen.

Leider habe ich jetzt das Problem, daß der Lancom aus dem Büro (der Lancom wird per PoE aus dem Serverscharnk im Keller versorgt) nicht mehr ansprechbar ist (Ping geht aber!) -- aber das untersuche ich lieber morgen (bzw. nachher).

Ich melde mich hier zurück, wenn es Neuigkeiten gibt, oder Fragen.
Vielen Dank an alle Helfer!!

So long,
Tillomar

[Tillomar]

Moin allseits,

ein kurzer Statusbericht, bevor ich zu einem Folgeproblem übergehe:

Die merkwürdigen Aussetzer in meinem Netzwerk haben sich mittlerweile ohne (bewußte) Einflußnahme meinerseits gegeben. Es sah fast aus, als ob IPs doppelt veregeben wären, und die beiden Lancom-Geräte (ISDN- und Wireless-Router) in meinem Netz waren weder im LANmonitor sichtbar noch im LANconfig ansprechbar. Aber: pingen konnte ich sie... Aber wie gesagt, jetzt geht es, und erst, wenn das Problem wieder auftritt, mache ich mir Sorgen.

Jetzt zu meinem neuen Problem. Ich habe das dritte Lancom-Gerät in Dienst gestellt, ein weiterer L-54g, der als AP/Bridge den Zugang für mobile Geräte innerhalb des Hause bereitstellen soll. Der AP soll seinen Clients IP-Adressen aus meinem internen Bereich zuteilen, ich haben den DHCP-Server entsprechend für Intranet und WLAN-1 freigeschaltet (vorerst keine Verknüpfung mit anderen DHCP-Servern, ich habe alle anderen ausgeschaltet).

Leider bekommt mein Notebook aber ein DHCP-Lease vom Nachbarnetzwerk, d.h. die Anfrage wird nicht von meinem AP beantwortet, sondern sie wird von meinem Wireless-Client an den AP des Nachbarn weitergegeben.

Weiß jemand von Euch, woran das liegt, und wie ich DHCP (und bei der Gelegenheit auch gleich DNS) richtig (oder optimal) einrichte?

Kurze Beschreibung, wie das Netz derzeit aussieht:

NACHBAR DSL/Wireless-Router
192.168.2.1
-- Funkstrecke --
192.168.2.xxx
WLAN-Client2 Wireless-Client Lancom L-54g
192.168.100.253
-- Ethernet --
192.168.100.254
LANCOM1100 ISDN-Router (Backup)
-- Ethernet --
192.168.100.250
WLAN-AP Wireless-AP Lancom L-54g
-- Ethernet --
<sonstige Rechner>

Danke und bis denn,
Tillomar

[Jirka]

Hallo Tillomar,

Leider bekommt mein Notebook aber ein DHCP-Lease vom Nachbarnetzwerk, d.h. die Anfrage wird nicht von meinem AP beantwortet, sondern sie wird von meinem Wireless-Client an den AP des Nachbarn weitergegeben.

Sollte die Konfiguration so sein wie oben beschrieben ist das schwer vorstellbar.
Was für eine IP bekommt das Notebook denn zugewiesen, wenn der WLAN-AP (192.168.100.250) denn abgestöpselt und dafür das Notebook angestöpselt wird? (Notebook WLAN ausschalten)
Was wird beim Notebook als DHCP-Server ausgewiesen?
Verbindet sich das Notebook per WLAN denn auch wirklich mit dem WLAN-AP (192.168.100.250)?
Warum hast Du den DHCP-Server im L-54g der im Client-Modus ist ausgeschaltet? Ich würde den DHCP dort einschalten und im WLAN-AP ausschalten. Die Clients am WLAN-AP bekommen dann die IP vom L-54g im Client-Modus.

Viele Grüße,
Jirka

[Tillomar]

Moin Jirka,

Was für eine IP bekommt das Notebook denn zugewiesen, wenn der WLAN-AP (192.168.100.250) denn abgestöpselt und dafür das Notebook angestöpselt wird? (Notebook WLAN ausschalten)

192.168.2.127, d.h. dieses Lease stammt vom Nachbar-AP. In den Details der Netzwerkeigenschaften ist auch der Nachbar-AP explizit als DHCP-Server angegeben.

Verbindet sich das Notebook per WLAN denn auch wirklich mit dem WLAN-AP (192.168.100.250)?

Ja, sieht ganz so aus -- im WLAN-Link-Test meines APs ist das Notebook eingetragen. Unter
Experten-Konfiguration -> Status -> WLAN -> Client -> Interfaces -> WLAN-1
finde ich allerdings nichts...
Der LANmonitor zeigt mein Notebook unter Wireless LAN -> Netzwerk 1 -> Client an.

Warum hast Du den DHCP-Server im L-54g der im Client-Modus ist ausgeschaltet?

Nach Euren Antworten -- siehe oben -- hatte ich ihn dort gar nicht mehr an...
Prinzipiell wollte ich den DHCP-Server am AP haben, damit ich auch den Client mal ausschalten kann (Strom sparen, bzw. Nachbar-Netz definitiv nicht benutzen), aber weiterhin einen DHCP-Server für mein Notebook oder Gäste habe.

Ich würde den DHCP dort einschalten und im WLAN-AP ausschalten. Die Clients am WLAN-AP bekommen dann die IP vom L-54g im Client-Modus.

Habe ich versuchsweise mal gemacht: Gleiches Ergebnis.
Mal 'ne Frage zum Verständnis: Wie bekommt eigentlich ein Knoten die Information, wo sich ein DHCP-Server für ihn befindet? Da muß er doch eigentlich einen Ebene-2-Broadcast loslassen, und da sich in einem Segment nur ein DHCP-Server befinden sollte, sollte der Knoten auch nur eine Antwort bekommen... und wie könnte also so ein Broadcast überhaupt in das Nachbarnetz übertragen werden? Ich blick' gerade nicht durch...

So long,
Tillomar

PS: Gibt's irgendwo im Netz ein gutes (freies?) eBook, daß mir mal IP und TCP und das ganze Routing verständlich macht?

[alf29]

Moin,

Ja, sieht ganz so aus -- im WLAN-Link-Test meines APs ist das Notebook eingetragen. Unter
Experten-Konfiguration -> Status -> WLAN -> Client -> Interfaces -> WLAN-1
finde ich allerdings nichts...

In dem Menü findest Du nur etwas, wenn das LANCOM selber als WLAN-Client agiert und nicht
als AP. Wenn das LANCOM als AP arbeitet, finden eingebuchte Clients sich unter Status->WLAN->
Stationsliste.

Mal 'ne Frage zum Verständnis: Wie bekommt eigentlich ein Knoten die Information, wo sich ein DHCP-Server für ihn befindet? Da muß er doch eigentlich einen Ebene-2-Broadcast loslassen, und da sich in einem Segment nur ein DHCP-Server befinden sollte, sollte der Knoten auch nur eine Antwort bekommen... und wie könnte also so ein Broadcast überhaupt in das Nachbarnetz übertragen werden? Ich blick' gerade nicht durch...

Das ist ein IP-Broadcast an die 255.255.255.255, der sich naturgemäß als MAC-Broadcast auf
dem Ethernet wiederfindet. Geroutet wird so etwas nicht, höchstens gebridget. Aber Du hattest das
DSLoL exklusiv ans WLAN gebunden (womit das WLAN vom Bridging ausgenommen ist), oder?

Gruß Alfred

[Tillomar]

Moin Alfred,

Wenn das LANCOM als AP arbeitet, finden eingebuchte Clients sich unter Status->WLAN->Stationsliste.

Da sieht das so aus:

Experten-Konfiguration->Status->WLAN->Stationstabelle
Index 1
AID 1
Interface WLAN-1
Netzwerk 1
VLAN-Id 0
Alter 60
Phy-Signal 85
MAC-Adresse 001a732427dc
Benutzername
Identifikation Dalaimoc_Rorvic
Tx-Bytes 0
Rx-Bytes 9141
Durchsatz 183 B
Max.-Durchsatz 355 B
Tx-Pakete 0
Rx-Pakete 53
Tx-Limit 0
Rx-Limit 0
Status Verbunden
MAC-Pruefung keine
Letztes-Ereignis Key-Handshake-Erfolg
Tx-Rate 6M
Rx-Rate 54M
Antenne 1
WPA-Version WPA2
QoS nein
Schluesseltyp AES-CCM
Power-Saving inaktiv
Listen-Intervall 10
Verb.-Zeit 41
Kurze-Praeambel nein
Kurze-Slot-Zeit ja
Kompression Keine
Cl.-Brg.-Support nein
IP-Adresse 192.168.2.148

...und da siehst Du auch gleich wieder die falsche IP-Adresse!

Geroutet wird so etwas nicht, höchstens gebridget. Aber Du hattest das DSLoL exklusiv ans WLAN gebunden (womit das WLAN vom Bridging ausgenommen ist), oder?

Hmm... ein klares JAIN. Wie der bereits früher gezeigte Auszug aus dem DSLoL-Status zeigt, habe [hatte] ich exklusiv eingestellt. Als ich allerdings gerade nachgesehen habe, stand die Konfiguration auf

Modus: automatic
LAN-Interface: any

...und ich habe keine Ahnung, wann (oder wodurch) das geändert worden ist. Ich hab's jetzt also zurechtgewurschtelt und dann den Laptop neu eingeloggt, und siehe, er hat eine IP vom WLAN-Client bekommen. Mal schauen, ob das so bleibt...

Danke erstmal und bis denn,
Tillomar

[Jirka]

Hallo Tillomar,

Hmm... ein klares JAIN. Wie der bereits früher gezeigte Auszug aus dem DSLoL-Status zeigt, habe [hatte] ich exklusiv eingestellt. Als ich allerdings gerade nachgesehen habe, stand die Konfiguration auf

Modus: automatic
LAN-Interface: any

...und ich habe keine Ahnung, wann (oder wodurch) das geändert worden ist.

Du hattest zwischendurch mal resettet:

Also habe ich den (neuen) Lancom komplett zurückgesetzt, die neuest Firmware hochgeladen und die Konfig nochmal "from scratch" aufgebaut. Noch die beiden 9dBi Richtantennen aus dem Fenster gehängt, dann ging es...

Noch mal zum DHCP: Ob Du den DHCP-Server nun im WLAN-AP oder dem AP im Client-Modus aktivierst bleibt Dir überlassen. Nach dem was Du geschrieben hast ist es evt. sinnvoll so wie Du es machen wolltest. Ich bin nur davon ausgegangen, dass der AP im Client-Modus praktisch immer an sein wird, da er die Hauptinternetanbindung zur Verfügung stellt.

Viele Grüße,
Jirka

[Tillomar]

Moin Jirka,

Du hattest zwischendurch mal resettet:

stimmt, ich könnte es einfach vergessen haben.

Frage dazu: Was ist durch diese (Fehl-) Einstellung passiert? Hat das WLAN-Interface, weil nicht exklusiv an die DSLoL-Verbindung genüpft, zusätzlich alle möglichen WLAN-Pakete des Nachbar-APs eingefangen und einfach in's LAN gebridged? Und umgekehrt anscheinend auch...?

Ich hatte am Sonnabend leider einen ca. 15-minütigen Verbindungsabbruch zwischen meinem Client und dem Nachbar-AP; während dieser Zeit versuchte der Client erfolglos, die Verbindung wiederaufzubauen. Der Verbindungsstatus war "Key Exchange". Da ich jedoch zur gleichen Zeit mit meinem Notebook problemlos die Verbindung herstellen konnte, scheidet ein Problem des APs, Manipulationen durch den Nachbarn o.ä. imho aus. Hast Du eine Idee, woran es gelegen haben könnte?

Ich habe dann versucht, durch Rückstellen meiner Gateway-IP- und DNS-IP-Konfiguration auf meinen ISDN-Router wenigstens auf diesem Wege eine Verbindungs herzustellen, doch das hat auch nicht funktioniert, der Router hat zwar einige Male eine Verbindung aufgebaut, ohne dabei jedoch (nennenswert) Daten zu übertragen. Kann es sein, daß man noch irgendwelche Caches löschen muß, bevor der Stack die neuen Parameter kapiert?

Als nächstes wollte ich dann den ISDN-Router als automatisches Fallback für die Funkbrücke konfigurieren. Mein erster Versuch, eine weitere Default-Route mit Ziel ISDN-Router und höherer Distance ging fehl -- ich kann keine zweite Default-Route eingeben... Jetzt bin ich auf folgende Idee gekommen: Ich habe eine weitere Gegenstelle "ISDN-FALLBACK" eingetragen mit Layer "IPoE" und habe diese Gegenstelle unter Rufverwaltung-Backuptabelle eingetragen. Es fehlt dem Router aber immer noch die Information über die IP des Fallback-Routers -- wie geht das richtig?

So long,
Tillomar

[Jirka]

Hallo Tillomar,

Frage dazu: Was ist durch diese (Fehl-) Einstellung passiert? Hat das WLAN-Interface, weil nicht exklusiv an die DSLoL-Verbindung genüpft, zusätzlich alle möglichen WLAN-Pakete des Nachbar-APs eingefangen und einfach in's LAN gebridged? Und umgekehrt anscheinend auch...?

Na ja, dann arbeitet das Gerät wie im normalen Client-Modus, den Du ja eigentlich schon kennst.
Alle möglichen Pakete des Nachbar-APs wird das LANCOM nicht ins LAN gebridged haben, aber zumindest alle Broadcasts und die Pakete für Deine Clients ... Auf alle Fälle befanden sich Deine Clients damit im LAN des Nachbarn, aber das hattest Du anhand der IP-Adressen ja auch schon festgestellt.
Umgekehrt entsprechend.

Ich hatte am Sonnabend leider einen ca. 15-minütigen Verbindungsabbruch zwischen meinem Client und dem Nachbar-AP; während dieser Zeit versuchte der Client erfolglos, die Verbindung wiederaufzubauen. Der Verbindungsstatus war "Key Exchange". Da ich jedoch zur gleichen Zeit mit meinem Notebook problemlos die Verbindung herstellen konnte, scheidet ein Problem des APs, Manipulationen durch den Nachbarn o.ä. imho aus. Hast Du eine Idee, woran es gelegen haben könnte?

Nö, hab da jetzt auch keine Idee. Weiter beobachten ...

Ich habe dann versucht, durch Rückstellen meiner Gateway-IP- und DNS-IP-Konfiguration auf meinen ISDN-Router wenigstens auf diesem Wege eine Verbindungs herzustellen, doch das hat auch nicht funktioniert, der Router hat zwar einige Male eine Verbindung aufgebaut, ohne dabei jedoch (nennenswert) Daten zu übertragen. Kann es sein, daß man noch irgendwelche Caches löschen muß, bevor der Stack die neuen Parameter kapiert?

Nicht das ich wüßte ...
Hast Du denn Deinem Notebook alle IP-Parameter fest zugewiesen, so dass dann alles zum ISDN-Router passte? (Ich mein am Samstag hattest Du ja vorher noch eine IP aus dem Nachbar-(W)LAN.)

Jetzt bin ich auf folgende Idee gekommen: Ich habe eine weitere Gegenstelle "ISDN-FALLBACK" eingetragen mit Layer "IPoE" und habe diese Gegenstelle unter Rufverwaltung-Backuptabelle eingetragen.

Das wird so nicht gehen, da die DSLoL-Schnittstelle schon "belegt" ist.
Da bliebe nur die Möglichkeit, das über die Aktions-Tabelle in Verbindung mit einem Polling-Eintrag für die Nachbar-AP-Verbindung, lokalem Routing zum ISDN-Router und Routing-Tag und entsprechenden Firewall-Einträgen zu lösen. Sehr komplex ... also mir fällt da nichts leichteres ein.

Viele Grüße,
Jirka