creation of nmap scripts to do network discovery of cinema equipment.

[Harold Hallikainen]

Sounds like a good approach. The text in /ConfigFlash.html is what makes the generic product this particular one. So, serial number plus all user settings are stored there. The firmware and hardware versions are not stored there but are, instead, read from the firmware and hardware on power up. That's why the are a comment in /ConfigFlash.html if they are there at all.

Other products that have /ConfigFlash.html include the IRC-28C (with the latest firmware, see http://ftp.uslinc.com/Products/IRC-2...Firmware/beta/ - QSC had not released these versions, but I hope MIT will), and the LSS-200. I do not have easy access to these. Perhaps someone could capture /ConfigFlash.html from units they have.

Harold

[James Gardiner]

Hello all,
I have had a good run at a number of devices now. Please check out the greatly updated GitHub Repo at https://github.com/jamiegau/cinema-nmap-scripts

Harold, can you send me the ConfigFlash.html output of an IRC-28C and an LSS-200 so I can pull the version out.. and other possible data.

PLEASE TRY the scripts as I only have a limited set of equipment I can test them against.

From the readme, the current state and roadmap of items I will support are.


The following is the initial set of equipment that scripts will be created for.

Dolby	Player	DONE	IMS1000, IMS2000, IMS3000 (DCP2000 and similar era kit unknown.) Initial beta version done, needs testing by the community.
Dolby	Sound Processor		CP750, CP850, CP950
Barco / Cinionic	Player		ICMP
Barco / Cinionic	Projector	DONE S1,S2	Barco Series 1&2 ready for testing, S4 different and I would need direct access to one for implementation
GDC	Player	DONE	SX2001A, SX3000, SR1000, SX4000, needs testing
Qube	Player		XP-D
NEC	Projectors	DONE	Series1 and Series2 projectors, needs testing
INTEG	Automation controller		JNIOR 400
RLY8	Automation controller		generic IP based automation controller
QSC-USL	Sound Processor	DONE	JSD100, JSD60, CM8, IRC-28C, LSS-200
QSC	Sound Processor		Other

Thanks for your help guys.

[Harold Hallikainen]

I've sent James the ConfigFlash.html for the IRC-28C. Note that it has moved to /debug/ConfigFlash.html . On the IRC-28C home page, there is a link to a debug page that then has links to ConfigFlash, logs, etc.

Harold

[James Gardiner]

Hello All,
I have had another big run at this and have now implemented a decent number of scripts.
I still have Qube over the weekend to do.
But otherwise, to do a lot more I will need access to the equipment directly.
If anyone can help by allowing me to have access to a linux system on a network with numerous devices I don't have listed. That would be great.

https://github.com/jamiegau/cinema-nmap-scripts

The following is the initial set of equipment that scripts will be created for.

Dolby	Player	DONE	IMS1000, IMS2000, IMS3000 (DCP2000 and similar era kit unknown.) Initial beta version done, needs testing by the community.
Dolby	Sound Processor		Appreciate access to these units for implementation, CP750, CP850, CP950
Barco / Cinionic	Player		ICMP
Barco / Cinionic	Projector	DONE S1,S2	Barco Series 1&2 ready for testing, S4 different and I would need direct access to one for implementation
GDC	Player	DONE	SX2001A, SX3000, SR1000, SX4000, needs testing
Qube	Player		XP-D
NEC	Projectors	DONE	Series1 and Series2 projectors, needs testing
INTEG	Automation controller	DONE	JNIOR 400
RLY8	Automation controller	DONE	generic IP based automation controller
QSC-USL	Sound Processor	DONE	JSD100, JSD60, CM8, IRC-28C, LSS-200
QSC	Sound Processor		Appreciate access to these devices to implement, please contact me

[James Gardiner]

Hellow all,
I have created two YouTube videos that go into how to use this tool, and how it can be used by other vendors to improve features for cinema owners and Integrators.

See:

Cinema Equipment Version Control with NMAP - https://youtu.be/1ZUCCIH4OYA

Free Cinema Tools: Device Discovery & MONITORING - https://youtu.be/7JnhEDdOobo

Thanks,
James

[Steve Guttag]

It's interesting stuff James. I think the version number stuff is mostly important to NOCs where they want equipment on a specific version number, more so than at the cinema level. Yeah, the DRF people (and really..."Digital Readiness" in 2022?) may ask for version numbers but, really, it is none of their business and it could change on any day. All the distributors really need to know is what Mediablock one has and what its serial number is. The rest is, at best, data mining. In the event of a server swap, it is the server and its serial number is all that has to be provided to a distributor, not the whole shebang again.

On the device page of your Discovery & Monitoring, you have a place for the server certificate but I think you should add a spot for the dn qualifier/public key hash. From a support standpoint, that has proven to be more handy. When keys are not taking, particularly if there have been server swaps, that can quickly troubleshoot why a key is not taking despite having the same serial number.

[Harold Hallikainen]

Very nice James! I noticed some unidentified USL/QSC equipment. On the USL equipment, you should at least be able to pull the model number from the third least significant byte of the MAC address. Bytes to the left of that are fixed for USL equipment I worked on (not CMS). Bytes to the right of that vary by unit.

Harold

[Bruce Cloutier]

James' JNIOR is from 2014. The first digit of the serial number is the product model/series. The 410, 412 and 414 are 6, 7 and 8 respectively. The next 4 digits represent the date of manufacture in the format YYMM. The rest is a sequential number assigned as the unit passes through Program and Test.

That unit is running v1.3 which I would bet is its factory condition. We are currently shipping JANOS v2.2. We highly recommend that everyone update their Series 4 units. INTEG support is free and for the life of the product but we only support the latest releases of the OS. It might be worthwhile to go through the update procedure for that unit. You could also then enable SNMP and show that? You can contact support and they will happily help you fully update that device.

The battery in that is likely nearly dead. It is easily replaced and not at all critical like other batteries in these cinema systems. With a good battery the JNIOR will maintain log information through power loss. The logging is a very useful feature in this automation. When there is some unexpected event you can go back and see what happened without needing to try to catch it when whatever it was happens again. That includes network capture. Much of that is greatly improved in later JANOS releases. The latest units ship with JBakup which can optionally archive logs longer term to flash storage.

You can get the S/N and OS version from the header when making a Telnet connection without logging in. You may be doing that. The system up time is also reported there. That might be useful. That resets on reboot. If you do log into the unit (and sometimes people change the passwords) the STATS command also reports the total all-time runtime. That also tracks the longest (record) up time. Just interesting sometimes.

The MANIFEST command in the JNIOR can be used as in your tools to detect (perhaps undesirable) changes in files on a unit.

[James Gardiner]

James' JNIOR is from 2014. The first digit of the serial number is the product model/series. The 410, 412 and 414 are 6, 7 and 8 respectively. The next 4 digits represent the date of manufacture in the format YYMM. The rest is a sequential number assigned as the unit passes through Program and Test.

I use the original Binary API as it should work with even the oldest units. However, its problematic to code. I couldn't work out the CRC and use the non-CRC flag.
I am not great with Lua, and the CRC code examples are a little complex. I am not sure how to replicate in Lua, But it appears to work fine not using them.

The units have not been updated as. Why fix something that is not broken.
Sure, a projectors and the support for edge case DCPs. Upgrade. But a contact closure box that does something so basic, and is doing it reliably. It was never on my radar.
All I can be sure of, is if I upgrade it. there is a chance (small that it is) it will no longer be reliable as it has been.

[Bruce Cloutier]

James, yeah CRC calculations are always a challenge. We do not recommend the old binary protocol for that and many other reasons. It is very limited.

As for an old JNIOR "not being broken"... I agree that they have been very reliable but a tremendous number of bugs and issues at all levels have been corrected since v1.3. I have to take it very personally that you or anyone would think that an update would make the product "no longer be reliable". I am not Microsoft. JANOS has a single author... me. There is not one byte of 3rd party code anywhere in that product. I personally will stand behind any OS update.

It is really insulting too when we ship new product and customers insist on rolling back the OS to some older level. With the recent supply chain issues we have had to accommodate a new network PHY chip and that required an OS change. Units shipping compatible with the new hardware obviously cannot be rolled back to an OS that is unable to use the network. It won't let you do it. Boy that has created a crisis. One that I cannot sympathize with. We also had to ship for a brief period with a modified memory mapping. That limited rollback as well.

Now, it has happened (it is rare but) with an update you need to also update an application on the JNIOR. Those applications by the way have one author... Kevin. He stands behind them all too. We're not Dolby. If there is any issue... it is immediately fixed. Well, provided we are told about it and we can identify it.

All said though JANOS reliability has been approaching 100% for a while and v2 is extremely stable and reliable. v1.3 and earlier just makes us shiver. Better than Series 3 though.

I am still running Windows 7 and refuse to upgrade for just the same reasons. So I understand. In fact I know that I cannot run on a Windows 10 machine. Let me tell you that MS really pisses me off. All of our new systems have been Ubuntu but the development environment for JANOS has to be Windows 7 based (for now). On this I could rant on...

So in the beginning Rick did not say "let there be JNIOR" and there was JNIOR. The development of the JNIOR has been a journey that began around 2003. The development of the OS for Series 3 and then Series 4 was an on-going activity and almost a continuum up until the release of JANOS v2. Every Series 4 JNIOR can benefit from that free of charge. I could write a book. A series of videos maybe if there was the time.

If you are just toggling a relay through a binary message then you are right, it works well and always has. Kevin would help you with the LUA CRC thing. Try the JSON-based JMP Protocol.

(I am going to probably hear about the Dolby comment)

[James Gardiner]

Personally, I use W10, for general Office and Cinema Support and Resolve & DCP creation, Ubuntu for Email-and-all other Admin, and MaxOS on my development laptop. (Tho I have considered going to a Linux Laptop, but its hard to beat the MacOS and its close to linux but also runs tier 1 Apps all in one.)

For critical complex devices like computers I use, I would update them all the time as they have external data coming in and out all the time, (Emails, etc) to ensure they are protected from Zero-Days that are so well published these days. It is a race to patch them as the hackers rush in and try to hack as many people as possible before auto-update.

I still have issues with cinema owners refusing to upgrade systems as they want them reliable.. But they ignore these threats. It's just a fact of life these days. Only non-internet-connected devices should have upgrades held back in my opinion.

Thanks for the tips. I will focus on the JSON-based API when I get to implementing some more work on the devices. But for version detection, the Binary API is probably best as it will work with everything from the oldest to the newest.

Dolby appears reasonable these days to me. They are dealing with an exponentially more complex system, so I am not surprised issues do arise in upgrades. Long periods between upgrades is a good path. Usually, they would have some test sites running a beta for a good few months before they should push out wide.

You guys are welcome at looking at the Lua script in the repo and modifying it to what you feel is best.
Its a little hacky, being my first Lua programming. Just do a pull request or send me a new version in an email. I'll quickly test it in my network, and push it into the scripts.

[Bruce Cloutier]

Here is a copy of our internal developer notes covering releases. That 2014 JNIOR (Series 4 initially shipped in 2014) was probably first built with JANOS v1.0.0 and so has in fact been updated at some point. The attached list is raw detail written for internal understanding and not generally for release. We use SVN and Redmine and the links in this document won't be functional as they lead back to our systems in here. I have not redacted this list before sharing. If there is anything where anyone would like a better explanation just ask (maybe in a new thread).

I think better of v1.3 after reviewing this list and recalling what was done. Prior to v1.3 it was possible to corrupt the Flash File System and not be able to recover data. Basically everyone pulls power to reboot the JNIOR and in doing so you can easily interrupt an ongoing Flash write operation leaving the memory structure invalid. A mechanism serializing the last known valid Flash File System state was added. On boot the system rolls the FFS back to a stable checkpoint if it is left in a bad way. This greatly improves reliability.

So I would say that if you have JNIORs running anything before v1.3 then an update is a necessity. This document needs to be updated to indicate that we have released JANOS v2.2.

Through this we have hunted down and eliminated a number of what we term "gremlins". These are a subclass of bugs that cause rare infrequent and random symptoms. Consider an errant random memory write. Most of the time the affected memory location is unused and there is no issue. When something critical is damaged it could be anything and something totally inexplicable then can happen seemingly out of the blue. When we (cautiously) claimed victory over the gremlin population with released the OS as v2. Our updates do not make the product less reliable.

I don't think any of your other suppliers would be this transparent. Nor with anything else do you have such direct contact with the original designers. Just saying.