About Central_Support

Possible causes and solution(s)   System overview:   FLEXIDOME multi 7000i NDM-7702-A with latest FW 8.80.0090 CM version 7.71 MQTT Explorer   Symptoms   For each of the 4 Cameras there are 4 VCA tasks "counting" named differently: for camera 1: "Counter-1-1" and "Counter-1-2" for camera 2*: "Counter-2-1", "Counter-2-2", "Counter-2-3" and so on. *For camera 2, there three counters, for the other three cameras only two. When looking at the MQTT explorer, the naming of the counters is always as in the first camera, so always "Counter-1-1" and "Counter-1-2". For the camera 2 the "Counter-2-3" is not there at all:   Solution   If you encountered the same behavior as explained above, you can add an additional counter "Counter-1-3" to the first camera. This became visible in the MQTT explorer and then also the third counter in camera 2 will become visible but must be named similar as the one in camera 1. You must take into consideration the rule: when camera 2 has three counters, also camera 1 needs to have three counters.  Info: in camera 3 the correct counter name "Counter-3-2" gets counted correctly, even if it states "Counter-1-2" as the rule name. ⚠️ Note:This one above is just a workaround of this behavior!  Please note that the Firmware release v9.00 fixed this behavior. Therefore, we recommend you to upgrade your camera to this version and always keep your cameras upgraded to the latest Firmware version available in Download Area. See also: Release Letter CPP14 FW_9.00.0210: “Addressed a bug in the current camera firmware related to line crossing functionality. Previously, when a line crossing event occurred on imagers 2-4, the system erroneously returned the task name associated with imager 1. With our recent fix, line crossing events on all imagers now correctly report the corresponding task name.” ... View more

