49
Zwei Netzwerke per Richtfunk verbinden
Hallo Zusammen,
aktuell möchte ich zwei Lokale Netzwerke (beide mit eigenem DHCP Server und eigenem Internetanschluss) miteinander verbinden. Habe hier im Forum schon viele Threads gelesen die sich mit dem Thema beschäftigen allerdings liegt der Teufel irgendwie im Detail bei mir. Ich habe mich zur Umsetzung an diese zwei Threads hier orientiert:
2 IP Netzte verbinden mit DD-WRT Router
Mit einem WLAN zwei LAN IP Netzwerke verbinden
Hier meine Fakten:
Netzwerk A:
Router IP: 192.168.178.1
DHCP Bereich: 192.168.178.20 - 192.168.178.200
Subnet: 255.255.255.0
Netzwerk B:
Router IP: 192.168.0.1
DHCP Bereich: 192.168.0.20 - 192.168.0.200
Subnet: 255.255.255.0
Da die beiden Netzwerke in zwei unterschiedlichen Gebäuden sind habe ich sie per Richtfunk miteinander verbunden. Da die Fritzbox, die sich auf der höchsten Etage befindet keine abnehmbaren Antennen hat, habe ich einen TP-Link TL-WA801ND AccessPoint dran gehangen mit einer Richtfunkantenne. Auf der anderen Seite des Gebäudes wartet ein weiterer AccessPoint im Client Mode und verbindet sich mit dem WLAN aus der oberen Etage. Die Verbindung direkt funktioniert einwandfrei. Kann alles anpingen und kann auch auf Daten zugreifen wenn ich es mit einem Client teste. Nun bin ich den beiden oberen Threads gefolgt um das Netzwerk A in das neue Netzwerk B einzubinden. Hierfür habe ich einen weiteren Router genommen (TL-WR841ND) und habe dd-wrt installiert.
Den Router habe ich wie folgt konfiguriert:
WAN Port IP: 192.168.178.251
Router IP: 192.168.0.2
Dem Router in Netzwerk A habe ich folgende statische Route definiert:
Netzwerk: 192.168.0.0
Subnet: 255.255.255.0
Gateway: 192.168.178.251
Router in Netzwerk B wie folgt:
Netzwerk: 192.168.178.0
Subnet: 255.255.255.0
Gateway: 192.168.0.2
Vom Zwischen-Router (192.168.0.2) kann ich problemlos alle IPs in 192.168.178.* anpingen. Alle Clients in diesem Netz können auch den Router anpingen, allerdings nur mit der WAN IP. Ich bekomme aber mit anderen Clients im jeweiligen Netz keine Verbindung hergestellt ins jeweils andere Netz. Noch zur Info: im Netzwerk A ist der erste Router (die Fritzbox) nur eine Verlängerung des Haupt Routers (auch eine Fritzbox - 192.168.178.1). Die statischen Routen sind nur in dem Hauptrouter eingetragen. Würde mich über jegliche Hilfe freuen.
Beste Grüße und ein schönes Wochenende!
aktuell möchte ich zwei Lokale Netzwerke (beide mit eigenem DHCP Server und eigenem Internetanschluss) miteinander verbinden. Habe hier im Forum schon viele Threads gelesen die sich mit dem Thema beschäftigen allerdings liegt der Teufel irgendwie im Detail bei mir. Ich habe mich zur Umsetzung an diese zwei Threads hier orientiert:
2 IP Netzte verbinden mit DD-WRT Router
Mit einem WLAN zwei LAN IP Netzwerke verbinden
Hier meine Fakten:
Netzwerk A:
Router IP: 192.168.178.1
DHCP Bereich: 192.168.178.20 - 192.168.178.200
Subnet: 255.255.255.0
Netzwerk B:
Router IP: 192.168.0.1
DHCP Bereich: 192.168.0.20 - 192.168.0.200
Subnet: 255.255.255.0
Da die beiden Netzwerke in zwei unterschiedlichen Gebäuden sind habe ich sie per Richtfunk miteinander verbunden. Da die Fritzbox, die sich auf der höchsten Etage befindet keine abnehmbaren Antennen hat, habe ich einen TP-Link TL-WA801ND AccessPoint dran gehangen mit einer Richtfunkantenne. Auf der anderen Seite des Gebäudes wartet ein weiterer AccessPoint im Client Mode und verbindet sich mit dem WLAN aus der oberen Etage. Die Verbindung direkt funktioniert einwandfrei. Kann alles anpingen und kann auch auf Daten zugreifen wenn ich es mit einem Client teste. Nun bin ich den beiden oberen Threads gefolgt um das Netzwerk A in das neue Netzwerk B einzubinden. Hierfür habe ich einen weiteren Router genommen (TL-WR841ND) und habe dd-wrt installiert.
Den Router habe ich wie folgt konfiguriert:
WAN Port IP: 192.168.178.251
Router IP: 192.168.0.2
Dem Router in Netzwerk A habe ich folgende statische Route definiert:
Netzwerk: 192.168.0.0
Subnet: 255.255.255.0
Gateway: 192.168.178.251
Router in Netzwerk B wie folgt:
Netzwerk: 192.168.178.0
Subnet: 255.255.255.0
Gateway: 192.168.0.2
Vom Zwischen-Router (192.168.0.2) kann ich problemlos alle IPs in 192.168.178.* anpingen. Alle Clients in diesem Netz können auch den Router anpingen, allerdings nur mit der WAN IP. Ich bekomme aber mit anderen Clients im jeweiligen Netz keine Verbindung hergestellt ins jeweils andere Netz. Noch zur Info: im Netzwerk A ist der erste Router (die Fritzbox) nur eine Verlängerung des Haupt Routers (auch eine Fritzbox - 192.168.178.1). Die statischen Routen sind nur in dem Hauptrouter eingetragen. Würde mich über jegliche Hilfe freuen.
Beste Grüße und ein schönes Wochenende!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 318703
Url: https://administrator.de/contentid/318703
Ausgedruckt am: 28.11.2024 um 13:11 Uhr
49 Kommentare
Neuester Kommentar
Hallo,
Du hast nur ein Standard Gateway.
Eingabe Aufforderung mit Administrator Rechten starten.
An allen Computern den Befehl Route add Zielnetz Mask 255.255.255.255 Router IP /P
z.B.: route add 192.168.178.0 Mask 255.255.255.255 192.168.0.2 /P
oder route add 192.168.0.0 Mask 255.255.255.255 192.168.178.251 /P
Der Parameter P steht dafür, dass nachdem Neustart die Route bestehen bleibt.
Du hast nur ein Standard Gateway.
Eingabe Aufforderung mit Administrator Rechten starten.
An allen Computern den Befehl Route add Zielnetz Mask 255.255.255.255 Router IP /P
z.B.: route add 192.168.178.0 Mask 255.255.255.255 192.168.0.2 /P
oder route add 192.168.0.0 Mask 255.255.255.255 192.168.178.251 /P
Der Parameter P steht dafür, dass nachdem Neustart die Route bestehen bleibt.
1
Hi Mike,
danke für deine Antwort. Was genau bedeutet "nur ein Standard Gateway". Habe bei jeweils zwei Clients (beide aus einem der beiden Netzwerke) die Route hinzugefügt zum testen, jedoch ohne Erfolg. Leider sind es auch so viele Rechner, das es ein sehr großer Aufwand wäre alle manuell zu konfigurieren. Benötige ich ggf. noch andere Hardware mit der es klappt?
Kann der Hund vielleicht auch irgendwo zwischen den beiden AccessPoints, wovon einer im Client Mode läuft und einer als AP, liegen?
Des Weiteren hätte ich auch noch einen TP-Link T1600G-52TS Pure-Gigabit Smart Switch hier der genutzt werden kann, der unterstützt wohl auch Statische Routen und Routing allgemein, nur müsste ich wissen, wenn es sinnvoll ist, wie man es umsetzt.
danke für deine Antwort. Was genau bedeutet "nur ein Standard Gateway". Habe bei jeweils zwei Clients (beide aus einem der beiden Netzwerke) die Route hinzugefügt zum testen, jedoch ohne Erfolg. Leider sind es auch so viele Rechner, das es ein sehr großer Aufwand wäre alle manuell zu konfigurieren. Benötige ich ggf. noch andere Hardware mit der es klappt?
Kann der Hund vielleicht auch irgendwo zwischen den beiden AccessPoints, wovon einer im Client Mode läuft und einer als AP, liegen?
Des Weiteren hätte ich auch noch einen TP-Link T1600G-52TS Pure-Gigabit Smart Switch hier der genutzt werden kann, der unterstützt wohl auch Statische Routen und Routing allgemein, nur müsste ich wissen, wenn es sinnvoll ist, wie man es umsetzt.
Hallo,
https://en.wikipedia.org/wiki/Default_gateway
Deine Windows Büchsen und andere können nur mit einem (1) Standard Gateway klarkommen. Können aber für verschiedene Ziele eigene Routen über entsprechende Gateways haben. Ein Gateway muss nicht zwingend das Standard gateway sein sofern mehrere Gateways vorhanden sind. Linux kennt da weitere spielarten, Windows eher nicht.
Hunde Bellen nur
Gruß,
Peter
https://en.wikipedia.org/wiki/Default_gateway
Deine Windows Büchsen und andere können nur mit einem (1) Standard Gateway klarkommen. Können aber für verschiedene Ziele eigene Routen über entsprechende Gateways haben. Ein Gateway muss nicht zwingend das Standard gateway sein sofern mehrere Gateways vorhanden sind. Linux kennt da weitere spielarten, Windows eher nicht.
Habe bei jeweils
Zu deinem Netzdesign. Nimm zwei Blatt Papier und mal dir dort pro Netz deine Aktiven am Routing beteiligten Komponenten auf. Verpassen diesen die dort vorhandenen IPs, GWs, SNMasken. Ein Router hat min. 2 IPs aus 2 Netzen wenn der Routen soll (und kann). Danach schaust du wie du von einem Client ins Internet kommst (Standrad Gateway) und wie du ins gegenüberliegende Netz kommst. Alles was dein Client als Ziel Netz nicht kennt geht über das Standard Gateway. Client 192.168.178.20 geht also nach 192.168.178.1 wenn er nach 192.168.0.21 will. Nun muss dein Router natürlich wissen wie er dort hinkommt. Dazu braucht er von dir eine Route dorthin. Hast du ja einmal schon gemacht = 50% der Miete. Warum? IP Kommunikation ist keine Einbahnstrasse. Es ist eine Zwei Wege Kommunikation Ergo muss auch der Rückweg bekannt sein. Auch die Erreichbarkeit aus dem gegenüberliegenden Netz muss dur Routen bekannt sein. Ergo musst du zwingen 2 Routen (auf jeder Seite eine) eintragen. Und das ganze ist je nach netzdesign mal so oder mal so zu lösen. Dein Netzdesign habe ich nicht ganz verstanden - dazu hast du mir zuviele verworrene Router und Konfigurationen die nicht eindeutig sind eingebaut. Dann hast du ein AP als AP laufen und ein AP im Client Modus laufen. Dir ist klar das ein AP nur eine Bridge zwischen Kuper und Luft darstellt. Wer Routet dan dar? Irgendwie vermisse ich den entscheidenden Router der dir 2 verschiedene Netze zusammenbringen kann bzw. es ermöglicht das daten von ein Netz in das andere geleitet werden un d umgekehrt. Mal mal bitte auf was du genau wie wo womit angeschlossen (auch die Gerätenamen und OSe) hast inkl. aller IPs usw. und stell uns das hier rein.zwei Clients (beide aus einem der beiden Netzwerke) die Route hinzugefügt zum testen,
Für testen ist es OK wenn man die IP Konfig anfassen tut. Es sollte aber das Ziel sein das die Router korrekt eingerichtet werden, dann Routen nämlich die Router ganz alleine.Leider sind es auch so viele Rechner,
In dein kleines Heimnetz mit 10 Geräten?Kann der Hund vielleicht auch irgendwo zwischen den beiden AccessPoints, wovon einer im Client Mode läuft und einer als AP, liegen?
Ich würd sagen das Problem ist immer eine Armeslänge von den Geräten entfernt Hunde Bellen nur einen TP-Link T1600G-52TS Pure-Gigabit
Was kann der denn ausser zu Schalten?nur müsste ich wissen ... wie man es umsetzt.
IT ist wohl nicht dein Beruf?Gruß,
Peter
1
Hi Peter, danke für deine Rückmeldung. Ich habe mal meine Grafikskills ausgepackt und es mal fix dargestellt. Vielleicht wird es dann deutlicher:
Wenn was fehlt sag Bescheid dann erweitere ich es noch. Es geht um knapp 50 Clients insgesamt.
Gruß!
Wenn was fehlt sag Bescheid dann erweitere ich es noch. Es geht um knapp 50 Clients insgesamt.
Gruß!
Ich vermute du fährst fälschlicherweise NAT auf dem DD-WRT am WAN-Port. das musst du zwingend deaktivieren damit transparentes Routing zwischen den Netzen stattfinden kann.
Zusätzlich musst du, damit PINGs zwischen den Windows-Clients überhaupt funktionieren kann, in deren Firewall das ICMP-Protokoll für alle Subnetze zulassen, per Default blockt Windows diesen Traffic aus fremden Subnetzen!
Gruß S.
Zusätzlich musst du, damit PINGs zwischen den Windows-Clients überhaupt funktionieren kann, in deren Firewall das ICMP-Protokoll für alle Subnetze zulassen, per Default blockt Windows diesen Traffic aus fremden Subnetzen!
Gruß S.
1
Hi sacknase,
der Operating Mode steht auf Router und laut Tutorial ist NAT dann deaktiviert oder? Zum Pingen habe ich Firewall beim Sender und Empfänger ausgeschaltet.
Gruß!
der Operating Mode steht auf Router und laut Tutorial ist NAT dann deaktiviert oder? Zum Pingen habe ich Firewall beim Sender und Empfänger ausgeschaltet.
Gruß!
Danke, das Bild macht vieles klarer... 
Was ist dieser ominöse "Router" 192.168.178.24 ???
Das ist doch gar kein Router, denn da ist ja nichts zu routen ?? Ist ja alles ein IP Netz 192.168.178.0 /24. Ist das nur ein dummer Switch oder ein Router wo nur die Switchkomponente benutzt wird oder was soll das sein ??
Tun wir also mal so als ob das ein Switch ist ! Dann sind das hier deine ToDos:
Wichtig wie immer hier die statischen Routen auf den beiden Internet Routern und der DD-WRT immer im Router Modus.
Sofern Winblows Machinen in den beiden Netzen sind ggf. noch die lokalen Firewalls anpassen.
Letztlich ist das Design eher unglücklich und damit fehleranfällig. Die sinnlosen und überflüssigen APs und den DD-WRT Router hätte man mit simplen 2 mal 40 Euro Mikrotik hAP oder SXT Routern realisiert wie sie im o.a. Tutorial ja auch beschrieben sind und das hätte die eigentlich überflüssige Frickelei mit den 2 APs ersetzt.
Aber warum einfach machen wenn es umständlich auch geht....?!
Was ist dieser ominöse "Router" 192.168.178.24 ???
Das ist doch gar kein Router, denn da ist ja nichts zu routen ?? Ist ja alles ein IP Netz 192.168.178.0 /24. Ist das nur ein dummer Switch oder ein Router wo nur die Switchkomponente benutzt wird oder was soll das sein ??
Tun wir also mal so als ob das ein Switch ist ! Dann sind das hier deine ToDos:
- Clients im .178.0er Netz haben die .178.1 als Default Gateway
- "Router mit Modem" bekommt eine statische Route: Zielnetz: 192.168.0.0, Maske: 255.255.255.0, Gateway: 192.168.178.252
- Router, 192.168.0.1 bekommt eine statische Route: Zielnetz: 192.168.178.0, Maske: 255.255.255.0, Gateway: 192.168.0.2
- DD-WRT Router MUSS im Router Modus arbeiten ! (Kein Gateway Modus !!)
- DD-WRT bekommt Default Gateway auf die 192.168.0.1
- Clients im .0.0er Netz haben die .0.1 als Default Gateway
Wichtig wie immer hier die statischen Routen auf den beiden Internet Routern und der DD-WRT immer im Router Modus.
Sofern Winblows Machinen in den beiden Netzen sind ggf. noch die lokalen Firewalls anpassen.
Letztlich ist das Design eher unglücklich und damit fehleranfällig. Die sinnlosen und überflüssigen APs und den DD-WRT Router hätte man mit simplen 2 mal 40 Euro Mikrotik hAP oder SXT Routern realisiert wie sie im o.a. Tutorial ja auch beschrieben sind und das hätte die eigentlich überflüssige Frickelei mit den 2 APs ersetzt.
Aber warum einfach machen wenn es umständlich auch geht....?!
1
Hi aqui,
danke für deine Antwort. Beim ominösen Router, einer alten Fritzbox, wird nur die Switchkomponente genutzt. Habe nun folgendes gecheckt:
- Clients im .178.0er Netz haben die .178.1 als Default Gateway
- Router mit Modem hat die statische Route: Zielnetz: 192.168.0.0, Maske: 255.255.255.0, Gateway: 192.168.178.252
- Router .0.1 hat statische Route: Zielnetz: 192.168.178.0, Maske: 255.255.255.0, Gateway: 192.168.0.2
- DD-WRT Router ist im Operating Mode "Router"
- DD-WRT hat bei WAN das Default Gateway 192.168.0.1
- Clients im .0.0er Netz haben die .0.1 als Default Gateway.
Im Tutorial stand dass der AccessPoint im Client Modus laufen soll, das tut er auch, ist es dann ausreichend wenn der "sendende" AccessPoint im normalen AP Mode läuft?
danke für deine Antwort. Beim ominösen Router, einer alten Fritzbox, wird nur die Switchkomponente genutzt. Habe nun folgendes gecheckt:
- Clients im .178.0er Netz haben die .178.1 als Default Gateway
- Router mit Modem hat die statische Route: Zielnetz: 192.168.0.0, Maske: 255.255.255.0, Gateway: 192.168.178.252
- Router .0.1 hat statische Route: Zielnetz: 192.168.178.0, Maske: 255.255.255.0, Gateway: 192.168.0.2
- DD-WRT Router ist im Operating Mode "Router"
- DD-WRT hat bei WAN das Default Gateway 192.168.0.1
- Clients im .0.0er Netz haben die .0.1 als Default Gateway.
Im Tutorial stand dass der AccessPoint im Client Modus laufen soll, das tut er auch, ist es dann ausreichend wenn der "sendende" AccessPoint im normalen AP Mode läuft?
DD-WRT hat bei WAN das Default Gateway 192.168.0.1
Falsch, das kommt das auf das LAN IF, auf dem WAN hat dieser ja ein ganz anderes Subnetz.Im Tutorial stand dass der AccessPoint im Client Modus laufen soll, das tut er auch, ist es dann ausreichend wenn der "sendende" AccessPoint im normalen AP Mode läuft?
Ja, dieser muss ebenfalls transparent durchreichen.
ok habe es auf das LAN IF gesetzt, hat sich leider noch nichts verändert.
Mach ein Tracert oder Pathping von einem Client zu einem anderen im anderen Netz, dann weist du sofort wo die Pakete hängen bleiben.
ok habe es auf das LAN IF gesetzt, hat sich leider noch nichts verändert.
Klar weil das hier auch nicht von Belang ist, war nur kleine Korrektur.
Hallo,
Du siehst mit Bildern geht einiges fast wie von selbst
Ein Wireshark in jedem Netz zeigt dir schnell wo es evtl hängen bleibt. Und ein NetIO zeigt dir schnell wie langsam dein Funkkabel sein wird. Eine Glasfaser zwischen deinen 2 Gebäuden ist zuverlässiger und liefert eine höhere Datenrate.
PS. Auch FritzBoxen können andere Antennen.
http://www.brennpunkt-srl.de/DECT-AntennenNachruestung.html
https://www.wlan-shop24.de/FritzBox-Umbauset?gclid=COCXgabA7M8CFRa3Gwod_ ...
https://niebegeg.net/post/fritzbox-antennen/
https://frixtender.de/
http://www.pcwelt.de/ratgeber/Zusatzantenne-bringt-viel-Nutzen-fuer-wen ...
Natülich behauptet AVM das aufgrund dessen das die Antennen perfekt abgestimmt sind (Wirklich perfekt abgestimmt) andere Antennen nicht gehen würden. Wer etwas von HF, Antennendesign, Elektronik und die Physikalischen gegenheiten beachtet dir schnell andere Antennen dran pappen können. Ob die dann besser sind ist eine andere Fragen und unter diesen Gesichtspunkten sagt AVM eben das es nicht geht. https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publicati ...
Gruß,
Peter
Du siehst mit Bildern geht einiges fast wie von selbst
Ein Wireshark in jedem Netz zeigt dir schnell wo es evtl hängen bleibt. Und ein NetIO zeigt dir schnell wie langsam dein Funkkabel sein wird. Eine Glasfaser zwischen deinen 2 Gebäuden ist zuverlässiger und liefert eine höhere Datenrate.
ok habe es auf das LAN IF gesetzt, hat sich leider noch nichts verändert.
Dann nutze Wireshark sowie Paketmittschnitt auf dein DD-WRT oder dessen Logs, dann siehst du was kommt und geht und somit siehst du das gewchlossene gatter (Gateway).PS. Auch FritzBoxen können andere Antennen.
http://www.brennpunkt-srl.de/DECT-AntennenNachruestung.html
https://www.wlan-shop24.de/FritzBox-Umbauset?gclid=COCXgabA7M8CFRa3Gwod_ ...
https://niebegeg.net/post/fritzbox-antennen/
https://frixtender.de/
http://www.pcwelt.de/ratgeber/Zusatzantenne-bringt-viel-Nutzen-fuer-wen ...
Natülich behauptet AVM das aufgrund dessen das die Antennen perfekt abgestimmt sind (Wirklich perfekt abgestimmt) andere Antennen nicht gehen würden. Wer etwas von HF, Antennendesign, Elektronik und die Physikalischen gegenheiten beachtet dir schnell andere Antennen dran pappen können. Ob die dann besser sind ist eine andere Fragen und unter diesen Gesichtspunkten sagt AVM eben das es nicht geht. https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publicati ...
Gruß,
Peter
habe von 192.168.0.103 tracert auf 192.168.178.1 ausgeführt. Folgendes Ergebnis:
Routenverfolgung zu 192.168.178.1 über maximal 30 Hops
1 <1 ms <1 ms <1 ms 192.168.0.2
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
Hallo,
Ist es ICMP dort erlaubt die Grenze zu überqueren?
Sicher das dein DD-WRT korrekt eingerichtet ist? Dir ist bewusst das eine Firewall erst einmal alles blockiert was nicht explizit Erlaubt ist und nicht wie eine Fritte alles durchwinkt?
Gruß,
Peter
Zitat von @sweetpotato:
habe von 192.168.0.103 tracert auf 192.168.178.1 ausgeführt. Folgendes Ergebnis:
Bleibt demnach in dein DD-WRT stecken.habe von 192.168.0.103 tracert auf 192.168.178.1 ausgeführt. Folgendes Ergebnis:
Ist es ICMP dort erlaubt die Grenze zu überqueren?
Sicher das dein DD-WRT korrekt eingerichtet ist? Dir ist bewusst das eine Firewall erst einmal alles blockiert was nicht explizit Erlaubt ist und nicht wie eine Fritte alles durchwinkt?
Gruß,
Peter
Firewall ist deaktiviert im DD-WRT Router.
Checke im anderen Netz per Wireshark ob dort die ICMPs an der Fritte überhaupt ankommen.
Deine Fritte besitzt auch ein eigenes Packet-Capture:
http://fritz.box/html/capture.html
Deine Fritte besitzt auch ein eigenes Packet-Capture:
http://fritz.box/html/capture.html
Bei der Fritzbox kommt folgendes an:
zur Übersicht etwas gekürzt.
192.168.0.103 192.168.178.1 ICMP 74 Echo (ping) request id=0x0001, seq=61/15616, ttl=127 (reply in 462)
192.168.178.1 192.168.0.103 ICMP 74 Echo (ping) reply id=0x0001, seq=61/15616, ttl=64 (request in 459)zur Übersicht etwas gekürzt.
Hallo,
Kommt das Antwortpaket an dein DD-WRT denn auch an dessen 192.168.178.251 Schittstelle von deiner 192.168.178.1 wieder an (ICMP Echo Reply)?
Gruß,
Peter
Zitat von @sweetpotato:
Firewall ist deaktiviert im DD-WRT Router.
Bei der Fritzbox kommt folgendes an:
Passt der Statische Routing Eintrag?Firewall ist deaktiviert im DD-WRT Router.
Bei der Fritzbox kommt folgendes an:
Kommt das Antwortpaket an dein DD-WRT denn auch an dessen 192.168.178.251 Schittstelle von deiner 192.168.178.1 wieder an (ICMP Echo Reply)?
Gruß,
Peter
In der Fritzbox 192.168.178.1 steht folgender statischer Routing Eintrag:
Der statische Routing Eintrag im Router 192.168.0.1:
Kann ich beim DD-WRT auch den Traffic aufzeichnen wie bei der Fritzbox?
Netzwerk Subnetzmaske Gateway
192.168.0.0 255.255.255.0 192.168.178.251 (also dem WAN Port vom DD-WRT)Netzwerk Subnetzmaske Gateway
192.168.178.0 255.255.255.0 192.168.0.2 (vom DD-WRT)Kann ich beim DD-WRT auch den Traffic aufzeichnen wie bei der Fritzbox?
Wenn die Fritte die Pakete wieder beantwortet kann es eigentlich nur noch am DD-WRT liegen. Ich schätze da wird noch die Option aktiviert sein die eingehende Pakete aus privaten Subnetzbereichen nach RFC1918 am WAN Port blockiert. Auch wenn der Modus auf Router steht, würde ich das nochmal explizit kontrollieren.
Ich habe leider keine JFFS2 Support Option die ich aktivieren kann bei dem Router, gibt es noch eine andere Möglichkeit zur loggen? Ich werde den Router jetzt durch einen mikrotik hex tauschen und es erneut probieren. Ich habe so oft die Konfiguration schon überprüft und es ist alles wie beschrieben konfiguriert. Ich hoffe es bringt jetzt den gewünschten Erfolg.
Die braucht JFFS man auch gar nicht ! Warum sollte das Sinn machen ?
Ja, mit der Syslog Funktion das Logging an einen Syslog Host zu senden !
Kostenlose Syslog Server Software findest du hier:
http://www.kiwisyslog.com/free-edition.aspx
http://www.draytek.co.uk/support/downloads ==> Unter "Router Tools" - Syslog Server
http://www.mikrotik.com/archive.php ==> Syslog Daemon
Such dir den schönsten aus.
Du hast irgendwo einen Konfig Fehler gemacht. Das ist aber nicht verwunderlich, denn das Design und die HW ist so umständlich und mit überflüssigen Komponenten überfrachtet das das irgendwo passieren musste.
Aber egal...wenn du es jetzt bereinigst kommt das auch mit dem MT sofort zum Fliegen !
Ja, mit der Syslog Funktion das Logging an einen Syslog Host zu senden !
Kostenlose Syslog Server Software findest du hier:
http://www.kiwisyslog.com/free-edition.aspx
http://www.draytek.co.uk/support/downloads ==> Unter "Router Tools" - Syslog Server
http://www.mikrotik.com/archive.php ==> Syslog Daemon
Such dir den schönsten aus.
Ich werde den Router jetzt durch einen mikrotik hex tauschen
Nicht besonders intelligent. Warum nicht gleich einen hAP, der hat das WLAN Interface schon gleich integriert und erspart dir überflüssige HW !Ich habe so oft die Konfiguration schon überprüft und es ist alles wie beschrieben konfiguriert.
Nein, das kann nicht so sein, denn dann würde es fehlerfrei funktionieren !Du hast irgendwo einen Konfig Fehler gemacht. Das ist aber nicht verwunderlich, denn das Design und die HW ist so umständlich und mit überflüssigen Komponenten überfrachtet das das irgendwo passieren musste.
Aber egal...wenn du es jetzt bereinigst kommt das auch mit dem MT sofort zum Fliegen !
denn das Design und die HW ist so umständlich und mit überflüssigen Komponenten überfrachtet das das irgendwo passieren musste.
Full ackn. "Consumer-Müllhalde" könnte man das auch bezeichnen . Da kacken dir die Möwen einmal auf deine Antennen und schon steht alles.
Syslog gibt folgendes: http://pastebin.com/swyt2hpW
Mit dem Mikrotik habe ich das selbe Ergebnis erhalten, hier nochmal Screenshots meiner Config, ich finde nämlich den Fehler nicht:
Mikrotik mit gelöschter Standard Config und der IP Vergabe an den Ports, sowie das Gateway:
statische Route in der Fritzbox (192.168.178.1):
statische Route im TP Link Router: (192.168.0.1):
Mit dem Mikrotik habe ich das selbe Ergebnis erhalten, hier nochmal Screenshots meiner Config, ich finde nämlich den Fehler nicht:
Mikrotik mit gelöschter Standard Config und der IP Vergabe an den Ports, sowie das Gateway:
statische Route in der Fritzbox (192.168.178.1):
statische Route im TP Link Router: (192.168.0.1):
Bitte lasse den Unsinn mit externen Bilderlinks hier im Forum !
Mit dem Kamerasymbol links hast du hier eine hervorragende und foreneigene Bilder Upload Funktion !
Die Gateway Einstellung am .178.251er Interface ist totaler Quatsch ! Das Gateway kann ja wohl unmöglich in einem fremden IP Netz liegen ! Routingtechnischer Blödsinn.
Wenn, dann muss das Gateway ja im .178.0er Netz liegen ! Sprich also .178.1 da es ja keinen anderen Router im .178er Netz gibt. Erster Fehler....
Sinnvoll wäre ggf. nochmal eine aktuelle Topo Zeichnung. Du hast immer noch nicht geklärt was der o.a. . "Router" mit der .178.24 sein soll, denn der hat da gar nichts zu routen bzw. ist kein Router.
Aölso wie sieht es, oder wie soll es jetzt mit MT aussehen ??
Mit dem Kamerasymbol links hast du hier eine hervorragende und foreneigene Bilder Upload Funktion !
Die Gateway Einstellung am .178.251er Interface ist totaler Quatsch ! Das Gateway kann ja wohl unmöglich in einem fremden IP Netz liegen ! Routingtechnischer Blödsinn.
Wenn, dann muss das Gateway ja im .178.0er Netz liegen ! Sprich also .178.1 da es ja keinen anderen Router im .178er Netz gibt. Erster Fehler....
Sinnvoll wäre ggf. nochmal eine aktuelle Topo Zeichnung. Du hast immer noch nicht geklärt was der o.a. . "Router" mit der .178.24 sein soll, denn der hat da gar nichts zu routen bzw. ist kein Router.
Aölso wie sieht es, oder wie soll es jetzt mit MT aussehen ??
Bilder wurden über das Kamerasymbol eingefügt. Mit dem MT is genau der gleiche Aufbau nur halt statt den dd-wrt Router den MT. Zu der .178.24 hatte ich weiter oben gesagt dass von dem Router nur die Switch Komponente und das WLAN genutzt wird. Gateway ist entsprechend angepasst. Habe folgenden Punkt deiner Aufzählung so verstanden dass es die .0.1 sein soll:
DD-WRT bekommt Default Gateway auf die 192.168.0.1
DD-WRT bekommt Default Gateway auf die 192.168.0.1
Aktueller Stand: Ich habe das 0er Netz mal rüber ins andere Gebäude mitgenommen und dort mit dem 178er Netz verbunden über den Zwischenrouter und es hat problemlos funktioniert. Nun habe ich den AP (178.150) und den "Router" (178.24) durch einen Router mit WLAN getauscht, also zwei Geräte durch eins ersetzt und dem die gleiche IP wie dem "Router" vorher gegeben. (178.24). Bei dem letzten AP habe ich nun von Client Mode auf Bridge AP Mode gestellt und ich kann einzelne Rechner anpingen und habe jetzt auch Zugriff auf den Datenserver.
Noch eine Frage zur Performance. Wenn ich direkt am Bridge AP dran bin komme ich auf knapp 9MB/s. Wenn ich aber über den Router also über das neue Subnetz gehe, komme ich auf maximal 1MB/s. Woran kann das liegen und kann man das optimieren?
Noch eine Frage zur Performance. Wenn ich direkt am Bridge AP dran bin komme ich auf knapp 9MB/s. Wenn ich aber über den Router also über das neue Subnetz gehe, komme ich auf maximal 1MB/s. Woran kann das liegen und kann man das optimieren?
Das Problem ist das du die WLAN Strecke mit dem gesamten Broad- und Multicast Traffic belastest aus einem der beiden Netzsegmente wenn du eine Seite im Bridge Mode betreibst.
Dadurch hast du dann auf der sowieso sehr geringen WLAN Bandbreite dann schon ein "Grundrauschen" der deinen Traffic auf dem Funklink arg belastet.
Dazu kommen vermutlich noch Störungen durch Kanalüberlagerungen von Nachbar WLANs ?? Hast du das mal ausgemessen mit dem ??
Eine saubere Kanalplanung mit einem minimalen 4 kanaligen Abstand ist hier ein absolutes Muss. Deaktivieren von TKIP sowieso. Guckst du auch hier:
Seit WLAN Umstellung von Cisco WAP 200 auf Zyxel NWA3560-N schlechtere Verbindung
Ideal wäre es in deinem Szenario also wenn du nur die Funkstecke als einzelnes IP Netz betreibst und an beiden Enden (APs) routest.
Damit verbannst du diesen Traffic komplett von der Funkstrecke und erreichst volle Performance auf der Bandbreite die deine HF Feldstärke auf dem Funklink dynamisch hergibt.
Oben hast du ja schon gelesen woran eigentlich dein gesamtes Projekt krankt. Das ist das vollkommen fehlerhafte Design und die (sorry) mehr als dilettantische Hardware Auswahl mit allerbilligsten China Consumer APs die gar nicht das hergibt was du erreichen willst.
Mit nur ein klein wenig mehr hättest du 2 RiFu APs im vollkommen ungestörten 5 Ghz Bereich genommen:
http://varia-store.com/Wireless-Systeme/Fuer-den-Aussenbereich/MikroTik ...
Beide Seiten als Router...fertig ist der Lack !
Für knapp 100 Euronen eine Super Lösung ohne Störungen von Nachbar WLANs mit voller Performance.
Dadurch hast du dann auf der sowieso sehr geringen WLAN Bandbreite dann schon ein "Grundrauschen" der deinen Traffic auf dem Funklink arg belastet.
Dazu kommen vermutlich noch Störungen durch Kanalüberlagerungen von Nachbar WLANs ?? Hast du das mal ausgemessen mit dem ??
Eine saubere Kanalplanung mit einem minimalen 4 kanaligen Abstand ist hier ein absolutes Muss. Deaktivieren von TKIP sowieso. Guckst du auch hier:
Seit WLAN Umstellung von Cisco WAP 200 auf Zyxel NWA3560-N schlechtere Verbindung
Ideal wäre es in deinem Szenario also wenn du nur die Funkstecke als einzelnes IP Netz betreibst und an beiden Enden (APs) routest.
Damit verbannst du diesen Traffic komplett von der Funkstrecke und erreichst volle Performance auf der Bandbreite die deine HF Feldstärke auf dem Funklink dynamisch hergibt.
Oben hast du ja schon gelesen woran eigentlich dein gesamtes Projekt krankt. Das ist das vollkommen fehlerhafte Design und die (sorry) mehr als dilettantische Hardware Auswahl mit allerbilligsten China Consumer APs die gar nicht das hergibt was du erreichen willst.
Mit nur ein klein wenig mehr hättest du 2 RiFu APs im vollkommen ungestörten 5 Ghz Bereich genommen:
http://varia-store.com/Wireless-Systeme/Fuer-den-Aussenbereich/MikroTik ...
Beide Seiten als Router...fertig ist der Lack !
Für knapp 100 Euronen eine Super Lösung ohne Störungen von Nachbar WLANs mit voller Performance.
Ich hänge mich grad einfach mal mit dran, weil ich ein ähnliches Problem habe:
Zwei Netzwerke mit unterschiedlichen IP-Netzen (192.168.1.0 und 192.158.188.0) sollen über eine Distanz von rund 700 Metern derart miteinander verbunden werden, dass verschiedene Ressourcen gemeinsam benutzt werden können (NAS, Drucker, DLNA), hingegen beide ihren eigenen Internet-Zugang behalten sollen.
Vorhanden sind neben Switches jeweils eine Fritzbox 7490 (einmal mit VDSL, einmal mit vorgeschaltetem Hybrid-Speedport) und jeweils DHCP in der FB. Angeschafft wurden speziell jetzt 2 Mikrotik SXT 5 Lite, über die die Verbindung wie oben von Aqui angeregt erfolgen soll.
Das Ganze existiert jetzt in einem Versuchsaufbau, aber bei der richtigen Konfiguration der SXT komme ich dann doch immer wieder und mehr ins straucheln. Verschiedenste Beispiele, wie sie hier im Forum zu finden sind, habe ich ausprobiert, wiesen aber immer irgendwelche Besonderheiten auf, die für die recht einfache Config nicht zutreffend sind.
Nach meinem Verständnis muss ein SXT als Bridge-Server (im Netz 192.168.1.0) und einer als Bridge-Client (im Netz 192.168.188.0) eingebunden werden. Der Link steht und ich kann vom ersten Netz auch problemlos über den aufgebauten Link den SXT-Client bedienen, aber exakt nichts mehr.
Kannst Du mir einen Denkanstoß in die richtige Richtung geben?
Zwei Netzwerke mit unterschiedlichen IP-Netzen (192.168.1.0 und 192.158.188.0) sollen über eine Distanz von rund 700 Metern derart miteinander verbunden werden, dass verschiedene Ressourcen gemeinsam benutzt werden können (NAS, Drucker, DLNA), hingegen beide ihren eigenen Internet-Zugang behalten sollen.
Vorhanden sind neben Switches jeweils eine Fritzbox 7490 (einmal mit VDSL, einmal mit vorgeschaltetem Hybrid-Speedport) und jeweils DHCP in der FB. Angeschafft wurden speziell jetzt 2 Mikrotik SXT 5 Lite, über die die Verbindung wie oben von Aqui angeregt erfolgen soll.
Das Ganze existiert jetzt in einem Versuchsaufbau, aber bei der richtigen Konfiguration der SXT komme ich dann doch immer wieder und mehr ins straucheln. Verschiedenste Beispiele, wie sie hier im Forum zu finden sind, habe ich ausprobiert, wiesen aber immer irgendwelche Besonderheiten auf, die für die recht einfache Config nicht zutreffend sind.
Nach meinem Verständnis muss ein SXT als Bridge-Server (im Netz 192.168.1.0) und einer als Bridge-Client (im Netz 192.168.188.0) eingebunden werden. Der Link steht und ich kann vom ersten Netz auch problemlos über den aufgebauten Link den SXT-Client bedienen, aber exakt nichts mehr.
Kannst Du mir einen Denkanstoß in die richtige Richtung geben?
Hört sich beim ersten Lesen für mich nach einem Routing-Problem an...
Wie hast du dein Routing konfiguriert?
Wie hast du dein Routing konfiguriert?
Irgendwie bin ich noch garnicht richtig beim Routing angekommen. In der FB sind die Routen zum jeweils anderem Netz eingetragen, die meisten Probleme habe ich jedoch wohl in den SXT selbst. Im SXT-Client lässt sich beispielsweise die statische Adresse des Subnetzes nicht einstellen, er schaltet ohne Meckern immer wieder die 192.168.88.2 dort ein, obwohl diese ja 192.168.188.3 lauten müsste, aber das ignoriert der SXT einfach. Daher kann ich von einem Laptop, der im 192.168.188.0 hängt, die Bridge auch nur über die 192.168.88.2 ansprechen.
Zum Verständnis: der SXT-Server hat die 192.168.88.1 (default) und der SXT-Client die 192.168.88.2 bekommen, damit beide von der administrativen Seite (Netz = 192.168.1.0) erreicht werden können.
Zum Verständnis: der SXT-Server hat die 192.168.88.1 (default) und der SXT-Client die 192.168.88.2 bekommen, damit beide von der administrativen Seite (Netz = 192.168.1.0) erreicht werden können.
Setz den SXT nochmal auf Factory Defaults und versuch das nochmal mit dem WinBox Tool. Irgendwas hat sich da verschluckt.
Hallo Aqui,
das habe ich gemacht und irgendwie krieg ich es jetzt garnicht mehr gebacken. Die IP ist jetzt wieder einstellbar, mehr aber auch nicht.
Hättest Du die Möglichkeit, mir die notwendigen Einstellungen für die SXT kurz zu schreiben? Die gewünschte Konstellation habe ich ja zuvor schon beschrieben. Ich seh den Wald wohl vor lauter Bäumen nicht mehr...
das habe ich gemacht und irgendwie krieg ich es jetzt garnicht mehr gebacken. Die IP ist jetzt wieder einstellbar, mehr aber auch nicht.
Hättest Du die Möglichkeit, mir die notwendigen Einstellungen für die SXT kurz zu schreiben? Die gewünschte Konstellation habe ich ja zuvor schon beschrieben. Ich seh den Wald wohl vor lauter Bäumen nicht mehr...
Also ich hab es jetzt hinbekommen, entscheidend war das Routing innerhalb der SXT! ich kann jetzt ganz normal Verbindungen herstellen und auf einer Windows-Maschine zeigt tracert auch artig die tatsächliche Route der Pakete an.
Was bis hierher funktioniert: Ich kann auf alle Web-Oberflächen zugreifen wie z.B. vom NAS oder MediaCenter, aber nicht auf die Festplatten selbst. Diese laufen ins Timeout. Allerdings ist auch per HTTP(s) die Verbindung sehr schleichend, wobei die Pings alle zwischen 1 und 2 ms liegen. Im 2. Subnetz fällt mir auch ein großer Paketstrom auf, sprich der Switch darin ist wild am flackern, hingegen auf der PTP-Serverseite ist es schön ruhig.
Woran kann der mangelnde Speed (oder diese Paketflut von offenbar klitzekleinen Paketen, entspricht einem "Grundrauschen" auf eth0 von ca. 300 KBit/s) herrühren? Und was muss getan werden, damit Windows-freigaben (Explorer) funktionieren?
Was bis hierher funktioniert: Ich kann auf alle Web-Oberflächen zugreifen wie z.B. vom NAS oder MediaCenter, aber nicht auf die Festplatten selbst. Diese laufen ins Timeout. Allerdings ist auch per HTTP(s) die Verbindung sehr schleichend, wobei die Pings alle zwischen 1 und 2 ms liegen. Im 2. Subnetz fällt mir auch ein großer Paketstrom auf, sprich der Switch darin ist wild am flackern, hingegen auf der PTP-Serverseite ist es schön ruhig.
Woran kann der mangelnde Speed (oder diese Paketflut von offenbar klitzekleinen Paketen, entspricht einem "Grundrauschen" auf eth0 von ca. 300 KBit/s) herrühren? Und was muss getan werden, damit Windows-freigaben (Explorer) funktionieren?
Hallo,
Welche Festplatten haben bei dir denn LAN Ports?
Gruß,
Peter
Welche Festplatten haben bei dir denn LAN Ports?
wobei die Pings alle zwischen 1 und 2 ms liegen.
PING = ICMP ungleich HTTP(s)Im 2. Subnetz
Wie viele Netze und Subnetze hast du denn?sprich der Switch darin ist wild am flackern
LOOP gebaut?(oder diese Paketflut von offenbar klitzekleinen Paketen
Wireshark ist dein FreundUnd was muss getan werden, damit Windows-freigaben (Explorer) funktionieren?
Was an deinen Freigaben funktioniert denn nicht?Gruß,
Peter
Zu den Fragen:
Die NAS-Platten können im 1. Subnetz als externe Laufwerke verbunden werden, im 2. Subnetz (über die Funkbrücke) sind diese nicht zu sehen.
Dass Pings nichts über die effektive Geschwindigkeit einer HTTP(s)-Verbindung aussagen ist mir klar. Im 1. Subnetz werden die HTTP(s)-Anfragen aber umgehend angezeigt, im 2. Subnetz kann ich aber bequem nen großen Schluck Kaffee und ein paar Züge an der Zigarette nehmen, bevor sich da was tut. Es liegt also nicht an den jeweiligen HTTP(s)-Servern, sondern es tröpfelt nur durch die Funkbrücke. Ein Download läuft hingegen mit ca 45 MBits/s bei fast voller Geschwindigkeit der Funkbrücke (54 MBit/s).
Es existieren im Versuchsaufbau sowie im zukünftigen Netzaufbau 2 Subnetze, jeweils eines auf jeder Seite der Funkbrücke.
An einen Loop hatte ich auch schon gedacht, aber schwierig bei lediglich einem Laptop und der Funkbrücke am Switch, WLAN ist abgeschaltet und sonst hängt da jetzt nichts dran. Die Funkbrücke zeigt mir in dem Subnetz an, dass sie auf ath0 reichlich Pakete empfängt, die demnach nur vom Laptop stammen können. Ich vermute einfach, dass ET, ähm Windows10 auf dem Laptop "nach hause telefonieren" will, hat aber kein INet-Zugang im Versuchsaufbau.
Bei den Freigaben ala \\server-ip\freigabename kann von dem Laptop her keine Verbindung aufgebaut werden. Auf der anderen Seite der Funkbrücke laufen die einwandfrei. Ergo blockiert die Funkbrücke irgendwas standardmässig, was ich noch nicht herausgefunden habe.
Grüße, Micha
Die NAS-Platten können im 1. Subnetz als externe Laufwerke verbunden werden, im 2. Subnetz (über die Funkbrücke) sind diese nicht zu sehen.
Dass Pings nichts über die effektive Geschwindigkeit einer HTTP(s)-Verbindung aussagen ist mir klar. Im 1. Subnetz werden die HTTP(s)-Anfragen aber umgehend angezeigt, im 2. Subnetz kann ich aber bequem nen großen Schluck Kaffee und ein paar Züge an der Zigarette nehmen, bevor sich da was tut. Es liegt also nicht an den jeweiligen HTTP(s)-Servern, sondern es tröpfelt nur durch die Funkbrücke. Ein Download läuft hingegen mit ca 45 MBits/s bei fast voller Geschwindigkeit der Funkbrücke (54 MBit/s).
Es existieren im Versuchsaufbau sowie im zukünftigen Netzaufbau 2 Subnetze, jeweils eines auf jeder Seite der Funkbrücke.
An einen Loop hatte ich auch schon gedacht, aber schwierig bei lediglich einem Laptop und der Funkbrücke am Switch, WLAN ist abgeschaltet und sonst hängt da jetzt nichts dran. Die Funkbrücke zeigt mir in dem Subnetz an, dass sie auf ath0 reichlich Pakete empfängt, die demnach nur vom Laptop stammen können. Ich vermute einfach, dass ET, ähm Windows10 auf dem Laptop "nach hause telefonieren" will, hat aber kein INet-Zugang im Versuchsaufbau.
Bei den Freigaben ala \\server-ip\freigabename kann von dem Laptop her keine Verbindung aufgebaut werden. Auf der anderen Seite der Funkbrücke laufen die einwandfrei. Ergo blockiert die Funkbrücke irgendwas standardmässig, was ich noch nicht herausgefunden habe.
Grüße, Micha
im 2. Subnetz (über die Funkbrücke) sind diese nicht zu sehen.
Logisch, denn Naming Services beruhen auf Broad- oder Multicasts die bekannter weise NICHT über geroutete Segmente übertragen werden !Du kannst sie aber lokal in die lmhosts Datei eintragen:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
...oder eben die IPs benutzen.
nen großen Schluck Kaffee und ein paar Züge an der Zigarette nehmen, bevor sich da was tut.
Klassischer DNS Timeout. Trag die Ziele statisch nach oder passe den DNS an.Es existieren im Versuchsaufbau sowie im zukünftigen Netzaufbau 2 Subnetze, jeweils eines auf jeder Seite der Funkbrücke.
Das ist auch gut und richtig so !Mit NetIO und/oder iPerf kannst du ja den tatsächlichen Durchsatz sauber testen sowohl für TCP aus auch für UDP.
Damit hast du einen verlässlichen Wert was die nackte Infrastruktur macht.
http://www.ars.de/ars/ars.nsf/docs/netio
http://www.nwlab.net/art/netio/netio.html
Alles andere sind Fehler im DNS oder in der Winblows Rechteverwaltung und hat mit dem Netz als solchem dann nichts zu tun.
Bei den Freigaben ala \\server-ip\freigabename kann von dem Laptop her keine Verbindung aufgebaut werden
Vermutlich wie immer die lokale Windows Firewall !!Bedekek das diese immer Absender IP Adressen komplett blockieren ! Du musst hier also zwingend deine Firewall anpassen da du ja aus einem anderen netz kommst.
Möglich auch das du auf der Funkstrecke auf einem der AP Router versehentlich NAT (IP Adress Translation) aktiviert hast.
Das wäre dann fatal, denn dann könnten Paket nur in einer Richtung fliessen, da die andere durch die NAT Firewall blockiert sind.
Letzteres wäre dann eine Fehlkonfig der Komponenten. Ist jetzt aber nur geraten weil hier die Details fehlen...
Danke Aqui für die Hinweise!
Grad mal etwas zum Stand der Dinge: Wir sind heute "ins kalte Wasser gesprungen" und haben die Clientseite in das reale Subnetz aufgebaut und angeschlossen. Und man mag es kaum glauben: die Probleme haben sich in Wohlgefallen aufgelöst! Es muss tatsächlich am DNS und vor allem an der Art und Weise gelegen haben, wie das Routing aum 2. SXT ablief. Dort war im Testaufbau noch keine Fritzbox als Standardgateway vorhanden, weshalb am Laptop, dass die Rechnerwelt im 2. Subnetz simulieren sollte, lediglich das Standardgateway auf das SXT verbogen war. Das reichte für die Pings, aber offenbar nicht für die komplexeren Abläufe eines Connects.
Sämtliche Freigaben laufen jetzt bestens, man kann bereits so per Dateibrowser auf die entfernten Laufwerke zugreifen, als stünden diese im lokalen Subnetz. Obwohl wir bislang noch die SXT nur jeweils unmittelbar an einem Fenster bzw. an einem Balkon provisorisch befestigt haben und das Signal lediglich über Reflektionen empfangen können (85dB bei 5 MHz Bandbreite), erlaubt der Link eine recht stabile Datenübertragung mit ca. 2 MBit/s. Am niedriger gelegenen Standort soll das SXT noch auf dem Dach montiert werden, womit dann nur noch der Dachstuhl eines Hauses die direkte Sichtverbindung behindert. Wenn das noch ein Plus von 6-10 dB bringt, dann kann der Link hoffentlich auch mit voller Geschwindigkeit laufen.
Bei der gesamten Konfiguration waren vor allem folgende Eintragungen in die IPv4-Routingtabellen der jeweiligen Fritzbox 7490 wichtig:
In der 1. FB 192.168.1.1:
192.168.188.0 -> 192.168.128.3 (IP des WLAN-Partners im 2. SXT (Client/CPE))
192.168.88.0 -> 192.168.128.3 (damit das 2. SXT auch aus dem 1. Subnetz administriert werden kann)
In der 2. FB 192.168.188.1:
192.168.1.0 -> 192.168.1.3 (IP des WLAN-Partners im 1. SXT (Server/AP))
192.168.88.0 -> 192.168.1.3 (damit das 1. SXT auch aus dem 2. Subnetz administriert werden kann)
Das 1. Subnetz hat die Netzwerkadresse 192.168.1.0, das 2. das Netzwerk 192.168.188.0 und die WLan-Verbindung zwischen den SXT läuft über das Subnetz 192.168.128.0. Die entsprechenden IP-Adressen waren dann in das jeweilige SXT an ether1 und an wlan1 zu binden. Das war eigentlich die gesamte Konfiguration und alles läuft. Natürlich wurden in beiden SXT eine Bridge angelegt und jeweils ether1 und wlan1 darin aufgenommen und NAT deaktiviert. Logischerweise noch WPA2 und ein WLan-Passwort für die Verschlüsselung der WLan-Verbindung nicht vergessen. Mehr musste nicht gemaacht werden ;)
Vielen Dank für die Anregungen, die mir unheimlich weitergeholfen haben!
Grüße, Micha
PS: Der Traffic im Versuchsaufbau rührte wohl wie vermutet vom Windows auf dem Laptop, das unbedingt "nach Hause telefonieren" wollte, aber logischerweise keine Verbindung zum Bill aufbauen konnte, da dieses LAN-Segment keinen Internet-Zugang hatte. Eigentlich mal ein guter Anlass, den Gesprächsbedarf eines Windows10-PC's genauer anzusehen...
Grad mal etwas zum Stand der Dinge: Wir sind heute "ins kalte Wasser gesprungen" und haben die Clientseite in das reale Subnetz aufgebaut und angeschlossen. Und man mag es kaum glauben: die Probleme haben sich in Wohlgefallen aufgelöst! Es muss tatsächlich am DNS und vor allem an der Art und Weise gelegen haben, wie das Routing aum 2. SXT ablief. Dort war im Testaufbau noch keine Fritzbox als Standardgateway vorhanden, weshalb am Laptop, dass die Rechnerwelt im 2. Subnetz simulieren sollte, lediglich das Standardgateway auf das SXT verbogen war. Das reichte für die Pings, aber offenbar nicht für die komplexeren Abläufe eines Connects.
Sämtliche Freigaben laufen jetzt bestens, man kann bereits so per Dateibrowser auf die entfernten Laufwerke zugreifen, als stünden diese im lokalen Subnetz. Obwohl wir bislang noch die SXT nur jeweils unmittelbar an einem Fenster bzw. an einem Balkon provisorisch befestigt haben und das Signal lediglich über Reflektionen empfangen können (85dB bei 5 MHz Bandbreite), erlaubt der Link eine recht stabile Datenübertragung mit ca. 2 MBit/s. Am niedriger gelegenen Standort soll das SXT noch auf dem Dach montiert werden, womit dann nur noch der Dachstuhl eines Hauses die direkte Sichtverbindung behindert. Wenn das noch ein Plus von 6-10 dB bringt, dann kann der Link hoffentlich auch mit voller Geschwindigkeit laufen.
Bei der gesamten Konfiguration waren vor allem folgende Eintragungen in die IPv4-Routingtabellen der jeweiligen Fritzbox 7490 wichtig:
In der 1. FB 192.168.1.1:
192.168.188.0 -> 192.168.128.3 (IP des WLAN-Partners im 2. SXT (Client/CPE))
192.168.88.0 -> 192.168.128.3 (damit das 2. SXT auch aus dem 1. Subnetz administriert werden kann)
In der 2. FB 192.168.188.1:
192.168.1.0 -> 192.168.1.3 (IP des WLAN-Partners im 1. SXT (Server/AP))
192.168.88.0 -> 192.168.1.3 (damit das 1. SXT auch aus dem 2. Subnetz administriert werden kann)
Das 1. Subnetz hat die Netzwerkadresse 192.168.1.0, das 2. das Netzwerk 192.168.188.0 und die WLan-Verbindung zwischen den SXT läuft über das Subnetz 192.168.128.0. Die entsprechenden IP-Adressen waren dann in das jeweilige SXT an ether1 und an wlan1 zu binden. Das war eigentlich die gesamte Konfiguration und alles läuft. Natürlich wurden in beiden SXT eine Bridge angelegt und jeweils ether1 und wlan1 darin aufgenommen und NAT deaktiviert. Logischerweise noch WPA2 und ein WLan-Passwort für die Verschlüsselung der WLan-Verbindung nicht vergessen. Mehr musste nicht gemaacht werden ;)
Vielen Dank für die Anregungen, die mir unheimlich weitergeholfen haben!
Grüße, Micha
PS: Der Traffic im Versuchsaufbau rührte wohl wie vermutet vom Windows auf dem Laptop, das unbedingt "nach Hause telefonieren" wollte, aber logischerweise keine Verbindung zum Bill aufbauen konnte, da dieses LAN-Segment keinen Internet-Zugang hatte. Eigentlich mal ein guter Anlass, den Gesprächsbedarf eines Windows10-PC's genauer anzusehen...
Ups, Korrektur/Nachtrag:
In der 1. FB 192.168.1.1:
192.168.188.0 -> 192.168.1.3 (IP des 1. SXT (Server/AP))
192.168.88.0 -> 192.168.1.3 (damit das 2. SXT auch aus dem 1. Subnetz administriert werden kann)
In der 2. FB 192.168.188.1:
192.168.1.0 -> 192.168.188.3 (IP des 2. SXT (Client/CPE))
192.168.88.0 -> 192.168.188.3 (damit das 1. SXT auch aus dem 2. Subnetz administriert werden kann)
Im 1. SXT:
192.168.188.0/24 -> 192.168.128.2 (WLan-IP des 2. SXT)
Und im 2. SXT:
192.168.1.0/24 -> 192.168.128.1 (WLan-IP des 1. SXT)
In der 1. FB 192.168.1.1:
192.168.188.0 -> 192.168.1.3 (IP des 1. SXT (Server/AP))
192.168.88.0 -> 192.168.1.3 (damit das 2. SXT auch aus dem 1. Subnetz administriert werden kann)
In der 2. FB 192.168.188.1:
192.168.1.0 -> 192.168.188.3 (IP des 2. SXT (Client/CPE))
192.168.88.0 -> 192.168.188.3 (damit das 1. SXT auch aus dem 2. Subnetz administriert werden kann)
Im 1. SXT:
192.168.188.0/24 -> 192.168.128.2 (WLan-IP des 2. SXT)
Und im 2. SXT:
192.168.1.0/24 -> 192.168.128.1 (WLan-IP des 1. SXT)
man kann bereits so per Dateibrowser auf die entfernten Laufwerke zugreifen, als stünden diese im lokalen Subnetz.
Das hinterlässt aber ein Geschmäckle und lässt den Verdacht aufkommen das da doch was falsch konfiguriert wurde ?!Da Broadcasts ja nicht übertragen werden düftest du SMB/CIFS Share niemals über geroutete Verbindungen sehen, es sei denn du arbeitest fest mit einem lokalen DNS Server ?!
Deine IP Adressierung ist weiterhin recht verwirrend
Wie sieht das denn nun aus ? So:(Internet)---Fritz1---(LAN:192.168.1.0)----SXT1---(Funk 192.168.128.0)---SXT2----(LAN:192.168.188.0)----Fritz2---(Internet)
Mist, falschen Button gedrückt, nochmal neu schreiben:
Dass die (NAS-) Freigaben im jeweils anderen Subnetz sichtbar sind war ja Ziel des Ganzen. Wer jeweils was damit machen darf ist Sache der Zugriffsberechtigungen.
Was an der IP-Adressierung "verwirrend" sein soll, habe ich nicht wirklich verstanden. Es sind klar abgegrenzte Subnetze und so sollte es doch wohl auch sein. Das einzige Problem, was mir jetzt noch aufgefallen ist: Neu im 2. Subnetz angemeldete Geräte haben sich ihre Adressen beim DHCP-Sever des 1. Subnetzes geholt statt von dem aus dem tatsächlich eigenem 2. Subnetz. Da muss ich die Anfragen wohl noch in den Firewalls der Funk-Brücke blockieren, nur was müsste da noch geblockt werden?
BTW und hat weniger mit dem Netzwerk ansich zu tun: Kann man den Client/CPE irgendwie dazu bewegen, wei einem Funkverlust automatisch die verbindung neu aufzubauen, wenn der Server/AP wieder sichtbar wird?
Dass die (NAS-) Freigaben im jeweils anderen Subnetz sichtbar sind war ja Ziel des Ganzen. Wer jeweils was damit machen darf ist Sache der Zugriffsberechtigungen.
Was an der IP-Adressierung "verwirrend" sein soll, habe ich nicht wirklich verstanden. Es sind klar abgegrenzte Subnetze und so sollte es doch wohl auch sein. Das einzige Problem, was mir jetzt noch aufgefallen ist: Neu im 2. Subnetz angemeldete Geräte haben sich ihre Adressen beim DHCP-Sever des 1. Subnetzes geholt statt von dem aus dem tatsächlich eigenem 2. Subnetz. Da muss ich die Anfragen wohl noch in den Firewalls der Funk-Brücke blockieren, nur was müsste da noch geblockt werden?
BTW und hat weniger mit dem Netzwerk ansich zu tun: Kann man den Client/CPE irgendwie dazu bewegen, wei einem Funkverlust automatisch die verbindung neu aufzubauen, wenn der Server/AP wieder sichtbar wird?
Neu im 2. Subnetz angemeldete Geräte haben sich ihre Adressen beim DHCP-Sever des 1. Subnetzes geholt
Oh oh oh....Genau das belegt die Vermutung das im Setup der Funkstrecke was gehörig falsch läuft !!!
Du hast scheinbar doch alles als simple Bridge konfiguriert und eben NICHT als gerouteten Link.
Das würde dann auch die Sichtbarkeit der der NAS Freigaben erklären !
In einem gerouteten Umfeld wäre es technisch unmöglich das diese Freigaben sichtbar sind, denn die basieren immer auf Broadcasts und jeder Netzwerker weiss das Broad- und Multicasts niemals über geroutete Verbindungen übertragen werden. Ein simpler TCP/IP Standard.
Mit anderen Worten: Wie bereits vermutet eine völlige Fehlkonfiguration des Links als Bridge.
Fatal ist jetzt das damit dann die jeweiligen IP Subnetze sowohl im einen als auch im anderen Segment verfügbar sind und es damit jetzt zu einem DHCP Chaos kommt.
Je nachdem welcher DHCP Server schneller ist vergibt die IP.
Ein Albtraum aus Netzwerk Sicht.... Das solltest du allerschnellstens wieder geradeziehen !!!
Kann man den Client/CPE irgendwie dazu bewegen, wei einem Funkverlust automatisch die verbindung neu aufzubauen, wenn der Server/AP wieder sichtbar wird?
Ääähhhh...? Wie bitte ?? Das ist simpler Standard !!!Wenn ich hier meinen AP vom netzteil abziehe und wieder aufstecke dann verbindet sich der Client von selber automatisach wieder mit dem AP OHNE manuelle Intervention !!
Das ist auch bei WLAN Links so. Alles andere wäre ja auch technsicher Blödsinn.
1
Bislang wurde die Konfiguration so vorgenommen, wie sie in mehreren HowTo's zu entnehmen waren. Nachdem im Link die Ports 68/69 (DHCP) ins Nirwana geschickt werden, ist das Problem mit den DHCP's auch nicht mehr existierend.
In den Fritzboxen wurden explizit die Routen zum anderen Netz eingetragen, d.h. wenn ich z.B. an einem PC mit der IP 192.168.1.100 den NAS mit der IP 192.168.188.2 anspreche, dann geht die Anfrage an das Standardgateway und von da aus an den Link 192.168.1.3->192.168.128.2->192.168.188.2 (kann mit traceroute bzw tracert nachvollzogen werden). Soweit ich weiss ist das alles bestens. Spreche ich von dem PC ein beliebiges anderes Netz an, dann wird die Anfrage ins Internet geschickt, so sollte es ja sein.
Was Du als "simplen Standard" bezeichnest, scheit in der Realität nicht zu funktionieren. Bei einem Linkverlust wurde bisher noch nie der Link automatisch wieder aufgebaut...
In den Fritzboxen wurden explizit die Routen zum anderen Netz eingetragen, d.h. wenn ich z.B. an einem PC mit der IP 192.168.1.100 den NAS mit der IP 192.168.188.2 anspreche, dann geht die Anfrage an das Standardgateway und von da aus an den Link 192.168.1.3->192.168.128.2->192.168.188.2 (kann mit traceroute bzw tracert nachvollzogen werden). Soweit ich weiss ist das alles bestens. Spreche ich von dem PC ein beliebiges anderes Netz an, dann wird die Anfrage ins Internet geschickt, so sollte es ja sein.
Was Du als "simplen Standard" bezeichnest, scheit in der Realität nicht zu funktionieren. Bei einem Linkverlust wurde bisher noch nie der Link automatisch wieder aufgebaut...
Nachdem im Link die Ports 68/69 (DHCP) ins Nirwana geschickt werden
Uhhhh wie gruselig.Du bekämpfst einfach die Symptome statt die Ursache.
Das ist wiederum ein Indiz das die Ursache allen Übel ein Bridging auf der Funkschnittstelle ist. Du hast jetzt einfach mal den Holzhammer rausgeholt und filterst DHCP Requests auf der einen Seite. Geht natürlich auch aber vom Lösungsansatz völlig falsch !
Sinnvoll ist hier einzig und allein nur ein Routing über die Funkschnittstelle und eben kein Bridging mit den "Verschlimmbesserungen"....aber egal.
scheit in der Realität nicht zu funktionieren.
Tut es hier mit einer reinen Ubiquity und auch einer reinen Mikrotik Linkstrecke als auch einer Ubiquity auf MT und Cisco gemischten vollkommen ohne Probleme. Also standardkonform, denn der WiFi Standard schreibt das vor.Ist ja auch logisch, stell dir mal vor wenn du zuhause wenn du vom Sessel auf die Couch gehst mit deinem Laptop und mal kurzzeitig die Funkverbindung abreisst du dich immer und immer wieder umständlich manuell neu einwählen musst.
Wenn dem so wäre würde weltweit WLAN unverkäuflich sein.
Das ist Unsinn das dem so ist. Kein Kunde würde sowas akzeptieren. Zeugt auch eher davon das bei dir doch erheblich was im Argen ist mit der Funkstrecken Konfig ?!
1
Hallo,
Wäre doch besser gewesen einen eigenen neuen Thread zu dein Problem zu eröffnen anstatt diesen zu kapern. Pinseln dein Netzaufbau mal auf Paier auf, gebe bitte an deinen beiden SXT5 die LAN IP, die WLAN IP in CIDR an, die GWs usw. Hast du DNServer, WINServer in deinenen beiden Netze (Subnetze scheinst ja nicht zu haben) oder wie wird bei euch dort DNS gelöst und oder WINS (Sichtbarkeit eines Clients) oder nutzt ihr ausschließlich OSe bei denen das sehen eines rechners im LAN anders gelöst wurde und somit Routingfähig ist? Dir ist schon klar das ein Router von haus aus die Sichtbarkeit von Rechner in anderen netzten (Routing) verhindert weil die genutzten Protokolle nicht Routingfähig sind. Wäre dem nicht so, dann müsstest do in dein netzwerk dann alle Rechner dieser Erde sehen können Ergo machst du irgendwie Bridging und nicht Routing. Was soll tatsächlich über dein WLAN gehen und was soll nicht darüber laufen? Jedes Bit was du dort überträgst obwohl nicht benötigt klaut dir Benötigte Datenbits auf deiner WLAN Leitung. Wenn nur die Autos auf einer Autobahn fahren die dort müssen - wäre der ein oder andere Stau vermieden. Dann hol aus deinen SXT5's eine Konfiguration als Textdatei und stelle die uns hie rein. Wenn du möchtest auch anonymisiert, aber dann bitte mit Anonymisierungsdaten die Sinn ergeben. Und falls du mal wieder von Anleitungen redest, bitte auch deren Quelle darlegen, sonst weiß keiner hier wovon du redest bzw. was dort steht. Damit ist der dortige Kontext noxh das dortige Ziel erkennbar. Es gibt immer mehr als ein Weg nach Rom und deine Mikrotiks bieten dir genügend Möglichkeiten etwas durcheinander zu bringen. Da gibbet viel Schalter und Häkchen die du verstellen kannst.
> Bislang wurde die Konfiguration so vorgenommen, wie sie in mehreren HowTo's zu entnehmen waren
Welche HowTo's? Von woher? Spätestens ab hier kann dir keiner mehr folgen oder gar nachvollziehen was denn nun gemacht wurde. Sorry, aber du möchtest für dein Problem eine Lösung, dazu muss aber erst dein Problem erkannt werden. Ein Doc fragt dich auch was denn für Schmerzen und wo wenn du Aua sagst
Ein Ipconfig /all sowie ein Route Print eines deiner jeweils im anderen Netz befindlichen Clients tut auch gut. Dazu dann links vom Textkasten dann das Icon oberhalb der Kamera nutzen (Codeblock)
) mal wieder Ordnung herstellen will dann käme ich nicht zum Arbeiten. Ist dort ein öffentlicher HotSpot (Ticketsystem) und anbindung an ein Zweitbüro auf der anderen Hafenseite.
Gruß,
Peter
Wäre doch besser gewesen einen eigenen neuen Thread zu dein Problem zu eröffnen anstatt diesen zu kapern. Pinseln dein Netzaufbau mal auf Paier auf, gebe bitte an deinen beiden SXT5 die LAN IP, die WLAN IP in CIDR an, die GWs usw. Hast du DNServer, WINServer in deinenen beiden Netze (Subnetze scheinst ja nicht zu haben) oder wie wird bei euch dort DNS gelöst und oder WINS (Sichtbarkeit eines Clients) oder nutzt ihr ausschließlich OSe bei denen das sehen eines rechners im LAN anders gelöst wurde und somit Routingfähig ist? Dir ist schon klar das ein Router von haus aus die Sichtbarkeit von Rechner in anderen netzten (Routing) verhindert weil die genutzten Protokolle nicht Routingfähig sind. Wäre dem nicht so, dann müsstest do in dein netzwerk dann alle Rechner dieser Erde sehen können
Ergo machst du irgendwie Bridging und nicht Routing. Was soll tatsächlich über dein WLAN gehen und was soll nicht darüber laufen? Jedes Bit was du dort überträgst obwohl nicht benötigt klaut dir Benötigte Datenbits auf deiner WLAN Leitung. Wenn nur die Autos auf einer Autobahn fahren die dort müssen - wäre der ein oder andere Stau vermieden. Dann hol aus deinen SXT5's eine Konfiguration als Textdatei und stelle die uns hie rein. Wenn du möchtest auch anonymisiert, aber dann bitte mit Anonymisierungsdaten die Sinn ergeben. Und falls du mal wieder von Anleitungen redest, bitte auch deren Quelle darlegen, sonst weiß keiner hier wovon du redest bzw. was dort steht. Damit ist der dortige Kontext noxh das dortige Ziel erkennbar. Es gibt immer mehr als ein Weg nach Rom und deine Mikrotiks bieten dir genügend Möglichkeiten etwas durcheinander zu bringen. Da gibbet viel Schalter und Häkchen die du verstellen kannst.> Bislang wurde die Konfiguration so vorgenommen, wie sie in mehreren HowTo's zu entnehmen waren
Welche HowTo's? Von woher? Spätestens ab hier kann dir keiner mehr folgen oder gar nachvollziehen was denn nun gemacht wurde. Sorry, aber du möchtest für dein Problem eine Lösung, dazu muss aber erst dein Problem erkannt werden. Ein Doc fragt dich auch was denn für Schmerzen und wo wenn du Aua sagst
Nachdem im Link die Ports 68/69 (DHCP) ins Nirwana geschickt werden, ist das Problem mit den DHCP's auch nicht mehr existierend.
Irgendwie der ganz falsche weg etwas zu tun - Erst die Möglichkeit schaffen das irgendwie etwas doch geht - nur um es dann totzutrampeln. Vielleicht erfordert dein Netz inkl. das 2te Netz am anderen Standort (per WLAN Verbunden) ein komplettes redesign. Wenn dein Auto in Zukunft nur noch Strom will, musst dein Tankstellennetz in deiner Birne auch neu erstellen In den Fritzboxen
Bitte auch auf dein Mal-papier hinmalen.Ein Ipconfig /all sowie ein Route Print eines deiner jeweils im anderen Netz befindlichen Clients tut auch gut. Dazu dann links vom Textkasten dann das Icon oberhalb der Kamera nutzen (Codeblock)
Was Du als "simplen Standard" bezeichnest, scheit in der Realität nicht zu funktionieren. Bei einem Linkverlust wurde bisher noch nie der Link automatisch wieder aufgebaut...
Dann liegt bei dir ein Konfigurationsfehler vor - ein gravierender. Auch bei einer Bridge (egal in welchem Frequenzband) wird der Leitung *+automatisch** neu aufgebaut - ausser es liegt ein Konfigfehler oder ein Hardware-problem vor. Wenn ich mir vorstellen jedesmal entweder per Fernwartung oder durch hinfliegen (Insel in Spanien) meine dortige Bridge neu zu starten weil dort mal wieder Stromausfall (USVen dort reichen nur für ca. 360 Minuten - und ja ab und an dauert dort ein Stromausfall schon mal 8 oder mehr Stunden (ca. 1-3% der Ausfälle)), Gewitter oder ein möchtegern Hausmeister (nur wenns einer aus Alemania ist ) mal wieder Ordnung herstellen will dann käme ich nicht zum Arbeiten. Ist dort ein öffentlicher HotSpot (Ticketsystem) und anbindung an ein Zweitbüro auf der anderen Hafenseite.Gruß,
Peter
1
Hallo ihr beiden...
Den Thread "kapern" wolte ich eigentlich nicht, nur war die Ursprungsthematik dieselbe und es ging da nicht weiter, daher hatte ich mich drangehängt, um vielleicht weitere Lösungsansätze zu schaffen. Gern mache ich dafür aber einen neuen Thread auf und werde dann tatsächlich auch ein Bild des Netzwerkaufbaus einfügen, zumal sich daran jetzt noch etwas ändern soll. Entsprechend werde ich darin den Ist-Zustand dokumentieren und den Soll-Zustand andersfarbin darin implementieren.
In Bezug auf das Reconnecten hbe ich absolut Null Einstellmöglichkeiten gefunden und ggf. hole ich den Client am Freitag nochmal hierher, um eine komplett neue Konfig aufzusetzen. Bisher war bei jedem linkabbruch immer ein manuelles Eingreifen erforderlich und leider sind diese noch regelmässig, weil mit -85 bis -90 dB ist der Link derzeit noch knapp über der Grasnabe.
Also gehe ich im wahrsten Sinne des Wortes zurück ans Zeichenbrett ;)
Mal ohne große Hilfsmittel skizziert, enthält nur obligatorische Komponenten, habe jetzt nicht relevante Dinge (z.B. Drucker, weitere PC's etc) ausgelassen. Reicht das Diagramm? Dann würde ich damit einen neuen Thread öffnen.
Den Thread "kapern" wolte ich eigentlich nicht, nur war die Ursprungsthematik dieselbe und es ging da nicht weiter, daher hatte ich mich drangehängt, um vielleicht weitere Lösungsansätze zu schaffen. Gern mache ich dafür aber einen neuen Thread auf und werde dann tatsächlich auch ein Bild des Netzwerkaufbaus einfügen, zumal sich daran jetzt noch etwas ändern soll. Entsprechend werde ich darin den Ist-Zustand dokumentieren und den Soll-Zustand andersfarbin darin implementieren.
In Bezug auf das Reconnecten hbe ich absolut Null Einstellmöglichkeiten gefunden und ggf. hole ich den Client am Freitag nochmal hierher, um eine komplett neue Konfig aufzusetzen. Bisher war bei jedem linkabbruch immer ein manuelles Eingreifen erforderlich und leider sind diese noch regelmässig, weil mit -85 bis -90 dB ist der Link derzeit noch knapp über der Grasnabe.
Also gehe ich im wahrsten Sinne des Wortes zurück ans Zeichenbrett ;)
Mal ohne große Hilfsmittel skizziert, enthält nur obligatorische Komponenten, habe jetzt nicht relevante Dinge (z.B. Drucker, weitere PC's etc) ausgelassen. Reicht das Diagramm? Dann würde ich damit einen neuen Thread öffnen.
Hallo,
dann ist dort was faul oder es liegt gar ein Defekt vor.
Fresnel Zone ist frei?
Antennen werden welche verwendet?
Eigentlich ist dein Signal schon 2 Meter unter der Erde.
Warum nicht mit deinen beiden 7490 ein Standort zu Standort VPN nutzen? Dürfte Schneller und Stabiler sein...
Und ein IPCionfig /all eines Clients aus jeder seite sowie ein Route print.
Gruß,
Peter
dann ist dort was faul oder es liegt gar ein Defekt vor.
um eine komplett
Konfig hier rein zu stellenweil mit -85 bis -90 dB ist der Link derzeit noch knapp über der Grasnabe.
Abstand der Geräte(Antennen)?Fresnel Zone ist frei?
Antennen werden welche verwendet?
Eigentlich ist dein Signal schon 2 Meter unter der Erde.
Warum nicht mit deinen beiden 7490 ein Standort zu Standort VPN nutzen? Dürfte Schneller und Stabiler sein...
Reicht das Diagramm?
JaUnd ein IPCionfig /all eines Clients aus jeder seite sowie ein Route print.
Dann würde ich damit einen neuen Thread öffnen.
Ist das beste. Mit Link von und zu diesen FredGruß,
Peter
Weiter geht's in Zwei private Netzwerke (LAN und WLAN) mit SXT Lite5 verbinden
Um Deine Fragen athok noch zu beantworten:
Abstand der Antennen ca. 650 Meter und derzeit besteht keine Sichtverbindung zwischen den Antennen (SXT haben eingebaute Richtantennen), wird vermutlich auch nach Montage auf dem Dach nicht frei sein, weil eines der Gebäude zu tief steht. VPN via Internet scheidet aufgrund des langsamen Uplinks der zweiten FB aus.
Grüße, Micha
Um Deine Fragen athok noch zu beantworten:
Abstand der Antennen ca. 650 Meter und derzeit besteht keine Sichtverbindung zwischen den Antennen (SXT haben eingebaute Richtantennen), wird vermutlich auch nach Montage auf dem Dach nicht frei sein, weil eines der Gebäude zu tief steht. VPN via Internet scheidet aufgrund des langsamen Uplinks der zweiten FB aus.
Grüße, Micha
