ich habe Wifi led streifen Treiber gekauft welche mit ihrer Cloud und
ihrer App funktionieren. Nirgends kann man einstellen welche Ip sie
nehmen sollen.
sie haben über DHCP eine IP bekommen. Diese sehe ich auch aber ich
möchte fest vergeben.
Wenn ich am DHCP jetzt eine Ip für die mac festlege bleiben die Geräte
aber bei ihrer vorherigen ip. Auch DHCP time runter setzen, Geräte neu
starten oder neu einrichten bringt nix. Die Geräte sind nun seit über 2
Wochen am Netz und haben noch immer die Ip die sie zu Anfang vom DHCP
bekommen hatten.
Da ich die Mac erst kenne wenn ich sie einmal verbunden habe fällt der
weg auch weg sie vorher einzurichten.
Habt ihr Ideen wie man das Lösen könnte?
Die jetzige IP aus dem DHCP Bereich entfernen. Dann müssen sie eine
andere akzeptieren (die gewünschte). Dannach kann der Bereich wieder
freigegeben werden.
Ein anderes Gerät auf diese IP legen und dann erst die LED einschalten
sollte auch funktionieren.
A. H. schrieb:> Die jetzige IP aus dem DHCP Bereich entfernen. Dann müssen sie eine> andere akzeptieren (die gewünschte).
Und wenn die das einfach nicht tun?
Oliver
Oliver S. schrieb:> Und wenn die das einfach nicht tun?
dann kann jeder der die Adresse kennt,
Dein licht an und aus schalten.
An Licht gehört ein normaler Schalter ran und gut.
Reiner schrieb:> Auch DHCP time runter setzen, Geräte neu> starten oder neu einrichten bringt nix.
Wenn die alte Lease-Time auf zwei Wochen stand, dann kann es bei
üblicher Vorgehensweise eine Woche dauern, bis sich eine Änderung
auswirkt.
(prx) A. K. schrieb:> Wenn die alte Lease-Time auf zwei Wochen stand, dann kann es bei> üblicher Vorgehensweise eine Woche dauern, bis sich eine Änderung> auswirkt.
Zusammen mit den o.a. Maßnahmen von A.H.
Ansonsten bekommt der Client einfach die alte IP verlängert.
Oliver
Jochen schrieb:> Der Treiber sollte sofort eine neue IP anfordern wenn die alte belegt> ist.
Warum sollte er das? Der Bug ist ja dann eindeutig auf Seiten des
DHCP-Servers, und ob den Treiber das überhaupt interessiert oder nicht,
liegt völlig in seinem Ermessen. Ansonsten bricht dann einfach Chaos
aus, weil die Pakete nicht mehr sauber zugeordnet werden und praktisch
kein Datenverkehr mehr möglich sein wird.
Der einzig saubere Weg wäre herauszufinden, auf welche Weise der
"Treiber" (was auch immer das für ein Teil sein mag) seine einmal
erhaltenen DHCP-Daten zwischenspeichert, und diese dort zu löschen. Wenn
er keinen alten Lease mehr irgendwo findet, muss er logischerweise einen
neuen anfordern.
Jörg W. schrieb:> Der einzig saubere Weg wäre herauszufinden, auf welche Weise der> "Treiber" (was auch immer das für ein Teil sein mag) seine einmal> erhaltenen DHCP-Daten zwischenspeichert, und diese dort zu löschen.
Ein Factory-Reset sollte das eigentlich erledigen.
Jörg W. schrieb:>> Der Treiber sollte sofort eine neue IP anfordern wenn die alte belegt>> ist.>> Warum sollte er das?
Höfliche Geräte prüfen jedenfalls, ob die IP bereits im Netz genutzt
wird, wenn sie ihren IP-Stack hochfahren.
(prx) A. K. schrieb:>> Warum sollte er das?>> Höfliche Geräte prüfen jedenfalls, ob die IP bereits im Netz genutzt> wird, wenn sie ihren IP-Stack hochfahren.
Naja, vorgeschrieben ist es halt nirgends. Als DHCP-Client darf ich mich
auf meinen Lease verlassen.
Ist ja auch eine Frage, wie das Teil intern organisiert ist: wenn
derjenige, der feststellt, dass die IP-Adresse doppelt vergeben ist,
eine ganz andere Schicht ist als der DHCP-Client, dann kann er
vielleicht nur eine interne Meldung absetzen.
Ich wollte ja nur darauf raus, dass man sich auf sowas nicht verlassen
kann.
Ich habe grade meinem Rechner die ip gegeben kann mich dort auch selber
anpingen. Wenn ich das Led teil anmache gibt es manchmal einige
Paketverluste. Der Led streifen bleibt bei seiner ip.
Ich habe meinen DHCP deaktiviert. Mein Rechner bekommt auch keine mehr.
Led Teil ist das Egal, Er bleibt einfach dort. Also nach Neustart egal.
Was auch immer sie da gemacht haben ist gegen jede Netzwerk regel und
einfach ohne Sinn.
Ich konnte das Problem nun aber Lösen. Ich habe sie auf einem anderen
Wlan angemeldet. Dann wird wieder der DHCP angefragt, aber auch nur ein
einziges mal.
BTW es handelt sich um Tuya Wifi led Controller Teile. Verbaut ist ein
Tuya CBU modul. Darinne werkelt ein bk7231.
Vom kauf wird abgeraten.
Reiner schrieb:> Was auch immer sie da gemacht haben ist gegen jede Netzwerk regel
Das kannst du natürlich so behaupten, aber deine Behauptung ist
anzuzweifeln.
Wenn das Ding einen DHCP Lease für 2 Wochen bekommen hat, weil der
Server so eingestellt ist, dann besagt die "Netzwerk regel", dass die
Kiste die so erhaltene Adresse auch 2 Wochen lang benutzen darf.
Natürlich kann sie auch zwischendurch mal nachfragen, aber sie muss
das nicht tun.
> Vom kauf wird abgeraten.
Nur, weil es einen DHCP Lease, den es mal bekommen hat, auch benutzt?
Das wäre mir ein bisschen dünn als Argument.
(Es kann natürlich andere Gründe geben, warum man vom Kauf abrät, aber
du hast keine genannt.)
Jörg W. schrieb:> Nur, weil es einen DHCP Lease, den es mal bekommen hat, auch benutzt?
Sehr beharrlich wenn es den nicht freigibt wenn die IP schon besetzt
ist.
@Reiner Hat sie denn nachdem sie im anderen Wlan war zurück im alten die
Wunsch IP angenommen?
A. H. schrieb:> Sehr beharrlich wenn es den nicht freigibt wenn die IP schon besetzt> ist.
Auch wenn viele IP-Stacks einen kurzen Check machen: das ist nirgends
vorgeschrieben. Ein IP-Stack kann also seine IP-Adresse (egal, woher er
sie hat) einfach so benutzen.
Nochmal ganz klar und deutlich: der Fehler liegt hier einzig beim
(ursprünglichen) DHCP-Server bzw. dessen Admin, indem dieser einen
entsprechend langen Lease überhaupt erst erteilt hat. In "normalen"
Umgebungen gibt es auch kaum einen Grund, warum man so lange Leases
erteilen müsste. Eine Erneuerung des Leases durch den Client spätestens
nach einem Tag anzufordern, ist selbst für "feste" Adressen ein durchaus
sinnvolles Maß. Für "fluktuierende" Adressen kann man das auch gut und
gern auf eine Stunde herunter drehen, so viel mehr Traffic und Last für
den DHCP-Server entsteht dadurch nun auch wieder nicht.
A. H. schrieb:> Sehr beharrlich wenn es den nicht freigibt wenn die IP schon besetzt> ist.
Ein Client ist nicht verpflichtet zu prüfen, ob eine per DHCP zugeteilte
IP-Adresse frei ist, es wird in RFC2131 bloss empfohlen:
> The client SHOULD perform a check on the suggested address to ensure> that the address is not already in use. For example, if the client> is on a network that supports ARP, the client may issue an ARP request> for the suggested request.
Und selbst diese Empfehlung ist heutzutage problematisch, weil er in
einem WLAN mit Client Isolation die Antwort nicht bekommen würde.
Jörg W. schrieb:> Nochmal ganz klar und deutlich: der Fehler liegt hier einzig beim> (ursprünglichen) DHCP-Server bzw. dessen Admin, indem dieser einen> entsprechend langen Lease überhaupt erst erteilt hat.
Der TO hat allerdings nie erwähnt, welche Lease Time tatsächlich
verwendet wird. Ich gehe zwar auch von einer ewig langen Zeit aus, mir
sind aber auch schon oft Clients begegnet, die abgelaufene Leases
einfach weiterhin benutzt haben.
Hmmm schrieb:> mir sind aber auch schon oft Clients begegnet, die abgelaufene Leases> einfach weiterhin benutzt haben
Das wäre natürlich in der Tat ein Fehler. Der wäre tolerierbar, wenn der
Client ihn in Ermangelung einer Antwort vom DHCP-Server gewissermaßen
vorübergehend weiter nutzt ("besser als gar nichts"), aber da ja hier
offensichtlich ein Server da ist, der reagiert, muss der Client
natürlich spätestens nach Ablauf des Leases neu anfragen.
> es wird in RFC2131 bloss empfohlen
Wobei ich das jetzt auch so lese, dass er diesen Test direkt nach der
Zuteilung des Leases ausführen soll. Während der Lebensdauer muss er das
dann nicht wiederholt machen.
Hmmm schrieb:> Ein Client ist nicht verpflichtet zu prüfen, ob eine per DHCP zugeteilte> IP-Adresse frei ist
Wie würde er das prüfen? Per Arp Frage?
Korriegiert mich bitte wenn ich falsch liege. Der Client ist auch nicht
verpflichtet die angebotene IP zu übernehmen?
Er meldet sich "Ich bin mac und hätte gern IP xy"
Der DHCP "Bitte nutze IP yz"
Der Client "Mag ich nicht ich will xy"
Hat der Dhcp dann eine Wahl?
Kann er den Zugang verweigern z.B. weil xy vergeben ist?
A. H. schrieb:> Wie würde er das prüfen? Per Arp Frage?
Ja, wurde ja im Zitat aus dem RFC explizit so genannt. Er fragt per ARP
an, ob sich jemand für diese Adresse meldet. Wenn ja, weiß er, dass sie
belegt ist. In einem interaktiven Umfeld (PC etc.) würde man dann wohl
den Bediener informieren. Bei so einem IoT-Device hat man dann
eigentlich nur die Wahl, gar keine IP-Adresse zu benutzen. Bleibt sich
letztlich gleich, denn eine Kommunikation ist in der Situation so oder
so nicht möglich.
Hmmm schrieb:> Der TO hat allerdings nie erwähnt, welche Lease Time tatsächlich> verwendet wird. Ich gehe zwar auch von einer ewig langen Zeit aus,
Wie groß können die denn werden? Meine bintec erlaubt keine Lease Time
größer 300 Minuten.
> mir sind aber auch schon oft Clients begegnet, die abgelaufene Leases> einfach weiterhin benutzt haben.
Ich habe eher das Gefühl, dass der DHCP-Server schuldig ist und die
einmal zugeteilte IP beliebig oft verlängert. Es gibt ja keinen
plausiblen Grund, bei einer Verlängerungsanfrage in der Tabelle zu
gucken, ob eine abweichende Reservierung eingetragen wurde.
Kommt mir vom Windows-Laptop bekannt vor: Erstmal eine IP holen lassen,
später im DHCP eine abweichende Reservierung eingetragen. Dauert ewig
und die Randbedingungen sind mir unklar, bis die Kiste diese neue,
andere IP, tatsächlich bekommt.
A. H. schrieb:> Er meldet sich "Ich bin mac und hätte gern IP xy"
Quark. "Ich bin mac sonstwas und hätte gerne eine IP", der weiß nicht,
in welchem Netz er ist. Nach Ablauf der Leasetime wird das interessant,
"ich habe IP xx und will verlängern".
Manfred schrieb:>> Der TO hat allerdings nie erwähnt, welche Lease Time tatsächlich>> verwendet wird. Ich gehe zwar auch von einer ewig langen Zeit aus,>> Wie groß können die denn werden?
Ich finde im RFC auf Anhieb keine Angabe dazu. Da es vier Bytes sind,
maximal 136 Jahre. ;-)
Jörg W. schrieb:> Das wäre natürlich in der Tat ein Fehler. Der wäre tolerierbar, wenn der> Client ihn in Ermangelung einer Antwort vom DHCP-Server gewissermaßen> vorübergehend weiter nutzt ("besser als gar nichts")
Selbst das nicht. Er könnte ja wegen Packet Loss (z.B. WLAN) keine
Antwort bekommen haben, während der DHCP-Server die Adresse längst neu
zugeteilt hat.
Wenn die Lease nicht verlängert wird, muss er nach Ablauf immer bei 0
anfangen und versuchen, eine neue zu bekommen.
Jörg W. schrieb:> Wobei ich das jetzt auch so lese, dass er diesen Test direkt nach der> Zuteilung des Leases ausführen soll. Während der Lebensdauer muss er das> dann nicht wiederholt machen.
Bei einem Neustart des Geräts, wie vom TO vorgenommen, ist es die Frage:
Verlässt man sich auf die SSID als Indiz, im richtigen Netz zu sein,
oder schickt man doch lieber nochmal ein DHCPDISCOVER? Wenn ich da an
die ganzen Fritzbox-Standard-SSIDs denke...
Während der Laufzeit macht es Windows meines Wissens passiv und schlägt
alarm, wenn es einen ARP-Request von seiner eigenen IP-Adresse sieht.
A. H. schrieb:> Wie würde er das prüfen? Per Arp Frage?
Ja.
A. H. schrieb:> Der Client "Mag ich nicht ich will xy"> Hat der Dhcp dann eine Wahl?
Der DHCP-Server kann einen DHCPREQUEST mit DHCPNAK ablehnen.
Kommt in der Praxis z.B. vor, wenn ein neuer Client erstmal eine
dynamische Adresse bekommt und man ihn dann auf eine statische umstellt.
Dann will er irgendwann seine vorhandene Lease verlängern, bekommt ein
DHCPNAK und wird so gezwungen, sich die neue zuteilen zu lassen.
Manfred schrieb:> Wie groß können die denn werden? Meine bintec erlaubt keine Lease Time> größer 300 Minuten.
Sekunden als unsigned 32-Bit Integer, also über 100 Jahre, infinite geht
auch.
Manfred schrieb:> Ich habe eher das Gefühl, dass der DHCP-Server schuldig ist und die> einmal zugeteilte IP beliebig oft verlängert.
Dass eine vorhandene Lease verlängert wird, ist der Regelfall. Ich
meinte aber schon Clients, die sie nicht verlängert und trotzdem benutzt
haben.
Zum einen waren das Smartphones, die vermutlich in einem Sleep-Zustand
waren und beim Aufwachen einfach die Adresse weiterbenutzt haben, zum
anderen meine ich mich an einen Drucker zu erinnern, der das ebenfalls
getan hat - wohl in der Annahme des Herstellers, dass Leases für Drucker
ohnehin feste IP-Adressen sein dürften.
Manfred schrieb:> Es gibt ja keinen> plausiblen Grund, bei einer Verlängerungsanfrage in der Tabelle zu> gucken, ob eine abweichende Reservierung eingetragen wurde.
Der DHCP-Server prüft, ob die Adresse verfügbar ist, also entweder dem
Client selbst gehört oder frei ist und zum dynamischen Pool gehört. Und
wenn es für den Client inzwischen eine feste IP-Adresse gibt, wird die
Verlängerung natürlich auch abgelehnt.
Manfred schrieb:> Kommt mir vom Windows-Laptop bekannt vor: Erstmal eine IP holen lassen,> später im DHCP eine abweichende Reservierung eingetragen. Dauert ewig> und die Randbedingungen sind mir unklar, bis die Kiste diese neue,> andere IP, tatsächlich bekommt.
Wenn Du es erzwingen willst: ipconfig /renew
Ansonsten dauert es halt bis zur Verlängerung der Lease, also meistens
etwa die halbe Lease Time.
Manfred schrieb:> Quark. "Ich bin mac sonstwas und hätte gerne eine IP", der weiß nicht,> in welchem Netz er ist.
Doch, wenn er nach dem DHCPDISCOVER ein DHCPOFFER von einem DHCP-Server
bekommt, dessen Server Identifier er kennt, kann er durchaus versuchen,
beim DHCPREQUEST nochmal die Adresse vom letzten Besuch zu bekommen. Ist
mir auch schon in freier Wildbahn begegnet.
