Forum: PC Hard- und Software Problem bei der Routerkonfigurierung: Linux PC geht nicht ins Internet wenn DHCP aktiv ist.


von X. A. (wilhem)


Angehängte Dateien:

Lesenswert?

Hallo Freunde,

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.

Was soll ich noch probieren?

: Bearbeitet durch User
von Np R. (samweis)


Lesenswert?

Mach doch mal
ip a
ip r
auf dem Laptop.

Ich nehme an, auf dem Laptop werden die Verbindungen durch den 
NetworkManager verwaltet?

: Bearbeitet durch User
von Rüdiger B. (rbruns)


Lesenswert?

Dumme Frage:
Ist auf dem Router der PC im WLAN aktiv ?
In der Shell mal ifconfig aufrufen.

von Hmmm (hmmm)


Lesenswert?

X. A. schrieb:
> - mit dem Kabel verbunden geht der Laptop ins Internet
> - über WLAN geht der Laptop ins Internet nicht

Hast Du auch (unterschiedliche) IP-Adressen für Ethernet- und 
WLAN-MAC-Adresse des Notebooks vergeben? Aus Sicht des Routers sind das 
zwei Geräte.

von X. A. (wilhem)


Lesenswert?

Np R. schrieb:
> Mach doch mal
> ip a
> ip r
> auf dem Laptop.
1
$ ip a
2
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
3
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
4
    inet 127.0.0.1/8 scope host lo
5
       valid_lft forever preferred_lft forever
6
    inet6 ::1/128 scope host 
7
       valid_lft forever preferred_lft forever
8
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
9
    link/ether c0:3e:ba:4a:51:38 brd ff:ff:ff:ff:ff:ff
10
    altname enp0s31f6
11
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
12
    link/ether 52:54:00:86:de:3d brd ff:ff:ff:ff:ff:ff
13
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
14
       valid_lft forever preferred_lft forever
15
4: wlp112s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
16
    link/ether 08:d2:3e:7c:28:10 brd ff:ff:ff:ff:ff:ff
17
    inet 192.168.1.70/24 brd 192.168.1.255 scope global noprefixroute wlp112s0
18
       valid_lft forever preferred_lft forever
19
    inet6 2003:f7:7702:dc01::2/128 scope global dynamic noprefixroute 
20
       valid_lft 86394sec preferred_lft 86394sec
21
    inet6 fe80::e5d:b3f4:8bc7:6ad7/64 scope link noprefixroute 
22
       valid_lft forever preferred_lft forever
23
24
$ ip r
25
default via 192.168.1.1 dev wlp112s0 proto dhcp metric 600 
26
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown 
27
192.168.1.0/24 dev wlp112s0 proto kernel scope link src 192.168.1.70 metric 600 
28
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

> Ich nehme an, auf dem Laptop werden die Verbindungen durch den
> NetworkManager verwaltet?

Ja

von X. A. (wilhem)


Lesenswert?

Rüdiger B. schrieb:
> Dumme Frage:
> Ist auf dem Router der PC im WLAN aktiv ?
> In der Shell mal ifconfig aufrufen.
1
$ ifconfig
2
eno1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
3
        ether c0:3e:ba:4a:51:38  txqueuelen 1000  (Ethernet)
4
        RX packets 13446  bytes 11294963 (11.2 MB)
5
        RX errors 0  dropped 47  overruns 0  frame 0
6
        TX packets 8398  bytes 1473892 (1.4 MB)
7
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
8
        device interrupt 16  memory 0xb5600000-b5620000  
9
10
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
11
        inet 127.0.0.1  netmask 255.0.0.0
12
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
13
        loop  txqueuelen 1000  (Lokale Schleife)
14
        RX packets 4078  bytes 398441 (398.4 KB)
15
        RX errors 0  dropped 0  overruns 0  frame 0
16
        TX packets 4078  bytes 398441 (398.4 KB)
17
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
18
19
virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
20
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
21
        ether 52:54:00:86:de:3d  txqueuelen 1000  (Ethernet)
22
        RX packets 0  bytes 0 (0.0 B)
23
        RX errors 0  dropped 0  overruns 0  frame 0
24
        TX packets 0  bytes 0 (0.0 B)
25
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
26
27
wlp112s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
28
        inet 192.168.1.70  netmask 255.255.255.0  broadcast 192.168.1.255
29
        inet6 fe80::e5d:b3f4:8bc7:6ad7  prefixlen 64  scopeid 0x20<link>
30
        inet6 2003:f7:7702:dc01::2  prefixlen 128  scopeid 0x0<global>
