Please add the ability to adopt PoE and Wifi cameras into the NVR manually via IP address and pa*sword, 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 b**ton 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 a*signed 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 a*signed to this vulnerability.

@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!

Is there a method of backing up the existing NVR configuration (ip address, pa*swords, camera settings, etc)? Your support page recommends resetting the NVR config prior to perform a firmware update, but doing so would erase configurations and require reconnecting the IP cameras manually? Would you be able to add a way to back up and import/restore a custom configuration file?

@joseph-chircop_497308027822318 , I just updated to the latest firmware release from Reolink's Download Center. After updating to version v3.2.0.212_22111848, the bug is still present and the issue is unresolved.

@joseph-chircop_497308027822318, This was an issue since I first purchased this NVR in January 2022. Below is my NVR's current version information:

Model: RLN16-4210
Hardware No: H3MB18
Config Version: v3.0.0.0
Firmware Version: v3.0.0.200_22081549

@joseph-chircop_497308027822318 , The KVM is a "KVM over IP" device, and not your typical KVM switch which just alters keyboard and mouse input. Below is a link to tiny pilot's KVM as an example. When using the KVM, I am using my laptop's trackpad and embedded keyboard. However, the issue has nothing to do with the KVM, since the behavior works exactly the same when only using Reolink's wireless mouse (KVM disconnected). I just didn't realize what the core issue was until I hooked up this KVM and replicated the odd behavior.

https://tinypilotkvm[dot]com/tinypilot-voyager2
^This forum did not allow links so had to replace the [dot]

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.

I am considering the purchase of the RLC-842A's. I was wondering if there is an option for a tinted gla*s? If not, will this be an added option in time? Are any third-party tinted gla*s domes compatible with this model? Finally, do you recommendations for or against using tinted gla*s on dome cameras?

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.

@Reolink-Fiona The video scrubbing ability within the NVR would also be a nice addition, demonstrated in this video: https://www.youtube.com/watch?v=LAn5BOkUM1Q

@reolink-fiona Is it possible to increase the cool-off period to several minutes rather than seconds when connecting via P2P (upwards of 30-minutes to 60-minutes after repeated fails)?