Ich habe folgendes Problem, dass beim ersten Zugriff über SSH immer folgende Meldung erscheint "ssh: connect to host rpi4xyz port 22: No route to host" die Namensauflösung kann es aber nicht sein da das Problem auch besteht wenn man die IP-Adresse verwendet. Hat jemand eine Idee wie man rausfinden kann woran das hängt. Reagiert der RPI4 evtl. zu langsam? Oder könnte das ein Problem der Firewall sein.
Kanst du ihn anpingen? Kannst du einen Portscan auf ihn loslassen? Was sagt traceroute?
:
Bearbeitet durch User
ich werde das morgen nochmal probieren(Router wird nachts neu gestartet), da ich ihn inzwischen schon angesprochen habe Ping 64 bytes from RPi4xyz (192.168.2.191): icmp_seq=3 ttl=64 time=10.3 ms 64 bytes from RPi4xyz (192.168.2.191): icmp_seq=4 ttl=64 time=5.89 ms 64 bytes from RPi4xyz (192.168.2.191): icmp_seq=5 ttl=64 time=6.49 ms 64 bytes from RPi4xyz (192.168.2.191): icmp_seq=6 ttl=64 time=10.6 ms 64 bytes from RPi4xyz (192.168.2.191): icmp_seq=7 ttl=64 time=4.100 ms 64 bytes from RPi4xyz (192.168.2.191): icmp_seq=8 ttl=64 time=4.76 ms 64 bytes from RPi4xyz (192.168.2.191): icmp_seq=9 ttl=64 time=5.16 ms Traceroute 30 hops max, 60 byte packets 1 * 2 * 3 * 4 * 5 * 6 * RPi4xyz (192.168.2.191) 93.641 ms 94.342 ms nmap -p-65535 rpi4xyz läuft noch,....
Wie bist du denn mit dem RPi verbunden? Direkt, Router dazwischen, sonstiges? Kann auch an einer Firewall liegen, klar. Sollte man in den Logdateien finden können. Vielleicht ist auf deinem RPi auch irgendein Sicherheitssystem installiert, das erst die zweite Verbindung akzeptiert... Security ist manchmal eher Voodoo. MfG, Arno
1 | sudo systemctl enable sshd |
2 | sudo systemctl restart sshd |
und mit
1 | ssh-keygen --help |
sollte man sich auch bischen beschäftigen. Nachtrag: https://www.heise.de/tipps-tricks/Raspberry-Pi-SSH-einrichten-so-geht-s-4190645.html https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html
:
Bearbeitet durch User
Mister A. schrieb: > sollte man sich auch bischen beschäftigen. Löst aber nicht "No route to host". Ein nicht laufender sshd erzeugt "connection refused". "No route to host" ist eher ein ARP/Ethernet-Issue. Aber ein
1 | 6 * RPi4xyz (192.168.2.191) 93.641 ms 94.342 ms |
spricht für einen ziemlichen F*ck*p im Netzwerk, wenn ein Ping mit 6ms durchgeht.
Georg A. schrieb: > Ein nicht laufender sshd erzeugt > "connection refused". Aaargh stimmt, eine Sekunde nicht aufgepasst :) Na dann, das WiFi Kabel gegen ein altmodisches 8poliges RJ45 tauschen. Uuuu ich sehe es schon kommen: 2 IP-Adressen, die Fritte dreht durch, Windows erst recht, der Begriff metric wird erfunden, Linux is sch** :) Vorsorglich werfe ich schon mal ein
1 | sudo systemctl disable wpa_supplicant |
2 | sudo ifdown wlan0 |
in den Raum. Thomas O. schrieb: > Reagiert > der RPI4 evtl. zu langsam? Oder könnte das ein Problem der Firewall > sein. Nein, eher der DNS 8.8.8.8 und 8.8.4.4
:
Bearbeitet durch User
und die nmap Ergebnisse Starting Nmap 7.70 ( https://nmap.org ) at 2020-10-02 22:58 CEST Warning: 192.168.2.191 giving up on port because retransmission cap hit (10). Nmap scan report for RPi4xyz-6.fritz.box (192.168.2.191) Host is up (0.064s latency). Not shown: 65310 closed ports, 224 filtered ports PORT STATE SERVICE 22/tcp open ssh Nmap done: 1 IP address (1 host up) scanned in 43869.48 seconds
interne Host werden aber doch nicht vom DNS aufgelöst. Mal kurz eine Beschreibung meines Netzwerkes falls es zur Lösung beiträgt OG DD-WRT Router als AP 192.168.2.3 DHCP off EG DD-WRT Router als AP 192.168.2.2 DHCP Server KG Fritzbox 7490 als AP 192.168.2.1 DHCP off
und hier ein frischer Ping ohne vorher verbunden gewesen zu sein, man sieht das der erste länger dauert als die nachfolgenden. ping rpi4xyz PING rpi4xyz (192.168.2.191) 56(84) bytes of data. 64 bytes from RPi4Luca (192.168.2.191): icmp_seq=1 ttl=64 time=112 ms 64 bytes from RPi4Luca (192.168.2.191): icmp_seq=2 ttl=64 time=10.5 ms 64 bytes from RPi4Luca (192.168.2.191): icmp_seq=3 ttl=64 time=12.1 ms 64 bytes from RPi4Luca (192.168.2.191): icmp_seq=4 ttl=64 time=20.6 ms 64 bytes from RPi4Luca (192.168.2.191): icmp_seq=5 ttl=64 time=12.7 ms 64 bytes from RPi4Luca (192.168.2.191): icmp_seq=6 ttl=64 time=8.32 ms --- rpi4xyz ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 14ms rtt min/avg/max/mdev = 8.315/29.449/112.478/37.327 ms und einmal mit der direkten IP da schauts aber noch schlimmer aus und es kommt zu Paketverlusten wobei ich ein paar mal mit STRG+C oder STRG+X es abzubrechen. ping 192.168.2.191 PING 192.168.2.191 (192.168.2.191) 56(84) bytes of data. 64 bytes from 192.168.2.191: icmp_seq=1 ttl=64 time=672 ms 64 bytes from 192.168.2.191: icmp_seq=2 ttl=64 time=9.41 ms 64 bytes from 192.168.2.191: icmp_seq=3 ttl=64 time=8.06 ms 64 bytes from 192.168.2.191: icmp_seq=4 ttl=64 time=8.27 ms 64 bytes from 192.168.2.191: icmp_seq=5 ttl=64 time=23.2 ms 64 bytes from 192.168.2.191: icmp_seq=6 ttl=64 time=7.47 ms 64 bytes from 192.168.2.191: icmp_seq=7 ttl=64 time=878 ms 64 bytes from 192.168.2.191: icmp_seq=8 ttl=64 time=410 ms 64 bytes from 192.168.2.191: icmp_seq=11 ttl=64 time=115 ms 64 bytes from 192.168.2.191: icmp_seq=12 ttl=64 time=5.55 ms 64 bytes from 192.168.2.191: icmp_seq=13 ttl=64 time=8.56 ms 64 bytes from 192.168.2.191: icmp_seq=14 ttl=64 time=5.29 ms 64 bytes from 192.168.2.191: icmp_seq=15 ttl=64 time=4.52 ms 64 bytes from 192.168.2.191: icmp_seq=16 ttl=64 time=14.3 ms 64 bytes from 192.168.2.191: icmp_seq=17 ttl=64 time=10.2 ms 64 bytes from 192.168.2.191: icmp_seq=18 ttl=64 time=13.1 ms 64 bytes from 192.168.2.191: icmp_seq=19 ttl=64 time=9.37 ms 64 bytes from 192.168.2.191: icmp_seq=20 ttl=64 time=20.8 ms --- 192.168.2.191 ping statistics --- 20 packets transmitted, 18 received, 10% packet loss, time 99ms rtt min/avg/max/mdev = 4.515/123.456/877.541/250.566 ms
Sieht nach wackeligem WLAN aus. "No route to host" gibt es je nach Betriebssystem auch im lokalen Netz, wenn die ARP-Requests nicht beantwortet werden. Es kann helfen, das WLAN-Power-Saving (sofern aktiviert) abzuschalten, das führt gerne mal zu Problemen.
Wer Funk kennt, nimmt Kabel - hast du dir mal über die belegten Kanäle und Nachbarnetzwerke Gedanken gemacht? Deine 3 APs sollten auf 3 Kanäle und dann ist es sinnvoll, sich von den Kanälen der Nachbarn fernzuhalten. Da wirds nämlich meistens schon eng.
Thomas O. schrieb: > interne Host werden aber doch nicht vom DNS aufgelöst. Ich kenne keine internen oder externen hosts. Nur hosts in einem Subnet und hosts außerhalb des Subnets (via Route oder Gateway). Die Namensauflösung erfolgt a) durch die /etc/hosts und b) durch die DNS in /etc/resolv.conf. DNS welche vom DHCP verteilt oder statisch hinterlegt sind. I.d.F. ist es die Fritte im Keller. Als DNS sollte sie, nur sich verteilen, keine externen DNS Server. Wenn die beiden APs auch selbständig DNS Server sind, können sie aufgenommen werden. Aber nun die bessere Frage, wie sind die beiden APs an die FritzBox angebunden? Kabel/Bridge oder als Repeater? Hoffentlich ist der letzte im DG nicht einfach kaskadiert. Hast du die Kontrolle welcher WiFi client sich an welchem AP einklinkt? Wählt er einen bestimmten, den stärksten oder nach Auslastung und Latenz? Matthias S. schrieb: > Deine 3 APs sollten auf 3 Kanäle und dann ist es sinnvoll, sich von den > Kanälen der Nachbarn fernzuhalten. Guter Ansatzpunkt. Aber die Anzahl der Kanäle wird nicht mehr, die Nachbarn fahren und funken auf der gleichen Autobahn. In der Tat sollte man sich die Kanalverteilung anschauen. Die Fritte macht das von Haus aus schon gut. Bei den beiden DD-WRT APs sollte man Hand anlegen (Kanalauswertung der Fritte zu Hilfe nehmen) und den Abstand beachten. Die Mbits der WiFi-Clientverbindung kommen nicht zufällig zustande, sondern durch Bündelung der angrenzenden Kanäle. Und die wurden noch nicht genannt.
:
Bearbeitet durch User
die beiden oberen AP hängen per LAN Kabel an der Fritzbox. Die Kanalverteilung passt, also meine Router haben nen festen Kanal( 1, 6 und 11) und die Nachbargeräte wählen den Kanal den die Fritzbox (11) im Keller hat, stört mich aber gar nicht da eigentlich niemand mit der FB im Keller verbunden ist und wenn doch kommt da von den Nachbarn nichts durch. Ja ich sehe welche Clients mit welchen Router(AP) verbunden sind. Ich kann dort auch Mindestsignalstärken vorgeben, so das sich ein schwächerer Teilnehmer aus dem EG nicht mit dem Router im OG verbindet. Im 5 GHz Band ist es auch so Kanalnummern müsste ich aber nachschauen. Meine Verbindung ist ansonsten 1A. Netflix, Amazone Prime.... Nur bei der SSH Verbindung ist es mir aufgefallen das ich das manchmal ein 2tes Mal anstoßen muss. Ich werde mal die Tage etwas mit der ARP Cache rumprobieren.
wie sehen eure Pingzeiten zum Vergleich aus?
:
Bearbeitet durch User
Thomas O. schrieb: > die Namensauflösung kann es aber nicht sein da das Problem auch besteht > wenn man die IP-Adresse verwendet. Doch, denn ssh will den Namen überprüfen. Mache einen Eintrag in /etc/hosts
Soweit gut. Die Priorisierung dürfte das einzige Problem sein. Ich habe keine Fritte mehr, glaube noch in Erinnerung zu haben, den Abschnitt in den Extended/Expert Settings gesehen zu haben. Versuche mal dort, nach der Telefonie/VoIP, eine Dienstgruppe anzulegen und DNS, ssh, ntp, icmp aufzunehmen. Danach erst http, https, FTP, multicast usw. Das sollte sich bemerkbar machen, die Antwortzeiten verkürzen und grundlegenden Diensten eine höhere Priorität einräumen. Du könntest testweise den Raspi mit statischen Daten, statt DHCP, füttern. Das könnte ggf. ein wenig beitragen. Das böse ist, es laufen auch ungewollte Dienste wie Zeroconf. In einer Windowsumgebung quatschen die Rechner untereinander mehr als lieb und nötig. Das läppert sich zusammen.
:
Bearbeitet durch User
Thomas O. schrieb: > Traceroute 30 hops max, 60 byte packets > 1 * > 2 * > 3 * > 4 * > 5 * > 6 * RPi4xyz (192.168.2.191) 93.641 ms 94.342 ms Wenn dein Netzwerk richtig konfiguriert ist, darf traceroute hier gar nicht bis 6 kommen. Eventuell sind noch ein paar Angaben hilfreich: Raspberry über Kabel oder WLAN angebunden? Raspberry mit DHCP oder statischer IO? Gleiches für Linux Maschine, auf der SSH gestartet wir? Wer macht DNS? Warum läuft DHCP nicht auf den Gazeway? Stefan ⛄ F. schrieb: > Doch, denn ssh will den Namen überprüfen. Mache einen Eintrag in > /etc/hosts Da würde ich eher schauen, dass DNS sauber läuft.
Nobody schrieb: > Da würde ich eher schauen, dass DNS sauber läuft. Verrate uns mal wie du schauen würdest, ob es sauber läuft. DNS läuft auf der FritzBox. Und was bedeutet d.M.n. Netzwerk richtig konfiguriert? Warum darf traceroute nicht bis zum 6. hop kommen? Ergo was bedeuten die anderen 5 * ?
:
Bearbeitet durch User
Beitrag #6427483 wurde vom Autor gelöscht.
Mister A. schrieb: > Warum darf traceroute nicht bis zum 6. hop kommen? > Ergo was bedeuten die anderen 5 * ? Gegenfrage: Warum soll traceroute überhaupt über einen Router gehen, da ja alles in 192.168.2.0/24(?) passiert.
Mister A. schrieb: >> Da würde ich eher schauen, dass DNS sauber läuft. > Verrate uns mal wie du schauen würdest, ob es sauber läuft. DNS läuft > auf der FritzBox. Bei der Auflösung mit Fritz.Box. Es wird aber auch mal ohne Fritz.Box aufgelöst. Aber ohne Angaben vom TO ist das was für die Glaskugel.
Nobody, das ist Käse. Entschuldige. Der TO hat Engpässe in der Leitung. Da ist nichts mit einen ping reparierbar. Nebenbei, ein pathping könnte etwas mehr Licht bringen, um die Problemstelle zu lokalisieren. Hier wird m.M.n. ordentlich geflutet und eingestreut. Das kann einerseits eine schlechte/lange/billige Hauptleitung zum Router sein. Oder kaskadierte Hubs/Switches zwischendrinn. Anderseits die Grundlast eines oder mehrerer Geräte, welche den DNS dermaßen fluten, dass er nicht mehr nachkommt. Kandidaten: Ein fröhlich tanzender Windows Rechner, ein alter Sat-Receiver, der Sohn der ordentlich zockt, die Tochter die am Chat hängt oder ein paar SmartTV die im Sekundentakt nach .cn reporten. Dann noch ein paar SmartHome und IoT devices. Das läppert sich schnell zusammen. Ich würde versuchen den DNS hochzustufen oder ihm eine Entlastung z.V. stellen. Der Raspi wird eh gerade "in Betrieb genommen". Darauf mal einen DNS Filter drauflegen (Pi-Hole) und auf der FritzBox als ersten DNS dahin verweisen. Dann die einzelnen Abschnitte/Teilstrecken untersuchen. Leute, lasst uns die Sache strukturiert und vernünftig angehen.
:
Bearbeitet durch User
Mister A. schrieb: > Nobody, das ist Käse. Entschuldige. Ok, wenn du meinst. Trotzdem hätte ich gerne eine Erklärung für die 6 Hops.
Nobody schrieb: > Gegenfrage: Warum soll traceroute überhaupt über einen Router gehen, da > ja alles in 192.168.2.0/24(?) passiert. Weil der client per Wifi am AP hängt. Womöglich er auch noch NAT-ed. Dazwischen 2-3 switches kaskadiert sind. Ich habe auch keine Glaskugel, nur logisches Denken. Dazu müsste man die ifconfig und routing-tables jedes einzelnen interfaces samt Netzwerkplan haben.
:
Bearbeitet durch User
Mister A. schrieb: >> ja alles in 192.168.2.0/24(?) passiert. > Weil der client per Wifi am AP hängt Komisch, bei mir geht traceroute über WLAN auch direkt zum Ziel. Sollte das WLAN bzw. Der AP nicht für traceroute transparent sein? Doppeltes NAT schließe ich auf Grund von alles in 192.168.2.0/24 aus. Bezüglich des Netzwerkplans stimme ich dir aber zu.
Thomas O. schrieb: > 64 bytes from RPi4xyz (192.168.2.191): icmp_seq=3 ttl=64 time=10.3 ms > 6 * RPi4xyz (192.168.2.191) 93.641 ms 94.342 ms Das ist - gelinde gesagt - merkwürdig, und sollte Anlass sein, das Networking insgesamt näher zu beleuchten. Ist sonst stochern im Nebel.
Oben wurde DD-WRT erwähnt. Ich gehe von Bridge-members (eth0-n und wlan0) aus. Da kommt nichts durchsitiges heraus. Ein ifconfig von dem würde sicherlich nur ein einzelnes iface herausspucken. Die beiden AP-Router wären eigentlich ideale Kandidaten den DNS zu verstärken. Vielleicht geistert auch noch irgendwo ein PC herum, bei dem 2 NIC gebondet wurde. Oder zus. noch ein USB-Wifi-Stick. Spanning tree gibts ja seit Jahunderten, keiner nutzt es :(
A. K. schrieb: > Das ist - gelinde gesagt - merkwürdig, und sollte Anlass sein, das > Networking insgesamt näher zu beleuchten. Ist sonst stochern im Nebel. Ja leider. Aber das kennen wir alle. Jahrelang wird aufgerüstet und dazu gebaut und dazu gesteckt. An der Infrastruktur wird nichts geändert. Da kauft man einfach einen 4-Port Switch dazu, wenn kein Stecker mehr Platz hat. Ja, Netzwerkplan könnte der TO schon zeichnen oder skizzieren.
Mister A. schrieb: > Ja, Netzwerkplan könnte der TO schon zeichnen oder skizzieren. Wenn er überhaupt noch mitliest.
Mister A. schrieb: > Ergo was bedeuten die anderen 5 * ? Diese 5 Hops antworten nicht auf die Pings vom Traceroute, leiten aber die Verbindung weiter zum nächsten Hop.
Stefan ⛄ F. schrieb: > Diese 5 Hops antworten nicht auf die Pings vom Traceroute, leiten aber > die Verbindung weiter zum nächsten Hop. Die Frage ist, warum es dazu überhaupt kommt, da ja so wie es aussieht alle in selben Subnet ist.
Stefan ⛄ F. schrieb: > Diese 5 Hops antworten nicht auf die Pings vom Traceroute, leiten aber > die Verbindung weiter zum nächsten Hop. Ich weiss was die Sternchen bedeuten und wo sie herkommen :) Nobody schrieb: > alle in selben Subnet ist. Tja. NAT, Bridge, Filter. Ich hätte von den AP auch ein anderes Subnet erwartet. Scheint pseudo-Transparenz zu sein.
:
Bearbeitet durch User
Ich wollte ja eben alles in einem Subnetz haben. Da die AP ja eher Switches sind sollte da keine NAT greifen. Die Firewalls der beiden AP sind auch deaktiviert.
soweit ich kann, liefere ich euch natürlich alle Infos, ist ja kein Geheimnis was ich da habe.
1 | ISP------Fritzbox(KG)-----LAN------AP1(EG) ))))WLAN-Client der SSH startet |
2 | 192.168.2.1 192.168.2.2 |
3 | DHCP Server off DHCP Server on |
4 | DNS von ISP zugewiesen Firewall off |
5 | | lok. DNS 192.168.2.1 |
6 | |
|
7 | -----------LAN------AP2(OG) ))))WLAN-Client auf den per SSH zugegriffen werden soll |
8 | 192.168.2.3 |
9 | DHCP Server off |
10 | Firewall off |
11 | lok. DNS 192.168.2.1 |
DHCP lasse ich von einem der DD-WRT AP erledigen da man hier alles auf einer Seite hat. Bei der Fritzbox, muss man jeden Teilnehmer aufrufen in ein neues Menü wechseln dort alles einstellen und speichern dann wählt man den nächsten Teilnehmer aus usw. Wenn das wegen NAT ein Problem ist sollte man das mit Portforwarding/Porttriggering hinbekommen oder?
Die beiden AP sind Router (keine WLAN Bridges), deswegen brauchen sie meiner Meinung nach auf der rechten Seite jeweils ein eigenes Subnetz. Also zum Beispiel: FritzBox: 192.168.2.x AP1: 192.168.3.x AP2: 192.168.4.x Und weil die FritzBox nur 192.168.2.x ins Internet lässt, müsste man dann wohl auf beiden AP auch das NAT einschalten. So stelle ich mir das jedenfalls vor, so läuft es bei mir zu hause (allerdings mit nur einem AP).
das man unterschiedliche Subnetze wählt hat ja eigentlich damit zu tun damit sich die ggf. die 3 DHCP-Server nicht in die Quere kommen oder sehe ich das falsch. Was mich an getrennten Subnetzen stört ist das ich wenn ich auf den Router eines anderen Subnetztes zugreifen will auch meine IP ändern muss und ich z.B. DHCP Static-Leases nicht zentral verwalten kann, sondern das dann in 3 Routern machen muss.
Thomas O. schrieb: > Was mich an getrennten Subnetzen stört ist das ich wenn ich auf den > Router eines anderen Subnetztes zugreifen will auch meine IP ändern muss > und ich z.B. DHCP Static-Leases nicht zentral verwalten kann, sondern > das dann in 3 Routern machen muss. Keine Ahnung. Thomas O. schrieb: > Was mich an getrennten Subnetzen stört ist das ich wenn ich auf den > Router eines anderen Subnetztes zugreifen will auch meine IP ändern muss > und ich z.B. DHCP Static-Leases nicht zentral verwalten kann, sondern > das dann in 3 Routern machen muss. Damit verlangst du aber das Unmöglich von deinen Routern. Sie sollen immer wissen, wo du dich gerade befindest obwohl deine IP Adresse diese Info nicht her gibt. Ich denke, das ist der Fehler. Alle Rechner innerhalb eines Sub-Netzes haben die gleiche Adresse. An der Adresse erkennen Rechner, ob das Ziel ein direkter Nachbar im selben Subnetz ist (ohne Router erreichbar) oder in einem anderen Subnetz über das default Gateway. Du hast physikalisch drei Subnetze und drei Gateways, deswegen brauchst du auch drei unterschiedliche Bereiche von IP Adressen. Sonst kann das Routing nicht korrekt funktionieren.
Ich würde auch ein Netz gegenüber mehreren + routing bevorzugen. Die FB wird sich schon merken, von welchem LAN-Interface / WLAN-Client das ARP packet zuletzt kam. Ausserdem bleiben die Verbindungen dann erhalten, wenn man den AP wechselt. Nur die FritzBox braucht dann halt eventuell einen Moment um zu merken, man nicht mehr über das alte Interface erreichbar ist, und muss dann nochmal alle fragen "Wer hat IP X", und dann kommt die ARP Antwort halt von nem anderen Interface zurück. TCP fängt den Unterbruch ja dann ab. @Thomas was bekommen die Clients eigentlich als DNS Server per DHCP? Ich nehme an, das DNS Zone Update durchgeführt von AP1 betrifft nur das DNS von AP1. Haben die Clients im Netz auch nur den als DNS eingetragen?
Thomas O. schrieb: > DHCP Static-Leases nicht zentral verwalten kann, sondern > das dann in 3 Routern machen muss. Du kannst DHCP Leases durchaus zentral verwalten, egal ob statisch oder nicht, statt es in 3 Routern einzeln machen zu müssen. Voraussetzung für zentrales DHCP ist entweder ein DHCP-Server, der in jedem Netz ein Bein hat, oder Router, die DHCP-Request forwarden können. Wenn allerdings diese Netze alle die gleichen Netzadresse haben, dann ist ein Postzusteller nicht zu beneiden, der fehlerfrei an drei verschiedene Thomas O in getrennten Häusern aber gleicher Hausnummer zustellen soll.
Beitrag #6428199 wurde vom Autor gelöscht.
Switches sind keine Hubs. Klar, am anfang und nach AP wechsel müssen sie es überall probieren, aber dann erstmahl nicht mehr: https://de.wikipedia.org/wiki/Switch_(Netzwerktechnik)#Source_Address_Table
🐧 DPA 🐧 schrieb: > Die FB wird sich schon merken, von welchem LAN-Interface / > WLAN-Client das ARP packet zuletzt kam. Die Forwarding-Table eines L2-Switch assoziiert MAC-Adressen mit Ports. Wandert eine MAC an einen anderen Port, kriegt der Switch das erst mit, wenn er vom neuen Port ein Paket mit dieser Adresse empfängt. Davor gehen ausgehende Pakete an den alten Port. Angesichts der Geschwätzigkeit üblicher Geräte ist das allerdings ein meist recht kurzer Zeitraum.
Eventuell könnte der andere AP noch ein ICMP typ 3 (destination unreachable) generieren, das jenachdem das auch nochmal beschleunigen könnte.
Stefan ⛄ F. schrieb: > Also zum Beispiel: > FritzBox: 192.168.2.x > AP1: 192.168.3.x > AP2: 192.168.4.x > > Und weil die FritzBox nur 192.168.2.x ins Internet lässt, müsste man > dann wohl auf beiden AP auch das NAT einschalten. Zusätzlich wäre noch eine Portweiterleitung für SSH auf den Raspi eicnzurichten.
@TO In welchem Modus arbeiten AP1 und AP2. Ich gehe mal nicht von Routermodus aus.
🐧 DPA 🐧 schrieb: > Ich würde auch ein Netz gegenüber mehreren + routing bevorzugen. So funktioniert TCP/IP aber nicht. Wenn Rechner A dem Rechner B etwas senden will, dann guckt er sich IP Adresse des Ziels an. Befindet sie sich im gleichen Subnetz, kann er das Paket direkt an B senden. Befindet sie sich in einem anderen Netz, dann sendet A das Paket an das Gateway mit der Bitte, es nach B weiter zu leiten. Die Router sind Gateways. Sie leiten Anfangen von A nach B nur dann weiter, wenn A ausdrücklich darum gebeten hat. Und das tut A nur dann, wenn die Adresse von B ein anderes Netz kennzeichnet. Was der Thomas da vor hat geht nur, indem man die Router (Gateways) AP1 und AP2 durch Switche ersetzt. Für den Übergang von Kabel zu WLAN braucht man in diesem Fall hingegen sogenannte Bridges. Die Geräte, die er vorliegen hat, können aber weder Switch noch Bridge sein, denn es sind Router.
Stefan ⛄ F. schrieb: > Die Geräte, die er vorliegen hat, können aber weder Switch noch Bridge > sein, denn es sind Router. Da wäre ich mir nicht so sicher. Ich habe einige "Router" mit AP, die gleichzeitig auch noch switches und was weiss ich was alles sind. Und bei einigen davon kann man sogar den "WAN" Port umkonfigurieren, dass er wie die restlichen LAN ports funktioniert. Warum solte also nicht auch sein AP nicht als Bridge konfigurierbar sein? Stefan ⛄ F. schrieb: > Was der Thomas da vor hat geht nur, indem man die Router (Gateways) AP1 > und AP2 durch Switche ersetzt. Ein guter punkt. In der tat, wenn seine APs als reine Router konfiguriert wären, dürfte er den PI doch überhaupt nicht erreichen können, auch nicht beim 2ten Versuch! Von daher kann sein AP doch eigentlich hier garnicht als Router gewirkt haben!
Dir 4-5 Ethernet Buchsen hängen ja an einem Switch. Der Übergang zu WLAN geht aber nicht am Router vorbei.
🐧 DPA 🐧 schrieb: > Eventuell könnte der andere AP noch ein ICMP typ 3 (destination > unreachable) generieren, das jenachdem das auch nochmal beschleunigen > könnte. Mir fällt da gerade noch ein, das würde das initiale "No route to host" erklären. Da der PC und der PI beim Kommunizieren im selben Netz ja ihre MAC addressen in die Packete schreiben, und nicht die von nem AP oder von nem Router, wird wenn der AP so ein Packet generiert das vermutlich an den PC gesendet stat an die FritzBox. Falls das das eigentliche Probem ist, gibt es 2 mögliche Lösungen: 1) Das Generieren der ICMP Nachricht beim AP abschalten, falls möglich 2) Die ICMP Nachricht bei der Fritzbox herausfiltern, falls möglich Alternativ könnte man eventuell auch versuchen, falls möglich, bei der Fritzbox einen ARP-Proxy einrichten, damit die ICMP-Packete zur Fritzbox gehen. Ich kenne mich mit ARP-Proxies aber nicht aus, und weiss nicht, ob das wirklich was nützen würde.
ok ich versuche mal auf alles zu antworten Ihr meint also das ein Rechner z.B. 192.168.2.100 hinter AP1 eine Anfrage an Rechner 192.168.2.130 hinter AP2 per 192.168.2.2 verschickt da er hinter einer NAT ist. Ich dachte da ein AP die IPs verwaltet kennt er alle IP so das es kein NAT Problem gibt. Wenn ich jetzt getrennte Subnetze hätte würde ja trotzdem alle Rechner hinter der jeweiligen NAT stecken. Können in einer Porttabelle mehrere MACs einen Port zugewiesen sein. Ich hätte meine Konfiguration eher so eingeschätzt, dass hier mehrere Switches zusammenarbeiten und da darf es eben nur einen DHCP Server geben. /Alle Rechner innerhalb eines Sub-Netzes haben die gleiche Adresse. An der Adresse erkennen Rechner, ob das Ziel ein direkter Nachbar im selben Subnetz ist (ohne Router erreichbar) oder in einem anderen Subnetz über das default Gateway./ Nach außen ja nach innen sind Sie durch x.x.x.0-255 unterscheidbar und somit direkte Nachbarn genau das will ich haben. @DPA: Die Clients bekommen den DNS Server(den die FB vom ISP mitgeteilt wird) von den APs durchgereicht. @A.K.:Bei verschienenen Subnutzen müsste man den den DHCP Server forwarden. Aber bei mir ist es ja nur ein großes Netz und da hat nur ein DHCP Server seine Finger im Spiel. Operating Mode Operating Mode: Gateway (Möglichkeiten: BGP, RIP2Router, OSPF Router, OSPF & RIP2 Router, OLSRRouter und Router Dynamic Routing Interface: disable (Möglichkeiten: WAN, LAN+WLAN, Both) es ist eine Bridge zw. ath und eth eingerichtet.
Thomas O. schrieb: > Ihr meint also das ein Rechner z.B. 192.168.2.100 hinter AP1 eine > Anfrage an Rechner 192.168.2.130 hinter AP2 per 192.168.2.2 verschickt > da er hinter einer NAT ist. Nein: Der Rechner 192.168.2.100 schickt Pakete direkt an 192.168.2.130, weil beide Adressen im gleichen Subnetz liegen. Da diese Annahme aber falsch ist, kommt das paket nicht an. Der sendende Rechner weiß nicht, dass er das Gateway (AP1) zur Weiterleitung bitten müsste. Und AP1 weiß nicht, dass er AP2 bitten müsste. Das Problem hast du sowohl mit als auch ohne NAT. Du brauchst entweder drei unterschiedliche Sub-Netze oder du musst die Router durch Switche und WLAN Brücken ersetzen. Thomas O. schrieb: > Ich hätte meine Konfiguration eher so eingeschätzt, dass hier mehrere > Switches zusammenarbeiten Du hast aber Router (Gateways) verwendet, nicht Switche.
Stefan ⛄ F. schrieb: > Der Rechner 192.168.2.100 schickt Pakete direkt an 192.168.2.130, weil > beide Adressen im gleichen Subnetz liegen. Da diese Annahme aber falsch > ist, kommt das paket nicht an. Doch, hat er doch so eingerichtet: Thomas O. schrieb: > es ist eine Bridge zw. ath und eth eingerichtet. Stefan ⛄ F. schrieb: > Du brauchst > entweder drei unterschiedliche Sub-Netze oder du musst die Router durch > Switche und WLAN Brücken ersetzen. Hat er längst so konfiguriert: Thomas O. schrieb: > es ist eine Bridge zw. ath und eth eingerichtet. ath ist die übliche Kennzeichnung für das wlan interface einer Atheros Wlan karte auf diversen BSD systemen.
Thomas O. schrieb: > @DPA: Die Clients bekommen den DNS Server(den die FB vom ISP mitgeteilt > wird) von den APs durchgereicht. Also haben die Clients direkt die ISP DNS Adresse? Das sollte dann aber zum Auflösen der IP des PI per DNS nicht gehen, (höchstens noch über mDNS). Der ISP kennt ja die IP des PI nicht. Oder haben sie die APs als DNS server? Falls das der fall ist, beide oder nur AP1? Wenn AP1 DHCP Server ist, und er den PI nur bei sich im DNS einträgt, müsste man bei den Clients den als DNS Server nehmen.
🐧 DPA 🐧 schrieb: >> es ist eine Bridge zw. ath und eth eingerichtet. > ath ist die übliche Kennzeichnung für das wlan interface einer Atheros > Wlan karte auf diversen BSD systemen. Danke für die Erklärung, mit dem Satz konnte eich nichts anfangen, wie du aufmerksam bemerkt hast.
Was mir in der ganzen Diskussion ein wenig fehlt, ist der Sinn der Übung. Wenn man es sich nicht über Gebühr schwer machen will, aber mehrere WLAN APs benötigt, dann nimmt man normale WLANs APs, die bridgen statt zu routen, getrennt oder als Mesh, und überlässt alles Zentrale dem Access-Router nach draussen. Irgendwelche IP-Konfigurationen in den APs sind dann unnötig, ausser den Management-Adresse der APs selbst. Netze, DHCP, DNS etc ist alles Sache des Access-Routers. So läufts probelemlos millionenfach in aller Welt. Hat man freilich absichtlich oder aus Versehen keine WLAN APs im Einsatz, sondern WLAN Router, dann wird die Chose interessant und ein Spielfeld für Masochisten. Besonders wenn die Kollegen in verschiedenen WLANs alle miteinander reden wollen. Mit IPv6 geht das im Prinzip einfacher, aber auch da gibts Überraschungen, einschliesslich Firmware-Bugs im Fritz. Also was soll das eigentlich werden?
:
Bearbeitet durch User
(prx) A. K. schrieb: > Also was soll das eigentlich werden? ich habe ihn so verstanden, dass seine Geräte immer die gleiche IP Adresse per DHCP bekommen sollen, egal in welchem Subnetz sie sich gerade befinden.
Du bist immer noch zu sehr im Detail. Mal ein oder zwei Schritte zurück, und die ganze Netzkonzeption in Frage stellen. Was soll damit erreicht werden? Ist das vielleicht nur die Folge davon, dass mit WLAN Routern an Stelle von APs versehentlich ins Klo gegriffen wurde? Was soll erreicht werden? Einfach bloss ein Netz mit mehreren WLAN-Basisstationen, in dem alle Geräte stecken? Oder haben die Subnetze einen tieferen noch nicht erklärten (oder von mir übersehenen) Sinn?
:
Bearbeitet durch User
(prx) A. K. schrieb: > Was mir in der ganzen Diskussion ein wenig fehlt, ist der Sinn der > Übung. Wenn man es sich nicht über Gebühr schwer machen will, aber > mehrere WLAN APs benötigt, dann nimmt man normale WLANs APs, die bridgen > statt zu routen, getrennt oder als Mesh, und überlässt alles Zentrale > dem Access-Router nach draussen. Genauso zeigt es IMHO auch die Skizze. Und laut Tante Google lasst dich DD WRT auch als AP konfigurieren.
Beitrag #6428492 wurde vom Autor gelöscht.
Nobody schrieb: > Und laut Tante Google lasst dich DD WRT auch als AP konfigurieren. Jo, aber auf einen AP schmeisst man üblicherweise keinen DHCP-Server drauf. Den aber zeigt die Skizze auch. Die Dinger sind also Router. Deshalb ja die Frage: Sind das mit Absicht Router, oder bloss aus Versehen? Falls aus Versehen: APs draus machen, den DHCP-Server zurück in den Access-Router, und die Sache hat sich.
Ich würde beim PC mal schauen, was ARP, ICMP und ssh mässig so gesendet wird, beim ersten fehlschlagenden Versuch:
1 | sudo tcpdump -vv -i wlan0 icmp or arp or '( tcp port 22 )' |
das Ziel war es, alle Geräte in einem Netz 192.168.2.x zu haben. So das ich immer auf alle Router zugreifen kann und das DHCP Static Lease nicht über die FB machen muss, da das dort grottig zu konfigurieren ist. Ich greife nicht von einem PC auf den RPi zu sondern ebenfalls von einem RPi. Ich werde mal die Tage mit nslookup probieren ob evtl. beim ersten Zugriff die Auflösung hängt. Was ich festgestellt habe mittels nslookup rpi4xyz wird als DNS Server immer 192.168.2.2 ausgegeben egal ob ich über die FB, AP1 oder AP2 verbunden bin, aber in den Aps steht jeweils lokal DNS ist die FB.
Thomas O. schrieb: > das Ziel war es, alle Geräte in einem Netz 192.168.2.x zu haben Dann bist du mit der Konfiguration als WLAN Router falsch abgebogen. Mach APs draus. Wenn dich das DHCP im Fritz stört, mach das eben woanders. Bei einem AP stellt sich die Frage nach Firewallfunktion beispielsweise überhaupt nicht, die in der Skizze als zwar abgeschaltet aber potentiell möglich steht.
:
Bearbeitet durch User
Thomas O. schrieb: > Ich werde mal die Tage mit nslookup probieren ob evtl. beim ersten > Zugriff die Auflösung hängt. Was ich festgestellt habe mittels nslookup > rpi4xyz wird als DNS Server immer 192.168.2.2 ausgegeben egal ob ich > über die FB, AP1 oder AP2 verbunden bin, aber in den Aps steht jeweils > lokal DNS ist die FB. Das ist gut so, genau das würde ich auch erwarten.
Thomas O. schrieb: > Was ich festgestellt habe mittels nslookup > rpi4xyz wird als DNS Server immer 192.168.2.2 ausgegeben egal ob ich > über die FB, AP1 oder AP2 verbunden bin, aber in den Aps steht jeweils > lokal DNS ist die FB. Die DHCP Clients bekommen aber den DNS vom DHCP Server und da vermute ich steht in den Optionen die 192.168.2.2 drin.
Nachtrag: Persönlich habe ich gute Erfahrungen gemacht, wenn der DHCP Server auch DNS macht. Dann können eventuelle DHCP Leases mit den Clientnamen automatisch in den DNS mit aufgenommen werden. Bei Windows Servern im AD wird bei der DHCP Rolle wimre DNS automatisch mit installiert.
DNS läßt sich bei der FB nicht abschalten, zumindestens nicht über die normale Oberfläche, werde da mal bei AVM nachfragen. Heute früh nochmal ping direkt per IP, der erste Ping liegt bei ca. 140 mSek und die nachfolgenden so um die 4-5mSek. Später wecke ich mal den RPi erst mit der Mouse auf und probiere es nochmal. Bei Traceroute kommt der Rpi jetzt auch als Punkt 1 mit 9mSek. In den (ich nenne Sie jetzt einfach weiterhin) APs steht local DNS die FB drin also 192.168.2.1 Habe ich soeben die erste Fehlermeldung erhalten was jetzt auf ein DNS Problem hinweisen könnte.
1 | nslookup rpi4xyz |
2 | Server: fd00::7eff:4dff:fe2e:7f43 |
3 | Address: fd00::7eff:4dff:fe2e:7f43#53 |
4 | |
5 | ** server can't find rpi4luca: NXDOMAIN |
beim 2ten mal hats dann funktioniert da wurde dann auch ein IPv4 DNS genommen
1 | nslookup rpi4xyz |
2 | Server: 192.168.2.2 |
3 | Address: 192.168.2.2#53 |
4 | |
5 | Name: rpi4xyz |
6 | Address: 192.168.2.191 |
Thomas O. schrieb: > DNS läßt sich bei der FB nicht abschalten, zumindestens nicht über die > normale Oberfläche, werde da mal bei AVM nachfragen. Das wäre auch keine gute Idee. Denn die Clients machen DNS ja über Client->AP1 für lokale Clients/domains, und Client->AP1->FB->ISP für Zeugs im Internet. Wenn du also DNS bei der FB abstellst, werden die Clients also keine Internet Domains mehr auflösen können. Was die IPv6 Sache angeht, mit IPv6 kenne ich mich leider noch nicht aus.
Last mal das DNS aussen vor, das ist ein Kollateralschaden. Das Problem sitzt tiefer. Wie ich gaaaanz am Anfang schon sagte: Ein tcpdump mit 6 Hops und 90ms vs. ping mit 6ms zeugt von grundlegenden Problemen, da kreiselt irgendwo was.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.