31
        ether 08:d2:3e:7c:28:10  txqueuelen 1000  (Ethernet)
32
        RX packets 789460  bytes 1045456146 (1.0 GB)
33
        RX errors 0  dropped 930  overruns 0  frame 0
34
        TX packets 257508  bytes 43007906 (43.0 MB)
35
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

von X. A. (wilhem)


Lesenswert?

Hmmm schrieb:
> X. A. schrieb:
>> - mit dem Kabel verbunden geht der Laptop ins Internet
>> - über WLAN geht der Laptop ins Internet nicht
>
> Hast Du auch (unterschiedliche) IP-Adressen für Ethernet- und
> WLAN-MAC-Adresse des Notebooks vergeben?
Ja ja!

von Np R. (samweis)


Lesenswert?

Hmmm schrieb:
> 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.

von Np R. (samweis)


Lesenswert?

Was passiert, wenn Du 192.168.1.70 vom Router aus pingst?

von X. A. (wilhem)


Lesenswert?

Np R. schrieb:

> 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.

von Hmmm (hmmm)


Lesenswert?

Np R. schrieb:
> 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.

von (prx) A. K. (prx)


Lesenswert?

Np R. schrieb:
> 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.

von Np R. (samweis)


Lesenswert?

Hmmm schrieb:
> Das ist nicht zu empfehlen.

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).

: Bearbeitet durch User
von Rolf (rolf22)


Lesenswert?

> inet addr:192.168.**122**.1

Lies mal hier nach:
https://askubuntu.com/questions/246343/what-is-the-virbr0-interface-used-for

von X. A. (wilhem)


Lesenswert?

Np R. schrieb:
> 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.

: Bearbeitet durch User
von Hmmm (hmmm)


Lesenswert?

Np R. schrieb:
> Aber es erklärt nicht sein Problem.

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.

Np R. schrieb:
> Ü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.

von X. A. (wilhem)


Lesenswert?

Hmmm schrieb:
> Np R. schrieb:
>> Ü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

: Bearbeitet durch User
von Rüdiger B. (rbruns)


Lesenswert?

Manche Router unterstützen Ping before DHCP, d.h. wenn das Gerät 
antwortet ist die IP belegt und es wird eine andere verwendet.

von Hmmm (hmmm)


Lesenswert?

X. A. schrieb:
> 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?

von X. A. (wilhem)


Lesenswert?

Hmmm schrieb:
> X. A. schrieb:
>> 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.

Selbst der Firmware ist auf dem letzten Stand

: Bearbeitet durch User
von Hmmm (hmmm)


Lesenswert?

X. A. schrieb:
> Jedenfalls ergab ein Ping an 192.168.1.70 gerade eben ausgeführt eine
> negative Antwort.

Und wie sieht's danach in der ARP-Table aus? Viele Geräte antworten 
heutzutage nicht mehr auf Pings.

von X. A. (wilhem)


Lesenswert?

Hmmm schrieb:
> X. A. schrieb:
>> Jedenfalls ergab ein Ping an 192.168.1.70 gerade eben ausgeführt eine
>> negative Antwort.
>
> Und wie sieht's danach in der ARP-Table aus? Viele Geräte antworten
> heutzutage nicht mehr auf Pings.

Ist die Tabelle, in der die angeschlossenen Geräte zu finden sind?

von Stephan S. (uxdx)


Angehängte Dateien:

Lesenswert?

Sieht Deine Seite des Netmanagers so aus - Das Funknetzwerk und die 
Sicherheit müssen natürlich passen, WPA2 etc)

von Hmmm (hmmm)


Lesenswert?

X. A. schrieb:
> Ist die Tabelle, in der die angeschlossenen Geräte zu finden sind?

Nein, das ist das interne Mapping von IP-Adressen auf MAC-Adressen.

Du kannst mal versuchen, von einem anderen System (egal ob unixoid oder 
Windows) die Adresse anzupingen, kurz danach dann auf der Commandline: 
arp -a

von Max I. (powermeter)


Lesenswert?

X. A. schrieb:
> 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.

von Stephan S. (uxdx)


Lesenswert?

Max I. schrieb:
> 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.

: Bearbeitet durch User
von Jens M. (schuchkleisser)


Lesenswert?

Max I. schrieb:
> 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).

von Hmmm (hmmm)


Lesenswert?

Max I. schrieb:
> 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.

von Stephan S. (uxdx)


Lesenswert?

X. A. schrieb:
> 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)

von Np R. (samweis)


Lesenswert?

Stephan S. schrieb:
> da geistert sicher irgendwo die .70 noch rum

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.

