ein ganz komisches Problem habe ich seitdem ich meinen alten Router gegen einen neuen (TP-Link Archer VR2100v) getauscht habe.
Unter dem Konfigurationsmenü des Routers habe ich den IP-Adresspool des DHCP-Servers verringert (eine IP-Adresse kann nun nur aus dem Bereich 192.168.1.150 bis zu 192.168.1.199 bezogen werden, Bild #1) und dann eine statische IP-Adresse für eigene Geräte vergeben (und zwar für die meisten Geräte, die permanent am Netz angeschlossen sind).
Die Prozedur ist sehr einfach: Ich suche die MAC-Adresse eines Gerätes aus der Liste der angeschlossenen Geräte aus und dann vergebe ich eine IP-Adresse außerhalb des oben erwähnten IP-Adresspooles. Die MAC-Adresse rufe ich direkt aus dem Menü in dem Router ab, sodass Tippfehler auszuschließend sind (Bild #2).
Bis jetzt konnte ich eine statische IP-Adresse an 16 Geräten ohne Probleme zuweisen.
Allerdings mein Laptop (ein Dell 7540 mit Ubuntu 22.04) will davon nichts wissen. Ich habe mehrfach versucht, eine statische IP-Adresse für die WLAN Verbindung zuzuweisen, aber es funktionert einfach nicht. Oder besser:
mit dem Kabel verbunden geht der Laptop ins Internet
über WLAN geht der Laptop ins Internet nicht, obwohl der Laptop mit dem Router über WLAN verbunden ist (Bild #3). Die statische IP-Adresse, die ich ihm zuweisen möchte, ist: 192.168.1.70. Wenn der Laptop sich über WLAN mit dem Router verbindet, dann bezieht er diese IP-Adresse auch.
Ich habe alles mögliche auch auf der Linux Seite ausprobiert: Ich habe versucht nochmal die DNS Servers per Hand einzugeben, dann die selbe statische IP-Adresse über den Network-Manager einzugeben. Nix hat geholfen. Der Laptop will ins Internet nicht gehen. Derselbe Laptop geht aber ins Internet problemlos über WLAN an der Uni, über einen Fritzbox Router, in der Bahn, im Hotel, usw. Gerade habe ich nochmal einen Versuch unternommen. Die Einstellung des Network-Managers ist DHCP (Bild #4).
Noch erstaunlicher ist wenn ich versuche, den Router zu pingen (der Router hat die IP-Adresse 192.168.1.1).
1
$ ping -c 4 192.168.1.1
2
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
3
4
--- 192.168.1.1 ping statistics ---
5
4 packets transmitted, 0 received, 100% packet loss, time 3069ms
Also, zusammengefasst:
Alle Geräte, die eine statische IP-Adresse bezogen haben, gehen problemlos ins Internet.
Der Laptop geht ins Internet über Ethernet Kabel mit einer statischen IP-Adresse ohne Probleme
Derselbe Laptop geht ins Internet nicht, wenn er eine statische IP-Adresse bezieht und eine Verbindung über WLAN mit dem Router erstellt.
Lasse ich den Laptop eine IP-Adresse selber beziehen (also ich trage die statische IP-Adresse aus der Liste aus), dann geht er ins Internet doch.
Hast Du auch (unterschiedliche) IP-Adressen für Ethernet- und
WLAN-MAC-Adresse des Notebooks vergeben?
Er kann dieselbe Adresse vergeben, nur an zwei unterschiedliche MAC-Adressen.
Aber selbst wenn er die WLAN MAC nicht vergeben hat, müsste dem Laptop per DHCP eine Adresse aus dem Bereich 192.168.1.150 bis 192.168.1.199 vergeben werden.
Sieht also eher so aus, als wäre das Laptop nicht verbunden oder mach keine DHCP-Abfrage.
Er kann dieselbe Adresse vergeben, nur an zwei unterschiedliche
MAC-Adressen.
Aber selbst wenn er die WLAN MAC nicht vergeben hat, müsste dem Laptop
per DHCP eine Adresse aus dem Bereich 192.168.1.150 bis 192.168.1.199
vergeben werden.
Sieht also eher so aus, als wäre das Laptop nicht verbunden oder mach
keine DHCP-Abfrage.
Doch! Habe ich auch oben geschrieben.
WENN ich die statische IP-Adresse aus der Liste austragen bzw. lösche, dann bezieht der Laptop eine IP-Adresse aus dem Pool und geht ins Internet. Zum Beispiel gerade eben ist er mit der IP-Adresse 192.168.1.151 mit dem Router über WLAN verbunden.
Er kann dieselbe Adresse vergeben, nur an zwei unterschiedliche
MAC-Adressen.
Das ist nicht zu empfehlen. Zum einen gibt es dann Ärger, wenn er versehentlich sowohl Ethernet als auch WLAN nutzt, zum anderen kann es beim Wechsel eine Weile dauern, bis er wieder mit allen Geräten im Netz reden kann, weil noch die andere MAC-Adresse im ARP-Cache liegt.
Er kann dieselbe Adresse vergeben, nur an zwei unterschiedliche
MAC-Adressen.
Dann sollte man sich aber verdammt sicher sein, dass nicht beide gleichzeitig aktiv sind. Was bei mir aktuell der Fall ist - irgendwann früher war es das nicht.
Ja, nicht zu empfehlen. Aber es erklärt nicht sein Problem.
Übrigens bekommt er grundsätzlich ein Problem, wenn er mit beiden Interfaces dieselbe Verbindung aufmacht (ohne Bonding).
Was passiert, wenn Du 192.168.1.70 vom Router aus pingst?
Ich versuche gerade herauszufinden, wie bei dem Router gehen soll.
ABER es gibt eine News: Ich habe mit zwei anderen statischen IP-Adressen gerade probiert. Einmal 192.168.1.80 und einmal 192.168.1.74.
Mit beiden geht!!!
Es sieht so aus, als ob einen Konflikt mit der IP-Adresse x.70 gäbe.
ABER:
Ich habe die Liste meiner per Hand eingetragenen statischen IP-Adressen zweimal gecheckt und die .70 wurde kein anderes Gerät bereits verwendet oder zugewiesen.
Gibt man eine bereits vergebene IP-Adresse ein, dann bekommt man eine Fehlermeldung, die darauf hinweist, dass es einen Konflikt mit einem anderen Gerät gibt...
????
PS: Für die LAN und für die WLAN Schnittstellen habe ich zwei verschiedene MAC-Adressen und daher habe ich zwei verschiedene IP-Adressen reserviert!!!
PSS: Ich nutze ausschließlich WLAN und nicht beide gleichtzeitig. Ich musste dennoch zum Kabel zugreifen, um herausfinden ob das Problem am Rechner liegt und um die statische IP-Adresse in dem Router zu löschen.
Doch, würde es. Wenn der Router dem WLAN-Interface dieselbe IP zuteilt wie kurz vorher dem Ethernet-Interface, kann es passieren, dass in der ARP-Table des Routers trotzdem noch die alte MAC-Adresse steht. Der dhcpd füttert i.d.R. nicht direkt die ARP-Table.
Übrigens bekommt er grundsätzlich ein Problem, wenn er mit beiden
Interfaces dieselbe Verbindung aufmacht (ohne Bonding).
Unter Linux habe ich das noch nicht ausprobiert, unter Windows ist es halbwegs erträglich: Die Default-Route springt bei jeder DHCP-Renewal auf das jeweilige Interface, evtl. auf dem anderen Interface bereits bestehende TCP-Connections überleben.
Übrigens bekommt er grundsätzlich ein Problem, wenn er mit beiden
Interfaces dieselbe Verbindung aufmacht (ohne Bonding).
Unter Linux habe ich das noch nicht ausprobiert, unter Windows ist es
halbwegs erträglich: Die Default-Route springt bei jeder DHCP-Renewal
auf das jeweilige Interface, evtl. auf dem anderen Interface bereits
bestehende TCP-Connections überleben.
Aber ich nutze die Schnittstellen nie gleichzeitig. Ich habe zum Kabel zurückgegriffen, weil ich sonst keine Verbindung zur Routerkonfiguration mehr hatte
Ich habe die Liste meiner per Hand eingetragenen statischen
IP-Adressen zweimal gecheckt und die .70 wurde kein anderes Gerät
bereits verwendet oder zugewiesen.
Hast Du evtl. vorher mal mit sehr langen Lease-Times gearbeitet, und irgendwo im Netz lungert seit Tagen oder Wochen ein Gerät mit dieser Adresse rum?
Ich habe die Liste meiner per Hand eingetragenen statischen
IP-Adressen zweimal gecheckt und die .70 wurde kein anderes Gerät
bereits verwendet oder zugewiesen.
Hast Du evtl. vorher mal mit sehr langen Lease-Times gearbeitet, und
irgendwo im Netz lungert seit Tagen oder Wochen ein Gerät mit dieser
Adresse rum?
Nein, definitiv nicht. Auch weil ich den Router mittlerweile dutzende Male in den letzten 2 Tagen rebootet habe.
Jedenfalls ergab ein Ping an 192.168.1.70 gerade eben ausgeführt eine negative Antwort.
Unter dem Konfigurationsmenü des Routers habe ich den IP-Adresspool des
DHCP-Servers verringert (eine IP-Adresse kann nun nur aus dem Bereich
192.168.1.150 bis zu 192.168.1.199 bezogen werden, Bild #1) und dann
eine statische IP-Adresse für eigene Geräte vergeben (und zwar für die
meisten Geräte, die permanent am Netz angeschlossen sind).
Die Prozedur ist sehr einfach: Ich suche die MAC-Adresse eines Gerätes
aus der Liste der angeschlossenen Geräte aus und dann vergebe ich eine
IP-Adresse außerhalb des oben erwähnten IP-Adresspooles. Die MAC-Adresse
rufe ich direkt aus dem Menü in dem Router ab, sodass Tippfehler
auszuschließend sind (Bild #2).
Entweder missverständlich geschrieben oder komplett falsch angewendet. Ich tippe auf letzteres, weil es in diesem Kontext sonst keinen Sinn ergibt.
Soll der DHCP für eine quasi-statische IP sorgen, also an eine bestimmte MAC immer dieselbe IP ausgeben, muss diese IP selbstverständlich innerhalb der Range liegen. Für andere IPs außerhalb der Range ist er nicht zuständig. Echte statische, also auf den Geräten selbst konfigurierte, IPs, müssen außerhalb der Range liegen.
Bei Wegwerfbüchsen wie diesen empfiehlt nach solchen Änderungen immer mal ein Neustart, dynamische Änderungen oder selektiven Neustart von einzelnen Diensten beherrschen sie in aller Regel nicht. Auch der ARP-Cache der Clients verdient Beachtung: Wenn manuelles flushen nicht geht, ist ein Neustart angesagt.
Soll der DHCP für eine quasi-statische IP sorgen, also an eine bestimmte
MAC immer dieselbe IP ausgeben, muss diese IP selbstverständlich
innerhalb der Range liegen. Für andere IPs außerhalb der Range ist er
nicht zuständig. Echte statische, also auf den Geräten selbst
konfigurierte, IPs, müssen außerhalb der Range liegen.
Bei den Fritzboxen geht das aber auch anders, ich habe DHCP von 192.168.x.200-229 und kann im Menu Netzwerkverbindungen die IP 192.168.x.57 fest an eine MAC koppeln.
Soll der DHCP für eine quasi-statische IP sorgen, also an eine bestimmte
MAC immer dieselbe IP ausgeben, muss diese IP selbstverständlich
innerhalb der Range liegen.
Das mag logisch stimmen, funktioniert aber mit zumindest sehr vielen Routern auch so, z.B. Fritz, Mikrotik, Lancom, TP-Link, Asus und einigen anderen Billigheimern.
Und: soweit ich weiß, lautet der richtige Begriff "static Lease". Ein Lease ist flexibel aus dem Pool, Static ist fix am Gerät konfiguriert, Static Lease dagegen pseudo-fix im DHCP-Server eingestellt.
Ich tippe auf "irgendein Gerät hat fix die 70", am Gerät selbst konfiguriert.
Könnte man verifizieren, in dem der Lappy fix auf 70 konfiguriert wird (geht trotzdem nicht) und dann alles außer dem Router und dem Lappy ausgeschaltet wird (geht dann).
Das Risiko, das das bislang übersehene Gerät dabei auch übersehen wird, ist allerdings groß, da müsste man dann auch das WLAN komplett tauschen (neue SSID, neuer Key).
Soll der DHCP für eine quasi-statische IP sorgen, also an eine bestimmte
MAC immer dieselbe IP ausgeben, muss diese IP selbstverständlich
innerhalb der Range liegen.
Nein, je nach Implementation ist das sogar verboten.
Die Range ist für dynamische Zuteilungen da, und es gibt durchaus Setups, wo man sowas gar nicht will, sondern ausschliesslich für bekannte Geräte Leases rausgibt.
ABER es gibt eine News: Ich habe mit zwei anderen statischen IP-Adressen
gerade probiert. Einmal 192.168.1.80 und einmal 192.168.1.74.
Mit beiden geht!!!
Zeig doch mal im Router die Liste der angeschlossenen bzw bekannten Geräte, da geistert sicher irgendwo die .70 noch rum (evtl von ausserhalb, Nachbar etc)
Wenn andere Adressen funktionieren, muss wohl etwas mit der .70 sein.
Wenn der DHCP-Server sie aber neu an das Laptop vergibt, dann weiß zumindest der DHCP-Server nichts von dem existierenden Lease - es gibt also keinen.
In der arp Table könnte er noch drin sein. Aber nach einem Neustart auch nicht mehr.
@Max I. (powermeter) @Hmmm (hmmm)
Ist das nicht ein Nebenkriegsschauplatz?
Wenn .70 nicht geht, .74 oder .80 aber doch, dann hat es nichts mit dem Range .150 bis .199 zu tun.
Und auch bei OpenWRT ist das so, ausserhalb des DHCP-Bereiches möglich.
OpenWRT benutzt dnsmasq als DHCP-Server.
Aus der man-page von dnsmasq: " --dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][,tag:<tag>][,<ipaddr>][,<hostname>][,<lease_time>][,ignore]
Specify per host parameters for the DHCP server. This allows a machine with a particular hardware address to be always allocated the same hostname, IP address and lease time.
...
Addresses allocated like this are not constrained to be in the range given by the --dhcp-range option, but they must be in the same subnet as some valid dhcp-range. "
Wahrscheinlich falsch implementiert. ;-)
Ist aber immer noch ein Nebenkriegsschauplatz und hilft X. A. (wilhem) wenig.
Soll der DHCP für eine quasi-statische IP sorgen, also an eine bestimmte
MAC immer dieselbe IP ausgeben, muss diese IP selbstverständlich
innerhalb der Range liegen. Für andere IPs außerhalb der Range ist er
nicht zuständig. Echte statische, also auf den Geräten selbst
konfigurierte, IPs, müssen außerhalb der Range liegen.
Ok, verstehe.
Ich will das jede Gerät eine statische IP-Adresse (also von mir vergeben) bekommen. Und dies geschieht durch die Eintragung der MAC-Adresse in einer Liste ein.
Es gibt aber was neues: Ich habe die IP-Adresse für die LAN Schnittstelle und für die WLAN Schnittstelle untereinander umgetauscht und es funktioniert:
LAN: 192.168.1.70: Funktioniert
WLAN: 192.168.1.72: Funktioniert (früher war .72 die IP-Adresse der LAN-Schnittstelle).
Soll der DHCP für eine quasi-statische IP sorgen, also an eine bestimmte
MAC immer dieselbe IP ausgeben, muss diese IP selbstverständlich
innerhalb der Range liegen. Für andere IPs außerhalb der Range ist er
nicht zuständig. Echte statische, also auf den Geräten selbst
konfigurierte, IPs, müssen außerhalb der Range liegen.
Sorry ich war noch nicht fertig.
Wenn ich die IP-Adresse 192.168.1.70 nicht in dem Router sonder statisch in meinem Ubuntu konfiguriere (über Network-Manager), dann funktionert auch nicht. Ich habe mit verschiedenen DNSs ausprobiert. Nicht. Die Verbindung zum Router kommt zustande aber der Laptop geht nicht ins Internet
ABER es gibt eine News: Ich habe mit zwei anderen statischen IP-Adressen
gerade probiert. Einmal 192.168.1.80 und einmal 192.168.1.74.
Mit beiden geht!!!
Zeig doch mal im Router die Liste der angeschlossenen bzw bekannten
Geräte, da geistert sicher irgendwo die .70 noch rum (evtl von
ausserhalb, Nachbar etc)
Mehrfach reingeschaut. Es wurde keine .70 IP-Adresse vergeben. Der Router ist neu und der Nachbarn hat das Passwort bestimmt nicht...
Ich will es mit einem Beispiel verdeutlichen.
Wenn wir Mitarbeiter an der Uni einen neuen Rechner/Laptop/Gerät von unserer IT-Abteilung freischalten lassen wollen, dann fragen die uns ausschließlich nach der MAC-Adresse des Gerätes. Die IP-Adresse wird dann von denen statisch über den Router vergeben.
Ein Tag davor hat man kein Internet (das Gerät sucht und sucht aber kann sich nicht verbinden) und am Tag danach erhält das Gerät eine IP-Adresse, die statisch ist UND diese IP-Adresse wird definitiv nicht von uns Mitarbeiter in das Gerät selbst als statisch konfiguriert.
Alles passiert im Router.
Das gleiche möchte ich in meinem Heimrouter realisieren. Gäste bekommen eine IP-Adresse aus dem Pool durch DHCP. Meine Geräte müssen aber eine statische IP-Adresse anhand ihrer MAC-Adresse beziehen können.
Und das ist reproduzierbar?
D.h. Du kannst da hin und her wechseln, beide (Laptop und Router) neu starten, und es geht nur, wenn LAN .70 ist und nicht, wenn WLAN .70 ist?
Oder hattest Du doch mal am Anfang schon LAN auf .70, mit langer lease time?
Was passiert denn, wenn Du die WLAN MAC des Laptops am Router auf .70 setzt und am Laptop
systemctl restart NetworkManager
oder
dhclient -r wlp112s0
dhclient wlp112s0
machst?
Komisch.
Mach ich aktuell so. Mikrotik 7.14.1
Lancom hab ich nur als ISDN-Adapter missbraucht, der hatte auch einen Static Lease außerhalb des Ranges für Wartungs-Laptop.
TP-Link nutze ich auch dauernd so, für eine Testumgebung, Laptop fest, Geräte aus dem Pool.
Im Router nicht. Aber hast du evtl. ein Gerät im LAN/WLAN, das fix konfiguriert ist?
Teste ob die 70 geht wenn dein Laptop das einzige Gerät im LAN ist. Wenn nicht ist es ein WLAN-Gerät.
Schalte das WLAN ab (wechsel die SSID). Wenn es dann immer noch nicht geht ist es ein Softwareproblem.
Ich habe keinen großen Nerv, das ausgerechnet hier auszudiskutieren, aber ich werfe hier nach dem Osterurlaub mal ein paar Configs/Logs/ von div. Microtiks, opn/pfsense, Cisco, Juniper, Lancom etc. rein. Wenn ich ganz viel Lust habe, auch noch von irgendwelchen Plastikhaufen.
ich werfe hier nach dem Osterurlaub mal ein paar Configs/Logs/ von
div. Microtiks, opn/pfsense, Cisco, Juniper, Lancom etc. rein
Brauchste nicht.
Fritz, Mikrotik, Lancom, TPLink hab ich hier, das geht so. OP beweist das auch.
Cisco und Juniper hat man nicht zuhause, die machen auch sonst vieles anders, mag sein auch hier.
Ich kenn die RFC dazu nicht, aber die oben zitierte Hilfe zu dnsmasq stimmt auch zu das es geht. Kann also nicht ganz falsch sein...
Ich habe keinen großen Nerv, das ausgerechnet hier auszudiskutieren,
aber ich werfe hier nach dem Osterurlaub mal ein paar Configs/Logs/ von
div. Microtiks, opn/pfsense, Cisco, Juniper, Lancom etc. rein. Wenn ich
ganz viel Lust habe, auch noch von irgendwelchen Plastikhaufen.
Wie immer glänzt unser Mäxchen mit völliger Ahnungslosigkeit in der unerschütterlichen Überzeugung den absoluten Durchblick zu besitzen.
ich werfe hier nach dem Osterurlaub mal ein paar Configs/Logs/ von
div. Microtiks,
Da geht zwar beides, aber Default ist sogar das komplette Nicht-Vorhandensein einer Dynamic Range (/ip dhcp-server add address-pool=static-only), da sind die statischen Leases dann zwangsläufig ausserhalb.
opn/pfsense
In pfSense (mit ISC DHCP unter der Haube) verhindert das Frontend statische Leases innerhalb der Ranges:
Und das ist reproduzierbar?
D.h. Du kannst da hin und her wechseln, beide (Laptop und Router) neu
starten, und es geht nur, wenn LAN .70 ist und nicht, wenn WLAN .70 ist?
So Freunde,
ich konnte erst jetzt den Test machen.
Das Problem ist REPRODUZIERBAR
Ich habe gerade die IP-Adressen umgetauscht:
LAN: 192.168.1.72: Funktioniert
WLAN: 192.168.1.70: Funktioniert NICHT!!!!
Oder hattest Du doch mal am Anfang schon LAN auf .70, mit langer lease
time?
Nein. Ich hatte keine .70er mit langem Leasetime.
Und das erklärt nciht, warum die Adresse über LAN problemlos funktioniert.
Ich vermute sehr start, ein Bug hat sich in die Firmware eingenistet.
Dürfte auch kein Teil der RFC sein, das ist ja keine Frage des
Protokolls, sondern nur eine der Konfiguration.
Och ich würde schon sagen das im "Gesetz" drin steht wie fixe Leases realisiert werden müssen, und eben auch ob sie innerhalb und außerhalb des Pools liegen müssen, sollen, oder dürfen.
Aber ich bin ja nicht alleine mit der Erfahrung das "außerhalb" funktioniert, und du hast sogar zwei Beispiele wo es nicht nur darf sondern sogar muss.
Und das erklärt nciht, warum die Adresse über LAN problemlos
funktioniert.
Evtl. hast du auch eine Gespensteradresse in einem Gerät, ein Adminzugang der versteckt und nur über WLAN erreichbar ist.
Das würdest du rausfinden, wenn du die SSID änderst und nur Router und PC wissen davon. Wenn es dann geht, stück für Stück jedes Gerät wieder einbinden und auf einmal ist 70 wieder kaputt...
Och ich würde schon sagen das im "Gesetz" drin steht wie fixe Leases
realisiert werden müssen, und eben auch ob sie innerhalb und außerhalb
des Pools liegen müssen, sollen, oder dürfen.
Es gibt kein "Gesetz", das das vorschreibt, aber es ist best practice, static leases ausserhalb des dynamischen Bereich zu legen.
Im Router nicht. Aber hast du evtl. ein Gerät im LAN/WLAN, das fix
konfiguriert ist?
Teste ob die 70 geht wenn dein Laptop das einzige Gerät im LAN ist. Wenn
nicht ist es ein WLAN-Gerät.
Schalte das WLAN ab (wechsel die SSID). Wenn es dann immer noch nicht
geht ist es ein Softwareproblem.
Ich kann es prüfen, ABER... der Router kam vor einer Woche verpackt und nie benutzt. Dann habe ich ihn konfiguriert, indem ich eine komplette neue SSID (also mit einem anderen Namen und Passwort) erstellt habe. Dann habe ich die MAC-Adresse von jedem Gerät, ein nach dem anderen, selber in die Tabelle im Router eingetragen und selber die IP-Adresse eingetragen.
Nie habe ich eine statische IP-Adresse direkt in mein Android, iPad oder Laptop (bis auf die Tests oben erwähnt) eingetragen.
Och ich würde schon sagen das im "Gesetz" drin steht wie fixe Leases
realisiert werden müssen, und eben auch ob sie innerhalb und außerhalb
des Pools liegen müssen
Aus Protokollsicht gibt es keinen Pool, sondern nur Leases. Woher der Server die nimmt, ist ihm überlassen.
Aber ich bin ja nicht alleine mit der Erfahrung das "außerhalb"
funktioniert, und du hast sogar zwei Beispiele wo es nicht nur darf
sondern sogar muss.
Ja, für mich ist eine DHCP-Range ein Pool für dynamisch verteilte Adressen, und auch wenn beide Varianten möglich sind, liegen die statischen ausserhalb.
Es wäre ja auch in der Praxis idiotisch, einem Drucker eine neue IP-Adresse verpassen zu müssen, wenn man sie nicht mehr lokal konfigurieren, sondern per DHCP vergeben will.
Nie habe ich eine statische IP-Adresse direkt in mein Android, iPad oder
Laptop (bis auf die Tests oben erwähnt) eingetragen.
Es existieren nur diese 3 Geräte in deinem Netz, plus Router?
Kein Smarthome, Drucker, Kinder?
Was ist sonst im LAN? Modem? Weitere Accesspoints oder dLAN? Powerline?
VPN? Switch? Spielkonsole? Fernseher?
Ich kann mir kaum vorstellen, das du der einzige bist, bei dem ein Firmwarebug verhindert das eine IP vergeben wird. Und dann auch nur exakt genau eine einzige, die nichtmal irgendwie besonders wäre.
Nie habe ich eine statische IP-Adresse direkt in mein Android, iPad oder
Laptop (bis auf die Tests oben erwähnt) eingetragen.
Es existieren nur diese 3 Geräte in deinem Netz, plus Router?
Kein Smarthome, Drucker, Kinder?
Was ist sonst im LAN? Modem? Weitere Accesspoints oder dLAN? Powerline?
VPN? Switch? Spielkonsole? Fernseher?
Ich kann mir kaum vorstellen, das du der einzige bist, bei dem ein
Firmwarebug verhindert das eine IP vergeben wird. Und dann auch nur
exakt genau eine einzige, die nichtmal irgendwie besonders wäre.
Es gibt sie doch! Und jedes Gerät erhält eine statische IP-Adresse zugewiesen.
Was ich meinte: Ich vergebe seit mindestens 10 Jahren immer wieder dieselben IP-Adressen an die gleichen Geräte:
.70 Laptop (Linux) WLAN
.71 Android
.72 LAN
ABER ich habe gerade einen euer Vorschläge probiert.
Ich habe den SSID Namen geändert
Router rebootet
Nur den Laptop an dem Netwerk angemeldet (sowohl über LAN als auch über WLAN)
ES HAT SICH NICHTS GEÄNDERT. Das Problem besteht immer noch.
Ich glaube auch nicht, dass ich der einzige dieser Welt bin, der auf diesen vermeintlichen Bug stoßt. Aber sowas habe ich noch nie erlebt.
Das würdest du rausfinden, wenn du die SSID änderst und nur Router und
PC wissen davon.
Es sei denn, es ist der ominöse Router selbst, der die .70 benutzt. Und selber nichts davon weiß.
Aber dann dürfte die .70 auch mit keinem anderen wireless Gerät gehen als dem Laptop.
Der Router weiß. Der Benutzer nicht. Und das Handbuch evtl. auch nicht.
Aber z.B. Fritzboxen haben auch eine fix eingestellte Wiederherstellungsadresse, die allerdings "schräg" ist und kurz nach dem Start nicht mehr erreichbar ist. An sowas ähnliches denke ich auch gerade.
Aber dann dürfte die .70 auch mit keinem anderen wireless Gerät gehen
als dem Laptop.
Genau dieses. Nächster Test!
Könnte aber auch ein ARP-Ärger sein weil OP doch einen ganzen Stapel nicht wirklich durchsichtig konfigurierbarer Geräte am Start hat (Sonos, Hue) und auch sonst noch eine Hand voll...
Ich habe gerade den Laptop meiner Frau (ein Asus mit Window 10) umkonfiguriert und den Test gemacht.
Die .70 Adresse habe ich im Router mit der MAC-Adresse des Win-Laptops verknüpft.
Und ES FUNKTIONIERT NICHT!!! (Sehe Screenshot):
Versuch mal eine Webseite abzurufen, bekommt man diese "Seiten-Ladefehler" nach gefühlten 30 Sekunden als Fehlermeldung.
Ich glaube, ich warte mal das nächste FW-Update ab.
Und dann wiederhole ich das Ganze nochmal.
Wenn ich nach vr2100v 192.168.1.70 google, stoße ich auf eine TP-Link Community-Seite, auf der für den vr1200v über seltsame Probleme mit ebendieser internen IP-Adresse berichtet wird.
Es wäre natürlich interessant, dem Phänomen mit Wireshark usw. auf den Grund zu gehen. Ansonsten halt einfach die .70 meiden.
Entschuldige bitte, ich hab es nicht alles gelesen. Hatte aber selbst schon mit tp-link Probleme (in Windows). Was mir geholfen hat war diese Seite : https://www.tp-link.com/de/support/faq/1556/
Ja, Entschuldigung, wirklich dumm von mir. ihr habt also herausgefunden, das eine .70 Addresse intern vom Router vergeben ist. Tut mir leid, daß ich reingeblödet habe.
ein kurzes Update: Ich habe den TP-Link Support eingeschaltet. Die meinten, ich soll einen Hardreset durchführen und nochmal schauen, ob das Problem besteht.
Hardreset durchgeführt und Problem gehoben.
Interessanterweise hatte ich meine Routerkonfiguration vor dem Reset gespeichert. Wenn ich die alte Konfiguration wiederlade, dann besteht das Problem immer noch...
Jedenfalls danke für die Hilfe und unzähligen Tipps.
Frohe Ostern
Wenn ich die alte Konfiguration wiederlade, dann besteht
das Problem immer noch...
*wieder
Interessant.
Da steht was drin, was du zwar eintragen kannst, aber nicht wieder löschen, und offensichtlich auch nicht sehen.
Also Stück für Stück konfigurieren und öfter die Settings sichern.
ein kurzes Update: Ich habe den TP-Link Support eingeschaltet. Die
meinten, ich soll einen Hardreset durchführen und nochmal schauen, ob
das Problem besteht.
Hardreset durchgeführt und Problem gehoben.
Interessanterweise hatte ich meine Routerkonfiguration vor dem Reset
gespeichert. Wenn ich die alte Konfiguration wiederlade, dann besteht
das Problem immer noch...
Ein ähnliches Szenario gibt es lustigerweise auch bei der Fritzbox. Zumindest dann, wenn die Konfig aus sem Backup einer anderen FB stammt. Auch dann kann es zu solchen "Leichen" kommen, die nirgendwo angezeigt werden und mit den Mitteln des GUI auch nicht behoben werden können. Im Falle der FB hilft leider auch kein Reset. Nur Rücksetzen auf Werkeinstellungen und komplette manuelle Neukonfiguration.
Zum Glück existierte das Problem bei den Fritzboxen schon zu einer Zeit, als man das Backup der Konfig noch unverschlüsselt speichern durfte. Das hat es zumindest möglich gemacht, den Fehler in der Firmware zweifelsfrei nachzuweisen. Behoben ist er aber bis heute nicht. Nur der eindeutige Nachweis wurde durch Einführung der Zwangsverschlüsselung (so sinnvoll diese aus Sicherheitsgründen auch ist) unmöglich gemacht...
Bei der FB ist es jedenfalls so: Wenn es zum Zeitpunkt der Gewinnung des Backup einen Peer mit IP-Reservierung, aber nur einem abgelaufenen Lease gab, dann ist diese IP unsichtbar "verbrannt". Kann also z.B. keinem anderen Gerät mehr zugewiesen werden.
Zum Glück existierte das Problem bei den Fritzboxen schon zu einer Zeit,
als man das Backup der Konfig noch unverschlüsselt speichern durfte.
Die Konfiguration wird nach wie vor nicht verschlüsselt gespeichert, die kann man sich mit einem Texteditor ansehen.
Wie kommst Du auf die Idee, daß es anders wäre? Verschwörungstheorie, weil der pfiffige "Observer" einen Fehler gefunden hat, und die bösen AVM-Leute das unter den Teppich kehren wollen?
Die Konfiguration wird nach wie vor nicht verschlüsselt gespeichert, die
kann man sich mit einem Texteditor ansehen.
Bei meiner geht das jedenfalls nicht mehr. Die will zwingend einen Key zum Speichern der Konfig (leer wird nicht mehr akzeptiert) und verschlüsselt das Backup dann offensichtlich auch. Mit einem Texteditotor bekommst du nur Gurkensalat zu sehen.
Bei meiner geht das jedenfalls nicht mehr. Die will zwingend einen Key
zum Speichern der Konfig (leer wird nicht mehr akzeptiert) und
verschlüsselt das Backup dann offensichtlich auch.
Was für eine Fritzbox soll das sein? Ich habs mir gerade mit 'ner 7530 mit aktuellem "FritzOS" angesehen - ja, da wird ein Passwort abgefragt, aber das steht nur verschlüsselt in einer der ersten Zeilen der Textdatei.
Der Rest ist Klartext (abgesehen natürlich von irgendwelchem Zertifikatsgeraffel und Passwörtern).
Mit einem Texteditotor bekommst du nur Gurkensalat zu sehen.
Ich habe auch mal so mit der .bin Datei probiert und ich kann es
bestätigen.
Jetzt warte ich 1-2-3, bis der Kirmbichler seine tolle (natürlich nur unter Linux brauchbare) Lösung offeriert, wie man das dann wieder in lesbaren Text umwandelt (wenn man den Key kennt natürlich nur, ansonsten wäre es ja sowieso sinnlos).
Er wird weder bestätigen, das eine unverschlüsselte Speicherung tatsächlich nicht mehr möglich ist noch wird er die Existenz des Firmware-Bugs an sich bestätigen.
7490 mit aktueller Firmware. Die Zwangsverschlüsselung des Konfig-Backups wurde aber schon lange vorher eingeführt. Das war noch irgendeine 6er auf einer (bei mir) 3490.
Jetzt warte ich 1-2-3, bis der Kirmbichler seine tolle (natürlich nur
unter Linux brauchbare) Lösung offeriert, wie man das dann wieder in
lesbaren Text umwandelt (wenn man den Key kennt natürlich nur, ansonsten
wäre es ja sowieso sinnlos).
Bist Du intellektuell in der Lage, zwischen einer BINÄRDATEI und einer TEXTDATEI zu unterscheiden?
Bist Du intellektuell in der Lage, zwischen einer VERSCHLÜSSELTEN Datei und einer Datei, die mit einer Prüfsumme gesichert ist, zu unterscheiden?
Im Anhang der Anfang einer vorhin exportierten Konfigurationsdatei einer 7530
(die ursprünglich den Namen "FRITZ.Box_7530_164.07.57i_30.03.24_1332.export" hatte)
Bild_1.jpg
(290 KB)
Bild_2.jpg
(310 KB)
Bild_3.jpg
(81 KB)
Bild_4.jpg
(110 KB)
