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

[James Gardiner]

Hi all,
I am looking at the next tool to develop for the cinema-catcher-app. That being a tool to do auto-discovery of equipment on a network.

In looking into this, obviously, I turned to the industry standard "nmap" tool.
This is an amazingly powerful tool in which scripts are used to do all the smart "DETECT OPERATING SYSTEM" and other features.
This is done by adding scripts written in "Lua". These script can, as an example, be run if certain ports are open (I.e. giving you a fingerprint of what the device is most likely), then query those ports in an attempt to figure out in detail what the device is and possibly query for versions. if at all possible without authentification.

I plan to use nmap to create an easy to use tool for cinema-catcher-app, but I was thinking, this would be great for the general cinema community to also benefit from this. The more technically focused cinema techs out there could also leverage this tool in their own scripts/software.

I plan to create a few scripts in the next week for detecting a few devices, but I was wondering if others would also contribute. By looking at pre-existing scripts, extend them to other devices I don't have to test against.

Would appreciate some feedback from other cinema techs.

[Marcel Birgelen]

Keep in mind that some gear, especially old-school gear like a Dolby CP750 or CP650 may not appreciate being battered by all kinds of IP requests and may even die completely. I've not yet let loose nmap on a cinema network, but I did get blasted once, because I killed someone's PDP-11 with an nmap scan .

[James Gardiner]

Keep in mind that some gear, especially old-school gear like a Dolby CP550 or CP650 may not appreciate being battered by all kinds of IP requests and may even die completely. I've not yet let loose nmap on a cinema network, but I did get blasted once, because I killed someone's PDP-11 with an nmap scan .

A basic SYN scan to detect live ports does very little to effect any devices. I assure you it's harmless if limiting the scripts run against the scan to well behaved ones as is expected here.

If using the larger intense analysis scripts, it can cause a headache for things like printers. (For example makes my printer print junk.) But the intention is to create a set of scripts that only affect Cinema type equipment and in a very harmless way. For example, looks like a X-Sound Processor as port X is open, send commend to read version. done.

A syn scan basically sets up a socket connection and cancels it before it's fully established, and generally does not even hit the logs.. and is mainly an in kernel/memory response.So has next to no effect to the target host. (Nothing more than a ping response in come ways)

[Marcel Birgelen]

I guess you live in a world, where all IP stacks are created equal.

I've not yet fired an nmap on a Dolby CP650 cinema processor, I'm pretty sure a bunch of SYN packets alone would be sufficient to do some potential harm on ongoing communications. It will probably not crash the device, but it could disrupt any communication between server and processor. Why? The thing handles TCP connections on a single-thread basis. So, once you send a SYN on an open port, chances are that nobody else will be able to send commands to the poor thing, until it has timed out. The CP750 will probably be fine though, their TCP services seem to be properly multi-threaded.

Not that long ago I've seen similar stuff with some wonky lightning controller that was "IP controllable". If you opened a TCP session to the control port with Telnet, the thing would crash, burn and reboot...

[James Gardiner]

A syn scan does not open a port. It basically asks if a port is available to be opened then says forget it. Like I said, typically does not get logged as it does not get that far. Not even to open a port. It's a low level very initial packet that asks if a port can be opened first.
like I said, it's has as much effect as responding to a ping.

Yes a single threaded piece of crap device may be slowed by this but still it is not expected to case a loss of traffic.

If find it hard to believe something that marginal would be expected to be reliable in a projection system. it's not fit for purpose.

[Marcel Birgelen]

Unfortunately, stuff "not fit for purpose" quite often makes it into customer environments. Let me give you some examples:

Just today I had a device that monitored the temperature of the walk-in fridges at their site, which had been dumped into the wrong VLAN by the installer. The thing is a complete piece of crap. The web interface is a complete joke and after we changed the IP address from DHCP to an IP in the right subnet and moved it to the right network, it didn't want to come back on-line. The installer needed to do a "factory reset", apparently only "DHCP" is supported...

