[Problem] AP hinter FB7490 vergibt lokale IP im falschen Bereich

[hexadezimal]

Hallo,
ich habe eine Wlan-Kamera mit einem Wlan-AP verbunden, obwohl im Router FB7490 für den DHCP Server der Bereich 192.168.178.20 bis 200 angegeben ist bekommt die Wlan-Kamera die IP 192.168.178.16 zugewiesen. Alles läuft nur lokal, Fernzugriffe nur über VPN, keine direkter Zugang ins Internet für die Wlan-Kamera.
Ich sehe nur in der Konfiguration des Wlan-AP die IP der Wlan-Kamera, nicht in der FB.

Konfiguration:
Router FB7490 per LAN verbunden mit AP FB7490
AP FB7490 per LAN verbunden mit AP D-Link COVR-1100
AP D-Link COVR-1100 verbunden per WLAN mit LSC PTZ Kamera

Woran kann das liegen, das die IP nicht im vorgegebenen Bereich liegt.

Mfg
Axel

 

[tango501]

Von der LSC PTZ Kamera gibt es nur einen Screenshot mit den Statusinformationen. Gibt es dort auch eine Konfigurationsseite und einen Screenshot davon?
Um welches Modell von LSC handelt es sich dabei? Ist es zufällig "Product 3007325" bzw. "factory model IPC167"?

 

[hexadezimal]

Da lässt sich manuell nichts einstellen, außer dem Wlan-AP über den sich die Kamera mit dem Netz verbindet, das läuft alles über eine App (LSC Smartconnect App, Tuya-App geht auch) hier daher nur auch nur ein Screenshot aus der App. Die IP ist die, der FB zugewiesene dynamische.

[Edit Novize: Beiträge gemäß der Forumsregeln zusammengefasst]

Das kann ich erst morgen früh sagen, die Kamera steht in einem anderen Haus.

[Edit Novize: Beiträge gemäß der Forumsregeln zusammengefasst]

Es ist Art.No.; 3007325.5 (Supplier reference 5525002003 G1)

 

[Grisu_]

Und wenn du die Verbindung auf der FB löschst und sie sich eine neue holen muß?
Währenddessen die Kamera stromlos machen, damit sie sich die aktuelle IP nicht merkt.

 

[hexadezimal]

Und wenn du die Verbindung auf der FB löschst und sie sich eine neue holen muß?

Da kann ich ja nichts löschen, die IP 192.168.178.16 liegt ja außerhalb des eingestellten Bereichs des DHCP der FB, der geht von 192.168.178.20 bis 200.
Ich hatte auch schon überlegt den Bereich in der FB zu ändern, es aber gelassen, weil ich mir da nichts zerschießen will.
Das mit dem stromlos machen werde ich heute Abend mal versuchen.

Da die AP (FB und D-Link) alle den FB-Router als DHCP nutzen, verstehe ich nicht, dass die Kamera eine falsche IP bekommt. Man kann die Kamera nur über die smartphon-App einrichten, dort muss ich aber mit der Kamera am gleichen Wlan-AP angemeldet sein, welches die IP ja über DHCP vom Router bekommen sollte.
Versuchsweise werde werde ich auch mal eine alte FB anstatt des D-Link AP einrichten, vielleicht ist es ja ein Übertragungsproblem der zwischen FB und D-Link, dass dort die Information über den Adressbereich verloren geht.

Um welches Modell von LSC handelt es sich dabei? Ist es zufällig "Product 3007325" bzw. "factory model IPC167"?

Es ist Art.No.; 3007325.5 (Supplier reference 5525002003 G1)

Dazu habe ich jetzt außer einem zusätzlichen Datenblatt, nichtssagenden Amazonbewertungen und älteren Fragen zum Firmwareupdate bei GitHub jetzt nichts weiter gefunden.
Die Firmware ist V1.0.0(6.2863.125)

 

[Deleted member 273463]

