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

[Mark Gulbrandsen]

That used to happen with my AT&T modem on occasion. But not at all since I switched to Fiber.

[Marcel Birgelen]

You couldhave also added in a Linux compatible network card. You would only need load the driver and it may have worked with one of the later versions of firmware.

The CP650 didn't boot any Linux as far as I'm aware. Just like the JSD-80 Harold worked on, that was pretty much all just microcontrollers running native code, without any real OS in the background, that may also explains the limited Ethernet functionality.

The CP850 and also the CP950 are Linux based machines, although that fact is better hidden on the CP950 than the CP850, which is essentially just another generic OEM Supermicro PC-based server.

Nowadays, embedded systems have become so powerful, they can run actual full OSes. Yet again, despite all those gains in processing power, I don't have the feeling we're using it to actually speed stuff up.

[Mark Gulbrandsen]

The CP650 didn't boot any Linux as far as I'm aware. Just like the JSD-80 Harold worked on, that was pretty much all just microcontrollers running native code, without any real OS in the background, that may also explains the limited Ethernet functionality.

The CP850 and also the CP950 are Linux based machines, although that fact is better hidden on the CP950 than the CP850, which is essentially just another generic OEM Supermicro PC-based server.

Nowadays, embedded systems have become so powerful, they can run actual full OSes. Yet again, despite all those gains in processing power, I don't have the feeling we're using it to actually speed stuff up.

I think we are using them to aggregate more functions into a given.system, because the parts for a given subsystem might cost a buck. Engineering is more, but spread over thousands of manufactured units. Nothing wrong with Super Micro, my only.beef about their servers are they were needlessly noisy, while Dell and HP were whisper quiet. I have an HP server here that has to be going.on.ten.years old, so they were quiet at least that long ago.

[Bruce Cloutier]

The port scans that include checks for security vulnerabilities tend to be extremely disruptive. We spent some effort running a few that we were aware of to both see that the JNIOR (Series 4) was not impacted by the scan and that it did not contain any actual vulnerabilities. Because the OS is unique most of those security issues don't exist. I am sure there are others. We made changes to avoid issues with malicious connections. We have JNIORs with ports open directly connected to Internet and configured only with a unique password. Those survive and have not (to my knowledge) been compromised (DoS aside).

I have to agree with Steve and others about the older equipment that might not have been originally intended to use the network as any primary connection. The Series 3 JNIOR might have difficulties. The firmware managing the network in those was not of our doing. I would be concerned about the effects of a network scan. And, you probably should never attach a Series 3 directly to the Internet.

[Marcel Birgelen]

I've seen entire webservers crash with those "security scans". They're far more intrusive than a normal portscan, as they actually try to hammer your services with all kinds of nasty requests of which many are actually designed to do harm to your environment.

We now have a public, paid for service that scans our public exposed parts of our network every week or so and sends us a report of what it had found. The first time it ran, it crashed a Tomcat Java thingy supplied by a third-party supplier...

I think we are using them to aggregate more functions into a given.system, because the parts for a given subsystem might cost a buck. Engineering is more, but spread over thousands of manufactured units. Nothing wrong with Super Micro, my only.beef about their servers are they were needlessly noisy, while Dell and HP were whisper quiet. I have an HP server here that has to be going.on.ten.years old, so they were quiet at least that long ago.

Dell and HP are both much harder to customize. A big part of Supermicro's business is in custom appliances and even if you buy a Supermicro server from a distributor, there are usually tons more options, starting at more than 20 current case models, at least 10 choices of motherboards and so on. I usually revert to Dell, as I know their server line-up, but Supermicro is a nice option if you really need an extremely customized piece of hardware that both Dell and HP don't offer.

[Mark Gulbrandsen]

Dell and HP are both much harder to customize. A big part of Supermicro's business is in custom appliances and even if you buy a Supermicro server from a distributor, there are usually tons more options, starting at more than 20 current case models, at least 10 choices of motherboards and so on. I usually revert to Dell, as I know their server line-up, but Supermicro is a nice option if you really need an extremely customized piece of hardware that both Dell and HP don't offer.