A while back, we operated a NetApp Metro storage cluster between two of our sites. Those things cost as much as a nice house in the suburbs a piece. The fibrechannel storage switches they provided died when we pinged them too often... yeah, a simple ICMP request every 30 or so seconds would eventually kill them... An SNMP read every 30 seconds would kill them even faster... The system could not be upgraded, because of a whole shitload of dependencies as dictated by NetApp, so essentially there was no way for us to monitor those switches...

A SYN packet is an initial request to open a port. If the server issues an ACK response, that essentially opens up a socket on the server, listening for more traffic. If nothing happens afterwards, the socket will time-out and get closed. A SYN flood is still a pretty effective way to overwhelm many servers with half-open connections, especially the embedded kind of appliance with just very limited resources.

Personally, I prefer to connect a CP650 via serial, because the Ethernet remote control implementation is wonky and known to skip commands issued to it. Still, there are quite a few CP650s around. Maybe, if I get the time somewhere this week, I'll spin one up and have a look how it behaves when it gets hammered with an nmap.

[Leo Enticknap]

The CP650's LAN interface is so bad that I've had to use Xeta servers to command them via IP from the source device, into the RS232 port of the CP650. Device lockups and missed commands ended after I did so.

[James Gardiner]

All this detail is great as it can be documented in the README of the GitHub repo this is stored.

[Steve Guttag]

Yeah, the CP650 port is "fragile." As some may recall, when the CP650 originally shipped, it wasn't even active. It gets flooded EXTREMELY easily. Note, even the CP650 software doesn't use the Ethernet port as an option, just the serial port. It does only accept one device at a time and if you have a DSS server in there, it will take that one and only position. It can withstand about a once per second poll/command and that is about it.

I too have used RS232 to LAN converters to allow for other devices to communicate with the CP650 since most of our installations with them also have DSS servers.

[Mark Gulbrandsen]

Yeah, the CP650 port is "fragile." As some may recall, when the CP650 originally shipped, it wasn't even active. It gets flooded EXTREMELY easily. Note, even the CP650 software doesn't use the Ethernet port as an option, just the serial port. It does only accept one device at a time and if you have a DSS server in there, it will take that one and only position. It can withstand about a once per second poll/command and that is about it.

All Dolby had to do was throw in a Realtek Network chip and the thing would have worked fine. Cost might have been a quarter... The Realtek chips are found on almost every mother board in exitance.

[Marcel Birgelen]

Realtek chips alone wouldn't have solved the problem, as the problem is clearly in the firmware. Implementing a TCP server that can handle just one session is asking for trouble. Either the folks at Dolby back then had no clue about how TCP/IP works or the resources on the CP650 board are so extremely limited that everything had to be done in one single thread. But even then, the "select" call has been implemented on many system and allows to handle multiple sockets/sessions in a single-threaded fashion. Some stuff I've written uses just a main-loop and can handle thousands of parallel sessions thanks to a bit of optimization and the usage of something like the "select()" call available in any UNIX-style system and many realtime stuff including VxWorks.

[Steve Guttag]

Again, when the CP650 was developed, the Ethernet port was a "future" item. It wasn't even active as most automation systems were contact closure with the "advanced" systems being RS232. I'm sure the Ethernet port was given near zero time as a "someday" sort of thing.

[Mark Gulbrandsen]

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.

[Harold Hallikainen]

The future support for Ethernet is something we did on the JSD-80. We had it on the backplane, but did not initially have hardware or software support on the control card. Eventually we added a daughterboard to the control card that had an Ethernet chip (MAC/PHY from Microchip). It had an SPI interface to the microcontroller. We then used Microchip library code to do the TCP/IP stack, web server, etc. A similar approach was used on all the later products I worked on. These are all "bare metal" firmware with no operating system. The CMS and related products (including a couple immersive sound processors that were OEM for other companies) used multicore processors and linux. MUCH more powerful (and complicated).

In the Microchip TCP/IP code, each socket took a chunk of RAM. I had to balance resources. I think most of the systems I did would support 5 simultaneous connections.

Harold

[William Kucharski]

Even today there is at least one home cable modem that will often require a reboot if subject to too much local network activity, like a port scan.