Film-Tech Forum ARCHIVE: Dolby IMS to JNIOR Issue

This is topic Dolby IMS to JNIOR Issue in forum Digital Cinema Forum at Film-Tech Forum ARCHIVE.

To visit this topic, use this URL:
https://ft-forum.com/ft/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=16;t=003871

Posted by Bruce Cloutier (Member # 9615) on 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.

Posted by Steve Guttag (Member # 268) on 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.

Posted by Bruce Cloutier (Member # 9615) on 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.

Posted by Harold Hallikainen (Member # 5405) on 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

Posted by Bruce Cloutier (Member # 9615) on 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.

Posted by Steve Guttag (Member # 268) on 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?

Posted by Bruce Cloutier (Member # 9615) on 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.

Posted by Marcel Birgelen (Member # 6801) on 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.

Posted by Bruce Cloutier (Member # 9615) on 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.

Posted by Steve Guttag (Member # 268) on 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.

Posted by Bruce Cloutier (Member # 9615) on 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.

Posted by Marcel Birgelen (Member # 6801) on 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? [Razz]

Posted by Bruce Cloutier (Member # 9615) on 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.

Posted by Steve Guttag (Member # 268) on 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.

Posted by Bruce Cloutier (Member # 9615) on 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?).

Posted by Marcel Birgelen (Member # 6801) on 12-09-2019, 06:29 PM:

quote: Bruce Cloutier
Marcel, it can happen. Um, that would mean that someone would have to first think to actually change the passwords away from the defaults.

I was thinking about it because I remember some vague instructions somewhere to apply "Base64 encoding" to your passwords to make them "stronger" because they're less readable. I guess they confused it with applying some hash to it like MD5, SHA*.

But yeah, the chances of someone choosing a password that actually is valid Base64 are pretty slim, but could cause for some hard-to-debug issues I guess. [Wink]

quote: Steve Guttag
Generally, when one makes a change on a Doremi configuration file, that change is not reflected until after a reboot.

I think you should reboot as fast as possible if you edit the file manually, because if you change some settings that cause the file to be re-written, it will probably overwrite your own changes.