Possible causes and solution(s)   Symptoms   Maintaining the highest level of data security requires continuous improvements in all the system components - including software and device firmware. Recent changes in the camera firmware are focused on improving the security level overall. However, it might cause some troubles when such cameras are connected to the previous BVMS releases. The potential symptoms are: no possibility to add the camera to BVMS no communication with the camera with unsecure connection (using HTTP or RCP+) no communication with the camera using secured, HTTPS connection Those symptoms might be caused by various changes in the firmware, explained below.   Causes   1) Legacy RCP+ commands received a higher authentication level in the camera firmware   Within the camera firmware changes were implemented, so that legacy RCP+ commands received a higher authentication level to further reduce the attack surface and improve security by default. Those changes might make it impossible to add a new camera to the BVMS. Changes introduced with: Platform Firmware version CPP6 / CPP7 / CPP7.3 7.87.0029 CPP13 8.90.0037 CPP14 9.00.0210   2) Unsecured ports and services disabled in the camera   As best practice to reduce potential attack surfaces and limit the exposure of sensitive services the following ports are disabled in the camera by default: RCP+: CONF_RCP_SERVER_PORT  HTTP: CONF_LOCAL_HTTP_PORT  RTSP: CONF_RTSP_PORT  iSCSI: CONF_ISCSI_PORT Closed RCP+ port in the camera might not allow adding this camera to the BVMS, as it was used in the earlier versions If camera is added to the system with Secured connection option disabled in the BVMS configuration (so it's using unsecured ports for the communication), Changes introduced with: Platform Firmware version Comments CPP6 / CPP7 / CPP7.3 - Changes considered in the future firmware released - to be determined later CPP13 8.90.0037 iSCSI - closed* (see below) RCP+ - closed HTTP - closed RTSP - closed CPP14.1 CPP14.2 CPP14.3 9.00.0210 iSCSI - closed* (see below) RCP+ - open HTTP - open RTSP - open CPP14.3 9.00.0190 iSCSI - closed* (see below) RCP+ - closed HTTP - closed RTSP - closed Important note: Intermediate fw version, replaced by 9.00.0210 - see the row above. *An unsecured connection is required for local storage replay, such as e.g. SD card, ANR. Communication over the RCP+ and iSCSI port is required in such a scenario. While communicating to the device on a secure connection, these ports can be re-enabled. A reboot of the device is required after re-enabling these ports, and then one can switch back to using an unsecure connection.   3) New firmware libraries with the limited backwards compatibility   The new libraries in the firmware, used for secured (HTTPS) communication are not compatible anymore with BVMS 11.1.1 or older. As a result, if secured communication is configured, camera will not function properly in BVMS anymore. Changes introduced in: Platform Firmware version Comments CPP6 / CPP7 / CPP7.3 -   CPP13 -   CPP14 9.00.0210     Solution   Please find the overview of applicable BVMS patches for supported BVMS versions Platform Firmware version BVMS 11.1.1 BVMS 12.0.1 BVMS 12.1 Resolved compatibility challenge Fix / patch Fix / patch Fix / patch CPP6 / CPP7 / CPP7.3 7.87.0029 BVMS111165 Patch CantAddCamSpecFW 424238 Included - no additional patch required Included - no additional patch required 1) Legacy RCP+ commands CPP13 8.90.0037 BVMS111165 Patch CantAddCamSpecFW 424238 Included - no additional patch required Included - no additional patch required 1) Legacy RCP+ commands Please consider workaround as described HERE BVMS1201375 Patch FW8_90 Cap 429121,418648,425002 Included - no additional patch required 2) Unsecured ports closed in the camera CPP14 9.00.0210 BVMS111165 Patch CantAddCamSpecFW 424238 Included - no additional patch required Included - no additional patch required 1) Legacy RCP+ commands Please update the fw to 9.00.0210 BVMS1201375 Patch FW8_90 Cap 429121,418648,425002 Included - no additional patch required 2) Unsecured ports closed in the camera BVMS111165 Patch FW90improve 434923,428521 Included - no additional patch required Included - no additional patch required 3) Libraries compatibility (for the secured connection)   BVMS 11.0 or previous versions   Since the mentioned FW versions were released more than 2 years after BVMS 11.0 release, compatibility cannot be guaranteed. In order to use the latest camera FW versions with BVMS, please consider upgrading BVMS to one of the versions mentioned above. ... View more

Question   Can I receive Configuration Manager or BVMS Software version Release Notifications?   Answer   Yes! You should only subscribe directly to this article (Option 1) or to the software_release_notification label (Option 2) and you will receive a notification in your inbox every time when a new Software version is released and added to the lists within this article.   The latest Software Release added within this article is marked as  in the tables below:   ⚠️  The complete software list (containing older active versions), together with other product information is available on the respective page for a product within our product catalogue, or via the Bosch Download Area BVMS Start availability BVMS 12.1   2023-11-30 BVMS 12.0.1 2023-06-30   Configuration Manager Start availability Configuration Manager 7.71    2023-11-06 Configuration Manager 7.70 2023-06-14    Nice to know: Bosch Building Technologies Software Service and Support definitions Can I receive Firmware Release Notifications for Bosch IP cameras and Encoders? How to subscribe on labels: e-mail notification for published/updated articles in BT Knowledge Base? ... View more

📚 Overview BVMS and VRM Encrypted Recording Prerequisites Data Encryption: General Overview VRM Encryption Operation Overview VRM Encryption Operation Overview: Playback Step-by-step guide VRM Encryption Configuration Step 1  Step 2  VRM Encryption: Certificate Page VRM Encryption: Playback VRM Encryption: What’s NOT Supported VRM Encryption: Old Keys | New Keys   BVMS and VRM Encrypted Recording Prerequisites   Starting with BVMS v10.0, you can leverage VRM Encryption Technology.   Compatibility requirements are as follows: VRM version 3.82 or higher Camera Firmware 7.10 or higher  Camera must have Crypto Coprocessor version 3 or higher Devices “System Overview” web page as noted in the “Lock Down Module”  Note Video Devices that do not meet the prerequisites defined above, or were produced prior to 2014, can be encrypted utilizing VSG   Data Encryption: General Overview    Data encryption on iSCSI storages The payload on an iSCSI drive is encrypted using a symmetric XTS (AES) encryption scheme This is block encryption, NOT Whole Disk Encryption The Step-by-Step Process is covered in this article The camera uses the VRM’s public key(s) to asymmetrically encrypt the XTS key for multiple receivers. These public key(s) are maintained in the camera’s certificate store. Usage can be defined as for “REC1 or REC2”. VRM decrypts the payload data for replay for supported clients Supported Clients: VSC, BVMS v10 and Higher   VRM Encryption Operation Overview   The VRM iSCSI encryption process happens in several phases and utilizes two sets of keys: VRM’s Asymmetric Key set   The cameras Internal Symmetric Key used specifically for “LUN” Encryption When cameras are added to the VRM configuration VRM distributes a “Static” public key to all devices   The Camera will encrypt all of it’s “Blocks” with its own dynamically generated Symmetric Keys: The AES Encryption Keys are generated in the cameras Crypto Co-Processor   Each Block is Encrypted with a Unique Key   The Camera’s “Symmetric Key” that was used to encrypt the block is then:  Encrypted VRM’s “REC1” public key   The key is then “Stored” in the block that it encrypted   VRM Encryption Operation Overview: Playback   VRM performs the playback function by retrieving the camera’s Symmetric Key that was encrypted with its “Public Key”, and stored in the block. VRM Decrypts the “Symmetric Key” using its “Private Key” The Video in the AES Encrypted “Block” can now be decrypted and played back to the client   Step-by-step guide   VRM Encryption Configuration   When a VRM service starts for the first time, it will auto generate a self signed “Recording” Certificate (REC1) Certificates and keys will either be placed in the OS Certificate Store (MMC), or the Crypto Co-Processor of its appliance if equipped.   Certificate Structure is the same as discussed in the “Certificate and MCA” module All capable video devices that are added to the VRM are automatically given the VRM’s static “Public” key:   Step 1    VRM encryption cannot be initially started until a “Backup” of the of its Private “REC1” key is made!   In the Devices Tree highlight the system’s VRM. Navigate to the “Service” menu tab and the “Recording encryption” submenu: Under “Redundancy key” select the “Create” button   You will receive a “Create redundancy key pop-up menu Select the “Browse” tab Once you select a location …   You will receive a key menu similar to the Micro CA  Fill in the appropriate data and password    Note The backup key will be saved as a PKSC12 File (PXF) which will contain the Private Key and X.509 Certificate    Step 2    After a Redundancy key has been created you will now have access to the “Enable encrypted recording” checkbox. After you select it you will be asked if you want to proceed: select “Yes”   After saving and activating your configuration, all VRM devices should show a status if “Encrypting”   VRM Encryption: Certificate Page   Similar to the Certificate Store in the Cameras and the Micro CA in Configuration Manager, VRM has a “Certificates Page” ( Services and Certificates menu). Back Up certificates can be uploaded using this page: Usage “REC1” needs to be applied    VRM Encryption: Playback   Because the Workstation setting of direct playback from storage will not function if dealing with encrypted video, this setting is automatically ignored if configured: The Workstation will be redirected to utilize VRM Decrypted Playback   VRM Encryption: What’s NOT Supported   Encoder 32 Block Playback during VRM Downtime Not Supported   ANR Playback does not function when recording are encrypted   VRM Encryption: Old Keys | New Keys   If there is a VRM failure and a new installation has occurred: Video encrypted with the original certificate cannot be replayed unless the “Back Up” key is applied to the new VRM In this example all video using the Certificate from July 2019 would be inaccessible unless the Redundancy Key was utilized:   Nice to know: What is VRM eXport Wizard and how to use it? How to play exported recording files from VRM eXporter Wizard in BVMS Export Player? How to export VRM recordings of cameras & convert them to mp4-file (VRM eXport Wizard 2.0)? How to export VRM recordings of cameras & convert them to mp4-file (VRM eXport Wizard 2.10)?   ... View more

Question:   What is the Glutton MODE in VRM, what are the causes and how does it work?   Answer:   Enhanced glutton protection mode is a new feature in VRM versions e.g. VRM 3.71 and newer.    The prevention of a glutton (German: Vielfraß) defines and prevents a camera or multi-channel encoder from mounting and consuming  a large number of  blocks in a very short time. If a device is placed in glutton mode, VRM performs the following operations: All blocks except the actual mounted and recording block are removed from the camera span list. If a device is in glutton mode, it gets only 6* number of configured cameras blocks per hour. The device is monitored and when block consumption returns to normal, it is removed from Glutton Mode.   Possible messages when a camera is in Glutton mode are as follows:   This device has an abnormal high storage consumption. To protect other recordings, storage allocation is reduced. This may result in recording gaps for this device. Device runs out of storage and might stop recording. This device had an abnormal high storage consumption and is now set back to regular mode.   Glutton Mode possible causes:   BVMS Profiles: Normal-Good-Excellent used on any Current CPP. Corrupts the Camera Configuration, VRM will place camera into Limited span mode (6 spans per hour max). Bad Time Server: If Time Server jumps more than 2 seconds (Forward or Backwards) frequently. Causes Camera to prematurely release blocks and take new ones. Network Issues: Wireless, bad cables, bad switch ports, port 3260 blockage issues, network disconnections, etc.   Glutton prevention feature explained:   Every time a block is mounted by a device, the block and the time of mount operation is saved. The last 15 time differences between mount operations are considered for glutton protection If more than the half time differences between mount operations are less than a threshold of 120 seconds, Glutton protection mode is switched on   ... View more