Nach einer kurzen Durchsicht der Anleitung des D-Link COVR, bin ich der Meinung, dass das Gerät nicht als IP Client, sondern nur als eigenständiger Router betrieben werden kann. Auf dem Gerät läuft also ein eigener DHCP, der der Kamera die entsprechende IP zuteilt. Das erklärt auch, warum die Kamera nicht in der Fritz!Box angezeigt wird.

 

[hexadezimal]

Nach einer kurzen Durchsicht der Anleitung des D-Link COVR, bin ich der Meinung, dass das Gerät nicht als IP Client, sondern nur als eigenständiger Router betrieben werden kann. Auf dem Gerät läuft also ein eigener DHCP, der der Kamera die entsprechende IP zuteilt. Das erklärt auch, warum die Kamera nicht in der Fritz!Box angezeigt wird.

In der "normalen" Anleitung steht das nicht, dazu gibt es die zusätzliche (siehe Anlage) die nennen das dort Bridge-Modus.
Alle anderen Geräte außer der Kamera, die ich über den D-Link AP anmelde bekommen IP im vorgegebenen Bereich.
Die Einstellungen sieht man auch im Anhang covr1konfig.png vom ersten Posting.

Könnte es vielleicht an den Einstellungen für IPv6 liegen?
Die Abhängigkeiten beim lokalen DHCP Server zwischen IPv4 und IPv6 sind mir nicht klar, brauch ich die auf der lokalen Ebene überhaupt?
Kann sein, dass der primär eine IPv6 erstellt und dann daraus eine IPv4 quasi ableitet und die landet im falschen Bereich?

 

[Deleted member 273463]

Die Einstellungen sieht man auch im Anhang covr1konfig.png vom ersten Posting.

Dort ist nicht erkennbar, dass das Gerät im Bridge Modus läuft.

Könnte es vielleicht an den Einstellungen für IPv6 liegen?

Nein.

brauch ich die auf der lokalen Ebene überhaupt?

Das kommt auf dein Netzwerk an. Ich sag mal, ja.

Kann sein, dass der primär eine IPv6 erstellt und dann daraus eine IPv4 quasi ableitet und die landet im falschen Bereich?

Nein.


Woher weißt du denn, dass die Kamera eine IP per DHCP zugewiesen bekommt? Hast du die Kamera mal direkt an der ersten Fritz!Box angemeldet?

 

[klp55tsch]

In der "normalen" Anleitung steht das nicht, ...

BTW: Es gibt tools mit denen Du testen/prüfen kannst ob ein bestimmtes Gerät in deiner Konstellation (Home-Netz), auch als DHCP-Server fungieren kann. Z. B.:

:~# dhcping -c 192.168.178.4 -s 192.168.178.1 -h ##:##:##:b6:b9:a2
Got answer from: 192.168.178.1

Man kann die FritzBox auch gezielt nach den ihr bekannten Clients (... auch die die ihre IP-Adresse nicht per DHCP von der FB bekommen haben) fragen. Z. B.:

:~# nmap -e eth0 -sP -R --dns-servers 192.168.178.1 192.168.178.0/24 | grep -i fritz.box | awk {'print $5$6'}
fritz.box(192.168.178.1)
yxyxyx.fritz.box(192.168.178.13)
yyyyy.fritz.box(192.168.178.40)
xxxxx.fritz.box(192.168.178.55)

Vor dem Scan mit nmap, evtl. einen arpscan (arp-scan -I eth0 -l) ins Home-Netz machen, damit die erreichten Clients, sich mit einem arp-reply bekannt geben.

EDIT:

Ein weiteres tool das DHCPDISCOVER an 255.255.255.255 port 67 sendet, ist check_dhcp aus dem package monitoring-plugins-basic:

/usr/lib/nagios/plugins/check_dhcp -i eth0 -v

Es gibt auch DHCP-Clients die sich eine IP-Adresse von außerhalb der DHCP-Pools des erreichbaren DHCP-Servers, "zuweisen" und den Server per DHCPINFORM benachrichtigen.

 

