14
FRITZ!Box 6490 Cable (kdg) - trendnet IP-Cams nicht mehr erreichbar
Hallo,
ich habe eine Problematik, bei der ich aktuell nicht weiter weis.
Als IT-Systemelektroniker und langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen, ist man tatsächlich irgendwann mal mit seinem Latein am Ende.
Folgende Konfiguration habe ich Vor-Ort:
- FRITZ!Box 6490 Cable (kdg) [FRITZ!OS:06.50]
- 3x Trendnet TV-IP310PI (per Kabel angebunden)
- 1x D-Link DCS-942L (W-LAN Cam)
- TP-Link TL-SG1008P (8-Port Gigabit POE Switch)
Die Verkabelung ist gem. dem Bild vorgenommen worde. Cat.6 Verlegekabel, Cat.6 Patchpanels, Cat.6 Patchkabel, Gibabit Switche usw.
Die Cams sind entsprechend an dem POE Switch an den POE-Ports angeschlossen.
Die ganze Netzwerkverkabelung wurde mit einem Fluke Tool durchgemessen, alles top.
Die Cams wurden von den IP-Adressen wie folgt konfiguriert :
Cam1: 192.168.xxx.40 Port: 8081
Cam2: 192.168.xxx.41 Port: 8082
Cam3: 192.168.xxx.42 Port: 8083
Cam4: 192.168.xxx.43 Port: 8084
auf der FritzBox wurde entsprechend eine Portforwarding für die Ports 8081,8082,8083,8084 auf den jeweiligen IPs vorgenommen.
DynDns Account eingerichtet.
Die Cams sind nun quasi über
https://xxxxx.dnydns.tv:8081
https://xxxxx.dnydns.tv:8082
https://xxxxx.dnydns.tv:8083
https://xxxxx.dnydns.tv:8084
aus dem Internet zu erreichen.
Nun das Problem:
Nach einer gewissen Zeit (varriert zwischen 2-12h) sind NUR die Trendnet Camsnicht mehr erreichbar!!!!! Die D-Link WebCam funktioniert ohne Probleme.
Starte ich aber die FritzBox NEU, funktioniert wieder alles bis es halt wieder nach der o.g. varrierenden Zeit von 2-12h wieder nicht funktioniert.
was ich schon gecheckt habe....
- anderen POE switch KEINE Veränderung
- 3 x POE Injektor (TP-Link) KEINE Veränderung
- neue Patchkabel (sowohl an den Cams, als auch von Switch zu Patchpanel und von Patchpanel an Switch) KEINE Veränderung
- aktuelle Firmware auf allen Netzwerkkomponenten (aktiv) aufgespielt (auch auf die IPCams)
Wiegesagt, da die Netzwerkverbindungen alle durchgemessen sind und da alles ok ist, kann ich das schon mal 100% ausschließen.
Switche würde ich auch aussschließen....
So....feuer frei.....was habt ihr noch für Ideen.
Sorry noch für die reudige Zeichnung....musste mir mit Word behelfen, habe gerade kein Visio aufm PC
Lg ollip2016
ich habe eine Problematik, bei der ich aktuell nicht weiter weis.
Als IT-Systemelektroniker und langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen, ist man tatsächlich irgendwann mal mit seinem Latein am Ende.
Folgende Konfiguration habe ich Vor-Ort:
- FRITZ!Box 6490 Cable (kdg) [FRITZ!OS:06.50]
- 3x Trendnet TV-IP310PI (per Kabel angebunden)
- 1x D-Link DCS-942L (W-LAN Cam)
- TP-Link TL-SG1008P (8-Port Gigabit POE Switch)
Die Verkabelung ist gem. dem Bild vorgenommen worde. Cat.6 Verlegekabel, Cat.6 Patchpanels, Cat.6 Patchkabel, Gibabit Switche usw.
Die Cams sind entsprechend an dem POE Switch an den POE-Ports angeschlossen.
Die ganze Netzwerkverkabelung wurde mit einem Fluke Tool durchgemessen, alles top.
Die Cams wurden von den IP-Adressen wie folgt konfiguriert :
Cam1: 192.168.xxx.40 Port: 8081
Cam2: 192.168.xxx.41 Port: 8082
Cam3: 192.168.xxx.42 Port: 8083
Cam4: 192.168.xxx.43 Port: 8084
auf der FritzBox wurde entsprechend eine Portforwarding für die Ports 8081,8082,8083,8084 auf den jeweiligen IPs vorgenommen.
DynDns Account eingerichtet.
Die Cams sind nun quasi über
https://xxxxx.dnydns.tv:8081
https://xxxxx.dnydns.tv:8082
https://xxxxx.dnydns.tv:8083
https://xxxxx.dnydns.tv:8084
aus dem Internet zu erreichen.
Nun das Problem:
Nach einer gewissen Zeit (varriert zwischen 2-12h) sind NUR die Trendnet Camsnicht mehr erreichbar!!!!! Die D-Link WebCam funktioniert ohne Probleme.
Starte ich aber die FritzBox NEU, funktioniert wieder alles bis es halt wieder nach der o.g. varrierenden Zeit von 2-12h wieder nicht funktioniert.
was ich schon gecheckt habe....
- anderen POE switch KEINE Veränderung
- 3 x POE Injektor (TP-Link) KEINE Veränderung
- neue Patchkabel (sowohl an den Cams, als auch von Switch zu Patchpanel und von Patchpanel an Switch) KEINE Veränderung
- aktuelle Firmware auf allen Netzwerkkomponenten (aktiv) aufgespielt (auch auf die IPCams)
Wiegesagt, da die Netzwerkverbindungen alle durchgemessen sind und da alles ok ist, kann ich das schon mal 100% ausschließen.
Switche würde ich auch aussschließen....
So....feuer frei.....was habt ihr noch für Ideen.
Sorry noch für die reudige Zeichnung....musste mir mit Word behelfen, habe gerade kein Visio aufm PC
Lg ollip2016
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 332670
Url: https://administrator.de/forum/fritzbox-6490-cable-kdg-trendnet-ip-cams-nicht-mehr-erreichbar-332670.html
Ausgedruckt am: 04.04.2025 um 08:04 Uhr
14 Kommentare
Neuester Kommentar
Moin,
Und zu guter letzt:
Du solltest umgehend die Portweiterleitungen zu den Kameras rausnehmen und stattdessen den ipsec-Tunnel der Fritzbox nutzen.
Meine Kristallkugel sagt nämlich, daß Du dem.İoT mehrere Bots spendiert hast.
lks
PS: https://www.google.de/amp/s/www.golem.de/news/mirai-iot-botnet-ip-kamera ...
- Hast du mal mit dem sniffer geschaut, ob die Fritzbox die Pakete zu den Trendnets weiterleitet oder nicht?
- Hast du mal von der Fritzbox aus die Trendnets gepingt?
Und zu guter letzt:
- Trendnet baut wundervolle İoT-Bots. Wenn Du die mit dem nackten Arsch ins İnternet hängst, ist das wie ein gloryhole auf dem Bahnhofsklo.
Du solltest umgehend die Portweiterleitungen zu den Kameras rausnehmen und stattdessen den ipsec-Tunnel der Fritzbox nutzen.
Meine Kristallkugel sagt nämlich, daß Du dem.İoT mehrere Bots spendiert hast.
lks
PS: https://www.google.de/amp/s/www.golem.de/news/mirai-iot-botnet-ip-kamera ...
Hast du dir mal mit einem Wireshark Trace und einem Mirrorport am Switch angesehen was genau passiert wenn die Trendnet Cams nicht mehr erreichbar sind ?
Forwardet die FritzBox dann überhaupt noch IP Pakete von extern auf die Cams ?
Das wäre essentiell zu wissen um das Problem dann bei der FB oder den Cams suchen zu müssen bzw. eingrenzen zu können.
KDG ist auch immer mit Vorsicht zu geniessen, da die fast immer DS-Lite Anschlüsse mit CGN (Carrier Grade NAT) verwenden wo IP Forwarding generell unmöglich ist. Das kanns aber bei dir natürlich nicht sein, denn ansonsten würde gar nix klappen. Vermutlich hast du eine öffentliche IP hier beantragt oder Glück das du eine bekommst.
Die Wahl der Ports ist auch nicht gerade glücklich bzw. intelligent. Als kundiger Netzwerker solltest du eigentlich wissen das man fest vergebene IANA Ports niemals nutzen sollte, da das ggf. mit entsprechendem Traffic im Provider bzw. Internet Backbone kollidieren kann:
https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Sinnvoller wären daher die extra dafür vorgesehenen sog. Ephemeral Ports
https://en.wikipedia.org/wiki/Ephemeral_port
von 49152 bis 65535 zu verwenden.
Nicht das du damit standardkonformer bist, es schützt dich und die FritzBox obendrein auch besser vor den obligatorischen Port Scanner Angriffen im Sekundentakt, die natürlich auch diese hauptsächlich für Caches benutzte Port Range immer mit scannen. Auch das weiss man als langjähriger Netzwerker.
Insofern war diese Wahl nicht gerade intelligent. Besser: //
Cam1: 192.168.xxx.41 Port: 58081
Cam2: 192.168.xxx.42 Port: 58082
Cam3: 192.168.xxx.43 Port: 58083
Cam4: 192.168.xxx.44 Port: 58084
Hat zudem auch noch eine logische Zuordnung der CAM Nummer und IP Adresse zum Port was für Laien nachher besser zu merken ist
Forwardet die FritzBox dann überhaupt noch IP Pakete von extern auf die Cams ?
Das wäre essentiell zu wissen um das Problem dann bei der FB oder den Cams suchen zu müssen bzw. eingrenzen zu können.
KDG ist auch immer mit Vorsicht zu geniessen, da die fast immer DS-Lite Anschlüsse mit CGN (Carrier Grade NAT) verwenden wo IP Forwarding generell unmöglich ist. Das kanns aber bei dir natürlich nicht sein, denn ansonsten würde gar nix klappen. Vermutlich hast du eine öffentliche IP hier beantragt oder Glück das du eine bekommst.
Die Wahl der Ports ist auch nicht gerade glücklich bzw. intelligent. Als kundiger Netzwerker solltest du eigentlich wissen das man fest vergebene IANA Ports niemals nutzen sollte, da das ggf. mit entsprechendem Traffic im Provider bzw. Internet Backbone kollidieren kann:
https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Sinnvoller wären daher die extra dafür vorgesehenen sog. Ephemeral Ports
https://en.wikipedia.org/wiki/Ephemeral_port
von 49152 bis 65535 zu verwenden.
Nicht das du damit standardkonformer bist, es schützt dich und die FritzBox obendrein auch besser vor den obligatorischen Port Scanner Angriffen im Sekundentakt, die natürlich auch diese hauptsächlich für Caches benutzte Port Range immer mit scannen. Auch das weiss man als langjähriger Netzwerker.
Insofern war diese Wahl nicht gerade intelligent. Besser: //
Cam1: 192.168.xxx.41 Port: 58081
Cam2: 192.168.xxx.42 Port: 58082
Cam3: 192.168.xxx.43 Port: 58083
Cam4: 192.168.xxx.44 Port: 58084
Hat zudem auch noch eine logische Zuordnung der CAM Nummer und IP Adresse zum Port was für Laien nachher besser zu merken ist
Zitat von @aqui:
Besser: //
Cam1: 192.168.xxx.41 Port: 58081
Cam2: 192.168.xxx.42 Port: 58082
Cam3: 192.168.xxx.43 Port: 58083
Cam4: 192.168.xxx.44 Port: 58084
Besser: //
Cam1: 192.168.xxx.41 Port: 58081
Cam2: 192.168.xxx.42 Port: 58082
Cam3: 192.168.xxx.43 Port: 58083
Cam4: 192.168.xxx.44 Port: 58084
Also da hätte ich jetzt 57041...57044 genommen.
Aber Mirai und Co. werden da trotzdem keinen Tag brauchen, um die wiederzufinden.
lks
Aber Mirai und Co. werden da trotzdem keinen Tag brauchen, um die wiederzufinden.
Ja, letztlich hast du natürlich recht. Aber wenigstens eine kleine Verschleierung die einen Angriff etwas erschwert.Auf diesen fatalen und grundlegenden Designfehler das der TO die Kameradaten vollkommen ungeschützt durchs Internet und für die gesamte Welt sichtbar schiebt mal gar nicht zu reden.
Das können personenbezogene Daten sein so das sich der TO mit so einem Konzept ggf. sogar strafbar macht nach IT Recht in D. Aber das ist jetzt einen ganz andere Story.... Durch den vollkommen ungeschützten Transfer der Daten ist das ja sehr einfach nachweisbar.
Die sinnvollste Lösung wäre ein VPN auf der FritzBox gewesen ! Damit wäre das Netzwerk geschützt, die FritzBox nicht durch Port Forwarding Löcher gefährtet und auch die Kameradaten sicher geschützt und nur für die Augen bestimmt die es sehen sollen.
Ob das Prädikat "langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen" dann wirklich stimmt ist fraglich. Wie immer aber relativ von der jeweiligen Sichtweise betrachtet. Aber ganz anderes Thema....
Netzwerker Fazit: Wireshark ist wie immer dein Freund hier
Hallo zusammen,
also ich denke an den Patchpanelen sind doch immer die Netzwerkdosen dran auf der einen Seite und von der anderen Seite werden
diese Ports dann eben auf einen Switch gepatched, oder? Und warum sind die beiden Patchpanel untereinander mit Patchkabeln
verbunden worden? Ich denke man sollte die beiden Switche untereinander verbinden bzw. miteinander verbinden und nicht die
Patchpanel!
per USB angeschlossene Webcam ist davon nicht betroffen, nach meiner Schätzung. Warum wählt man sich nicht einfach via AVM
Android oder iOS VPN APP (Fritz!Fernzugang) ein und hat dann auf alle angeschlossenen Geräte Zugriff, also von außen Zugriff
via VPN! Warum Ports freigeben und dann kann das gesamte Internet über die Kameras mit zuschauen was da "abgeht"?
Gruß
Dobby
also ich denke an den Patchpanelen sind doch immer die Netzwerkdosen dran auf der einen Seite und von der anderen Seite werden
diese Ports dann eben auf einen Switch gepatched, oder? Und warum sind die beiden Patchpanel untereinander mit Patchkabeln
verbunden worden? Ich denke man sollte die beiden Switche untereinander verbinden bzw. miteinander verbinden und nicht die
Patchpanel!
So.... feuer frei.....was habt ihr noch für Ideen.
Das wars schon, verbinde die Switche untereinander und nicht die Patchpanel und dann sollte es funktionieren.Nun das Problem:
Nach einer gewissen Zeit (varriert zwischen 2-12h) sind NUR die Trendnet Cams nicht mehr erreichbar!!!!! Die D-Link WebCam
funktioniert ohne Probleme.
Die D-Link Webcam ist via USB an der AVM FB dran richtig!? Dann ist das wohl eher wegen der 24h ISP Zwangstrennung und dieNach einer gewissen Zeit (varriert zwischen 2-12h) sind NUR die Trendnet Cams nicht mehr erreichbar!!!!! Die D-Link WebCam
funktioniert ohne Probleme.
per USB angeschlossene Webcam ist davon nicht betroffen, nach meiner Schätzung. Warum wählt man sich nicht einfach via AVM
Android oder iOS VPN APP (Fritz!Fernzugang) ein und hat dann auf alle angeschlossenen Geräte Zugriff, also von außen Zugriff
via VPN! Warum Ports freigeben und dann kann das gesamte Internet über die Kameras mit zuschauen was da "abgeht"?
Starte ich aber die FritzBox NEU, funktioniert wieder alles bis es halt wieder nach der o.g. varrierenden Zeit von 2-12h
wieder nicht funktioniert.
Zwangstrennung des ISP? Oder macht der DynDNS Dienst dort nicht mehr mit bzw. Probleme!?wieder nicht funktioniert.
Gruß
Dobby
Und warum sind die beiden Patchpanel untereinander mit Patchkabeln verbunden worden?
Das wäre in der Tat Quatsch ist aber vermutlich ein Zeichnungsfehler und soll wohl nur verdeutlichen das der eine Switch über das Patchpanel aufs andere Panel zum dortigen Switch durchgepatcht ist. Was dann natürlich absolut OK ist.Da es ja temporär alles klappt zeigt das die physische Infrastruktur soweit ja unstrittig und richtig ist, da mit der D-Link Cam ja alles sauber funktioniert
Das sieht mehr nach einen Forwarding Bug aus in Router oder Kamera. Ggf. die auch die TCP Portproblematik.
Das müsste der TO aber mal mit dem Kabelhai klären.
Auch bleibt die Frage offen warum er die Ports auf den Kameras selber umgestellt hat. Das ist eigentlich vollkommen überflüssig, denn die FritzBox supportet ja auch IP Port Translation, so das man intern immer mit dem Standardport TCP 80 auf den Cams arbeiten kann OHNE die verbiegen zu müssen.
Man macht dann entsprechend Port Translation auf dem Router ala:
Incoming TCP 58081 -> auf lokal TCP 80 IP: 192.168.178.41
Incoming TCP 58082 -> auf lokal TCP 80 IP: 192.168.178.42
usw.
Möglich auch das die Kameras einen FW Bug haben wenn sie mit fremden TCP Ports arbeiten. Bei billiger und oft schlampig programmierter China Ware wie der obigen sollte man sowas immer auf dem Radar haben.
Das würde der Wireshark aber auch sofort aufdecken !
TO hat den Thread ja jetzt selber auf gelöst geklickt. Problem hat er dann ja vermutlich gefixt. Wäre in einem Forum ja immer mal interessant zu erfahren was es denn letztlich war ?!
Vielen Dank an aqui und Lochkartenstanzer .
Da das ganze in der Konfiguration nur Geländeabschnitte um ein privates Einfamilienhaus sichtbar macht, ohne das hier ein Nachbarhaus oder andere öffentliche Bereiche sichtbar sind, sehe ich da ganze in Bezug auf den Schutz personenbezogener Daten als unkritisch an.
Das mit der Nutzung der Netzwerkports (gem. IANA) ist mir selbstverständlich bewusst.
Der Angreifbarkeit von IPCams war ich mir zwar bewusst, aber das dass so krass ist, wie in dem Artikel "Mirai-IoT-Botnet" beschrieben ist, war mir nicht bewusst.
@aqui: danke für die Kommentierung von "langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen".... :D
Da das ganze in der Konfiguration nur Geländeabschnitte um ein privates Einfamilienhaus sichtbar macht, ohne das hier ein Nachbarhaus oder andere öffentliche Bereiche sichtbar sind, sehe ich da ganze in Bezug auf den Schutz personenbezogener Daten als unkritisch an.
Das mit der Nutzung der Netzwerkports (gem. IANA) ist mir selbstverständlich bewusst.
Der Angreifbarkeit von IPCams war ich mir zwar bewusst, aber das dass so krass ist, wie in dem Artikel "Mirai-IoT-Botnet" beschrieben ist, war mir nicht bewusst.
@aqui: danke für die Kommentierung von "langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen".... :D
@108012:
wie schon von aqui geschrieben, ist die Zeichnung vielleicht etwas irreführend.
klar sind die switche miteinander verbunden.
port 12 kamera-panelist mit cat.6 verlegekabel mit dem Port 32 des hauptpatchpanelsverbunden.
von port 12 geht dann ein patchkabel auf den kamera switch, von port 32 ein patchkabel auf en 16 port hauptswitch.
somit wird hier nur die verbindung hergestellt.
im außenbereich liegt das cat.6 verlegekabel in einer Aufputzverteilerdose und ist darin mit einem Cat.6 Keystone aufgelegt....im Keystone steckt dann ein kurzes Patchkabel von 0,5m und verbindet dann die "Festverkabelung" mit dem RJ45 plug der IPCam.
Das Problem ist noch nicht gelöst, kann ich erst im laufe der woche umsetzen/ausprobieren, da ich auf der Arbeit bin.
War mir der Funktion des "zur Lösung beigetragen" Buttons nicht vollumfänglich bewusst.
wie schon von aqui geschrieben, ist die Zeichnung vielleicht etwas irreführend.
klar sind die switche miteinander verbunden.
port 12 kamera-panelist mit cat.6 verlegekabel mit dem Port 32 des hauptpatchpanelsverbunden.
von port 12 geht dann ein patchkabel auf den kamera switch, von port 32 ein patchkabel auf en 16 port hauptswitch.
somit wird hier nur die verbindung hergestellt.
im außenbereich liegt das cat.6 verlegekabel in einer Aufputzverteilerdose und ist darin mit einem Cat.6 Keystone aufgelegt....im Keystone steckt dann ein kurzes Patchkabel von 0,5m und verbindet dann die "Festverkabelung" mit dem RJ45 plug der IPCam.
Das Problem ist noch nicht gelöst, kann ich erst im laufe der woche umsetzen/ausprobieren, da ich auf der Arbeit bin.
War mir der Funktion des "zur Lösung beigetragen" Buttons nicht vollumfänglich bewusst.
Zitat von @oscarpapa:
Das Problem ist noch nicht gelöst, kann ich erst im laufe der woche umsetzen/ausprobieren, da ich auf der Arbeit bin.
Das Problem ist noch nicht gelöst, kann ich erst im laufe der woche umsetzen/ausprobieren, da ich auf der Arbeit bin.
Sniffen mit der fritzbox
Die D-Link Cam ist per WLAN verbunden.
Das mit dem VPNaccess ist richtig, werde ich auch so umsetzen.
Zwangstrennung nach 24h gibt es im Kabelnetz nicht, das gibt es nur bei DSL.
Der DynDns Service ist ja für solch ein Scenario gedacht, dass quasi nach 24h bei der DSL Zwangstrennung die IP wieder einem "Namen" zugeordnet wird.
Das mit dem VPNaccess ist richtig, werde ich auch so umsetzen.
Zwangstrennung nach 24h gibt es im Kabelnetz nicht, das gibt es nur bei DSL.
Der DynDns Service ist ja für solch ein Scenario gedacht, dass quasi nach 24h bei der DSL Zwangstrennung die IP wieder einem "Namen" zugeordnet wird.
aber das dass so krass ist, wie in dem Artikel "Mirai-IoT-Botnet" beschrieben ist, war mir nicht bewusst.
Viele Laien unterschätzen das wie man auch hier in einem Administratorforum täglich lesen kann.Man kann nur jedem einmal empfehlen einen Sniffer auf seinen DSL, Kabel oder Internet Port zu aktivieren.
Das öffnet einem ganz schnell die Augen was da im Sekundentakt weltweit reinprasselt. Irgendwo auf der Welt sind immer Port Scanner und Script Kiddies am Werk...Botnetze sowieso.
Aber auch das weiss man natürlich alles als "langjähriger IT-Systemadministrator mit tiefgreifenden Netzwerkkenntnissen" da ist man ja nicht mehr blauäugig oder sollte es wenigstens nicht mehr sein, oder ?
die genannte Thematik ist mir selbstverständlich mehr als geläufig bzw. present.
Habe die Thematik aber in Bezug auf IPCams ehrlich gesagt etwas blauäugig behandelt, das muss ich zugeben.
Ich möchte mich hier auch nicht mit meiner Berufserfahrung brüsten, jeder ist ja unterschiedlich versiert, ja nach Erfahrung und womit er am meisten gearbeitet hat.
Aber schonmal vielen Dank für deine hier zur Verfügung gestellte Expertise, die bringt mich schon in dem ein oder anderen Bereich um einiges weiter.
Habe die Thematik aber in Bezug auf IPCams ehrlich gesagt etwas blauäugig behandelt, das muss ich zugeben.
Ich möchte mich hier auch nicht mit meiner Berufserfahrung brüsten, jeder ist ja unterschiedlich versiert, ja nach Erfahrung und womit er am meisten gearbeitet hat.
Aber schonmal vielen Dank für deine hier zur Verfügung gestellte Expertise, die bringt mich schon in dem ein oder anderen Bereich um einiges weiter.
Vielen Dank für die ganzen Beiträge.
Ich habe nun die Konfiguration dementsprechend geändert, indem ich alle Portweiterleitungen aufgehoben habe, die Ports auch jeweils wieder auf den Standard-Port 80 zurückgesetzt habe und einen VPNconnect eingerichtet habe.
Damit funktionieren jetzt die Kameras alle einwandfrei und ohne Probleme, ohne einfrieren der Cams nach wenigen Stunden.
Danke nochmals für eure Hilfe.
Ich habe nun die Konfiguration dementsprechend geändert, indem ich alle Portweiterleitungen aufgehoben habe, die Ports auch jeweils wieder auf den Standard-Port 80 zurückgesetzt habe und einen VPNconnect eingerichtet habe.
Damit funktionieren jetzt die Kameras alle einwandfrei und ohne Probleme, ohne einfrieren der Cams nach wenigen Stunden.
Danke nochmals für eure Hilfe.
* Trendnet baut wundervolle İoT-Bots. Wenn Du die mit dem nackten Arsch ins İnternet hängst, ist das wie ein gloryhole auf dem Bahnhofsklo.
Meine Kristallkugel sagt nämlich, daß Du dem.İoT mehrere Bots spendiert hast.
Dann gibst bestimmt bald auch das alt Bekannte Schlangenöl für Waschmaschinen, Trockner, Geschirrspüler, Glotzen!
