Adobe-Flash-Player wird eingestellt

INSTAR Software Informationen / Downloads
63

Wenn du bei Multimedia / Video wieder auf Flash gehst dann ist es so wie vorher bei der 2.5

1 „Gefällt mir“
64

Habe es so gemacht, wie von Polinowski im anderen Thread empfohlen. Logbuch geöffnet, d,e und v gleichzeitig gedrückt und auf Full HD gestellt. Funktioniert.

1 „Gefällt mir“
65

Habe es so gemacht, wie von Polinowski im anderen Thread empfohlen. Logbuch geöffnet, d,e und v gleichzeitig gedrückt und auf Full HD gestellt. Funktioniert.

Eine derartige Funktion gibt es in diesem Menü (IN-8015 Full HD WLAN) nicht (mehr?). Oder wurde diese (neben der Vollbild-Funktion) auch mit der neuen 2.6 (320) entfernt?

66

Habe gerade mal nachgeschaut. Es funktioniert wirklich nicht mehr. Zuvor hat es im Logbuch der 9020 noch funktioniert. Dann habe ich es im Logbuch der 8015 probiert und es funktionierte nicht. Danach konnte ich im Logbuch der 9020 diese Tastenkombination auch nicht mehr anwenden. Das Ganze im Firefox, den ich hauptsächlich verwende. Nutze ich einen anderen Browser funktioniert es natürlich wieder, weil die Einstellung ja Browserbezogen sind. Keine Ahnung, warum das so ist und ich die Funktion jetzt im Firefox auch nicht mehr habe.

67

Habe gerade mal nachgeschaut. Es funktioniert wirklich nicht mehr. Zuvor hat es im Logbuch der 9020 noch funktioniert. Dann habe ich es im Logbuch der 8015 probiert und es funktionierte nicht. Danach konnte ich im Logbuch der 9020 diese Tastenkombination auch nicht mehr anwenden. Das Ganze im Firefox, den ich hauptsächlich verwende. Nutze ich einen anderen Browser funktioniert es natürlich wieder, weil die Einstellung ja Browserbezogen sind. Keine Ahnung, warum das so ist und ich die Funktion jetzt im Firefox auch nicht mehr habe.

Eine derartige Funktion gibt es in diesem Menü (IN-8015 Full HD WLAN) nicht (mehr?). Oder wurde diese (neben der Vollbild-Funktion) auch mit der neuen 2.6 (320) entfernt?

Sorry, da hatte ich mich missverständlich ausgedrückt. Die Tastenkombination (d+e+v) und der Zugriff aufs „DEV-Menü“ funktioniert sehr wohl noch. Allerdings gibt es dort keine Funktion für das Umschalten auf FullHD bei https (bei HTML5 Stream).

Mein Reverse Proxy greift aber ohnehin per http auf die Kamera zu, und darüber geht ja FullHD per HTML5 eigentlich ganz wunderbar. Der Reverse Proxy übernimmt dann auch erst die Verschlüsselung. Daher würde ich mir eine entsprechende Option/Funktion (zurück?) wünschen.

68

Gibt es für die IN-5905HD noch gar kein Update, weder online noch auf der Homepage bin ich fündig geworden?!

69

Hallo zusammen,

ich greife dieses Thema nochmal auf.

Ich habe dasselbe Problem wie @NtC und möchte im ReverseProxy verschlüsseln. Das funktioniert auch prinzipiell wunderbar. Der ReverseProxy wird per HTTPS angesprochen und leitet per HTTP an die Kamera (IN-9020) weiter. Allerdings erkennt die Kamera, dass der Request ursprünglich mal HTTPS war und weigert sich, den HTML5 stream zu liefern. Das ist Mist!

@NtC, hast Du eine Lösung hierfür gefunden (ich denke z.B. an Headermanipulation, um den ursprünglichen Request zu verschleiern)?

Ansonsten wäre es wirklich hilfreich, wenn man - zumindest im DEV Menü - die Wahl hätte, den HTML5 Stream auch bei HTTPS zu erzwingen.