[BenaresNeu]

Da kann ich ja nichts löschen, die IP 192.168.178.16 liegt ja außerhalb des eingestellten Bereichs des DHCP der FB, der geht von 192.168.178.20 bis 200.

Schau mal auf deiner Fritzbox unter Heimnetz, Netzwerk. Der eingestellte DHCP-Bereich gilt nur für neue Geräte. Wenn es schon Geräte außerhalb dieses Bereiches gibt, bekommen die auch wieder diese IP. Das geht durchaus. Du kannst dort auch ein Gerät löschen, dazu muss es aber erst inaktiv/aus sein und unter "ungenutzte Verbindungen" aufgeführt sein. Du kannst aber auch einfach dessen IP über "Bearbeiten" ändern, dann bekommt es beim nächsten Neustart diese IP.

 

[tango501]

Dazu habe ich jetzt außer einem zusätzlichen Datenblatt ... jetzt nichts weiter gefunden.

Zumindest ein "Benutzerhandbuch" als PDF wäre da dann auch noch verfügbar.

https://asset.action.com/image/upload/v1730447990/Final/Documents/Quality%20Product%20Documents/5525000100_c4_um.pdf

 

[Ldwg2002]

Bei DHCP macht aus den RFC's so jeder Hersteller was er will.
DHCP-Server machen was der Hersteller will. DHCP-Hosts machen was der Hersteller will.