Mal mit wireshark nachschauen?

von Max I. (powermeter)


Lesenswert?

Hmmm schrieb:
> Nein

Doch.

> je nach Implementation ist das sogar verboten.

Ja, wie immer gilt: RTFM. Und gerade der ganze billigkram ist so 
unterwegs.

von Max I. (powermeter)


Lesenswert?

Jens M. schrieb:
> Das mag logisch stimmen, funktioniert aber mit zumindest sehr vielen
> Routern auch so, z.B. Fritz

Nein.

> Mikrotik, Lancom,

Definitiv nein.

> TP-Link, Asus und einigen anderen Billigheimern.

Mag sein, bei dem Gerümpel bin ich raus.

: Bearbeitet durch User
von Np R. (samweis)


Lesenswert?

@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.

von Stephan S. (uxdx)


Lesenswert?

Max I. schrieb:
> Jens M. schrieb:
>> Das mag logisch stimmen, funktioniert aber mit zumindest sehr vielen
>> Routern auch so, z.B. Fritz
>
> Nein.

Doch, ist so, habe hier mehrere ESP dran hängen.

Und auch bei OpenWRT ist das so, ausserhalb des DHCP-Bereiches möglich.

von Np R. (samweis)


Lesenswert?

Stephan S. schrieb:
> 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>][,<ipad 
dr>][,<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.

: Bearbeitet durch User
von X. A. (wilhem)


Lesenswert?

Max I. schrieb:

> 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).

Kann es sein, dass die Firmware einen Bug hat?

von X. A. (wilhem)


Lesenswert?

Max I. schrieb:

> 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

von X. A. (wilhem)


Lesenswert?

Stephan S. schrieb:
> X. A. schrieb:
>> 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...

von X. A. (wilhem)


Lesenswert?

@X. A.

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.

von Np R. (samweis)


Lesenswert?

X. A. schrieb:
> - LAN: 192.168.1.70: Funktioniert
> - WLAN: 192.168.1.72: Funktioniert

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?

von Jens M. (schuchkleisser)


Lesenswert?

Max I. schrieb:
> Nein.

Lustig.
Habe ich lange so gemacht. Ne 7490 mit FritzOS 7.x

Max I. schrieb:
> Definitiv nein.

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.

X. A. schrieb:
> Es wurde keine .70 IP-Adresse vergeben.

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.

von Max I. (powermeter)


Lesenswert?

Jens M. schrieb:
> Lustig

Mitnichten.

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.

von Jens M. (schuchkleisser)


Lesenswert?

Max I. schrieb:
> Ich habe keinen großen Nerv, das ausgerechnet hier auszudiskutieren

Ist ja auch nicht sinnvoll, denn daran liegts offensichtlich nicht, wenn 
80 oder 74 gehen, 70 aber nicht.

Max I. schrieb:
> 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...

von Harry L. (mysth)


Lesenswert?

Max I. schrieb:
> Jens M. schrieb:
>> Lustig
>
> Mitnichten.
>
> 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.

https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt

von Hmmm (hmmm)


Lesenswert?

Max I. schrieb:
> 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:

https://docs.netgate.com/pfsense/en/latest/services/dhcp/mappings-in-pools.html

Jens M. schrieb:
> Ich kenn die RFC dazu nicht

Dürfte auch kein Teil der RFC sein, das ist ja keine Frage des 
Protokolls, sondern nur eine der Konfiguration.

von X. A. (wilhem)


Lesenswert?

Np R. schrieb:
> X. A. schrieb:
>> - LAN: 192.168.1.70: Funktioniert
>> - WLAN: 192.168.1.72: Funktioniert
>
> 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.

Die anderen Tests müss ich leider morgen machen.

von Jens M. (schuchkleisser)


Lesenswert?

Hmmm schrieb:
> 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.

von Max I. (powermeter)


Lesenswert?

Harry L. schrieb:
> Mäxchen

Ja ja.
(frei nach Rörich)

von Jens M. (schuchkleisser)


Lesenswert?

X. A. schrieb:
> 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...

von Harry L. (mysth)


Lesenswert?

Jens M. schrieb:
> 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.

von X. A. (wilhem)


Lesenswert?

Jens M. schrieb:

> 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.

von Hmmm (hmmm)


Lesenswert?

Jens M. schrieb:
> 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.

Jens M. schrieb:
> 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.

Harry L. schrieb:
> Es gibt kein "Gesetz", das das vorschreibt, aber es ist best practice,
> static leases ausserhalb des dynamischen Bereich zu legen.

Genau.

