CyberData Home Tech Support
 Knowledgebase
Knowledgebase:
Critical Error, VIDEO INTERCOM & VIDEO KEYPAD: 500 Internal Server Error
Posted by Paul Tuttle on 18 January 2018 05:17 PM

There is currently a bug with the Video Intercom and Video Intercom with Keypad, that can put the device into a state where it is unusable. This bug occurs in the main application and thus will render the intercom "bricked". This bug could occur in any current version from 1.0 to 1.3.1. 

This bug occurs if an HTML specific character gets into registration information. This occurred specifically with the password field but could happen with any field. I encountered this bug when copy and pasting registration information from ringcentral although it is not specific to a particular PBX. This could happen with any PBX and is not SIP related.

If an HTML character, for example a 'Tab' character is copied accidentally it will render the device useless when the config is saved and the device is rebooted. This occurs because the device is attempting to parse the 'Tab' character and recognizes the character as "UNPRINTABLE CHARACTER IN STRING". Once this occurs the device will be stuck in a "booting loop" where the call button will blink endlessly, the device will respond to Pings, and the web interface can be reached. Although the Web Interface shows this error:

 

The customer has no option to clear the config from the device. Holding the RTFM button after it has gotten into this state will do nothing as the main app has crashed. Holding down the RTFM button prior to powering the device will also not have any effect. Currently the only way to clear the config is to SSH into the board itself and delete the file. This is not possible for a customer; the device will only allow those with a proper certificate to SSH into the board (any engineering staff can do this).

I do not expect to have this error occur out in the wild but it is entirely possible. In my opinion the best possible options if a customer experiences this issue would be one of two things.

1. Assuming the customer is willing; have the customer open a port on their network to allow for SSH access to the device. One of the engineering staff can then delete the configuration file and reboot the device, which will recover it from this error. This would take anywhere between 3-5 minutes tops.

2. If the customer is not willing to open a network port to allow for SSH access, the only other option would be RMA.

Thanks,

Paul Tuttle

(0 vote(s))
Helpful
Not helpful

Comments (0)