Es gibt DHCP-Server (Hersteller), die erteilen neue Leases (wenn eine LeaseTime abgelaufen ist) aus Bereichen ]20 bis 200[ für die sie nicht (mehr) zuständig sind, keinen administrativen Eintrag haben und deshalb keinen Renew mehr erteilen dürften. So tun es die FritzBoxen / FritzOS, deshalb sind es Consumerboxen, die den Kunden (als Verbraucher) rundum glücklich machen.

Wenn es schon Geräte außerhalb dieses Bereiches gibt, bekommen die auch wieder diese IP. Das geht durchaus.

"bekommen" ist definitiv kein Standard. Nur eine (im Host eingetragene oder im Server verwaltete) feste/statische IP außerhalb des dynamischen Bereichs darf "behalten" werden.

Es gibt Hosts (Hersteller), die behalten nach der Einrichtung mit einer App eine (erstmals mit LeaseTime) zugeteilte IP-Adresse auch wenn bei einem Neustart die LeaseTime längst abgelaufen ist. So erlebt bei einer Steinel CAM600 (Haustürkamera) mit Pi-hole als DHCP-Server.

Besonders lustig werden DHCP-Themen, wenn es einen rogue DHCP-Server im LAN gibt, der unentdeckt bleibt.

im Router FB7490 für den DHCP Server der Bereich 192.168.178.20 bis 200 angegeben

Wenn du dein Netz im Standardvorschlag (192.168.178.1/24) verwaltest, wird es schwieriger mit den Vorschlägen von @klp55tsch einen Schurken (rogue / Fehlkonfiguration) zu finden der im Standardnetz mitmischt.

 

[tango501]

wenn es einen rogue DHCP-Server im LAN gibt, der unentdeckt bleibt

In solchen Fällen einfach mal einen geeigneten Netzwerkscanner einsetzen, der hilft dann weiter.

 

[klp55tsch]

Besonders lustig werden DHCP-Themen, wenn es einen rogue DHCP-Server im LAN gibt, der unentdeckt bleibt.

BTW: Dann starte ich z. B.:

dhcpdump -i eth0

auf 2 - 3 Geräten im LAN und wenn dieser rogue DHCP-Server Datenpakete mit DHCP-Bezug sendet, wird er auch entdeckt.

 

[Grisu_]

Ändere doch einfach einmal das Subnetz, welche IP die Kamera dann nutzt (und später wieder zurück).

 

[hexadezimal]

Man kann die FritzBox auch gezielt nach den ihr bekannten Clients (... auch die die ihre IP-Adresse nicht per DHCP von der FB bekommen haben) fragen. Z. B.:

:~# nmap -e eth0 -sP -R --dns-servers 192.168.178.1 192.168.178.0/24 | grep -i fritz.box | awk {'print $5$6'}

[/QUOTE]
sieht bei mir so aus, jetzt hat die Kamera hinten die 163, aber in der Geräteliste des Router steht die nur als "ungenutzte Verbindung" auch wenn ich mir gerade Bilder über die Kamera ansehe.
[FONT=courier new]nmap -e eno1 -sP -R --dns-servers 192.168.178.1 192.168.178.0/24 | grep -i fritz.box | awk {'print $5$6'}
fritz.box(192.168.178.1)
....
lscptzcam11.fritz.box(192.168.178.163)[/FONT]

 

[klp55tsch]

Benutzt Du zum anschauen der Bilder über die Kamera, die IP .163? Mach mal einen arp-scan in das Subnetz der FB um zu sehen welche MAC-Adresse der IP .163 zugeordnet ist und um zu sehen, ob sich die MAC-Adresse der Kamera evtl. ändert.

 

[Ldwg2002]

Bei allen Tests und Überlegungen musst du bedenken wie lange ein vergebener Lease vom Client verwendet werden darf (Standard) und tatsächlich verwendet wird (Realität).

Welche Gültigkeitsdauer verwendet dein DHCP-Dienst? Im FritzOS sind 10 Tage Standard, siehe #1. Das ist gähnend lange, wenn man IPAM-Probleme im LAN aufspüren muss. Minimum am FritzBox-Router ist 1 Tag.

Bei einem Reboot verhält sich jeder Client/Host anders, je nach Hersteller/Betriebssystem.

Z.B. MS-Windows behält den Lease über einen Reboot hinaus, auch wenn der vergebende DHCP-Dienst nicht erreichbar ist und selbst dann noch, wenn die lease time abgelaufen ist. Ein FritzBox-Router bestätigt alles was sie längst nichts mehr angeht, auch noch wenn DHCP komplett OFF/aus ist. Das führt im Zusammenwirken zu 'klebrigen DHCP-Leases', die man nach DORA so nicht erwartet.
Kein Verbraucher / Nur ein Administrator / wundert sich, was in seinem W/ LAN abgeht

Inzwischen bevorzuge ich sehr kurze Leases von 1 Stunde für Hosts der Verbraucher (tablet, phone, usw.) und 1 Tag für Geräte der W/LAN-Infrastruktur oder IoT-Devices. So sieht man im LeaseTable, um welche Art von Teilnehmer es sich handelt und Reorganisationen gehen locker von der Hand. Deshalb wurde dem Router (der FritzBox) der DHCP-Dienst weggenommen. (M)Ein Router ist ein Router.
btw: Die Geräte der Infrastruktur (FritzBoxen im IP-Client-Modus als WLAN-Accesspoints) könnten auch feste statische IPv4-Adressen bekommen, aber dann fehlt ihnen die korrekte Systemzeit. In (meinem) FritzBox-Netz braucht es die Zeitinitialisierung der AP's mit dem DHCP-Lease-Offer, so zumindest meine Beobachtung und die darausfolgende Entscheidung alles per DHCP organisieren.

Heutzutage, in Zeiten von randomized MAC-addresses (habe ich bisher nur bei mobile devices gesehen) muss man auch die Frage beantworten: Möchte ich sowas Hässliches wie randomized MAC-address im vertrauten W/ LAN hinter meiner Haustür zulassen? bzw. administrieren?

btw @hexadezimal der Titel 'AP hinter FB7490 vergibt lokale IP im falschen Bereich' passt nicht. Ein WLAN-Accesspoint (IP-Client-Modus) vergibt keine IP-Adresse. Der DHCP-Dienst läuft auf dem Router, deiner FritzBox7490.
Warten wir dein Ergebnis ab, bei DHCP macht jeder Hersteller was er will bzw. für opportun hält.

Ein Beispiel: @Grisu_ #4 Diese Kamera merkt sich ihre IP ganz lange, bis zum nächsten INIT mit der handy-APP. Meine Haustürkamera, eine Steinel Cam L 600 o.ä., arbeitet z.Z. mit einer IPv4-Adresse, die wurde initial vom Router vergeben (lease time one day), weil anfangs die Geräte-MAC noch nicht bekannt war. Jetzt ist der DHCP-Dienst an der FritzBox wieder OFF/aus. Vielleicht bestätigt FritzOS irgendetwas. Jedenfalls verwendet die Kamera nicht die aktuell angebotene IP-Adresse. Mein DCHP-Dienst auf dem Pi-hole bietet für die Geräte-MAC-Adresse der Kamera eine (andere) IPv4-Adresse an. Weitere Untersuchungen / Abhilfe habe ich derzeit nicht angestellt. Müsste mit der APP und dem aktuellen Angebot vom Pi-hole neu im Mesh-WLAN initialisieren und dabei das DHCP-Protokoll auf den LAN mithören. Netzwerkverbindung zurücksetzen: Beim Zurücksetzen werden alle Einstellungen und gespeicherten Daten für dieses Gerät gelöscht. Es wird als neues Gerät ins Heimnetz aufgenommen. wäre auch noch eine Idee, egal.

Nun ist sie halt mal da, die Initial-IP-Adresse und die (Hersteller-) APP funktioniert zum Anschauen der Bilder. Genau wie bei dir ...

Von der LSC PTZ Kamera gibt es nur einen Screenshot mit den Statusinformationen.

Da lässt sich manuell nichts einstellen, außer dem Wlan-AP über den sich die Kamera mit dem Netz verbindet, das läuft alles über eine App (LSC Smartconnect App, Tuya-App geht auch) hier daher nur auch nur ein Screenshot aus der App. Die IP ist die, der FB zugewiesene dynamische.

Mein FAZIT:
IP-Kamera-Hersteller machen bei der Initialisierung mit einer handy-Hersteller-APP am gleichen WLAN-Accesspoint aus einer DHCP-Lease Time was sie wollen, nämlich eine statisch feste IP-Adresse. Manche IP-Kameras (Hersteller für Consumerprodukte) halten sich einfach nicht an RFC 2131 u.a. 2132, 3315, 1542. IP-Kamera-Hosts mit handy-APP machen aus DHCP was der Hersteller will, keinesfalls das, was ein Standard mit einem RFC fordert. Wenn eine Kamera keine Standards, z.B. RTSP Stream, unterstützt, ist der Hersteller der APP der erste Ansprechpartner bzgl. Support und Funktionalität. https://de.wikipedia.org/wiki/Security_through_obscurity

 

[hexadezimal]

Leider kann ich die grundlegenden Tests, bei denen ich die FB auch mal zurücksetzen muss, erst am Wochende durchführen, weil meine Familie unter der Woche die Internetvernbindung benötigt.

Das einzige was ich bisher noch testen konnte, war das zurücksetzen der Kamera auf Werkseinstellungen. Bei der Neuanmeldung am D-Link AP bekam sie wieder die IP 192.168.178.16.
Wenn ich mit Angry-IP die IP prüfe steht da aber 192.168.178.163, in der FB steht die 163 unter "ungenutzte Verbindungen" und die 16 konnt gar nicht vor.
Ich würde daher auch am D-Link AP ansetzen. Den muss ich dann zurücksetzen denn grundliegende Einstellungen kann man nur bei der Einrichtung vornehmen.

 

[tango501]

Wenn ich mit Angry-IP die IP prüfe

Es gibt dafür noch eine ganze Reihe von vergleichbaren Tools zur Suche und Analyse. Welche Tools sind neben dem Angry IP Scanner dafür sonst noch vorhanden?