Die Telekom hilft Community zieht um und ist bis zum 8. Januar 2025 nur eingeschränkt zugänglich.
Speedport Smart 3 DHCP ignoriert statische IP und vergibt neue IP
vor 4 Jahren
Hallo zusammen,
ich habe einen Speedport Smart 3 als Router. DHCP Server für LAN und WLAN ist aktiviert. IP Adressen werden über den Bereich 192.168.2.100 bis 192.168.2.230 vergeben. Automatische IP-Vergabe via DHCP Server erfolgt problemlos. Ich habe nun ein Gerät (Raspberry Pi 1) mit einem Debian Linux als Printserver am laufen. Mal ist er über WLAN und mal über LAN angebunden (mal über beides) angebunden.
Dem Raspberry Pi habe ich statische IP Adressen für LAN und WLAN gesetzt (in der /etc/dhcpcd.conf):
# LAN
interface eth0
static ip_address=192.168.2.220/24
static routers=192.168.2.1
static domain_name_servers=192.168.2.1
# WLAN
interface wlan0
static ip_address=192.168.2.100/24
static routers=192.168.2.1
static domain_name_servers=192.168.2.1
Wenn ich ifconfig auf dem Pi aufrufe, bekomme ich die korrekten IP Adressen angezeigt.
Wenn ich nun in der Weboberfläche meines Speedport Smart 3 nachschaue, hat der Pi via LAN die korrekte IP bekommen aber via WLAN eine andere (z.B. 192.168.2.150) -- zumindest laut Anzeige. Greife ich auf den Pi via SSH zu, ist er manchmal über beide WLAN IPs (...100 und ...150) zu erreichen, manchmal nur über die statische und manchmal gar nicht.
Wenn ich ins Log des Routers schaue, steht dort folgendes:
08.09.2020 22:48:59 (H001) DHCP ist aktiv: 08.09.2020 22:48:58 LAN printserver b8:27:eb:c4:20:97 192.168.2.209 255.255.255.0 192.168.2.1 192.168.2.1 1814400
08.09.2020 22:48:57 (H001) DHCP ist aktiv: 08.09.2020 22:48:56 WLAN printserver f8:1a:67:09:22:ed 192.168.2.150 255.255.255.0 192.168.2.1 192.168.2.1 1814400
Sowohl für LAN wie auch für WLAN möchte der DHCP selbst IP-Adresse vergeben. Das LAN Device des Ri scheint mit dem Router aber seine statische IP auszuhandeln, sodass diese später auch in der Weboberfläche angezeigt wird. Für das WLAN wird mir im Webinterface später die vom DHCP Server vergebene IP Adresse angezeigt, obwohl das Pi WLAN tatsächlich die selbst gewählte statische IP Adresse hat.
Zusätzlich treten manchmal Artefakte auf, dass die statische IP des WLAN devices auf einmal als IP Adresse des LAN Devices im Webinterface des Speedport angezeigt wird. Ich habe testweise feste Namen für die beiden Verbindungen in der Weboberfläche vergeben. Manchmal werden dann auch die Namen für LAN und WLAN Device in the Weboberfläche vertauscht.
Wenn ich 20 Minuten warte stimmen die angezeigte IP Adresse im Webinterface und die tatsächliche statische IP Adresse auf einmal überein. Manchmal aber auch nicht.
Ich hatte ursprünglich IP Adresse außerhalb des vom DHCP Server vergebenen IP-Bereich gesetzt (so ist ja für gewöhnlich die Empfehlung). Da dies nicht ging, habe ich es anders probiert ... . Geht auch nicht. Bzw. geht fürs LAN Device aber nicht fürs WLAN Device.
Ich bin mir nicht sicher, ob hier ein Problem mit der Firmware des Speedport Smart 3 vorliegt oder mit Linux dem Router nicht seine tatsächliche statische WLAN IP mitteilit.
3387
13
Das könnte Ihnen auch weiterhelfen
vor 3 Jahren
813
0
2
1294
0
4
417
0
4
944
0
6
820
0
2
Community Guide
vor 4 Jahren
@neumannd
1) Ändere das Ende des DHCP-Bereiches.
In den Werkseinstellungen des Routers wäre es an der vierten Position 100 bis 199. Du hast aber dort manuell bis
300230 eingetragen.Laut Bedienungsanleitung darf man den Bereich weiter einschränken, also verkleinern. Von vergrößern steht dort nichts. Womöglich mag er das nicht.
Zunächst hatte ich 300 statt 230 gelesen, und deshalb das geschrieben, was ich nun nachträglich in den Spoiler geschoben habe. Vielleicht ist es aber auch so noch von Nutzen, auch wenn es sich auf die 300 noch bezieht, da es erklärt, dass und wieso das Maximum an der vierten Position die 254 ist. Deshalb habe ich es im Spoiler erhalten.
Mich wundert, dass es der Router die 300 überhaupt angenommen hat. Denn er kann an der vierten Position nur bis 254.
Eine IPv4-Adresse besteht aus vier Teilen, getrennt durch Punkte. Und jeder Teil wird in einem Byte (= 8 Bit) definiert.
1 Bit kann zwei Zustände einnehmen: 0 oder 1, man hat somit 2 Möglichkeiten. Sind es zwei Bit, dann verdoppeln sich die Möglichkeiten zu 2*2 oder 2 hoch 2 = 4, sind es drei Bit, dann werden die 4 Möglichkeiten wieder um den Faktor 2 vervielfältig 2*2*2 oder 2 hoch 3 = 8. ... Bei 8 Bit hat man 2 hoch 8 Möglichkeiten = 256.
Die erste Möglichkeit ist die Zahl 0.
Die zweite Möglichkeit ist die Zahl 1.
Die dritte Möglichkeit ist die Zahl 2.
...
Die 256te Möglichkeit ist demnach die Zahl 255.
Somit können alleine durch die Nutzung von einem Byte je Position in der Adresse, nur Zahlen von 0 bis 255 verwendet werden.
Wieso du dann eine Zahl als Ende des DHCP-Bereiches vergibt, welche größer als dieses Maximum ist (die 300 liegt deutlich darüber), ist mir ein Rätsel.
Hinzu kommt, dass anscheinend sogar für den Router selbst bei der vierten Position als Maximum nicht die rechnerische Zahl 255 sondern die Zahl 254 voreingestellt ist. Ich gehe davon aus, dass für systeminterne Zwecke die 255 an der vierten Position für etwas verborgenes verwendet wird. Außerdem darf anscheinend auch nicht die 0 verwendet werden, als kleinste Zahl an der vierten Position ist die 1 vorgesehen.
Dass man nicht mal für den Router selbst nur maximal die 254 an der vierten Position vergeben darf (Vergabe nur von 1 bis 254), findest du in der Betriebsanleitung des Smart 3 auf der Seite 242.
Wenn der Router selbst für sich nicht mehr darf, wie soll er dann IPv4-DHCP-Adressen vergeben können, welche sogar außerhalb des für den Router selbst möglichen Bereiches liegen?
2) Auch keinem Client eine Adresse an der vierten Position zuweisen, welche über dieses Maximum von 254 hinaus geht. Und natürlich keine Adresse an der vierten Position, welche ein anders Gerät bereits hat.
Du hast erwähnt, dass es Probleme dabei gab, Adressen im Nicht-DHCP-Bereich, wie man es eigentlich machen sollte, dem Client zu vergeben. Für die LAN-Adresse wäre es gegangen, für die WLAN-Adresse nicht. Wenn du eine Adresse für das WLAN dabei vergeben hattest, welche entweder bereits durch ein anderes Gerät belegt war (nie Adressen an der vierten Position doppelt) oder es eine Zahl war, welche über das Maximum von 254 hinaus gegangen war, dann sind Probleme vorprogrammiert.
Hatte die von dir zunächst gewählte WLAN-Adresse für den Client an der vierten Position eine Zahl, welche höher als die 254 war? Dann hast du schon mal die Antwort dafür, wieso die Adresse nicht funktionieren konnte.
3) Wie du schon selbst geschrieben hast: Feste IP-Adressen, welche in einem Client (statt im Router) vergeben werden, nur aus dem Nicht-DHCP-Bereich eines Routers wählen, nicht im DHCP-Bereich.
Wenn du den DHCP-Bereich des Routers auf seinen ursprünglichen zurücksetzt, das wäre an der vierten Position 100 bis 199. Dann liegt der Nicht-DHCP-Bereich des Routers an der vierten Position bei 1 bis 99 (bzw. 001 bis 099) und zusätzlich bei 200 bis 254.
Da der Router in diesem Nicht-DHCP-Bereich schon sich die 1 (bzw. 001) geschnappt hat, bleiben an der vierten Position nur noch die Nummern 2 (002) bis 99 (099) und die Nummern 200 bis 254 übrig. Vorausgesetzt, die hat auch noch kein anderes Gerät fest zugewiesen bekommen.
4) Falls die abgelehnte WLAN-Adresse an der vierten Position ein- oder zwei stellig war, und deshalb abgewiesen worden war: dann schreibe die Nummer dreistellig.
Es gibt Clients, bei denen könnte die Zahl der vierten Position auch ein- oder zweistellig geschrieben werden. Es gibt aber auch Clients, die packen es nur dreistellig. Deshalb habe ich in meinen Beispielen beide Schreibarten verwendet, z. B. nach der 2 in Klammern 002 und nach der 99 in Klammern die 099. Dann einfach die Schreibweise verwenden, welche der Client lieber hätte.
5) Sehr gut, dass du dem Router und allen Clients identischen Zahlen an den vorderen Positionen (Position 1 bis 3 der Vier-Positionen-Adresse) zugewiesen hast. Die müssen in allen Geräten gleich sein, dürfen sich nicht unterscheiden.
6) @UlrichZ ist die Bedienungsanleitung aus dem Downloadbereich veraltet bzgl. fester IP-Adressen oder habe ich es darin nur übersehen? Der Smart (1) und der Smart 2 können beide auf eine bequemere Weise Clients eine DHCP-IP-Adresse fest zuweisen, über das Routermenü selbst.
Wenn der Client sogar DHCP-Adressen akzeptiert, warum sich es so schwer machen mit dieser altmodischen festen IP-Adressvergabe, falls es im Smart 3 eine ähnlich einfache alternative Möglichkeit geben würde?
Im Smart 2 kann beispielsweise eingestellt werden, dass er einem Gerät immer wieder die gleiche Adresse gibt, welche der Router dem Gerät per DHCP automatisch zugewiesen hatte. Er gibt also dann eine DHCP-Adresse fest immer nur diesem Gerät, wobei Wlan und LAN unterschiedlich behandelt werden, falls das Gerät extra Chipsatz und MAC-Adresse für WLan und für LAN hat. Man das also erstens für Wlan und zweitens für Lan dann einstellen müsste, nachdem der Router aufgrund der Verbindung per LAN und per WLAN dem Gerät zwei verschiedene Adressen bereits gegeben hatte.
Die kann man dann durch Haken-Setzen im Routermenü als fixierte Adressen festlegen.
Das sieht bei mir im Smart 2 beispielsweise so aus:
Das Gerät hatte von selbst per DHCP die 100 am Ende erhalten. Dass es auch in Zukunft die 100 bekommen wird, und kein anderes Gerät, habe ich dann folgendermaßen festgelegt:
Ich habe auf das magentafarbene Wort "ändern" in meinem Smart 2 dahinter geklickt. Bei deinem Smart 3 könnte dort ein anderer Begriff stehen, könntest du dann auch mal ausprobieren, was dann passiert, @neumannd .
Dadurch blättert bei mir die Info zu dem Gerät weiter auf und kann ich kann manches machen, z. B. dem Gerät einen (anderen) Namen geben oder ihm den Haken setzen, dass es immer diese Adresse in Zukunft weiter behalten soll, also auch künftig diese IP zugeordnet bekommen soll. Und dann speichern.
So sieht das bei mir aus:
3
Antwort
von
vor 4 Jahren
@Sherlocka Danke für die auswührliche und schnelle Rückmeldung.
zu 1:
Ich habe hier mehrere Geräte, die automatisch IP Adressen zwischen 200 und 230 zugewiesen bekommen haben. Das Festlegen einer IP ("Immer diese IP beziehen") und das setzen eines Namens über das Webinterface des Speedports gehen fehlerfrei (z.B. bei einem Gerät mit der automatisch zugewiesenen IP 208 im vierten Block).
zu 2:
Ist ordentlich konfiguriert, wie du schreibst.
zu 3:
Habe es im IP Bereich des DHCP-Servers versucht und außerhalb. IP Adressen wurden nicht doppelt vergeben.
zu 4:
Tatsächlich versuche ich gerade zweistellige Nummern im vierten Block zu vergeben. Für die LAN-Karte geht das aber problemlos. Nur das WLAN macht Probleme. Das Problem bestand aber auch für dreistellige Nummern im vierten Block. Wäre traurig, wenn es daran liegt und es nicht ordentlich dokumentiert ist.
zu 5:
Ist ordentlich konfiguriert, wie du schreibst.
zu 6:
Funktioniert einwandfrei die IP, die vom DHCP-Server vergeben wurde, festzulegen. Das habe ich bisher so gemacht. Ich habe hier aber mittlerweile sechs Geräte im LAN/WLAN, die statische IPs haben sollen. Wenn ich einfach die IPs, die der DHCP-Server setzt, als dauerhaft zu vergeben markiere, habe ich irgendwelche statische IPs. Die kann ich mir schlecht merken. Natürlich könnte ich sie auf einen Zettel schreiben oder an die Geräte kleben, was ich aktuell mache. Davon wollte ich aber weg und das ganze systematisieren.
3 Sterne Mitgestalter*in
vor 4 Jahren
HI,
naja, solange kein DHCPDISCOVER (schickt der Client) kommt, antwortet der Server auch nicht (DHCPOFFER).
von daher wuerde ich mir die Konfig des Clients erstmal vornehmen.
ein Trace (wireshark?) könnte helfen
evtl. kann man den DHCP daemon (DHCPD?) am client (PI) mal deaktivieren
2
Antwort
von
vor 4 Jahren
>sollte meine dhcpcd Prozess eigentlich kein DHCPDISCOVER schicken, oder?
wie gesagt - ziehe einen Trace, dann weisst du es
1 Sterne Mitglied
vor 4 Jahren
0
Telekom hilft Team
vor 4 Jahren
wie weit bist du gekommen?
Ansonsten unterstützen unsere Kollegen von der Computerhilfe auch gerne weiter.
Schau mal hier:
https://www.telekom.de/zuhause/tarife-und-optionen/zubuchoptionen/computerhilfe
Viele Grüße
Markus Km.
2
Antwort
von
vor 4 Jahren
ich habe mal dein Fehlerbild an die Kollegen der Fachabteilung als Bug Reporting weitergegeben.
Sollte ich noch etwas brauchen, melde ich mich bei dir.
Auch Updates bezüglich dieses Falles werde ich dir hier geben.
Viele Grüße Nico B.
Telekom hilft Team
vor 4 Jahren
da bin ich wieder.
Die Probleme werden zurzeit untersucht und sind leider auch mit der aktuellsten Firmware vorerst nicht behoben.
In späteren Updates wird sich diesem Problem angenommen, wann das nächste Firmware Update mit einem Bug-Fix diesbezüglich kommt, können wir leider aktuell nicht sagen.
Viele Grüße Nico B.
0
Telekom hilft Team
vor 4 Jahren
die Fachabteilung hat uns geantwortet.
Das Verhalten ist bei den Produktverantwortlichen gemeldet und in der Untersuchung.
Wann hierfür eine Lösung bereitgestellt werden kann, konnten die Kollegen mir nicht mitteilen. Sie bedanken sich jedoch für die Meldung.
Viele Grüße
Dean B.
0