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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
(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
Oder einem anderen Gerät die IP geben. Der Treiber sollte sofort eine neue IP anfordern wenn die alte belegt ist.
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.)
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch Moderator
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.