my profile | my password | search | faq & rules | forum home

» Film-Tech Forum ARCHIVE   » Operations   » Digital Cinema Forum   » Dolby IMS to JNIOR Issue (Page 1)

This topic comprises 2 pages: 1  2

Author Topic: Dolby IMS to JNIOR Issue Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 12-05-2019 12:11 PM                        I've mentioned this before but this is a real issue and ALL on Dolby. Does anyone know who at Dolby might be the right person to approach on this? We need to have a discussion. Basically the IMS does not send the JNIOR the login password correctly. Probably about 3/4 of our support calls are on this very issue. Naturally, with some odd combination of rebooting the IMS, removing configuration on the IMS and setting the IMS back up again you can get it to work. We have yet to pin down exactly which are the magic steps. And, I don't think that once you achieve communications that the issue doesn't come back to haunt you some time down the road. We hate to have to run customers down this path. Someone from Dolby told Kevin that they are aware of the problem and that it will be fixed. Um, I'm thinking that was a couple of years ago. Well? Here's a description from the jnior.com site: https://jnior.com/dolby-ims-jnior-connection-issue/ It's Software and not Rocket Science! We haven't been collecting information as to what IMS models and versions have been encountering this. I am going to recommend that we start doing that. We may need to start redirecting folks to Dolby support. We try to help but it would be nice to know that Dolby cares too.  |  IP: Logged Steve Guttag We forgot the crackers Gromit!!! Posts: 12814 From: Annapolis, MD Registered: Dec 1999 posted 12-05-2019 12:43 PM                     I'll get you to the right person. Note, this is from the Doremi group and they are different than the traditional Dolby people. I've, personally, found them to be more difficult and much more resistant to change/suggestions. I have also found the Ethernet communication from the Doremi product line (including the IMS servers) to be more flaky than other servers and always suggest putting in the /w (wait) command on every command. The fact that they had to have the /w command at all is an admission of guilt in how they open ports/send commands.  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 12-05-2019 02:32 PM                        We had the Doremi network issues in the past. That was a case where the programmer assumed that each TCPIP packet equals one message. So when a message got split across two or more packets it would not be interpreted successfully. Also if two messages came in one packet the second would be ignored. That (I believe) got resolved. This is a rookie programming mistake that keeps coming up. It's just a lack of experience. It didn't help that 99% of the time a packet carried one and only one message. Kevin has been in touch with someone at Dolby on this specific password issue. I am just not sure that is the right person to push the solution out. It keeps sounding like it has been resolved and will be out in some release but we continue to deal with it. Kevin thinks it might be just be coming up on a year. It amounts to 2-3 calls a week. That doesn't count those who find the article online and follow the steps without calling. With today's support call the online steps worked for several IMS systems but not on one... ergo the call. They have tried to blame the browser for not properly filling in fields. You are right though, it is definitely not Dolby in general.  |  IP: Logged Harold Hallikainen Jedi Master Film Handler Posts: 906 From: Denver, CO, USA Registered: Aug 2009 posted 12-05-2019 04:47 PM                        Note that the wait escape sequence is \w . I often put it before and after a command to make sure the TCP connections is established before data is sent and held until after it has been received by the other end. Harold  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 12-06-2019 07:59 AM                        Harold, this issue is with the password login for the IMS2000 built-in JNIOR interface. The \w is a good point for commands. Our guess right now is that when the user specifies a password it is saved in an XML file in plain text where the Doremi code expects it to have been stored as encrypted. They then decrypt the stored (unfortunately plaintext) password for transmission to the JNIOR which naturally is in error. If you leave the password field blank (making sure too that the browser does not auto-fill that field with some prior entry), then they load the XML with the default password in properly encrypted form provided that there wasn't a password already set. Most of our Digital Cinema customers retain the default administrator passwords even though it would be wise to not do so. Here, it appears, that you do not have the option. I wonder if on a working IMS2000 you could locate the JNIOR login credentials in the devices XMP file and copy that line as a correction for those with the communication problem. That would be more of a definitive solution than the kind of punt and try again approach that is currently recommended. I don't have an IMS2000. Maybe someone can look into that? By the way, I have been told that this password problem has been taken care of with IMS3000.  |  IP: Logged Steve Guttag We forgot the crackers Gromit!!! Posts: 12814 From: Annapolis, MD Registered: Dec 1999 posted 12-06-2019 08:10 AM                     How about a "no password" option for such commands? That is, give a configuration option that omits the password requirement?  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 12-06-2019 08:31 AM                        You can disable the login requirement and define an anonymous account to be used. In that case the connection would succeed when no login credentials (or blank credentials) are supplied. The issue is that if login credentials are supplied they must be valid regardless of whether or not an anonymous connection is possible. That is to allow you to access other accounts and capabilities beyond what you might allow an anonymous user to do. I can modify JANOS for the JNIOR4 but that wouldn't address the population of JNIOR3 out there.  |  IP: Logged Marcel Birgelen Film God Posts: 3357 From: Maastricht, Limburg, Netherlands Registered: Feb 2012 posted 12-06-2019 01:09 PM                     So, is it a properly encrypted string and thus reversible or is it a hash value what they're storing? (which would be double-plus-stupid...) Maybe you should offer them a JNIOR 3 and 4 for free, so they can put one into their official testing procedure for new software releases. :> quote: Steve Guttag The fact that they had to have the /w command at all is an admission of guilt in how they open ports/send commands. I think it is good to have a "wait" on all platforms. Reason: a lot of stuff out there is far from perfect. But a wait function is especially useful if you're communicating with older, slower gear or stuff that incurs a latency during certain operations, for example, when stuff uses a login that needs to be validated over a network, etc. Since the "other side" may start another process, depending on your input, you can't entirely rely on the I/O buffers on several levels here. For example, if the login process is slow, but is handled by another process, it may receive commands that are destined for the process that comes after the login process and those may end up being discarded. Sometimes I wished those servers would offer a somewhat more sophisticated infrastructure to interface with external gear. Something that allows you to read return values and make decisions based on that. But you're probably going to need a Turing-complete scripting language to do that, which may be a bit beyond the application domain of this kind of equipment.  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 12-06-2019 01:57 PM                        quote: Marcel Birgelen So, is it a properly encrypted string and thus reversible or is it a hash value what they're storing? (which would be double-plus-stupid...) I'm not sure what approach is intended. They are making a JNIOR Protocol connection (typically via port 9200). This is a legacy JNIOR3 interface whereas with JNIOR4 has a more modern JSON interface also available. With the JNIOR Protocol the username and password can be supplied in clear text. Optionally it can be obfuscated using Base64 encoding. And, you may even obtain a NONCE (stupid stuff) and generate an MD5 message digest. But the IMS might encode the password in some reversible form for storage and then try to encode it for our protocol. Just don't know. With JNIOR4 you can upgrade a port 80 HTTP connection to Websockets and use the JANOS Management Protocol (JMP) which is pure JSON. This JMP interface is also available since v1.8 on a separate port (for those who struggle with Websockets). This interface lets you do just about anything and everything. Our default web pages, Dynamic Configuration Pages (DCP), uses a single Websocket connection to manage the unit. The legacy JNIOR Protocol (which is binary) is fully functional for JNIOR3 and JNIOR4 but limited to I/O related operations.  |  IP: Logged Steve Guttag We forgot the crackers Gromit!!! Posts: 12814 From: Annapolis, MD Registered: Dec 1999 posted 12-06-2019 02:48 PM                     Marcel, I don't mind the wait option...I just think it is an admission of guilt that they need it for practically every communication...they should build that wait into every command so it is transparent.  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 12-09-2019 07:26 AM                        We've confirmed that the issue is in fact that the IMS stores the JNIOR password in plain text when their driver is expecting to be hiding it with Base64 encoding. If you locate the "JNior" device in the /doremi/etc/devices.xml file the incorrect XML file will show the JNIOR password in readable form. The default password should be "am5pb3I=" in that file when properly encoded and when communications works. There are a bunch of Base64 encode/decode sites on the net where you can obtain the proper coding for the password. You can then edit this file to definitively correct the operation of your IMS2000 or IMS3000. By the way, we think their driver then decodes the password and transmits it to the JNIOR in plain text. They can actually just send the Base64 encoded stuff. It fails now because they try to decode the Base64 to get the plain text to send. If it is not Base64 to begin with then it fails as we all now know. Not withstanding that it is a simple matter to detect whether or not something is Base64 encoded or not. And that encoding really was just to keep the honest people honest by simply hiding the password when the network is sniffed. Ideally you can request the NONCE value and calculate an MD5 digest value that cannot be reversed if you really wanted to protect the password. The JNIOR4 also supports a kind of STARTTLS and allows the JNIOR Protocol to continue over a secure connection (TLSv1.3). That would protect everything including the password. We are hoping that Dolby commits to including a fix for this in the next update. It sounded like updates come out quarterly so... in the next few months. I think we are going to recommend editing of the XML file going forward rather than the shenanigans involving any "punt and start over" strategy.  |  IP: Logged Marcel Birgelen Film God Posts: 3357 From: Maastricht, Limburg, Netherlands Registered: Feb 2012 posted 12-09-2019 08:05 AM                     quote: Bruce Cloutier Not withstanding that it is a simple matter to detect whether or not something is Base64 encoded or not. What happens if my randomly-chosen, hyper-secure password also decodes to Base64?  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 12-09-2019 08:52 AM                        Marcel, it can happen. Um, that would mean that someone would have to first think to actually change the passwords away from the defaults. We've checked that the XMP file is similar on the DCP2000 that we actually do have in here. Kevin was checking the ability to edit that file and whether or not a reboot is actually necessary.  |  IP: Logged Steve Guttag We forgot the crackers Gromit!!! Posts: 12814 From: Annapolis, MD Registered: Dec 1999 posted 12-09-2019 09:18 AM                     Generally, when one makes a change on a Doremi configuration file, that change is not reflected until after a reboot.  |  IP: Logged Bruce Cloutier Expert Film Handler Posts: 161 From: Gibsonia, PA, USA Registered: Aug 2016 posted 12-09-2019 02:33 PM                        I've been told that there will be a fix for this issue in the IMS2000 update in 1Q20 (February?).  |  IP: Logged

All times are Central (GMT -6:00)

This topic comprises 2 pages: 1  2

Printer-friendly view of this topic

Hop To: Select a Forum: Category: Operations -------------------- Digital Cinema Forum Film Handlers' Forum Large Format Forum Ground Level Feature Info, Trailer Attachments & REAL Credit Offsets Category: Community -------------------- Film-Yak Film Handlers' Movie Reviews The Afterlife Bob Maar's Joke-A-Thon Category: Classified -------------------- Equipment and Supplies Wanted/For Sale Help Wanted/Seeking Employment Category: System -------------------- Software Beta Testing Forum

The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion and agrees to release the authors from any and all liability.