Gibt es hierfür mittlerweile eine Lösung oder zumindest einen Workaround?

Danke und beste Grüße
Bb

1 „Gefällt mir“
70

Hallo biberbb,

vielen Dank, dass du dich auf den Post meldest, ich dachte schon, ich würde mit dem - eigentlich doch gar nicht so exotischen - Problem alleine auf der Welt sein.

Ich habe noch keine Lösung gefunden, genau was du schreibst, stelle ich mir aber auch vor. Woanders in diesem Forum hatte ich aufgeschnappt, dass ein entsprechender Schalter im DEV Menü existiert haben soll. Wenn dem so ist, hätten wir den gerne zurück! :slight_smile:

Vielleicht kann sich ein INSTAR Mitarbeiter melden, wie das gelöst oder umgangen werden kann. Die Möglichkeit, unter https auf H.264 umzuschalten habt ihr uns ja knallhart genommen. :slight_smile:

Viele Grüße

NtC

1 „Gefällt mir“
71

Die ist immer noch genau da wo sie immer war - Flash Plugin :wink:

Der HTML5 Videostream wird über einen Websocket (ws nicht wss - secure web socket) bereitgestellt. D.h. es ist nicht möglich diesen Stream in der HTTPS WebUI einzubetten.

Dort bleibt der MJPEG Stream oder halt Flash. Und das komfortabelste ist natürlich die HTTP Seite über ein VPN abzurufen.

72

Hi @m.polinowski

Erstmal vielen Dank für Deine schnelle Reaktion.
Aus meiner Sicht dazu folgendes:

Der Flash Stream realisiert leider deutlich weniger FPS als der HTML5 stream. Außerdem steht nach wie vor die Sicherheitsfrage und die Flash-Ablösung im Raum.

Wir wollen ja auch gar nicht das HTTPS WebUI. Die Kamera wird vom Proxy über HTTP angesprochen und sollte bitte auch das HTTP WebUI samt HTML5 stream liefern. (Stattdessen versucht die Kamera schlau zu sein und liefert das HTTPS WebUI ohne HTML5 stream. :roll_eyes:)

Hierfür müsste jedes Endgerät einen VPN-Zugang haben. Das ist für meinen Anwendungsfall (und ich vermute für andere ebenfalls) leider nicht realistisch.

Ich stimme @NtC zu. Das Einbinden über einen ReverseProxy ist in meinen Augen kein sonderlich exotischer Usecase.

Vielen Dank für Eure weitere Unterstützung und beste Grüße
Bb

73

Liebes @INSTAR -Team,

ich habe nach @m.polinowski’s Post den Eindruck, dass man bzgl. dieses Themas eher abgeneigt ist, dem Nutzer eine Einstellmöglichkeit (HTTP vs. HTTPS) zu geben.

Um ein Behelf zu schaffen, würde ich also gerne den ReverseProxy so bauen, dass die Kamera die „richtige“ Entscheidung trifft: Auf welcher Grundlage (vmtl. Header-Flags?) entscheidet die Kamera, ob sie das HTTP- oder HTTPS-WebUI liefert?

Vielen Dank für die Unterstützung und beste Grüße
Bb

74

Für Firmen eher nicht, aber 99,9% der Privathaushalte werden eher Portforwarding einsetzen. Die Firewall des Routers wird dann hoffentlich erkennen, ob jemand von aussen am Fenster fummelt und Millionen Schlüssel ausprobiert. Dann kommt der Panzerriegel zum Einsatz. :slight_smile:

75

Wie ist der Proxy denn konfiguriert? Wenn ich auf die Schnelle einmal NGINX vor die Kamera stelle:

