Kann man aus diesem Verhalten nicht folgern. Wenn z.B. eine vom System unabhängige Realtime Clock zum definierten Zeitpunkt einen Reset auslöst, kann das komplette Betriebssystem schon stundenlang eingefroren gewesen sein.
Aus verschiedenen Threads entnehme ich zudem, dass INSTAR keinen Watchdog im System integriert hat, der im Fehlerfall einen Reset (Warmstart) ausführt.
Sodarle, kurzes Update:
Ich bin bisher davon ausgegangen, dass ich einen Zugriff auf die Kamera von aussen aus dem Internet gar nicht erst probieren brauche, wenn der Zugriff aus dem lokalen Netz nicht klappt.
Aber siehe da : Genau das hat geklappt : Zugriff aus dem heimsichen LAN klappt nicht, über das Internet schon.( Immer probiert über das iPhone).
Ich habe dann mal den LAN/WAN-Verkehr mitgesniffert und das brachte Indizien, dass es wohl Probleme mit der dynamischen IP-Adressvergabe für das iPhone in meinem heimischen LAN bzw. WLAN gibt (Die Kamera hat ne statische IP-Adresse, das iPhone eine dynamische.)
Ich habe dann in meiner FritzBox meinem iPhone eine statische IP-Adresse zugewiesen und seitdem klappt der Zugriff auf die Kamera vom iPhone wunderbar.
Erklären kann ich mir das nicht, aber ich arbeite lange genug in der IT, um auch mal Dinge ohne grosse Nachfrage zu akzeptieren …
die festen IP´s liegen im DHCP Bereich ?
Stichwort: Ip-Adresskonflikt.
Gruß
Hbr
Nein, ich habe getrennte Bereiche, aber danke für den Hinweis. Auf Grund meiner hier gemachten Erfahrung habe ich bei der Gelegenheit jetzt gleich alle meine Clients (sooooo viele sind es ja nicht …) auf statische DHCP-Adressen umgestellt und nur noch im Gäste-WLAN mache ich echten DHCP.
Der Zugriff auf meine Kamera klappt seit der Umstellung völlig problemlos. Mein Problem war also hausgemacht und nicht durch INSTAR verursacht - Asche auf mein Haupt.
Servus,
… alle meine Clients auf statische DHCP-Adressen umgestellt
das wird immer wieder gern von allen Seiten empfohlen 
gruss
PS:
Und DANKE für die Rückmeldung, ist leider nicht immer selbstverständlich.
@all besten Dank für die Tipps. Die Kamera wurde eingeschickt und getauscht, mittlerweile läuft sie - die Neue - seit gut 5 Tagen durch und wird auch vom „Camera tool“ gefunden. Ich tippe mal auf „Montagsgerät“, technische Details wird man sicher nicht erfahren. Weiterschauen und beobachten …
@InstarNeuling bei mir zeigte sich das Problem wie folgt:
- die Kamera blieb nach ca. 1-2 Tagen, manchmal mehrmals am gleichen Tag, scheinbar stehen
- über HTTP oder per App war die Kamera nicht mehr erreichbar, kein Bild, kein live-stream, „no connection“, etc.
- ob mit oder ohne DHCP spielte keine Rolle
- man konnte nur den Stromstecker ziehen
- die Kamera reagierte allerdings auf „ping“, tracert", „pathping“ - Kommandos oder auch auf UDP-broadcasts des „Camera Tool“
- wenn man die TCP/IP Adresse der Kamera i.V.m. dem browser „besnifferte“ (MS NetMonitor ist da ein sehr gutes tool) sieht man, dass die Kamera auf die SYN requests des browser immer nur mit ACK RST antwortete. Vereinfach gesagt heißt das, die SYN requests kommen an, Kamera anwortet allerdings: „ich kann aus irgendeinem Grund nicht (mehr)“. Oftmals sind firmware bugs die Ursache, oder vollgelaufene buffer oder loopende Prozesse; interessant ist jedoch, dass die „Antworten“ auf die UDP broadcast zumindest im sniffer-trace gut ausschauten, aber vom Camera-Tool nicht „gefunden“ oder „verstanden“ worden
- da man sich auf die Kamera nicht mit SSH oder telnet o.a. einwählen kann, kann man über technische Details nur spekulieren; da wird INSTAR sich auch nicht in die Karten schauen lassen wollen
- bei vielen anderen Geräten hat man wenigstens eine Funktion, á la „Problemdokumentation erstellen“ oder so; so etwas wäre auch hier echt wünschenswert, wie auch die login-Möglichkeit per SSH oder telnet
Bei den FritzBoxen ist es verbreitet, dass Änderungen bzgl. fester oder dynamischer TCP/IP Adresse oder auch Portfreigaben etc. erst zeitverzögert oder nur nach einem Neustart der Box wirksam werden. Ich konnte mal eine Portfreigabe partout nicht über die GUI löschen bzw. sie wurde immer wieder als aktiv angezeigt, die alten routing tables hielten sich hartnäckig; da half nur ein Neustart. Die AVM-Foren sind voll von diesen Problemen.