I have yet to ever run across any customized Dells or HP's. And keep in mind that both companies servers used to be as noisy as most Supermicro's. Dell's first quiet server that had throttled fans was the 2450. Customizing is Supermicro's main business. They even made customized Atom based motherboards for a long time. When I built up a bunch of TMS systems, I went with Dell 2950's or 2900's for up to 4 screens. And all but four of those are still running. The other four having been updated to newer Dells. The HP DL380 G5 I have had at home for at least a decade has been whisper quiet and the only maintainance I've had to do it is replace the BIOS and Raid batteries. So no complaints about Dell or HP servers. My only complaint about Supermicro was the noise. Otherwise, same reliability as the other two mentioned.

[James Gardiner]

I am not talking about using nmap for a security scan. Yes it can be used to do that. But in this case its using a set of custom nse script written to do nothing but identify socket fingerprints of common cinema equipment, then if, for example, a Dolby IMS is detected based on the open sockets, it then runs suitable SOAP commands in the nse scripts against the device to pull its information. The objective is to not hit any devices with a script unless it has a socker fingerprint indicates the type of device it is, and has the ability to service the queries in the script designed for that device.

This should be harmless to all devices. A SYN scan has a minimal impact, and the NSE scripts run against the devices are only cinema specific ones. Not intrusive scripts.

In my opinion, if a SYNC scan overruns the TCP/IP stack, my position is that the device should be depreciated as its not fit for purpose. I personally don't recommend to use a fragile device that cannot deal with a syn scan be used in critical infrastructure for the automation/operation of a cinema. Otherwise, I would indicate warnings for those unist the tool to be aware of certain devices that could be effected.
Like a CP650.

Has anyone tried a basic SYN scan only against a CP650 yet, Would like to hear if it had any effect.)

[Marcel Birgelen]

Has anyone tried a basic SYN scan only against a CP650 yet, Would like to hear if it had any effect.)

I just did so, and the thing is still alive... But, I kept a ping open to it and during the scan it already lost a packet during that scan. Also, when repeatedly trying to connect to the service port, I got one timeout in the seven times I tried.

So, I guess it's mostly harmless, but it could potentially interrupt communications between the CP650 and a third device, while you're scanning it. So, try to avoid scanning while running a show would be a safe bet.

[James Gardiner]

I just did so, and the thing is still alive... But, I kept a ping open to it and during the scan it already lost a packet during that scan. Also, when repeatedly trying to connect to the service port, I got one timeout in the seven times I tried.

So, I guess it's mostly harmless, but it could potentially interrupt communications between the CP650 and a third device, while you're scanning it. So, try to avoid scanning while running a show would be a safe bet.

Thanks Marcel, the result is exactly what I would have expected for a low powered (single threaded) device. the SYN scan would not hurt it but yes, other devices that are actually trying to connect to it for a real reason my fail to do so as it gets lost in the traffic. So yes, I would suggest such scans are not performed in a projection network if there is a likelihood there are low powered devices and they are expecting critical messages at the time of the scan.

If all devices are implemented well and have a full IP-stack and multi threaded implementation, you should see no impact whatsoever. Should being the word. you could still be ultra conservative and perform scans during a time no automation messages are in use.

[James Gardiner]

Hello all,
I have finished the initial script that identifies Dolby IMS* players. However I only really have IMS2000's, so I would appreciate feedback on IMS3000, DCP2000 and any other Dolby type players in the field.

To get access to the script and more information. Please refer to the GitHub repo at https://github.com/jamiegau/cinema-nmap-scripts

I will be adding to this Repo with other scripts as mentioned in the README over time.

[James Gardiner]

Ok, a question for everyone.
Just looking to write a script for USL (now QSC) devices. These devices typically have a port 80 for some basic web action. And port 10001 for socket commands.
For example
jsd[60,100].sys.fader\r
would return the current fader value...
I was also able to find these.
jsd60.sys.theater_name
jsd60.sys.theater_number
in some old documentation...
They work..
But nothing on how to query the Version information. It does not appear to be documented in the open. Does anyone have this info (Harold?)
I tried some things like
jsd60.sys.version & hardware_version & software_version etc stuff like that but no joy.

Also, I have a CM-8E as well. It has port 10001 open, but found nothing on its command protocol whatsoever.

If anyone has this info I would appreciate it.