von Jens M. (schuchkleisser)


Lesenswert?

X. A. schrieb:
> 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.

: Bearbeitet durch User
von Harry L. (mysth)


Lesenswert?

X. A. schrieb:
> Ich vermute sehr start, ein Bug hat sich in die Firmware eingenistet.

Ein Bug, der genau eine IP-Adresse betrifft? - glaubst du das wirklich?
Ein Layer8-Problem ist da schon sehr viel wahrscheinlicher. (Ocams Law)

von X. A. (wilhem)


Lesenswert?

Jens M. schrieb:
> X. A. schrieb:
>> 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.

von Np R. (samweis)


Lesenswert?

Jens M. schrieb:
> 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.

von Jens M. (schuchkleisser)


Lesenswert?

Np R. schrieb:
> Es sei denn, es ist der ominöse Router selbst, der die .70 benutzt.

Das scheint ja so zu sein. Mit abgestecktem LAN und frischem unbenutzten 
WLAN gibt's das Problem immer noch.

Np R. schrieb:
> Und
> selber nichts davon weiß.

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.

Np R. schrieb:
> 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...

: Bearbeitet durch User
von X. A. (wilhem)


Angehängte Dateien:

Lesenswert?

Hallo Freunde!

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.

: Bearbeitet durch User
von Sebastian W. (wangnick)


Lesenswert?

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.

LG, Sebastian

von Jens M. (schuchkleisser)


Lesenswert?

höhöhö, die Chinesen haben eine Backdoor eingebaut...

Versuchs mit 192.168._2_.x
Nimmt der Router die mit?

von Sebastian W. (wangnick)


Lesenswert?

Jens M. schrieb:
> höhöhö, die Chinesen haben eine Backdoor eingebaut...

Ui, ich hab drei Geräte von denen ... auf denen OpenWRT läuft :)

LG, Sebastian

von X. A. (wilhem)


Lesenswert?

Sebastian W. schrieb:
>auf denen OpenWRT läuft :)

Das wollte ich auch ausprobieren. Allerdings scheint OpenWRT nicht 
kompatible mit meinem Modell zu sein.

von Carypt C. (carypt)


Lesenswert?

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/

Mein Router konnte von allein nicht ins internet.

von Hmmm (hmmm)


Lesenswert?

Carypt C. schrieb:
> Entschuldige bitte, ich hab es nicht alles gelesen.

Warum schreibst Du dann etwas dazu?

von Carypt C. (carypt)


Lesenswert?

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.

: Bearbeitet durch User
von X. A. (wilhem)


Lesenswert?

Hallo Freunde,

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

von Daniel F. (df311)


Lesenswert?

X. A. schrieb:
> ...Routerkonfiguration vor dem Reset gespeichert. Wenn ich die alte
> Konfiguration wiederlade...

ok, dann schau doch mal ob die Konfiguration ein einfach lesbares Format 
hat (plain text oder ein Archiv).

vielleicht findest du dann darin einen Hinweis auch die .70

von Jens M. (schuchkleisser)


Lesenswert?

X. A. schrieb:
> 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.

von X. A. (wilhem)


Lesenswert?

Daniel F. schrieb:
> X. A. schrieb:
>> ...Routerkonfiguration vor dem Reset gespeichert. Wenn ich die alte
>> Konfiguration wiederlade...
>
> ok, dann schau doch mal ob die Konfiguration ein einfach lesbares Format
> hat (plain text oder ein Archiv).
>
> vielleicht findest du dann darin einen Hinweis auch die .70

Leider ist eine .bin Datei. Die kann ich nicht auslesen.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

X. A. schrieb:

> 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.

von Harald K. (kirnbichler)


Lesenswert?

Ob S. schrieb:
> 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?

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Harald K. schrieb:

> 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.

von X. A. (wilhem)


Lesenswert?

Ob S. schrieb:

> 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.

von Harald K. (kirnbichler)


Lesenswert?

Ob S. schrieb:
> 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).


X. A. schrieb:
> Ich habe auch mal so mit der .bin Datei probiert und ich kann es
> bestätigen.

Die Fritzbox erzeugt keine ".bin"-Datei, sondern eine ".export"-Datei. 
Und das ist 'ne Textdatei.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

X. A. schrieb:
> Ob S. schrieb:
>
>> 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.

So kenn' wir ihn...

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Harald K. schrieb:

> Was für eine Fritzbox soll das sein?

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.

von Harald K. (kirnbichler)


Angehängte Dateien:

Lesenswert?

Ob S. schrieb:
> 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)

Bitte 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
Noch kein Account? Hier anmelden.