Best posts made by schonuf

Please add the ability to adopt PoE and Wifi cameras into the NVR manually via IP address and password, when you are accessing the NVR through the web or client software. It seems to be only possible if you are physically in front of the NVR, but not through these other means (using the new UI). This would be extremely helpful since I do not have local (physical) access to the NVR. I can have someone on site simply plug-in the camera into our PoE switch, and then adopt the camera into the NVR by its IP address. Thank you!!

Great updates! I'm excited for some of the new features. I would also love to see the following features added to the app/client:

1. Picture-in-Picture (PiP) mode on iOS? I've read on your forums that this was a limitation with iOS. Is this something that will be eventually overcome? I've started to notice some iOS apps implementing this feature (e.g.: Netflix).
2. Picture and/or video previews from push notifications. A picture of three-to-five second video preview of the motion/person/vehicle alert would help identify if further action is actually required, v.s. a false positive.
3. Creation of multiple detection "zones" per camera.
4. Quick forward and backward when viewing video playback: A button on the GUI to quickly skip backward or forward 10, 15 or 30 seconds when using the playback feature (whether using when viewing full recordings, motion, person, or vehicle alerts)

@nickm_495538090946719

same.

Is it possible to enable the "talk" feature per camera or NVR without giving administrative access to that specific standard user account? I would like to give standard users the ability to use the talk feature, while denying access to other administrative actions.

@tazzy_423116622815407


Something similar to how the nest cameras implement it by allowing multiple alert zones per camera. This feature enables you to receive alert from the specific zone you may be most interested in. For example: If I have one camera which covers a public road, a private building with door, and a private trash can; I would like an push alert that can separate the detected activity and say "motion detected by the trash can", or a different alert if there was motion detected by the "public road", or motion detected by the "office building door". You can then also filter by these motion alerts when using the playback feature.

TL;DR:
Reolink’s wireless mouse on the RLN16-410 NVR does not work because the NVR does not properly capture or render the cursor movements in real time to the operator (see attached videos). I'm not sure if anyone else has experienced the same wireless mouse issues...

I purchased Reolink’s wireless mouse for the RLN16-410 NVR, but the wireless mouse never worked with my NVR. Reolink quickly sent me a replacement wireless mouse. Unfortunately, the replacement mouse did not resolve the issue either. I then decided to cut my losses, and just use the included wired mouse.
Fast-forward some time, we recently installed a "KVM over IP" device in order to remotely manipulate some of the NVR’s features which can only be accessed when physically in-front of the NVR. The KVM enables us to interact directly with the NVR’s mouse and monitor input remotely, as if we were standing directly in-front of the NVR.
After setting up the KVM, the HDMI input worked perfectly, but the mouse would not respond. After further testing, The NVR would sporadically receive mouse clicks, but in unintended locations. I then realized that the “real cursor” was not being updated as I moved the “virtual” mouse cursor. This exact same behavior was exhibited when using Reolink’s wireless mouse with the NVR (and the KVM disconnected). The wireless mouse fails to display cursor movements to the operator, and certain keys are pressed when located on incorrect parts of the screen.


Another odd behavior was when I moved the mouse cursor (either the wireless mouse, or the KVM’s virtual mouse), the “real” cursor would not move. When I subsequently tap the actual physical wired-mouse, the “real” cursor would quickly “jump”, and catch up with virtual mouse cursor movement. This behavior can be seen in the second video I’ve uploaded.

Thank you @reolink-fiona for the clarification and fixing the issue with your cameras. Are there any plans to integrate MFA/2FA, verification codes, etc. to further secure the UID/P2P stream?

@user_642953612914768_642953612914768

Update!

Good News! I reached out directly to Reolink Support, and they were able to determine the issue. The latest Reolink RLN-16 NVR firmware has fixed the wireless mouse issue I was experiencing.

However, I am still having an issue capturing the mouse input into the KVM over IP (e.g.: TinyPilot), but I found a weird workaround. When my wireless mouse is motionless, I am unable to control the mouse movement using the KVM over IP. However, when the mouse is moving, even slight mouse movements due to vibrations, I can control the mouse via the KMV-IP. Seems as though when the mouse’s laser detects minor movements, I am simultaneously able to move the mouse. I will upload a video later.

Hope this can help someone else!

Have the vulnerabilities discussed below been fully addressed and fixed? I realize that the UID can be disabled, but if the UID is enabled, have these underlying vulnerabilities been mitigated? Would it be possible to secure the P2P feature with additional security measures like multi-factor authentication or a user-defined verification code along with the UID to access the stream (in addition to the credentials...)? If not, is there a better way to secure this protocol aside from enabling VPN access and blocking its access to the internet? I would very much like to have the push notifications enabled, but not sacrificing privacy and security.

USE OF HARD-CODED CRYPTOGRAPHIC KEY CWE-321

An attacker with local network access can obtain a fixed cryptography key which may allow for further compromise of Reolink P2P cameras outside of local network access. CVE-2020-25173 has been assigned to this vulnerability. 

CLEARTEXT TRANSMISSION OF SENSITIVE INFORMATION CWE-319

The affected Reolink P2P products do not sufficiently protect data transferred between the local device and Reolink servers. This can allow an attacker to access sensitive information, such as camera feeds. CVE-2020-25169 has been assigned to this vulnerability.