location / {
        # redirect all HTTP traffic to IP Camera
        add_header X-Frame-Options "";
        proxy_pass http://kamera-ip;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # WebSocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

Habe ich immer noch das Problem, dass der Browser versucht das Video über wss zu erhalten und die Kamera es nur unverschlüsselt zur Verfügung stellt. Das TLS Upgrade scheint da nicht zu funktionieren - gut möglich das ich da nur was übersehe.

76

Hi @estimator

Die Firewall des Routers ist hier nicht der Schwachpunkt, sondern vielmehr, dass diese „99,9% der Privathaushalte“ wie Du sagst ein Portforwarding haben, und darüber das WebUI per HTTP aufrufen.
Jeder, der sich zwischen Benutzer und Kamera befindet kann dadurch die Logindaten (und den Stream) ungeschützt mitlesen.

Deshalb braucht es eine Instanz im vertrauensvollen Netz der Kamera, der die Kommunikation „nach außen“ absichert → ReverseProxy.

Beste Grüße
Bb

77

Bei den FullHD-Kameras kommt man auch per HTTPS drauf. Ob beim streamen mittlerweile rtsps geht, müsstest Du mal nachschauen. Auf jeden Fall kann man bei den FullHD`s auch mit Zertifikaten spielen.
Die Funktion eines Reverse Proxy ist mir bekannt.

78

Hi @m.polinowski,

Mein Proxy läuft im Apachen, sollte aber von den Parametern eigentlich Deinem NGINX-Beispiel entsprechen.
Bist Du sicher, dass das Problem im TLS Upgrade liegt? Das würde ja bedeuten, dass der Browser das WebUI als korrekt HTTP lädt und nur den Stream als wss anfordert. Meiner Ansicht nach wird aber das gesamte WebUI als HTTPS geladen. Daher meine Vermutung, dass die Kamera die (falsche) Entscheidung trifft, und nicht der Browser.

Vermutest Du es andersherum?

Danke und beste Grüße
Bb

@estimator
Vielleicht empfinden es die anderen User anders, aber auf mich wirken Deine letzten Beiträge etwas „an der Diskussion vorbei“, und helfen (mir) daher leider nicht weiter. Trotzdem Danke.

79

Wenn ich mir nun genauer die verteilten Informationen in diesem langen Thread ansehe, dann hast Du recht. Wie sagte hier schon ein anderer Moderator jüngst: „Ich habe mich von mir selber verwirren lassen“. Das Problem betrifft eher die Firmware der Kamera und da können nur Mike oder der Support helfen.

80

Die WebUI versucht einfach auf den Websocket zuzugreifen. Wenn dies verschlüsselt passiert - weil die WebUI über HTTPS geladen wurde - gibt die Kamera eine Fehlermeldung zurück (es gibt keinen gesicherten Websocket auf der Kamera). D.h. der Proxy müsste die verschlüsselte Anfrage annehmen und unverschlüsselt Richtung Kamera senden. Dann würde die Kamera die Anfrage akzeptieren.

81

Ganz genau, das war der Plan und das tut der Proxy m.A.n. auch (genau wie Dein obiges NGINX-Beispiel).

Irgendwie scheint die Kamera aber dennoch mitzubekommen (wie?), dass die Originalanfrage (an den Proxy) verschlüsselt war, und reagiert auf die dann unverschlüsselte Anfrage vom Proxy dennoch per HTTPS.

Ich habe nach wie vor die Vermutung, dass die Firmware auf irgendeine bestimmte Eigenschaft prüft (vmtl. ein Flag im Request-Header), und basierend darauf entweder HTTP oder HTTPS liefert. Ich habe bereits rumexperimentiert und die aus meiner Sicht wahrscheinlichsten Flags aus dem Header streichen lassen (im Proxy), aber im Blindflug ist das ein Glücksspiel.

Liebes @INSTAR -Team,

Ihr habt so viele tolle und detaillierte und sogar auf Spezialfälle zugeschnittene HowTos im Wiki. Es wäre toll, wenn es eines für diesen Fall geben würde:

Internet ← HTTPS → Apache Reverse Proxy ← HTTP → Kamera

… so, dass die Kamera tatsächlich auch das HTTP WebUI liefert, incl. HTML5 stream

Vielen Dank und beste Grüße
Bb