Thanks,
James

[Steve Guttag]

Harold is your best bet here, if he was willing (or able) to share.

[Jay Wyatt]

Ok, a question for everyone.
Just looking to write a script for USL (now QSC) devices. These devices typically have a port 80 for some basic web action. And port 10001 for socket commands.
For example
jsd[60,100].sys.fader\r
would return the current fader value...
I was also able to find these.
jsd60.sys.theater_name
jsd60.sys.theater_number
in some old documentation...
They work..
But nothing on how to query the Version information. It does not appear to be documented in the open. Does anyone have this info (Harold?)
I tried some things like
jsd60.sys.version & hardware_version & software_version etc stuff like that but no joy.

Also, I have a CM-8E as well. It has port 10001 open, but found nothing on its command protocol whatsoever.

If anyone has this info I would appreciate it.


Thanks,
James

There's already a method in place for discovering USL devices that Harold baked into all the products firmware. If I recall it's a multicast "Anybody out there" request and the USL devices will reply with hostname, firmware version, and other details.

http://ftp.uslinc.com/Products/Ether...overer_v2_0_0/

You could run wireshark while executing the USL Ethernet Discoverer utility to see how the request/response behaves.

[Harold Hallikainen]

Thanks Jay! Ethernet discoverer reports the MAC address, IP address, Serial Number, Theater Name, and Auditorium number.

On the JSD-60, you can use a web browser to look at /ConfigFlash.html . This has all user configuration saved as tab delimited commands. These are sent to the same command interpreter that is on port 10001. In general, if you use a command from that page without the last parameter, it will return the current setting. Let me know of any questions.

Things that are not user set are also readable through the command interpreter on port 10001. There are LOTS of commands, so let me know if there is a particular one you are interested in. One that comes to mind is the firmware version.

jsd60.sys.ver\r

returns the main PCB version (a letter), the bootloader version, the PIC application version, the DSP version, the front panel firmware version, rear panel type (space for none, x for crossover, a for AES, n for BlueLink), rear panel hardware version.

The CM-8E similarly has configuration at /ConfigFlash.html

The CM-8E version information is not available through the command interpreter.

In early products (like JSD-100), configuration was saved as a binary blob. This made it very difficult to add features. The IRC-28C originally saved configuration as a binary blob, but a later update read that blob and then wrote it back to flash (/ConfigFlash.html) as text commands. Similarly, button pushes and form data from the web interface was originally handled in the web server. This required separate code for the web interface and the command line interface. I finally changed the web interface to just do a post of a command that is then sent to the same command interpreter that is handling port 10001, the configuration flash, and the SD card. That made it a LOT easier to maintain!

Fun stuff!

My latest project is combining the old and new.

https://w6iwi.org/rtty/DspTU/

https://w6iwi.org/rtty

Harold

[James Gardiner]

Harold,
Thanks so much.. I would like to comment..
I have a jsd60 and cm8, so can test against them. Just playing with them after getting your info..

If port 80, 10001 are open and some other common ports closed 21,22 I will assume its a USL device and attempt to hit /ConfigFlash.html

Why... as because it appear to be the best way to get a reliable read on exactly what the device is. JSD100, JSD60, CM8. as it states it in the first line (in a comment) the device type.
If CM8, get firmware from the same first line. (No ver command) ie

# USL CM-8E s/n 852 Configuration Data
# PIC Firmware Version: 140801 <-- will need to pickup this value here from a comment.. does not appear anywhere else.
cm8.sys.serial_number 852
cm8.sys.theater_name digitAll QC Screen
cm8.sys.theater_number 1
cm8.sys.auditorium 1


If a JSD60/100 I can then hit port 10001 with a jsd[60,100].sys.ver to get the version info ie
jsd[60,100].sys.ver
E 141205 141218 141014 140811
main PCB version (a letter), the bootloader version, the PIC application version, the DSP version, the front panel firmware version

Plus pick up a few other variables that would be helpful such as
jsd60.sys.theater_name digitAll QC Theatre
jsd60.sys.theater_number 1
jsd60.sys.serial_number 3664

Are there other devices we could add here I am unfamiliar with?

Otherwise.

Sound like a goof path to you Harold?
James