Debugging telnet remote control problem?

[dbn]

It's been a couple of years since I last used telnet remote control between two PCs, and I seem to have forgotten the recipie. I'm looking for some assistance in troubleshooting.

I'm running SCS 11.2.5 on Windows XP. The remote control program is LightFactory on a separate but similar Windows XP system. PING works fine between the systems.

If i use the built-in Windows command line telnet client, to conenct to the remote system, I see the commands come across just fine, e.g.scsGo ("1').

If I use the Test Telnet Control feature tha appears on the Cue Control Devices tab of the Production Properties, nothing displays. And, of course, the cue doesn't fire when not using the Telnet Test window.

SCS announces in a banner at the bottom of the screen that it has connected to the remote host, e.g., 192.168.125:3100.

Netstat -a on the remote system shows the active tenlet session from the SCS host.

I'm pretty sure the telnet server on the remote system, is fine. LightFactoiry has been seen to be sending the requisite commands. SCS seems to be configured correctly, based on the connection announcement banner and the netstat results. I'm at a loss as to what I might try next. The show is teching this week and opening on Friday. Thanks, in advance, for any assistance.

[Mike Daniell]

I haven't used LightFactory so can't give you first-hand advice about the setup, but could you email me an SCS diagnostic dump file? You can create this file by selecting 'Create Diagnostic Dump File' from the drop-down menu displayed when you click the Help button in the main window. The file will be saved in a folder named "SCS Dumps" under "Documents" or "My Documents". For the LightFactory Telnet configuration, a screenshot of the LightFactory Telnet setup screen would also be useful.

If anyone else has used Telnet control of SCS from LightFactory, perhaps you could help Dave.

[BCGTech]

Hey Dave - It's been a long time since we last corresponded

The secret to getting LightFactory to send telnet commands to SCS is to set up SCS as a telnet server listening on port 3100. It seems LightFactory does not honor the port number set in the "System Properties" window and always connects with port 3100. SCS has a different default port number, but if you set the listen port to 3100 it should work. I just tested this with SCS 11.2.4 running on an XP system and it worked just fine.

Hope that does it for you.

Bruce (formerly known as Theatre III Sound)

[BCGTech]

Continuing from my last reply...

Some more thoughts:

I missed from your original post that you had already set up SCS to listen on port 3100, so I guess that's not your problem.

The only other thing is when I set up my test, I did get a message from Windows Firewall asking if I wanted to let SCS accept connections, but again if you can send commands from a telnet app, then it should work with LightFactory as well.

What was the exact string you sent SCS for the go? The syntax is scsGO("<cue>"), where <cue> is the cue number string (like Q1) not just the number or 0 (as in scsGo("0") ) for a general Go command. The telnet test window doesn't show anything unless it receives a legitimate SCS command.

Hope you can get it going.

Bruce

[Mike Daniell]

Bruce/Dave,

Dave sent me the diagnostic file and I noticed he had SCS set up as a Telnet client, not server (as Bruce correctly advised). So I've asked Dave to change the Telnet Role to 'server' in SCS. Hopefully that will fix the problem. Glad to have your confirmation of this approach, Bruce.

In SCS 11.4 I am changing SCS to remove the 'role' selection because for Cue Control (Telnet receive) SCS should always be a 'server' as it is required to act upon messages sent by a 'client' (such as LightFactory). The reverse is the case with SCS Control Send cues (Telnet send), where SCS is always technically a Telnet 'client' that sends commands to be acted upon by a separate 'server'.

[dbn]

In SCS 11.4 I am changing SCS to remove the 'role' selection because for Cue Control (Telnet receive) SCS should always be a 'server' as it is required to act upon messages sent by a 'client' (such as LightFactory). The reverse is the case with SCS Control Send cues (Telnet send), where SCS is always technically a Telnet 'client' that sends commands to be acted upon by a separate 'server'.

As I mentioned in a reply email, please (pretty please) don't do that. As a long-time network software and protocol developer, with many years of experience in the industry, the IETF and IEEE standards organizations, I can say with assurance that the Telnet client and server roles are completely independent of which end of the connection (session) is the primary sender and which is the primary receiver. Telnet provides symmetrical, bi-directional communication, like a phone call. The client is the one who "dials" and the server is the one who "answers', but during the call, each end can speak freely to the other. It's just a two-way pipe. Having the ability for SCS to act as either client or server is a very valuable product feature, and removing it may inhibit interoperability with other products, such as Light Factory.

[dbn]

The secret to getting LightFactory to send telnet commands to SCS is to set up SCS as a telnet server listening on port 3100. It seems LightFactory does not honor the port number set in the "System Properties" window and always connects with port 3100. SCS has a different default port number, but if you set the listen port to 3100 it should work. I just tested this with SCS 11.2.4 running on an XP system and it worked just fine.

Hi Bruce! AFAICT, LightFactory only operates as a Telnet server (listener). I don't see any place to put the remote host (server) address, just the listener port number. The ability is there to configure the remote peer for the "live tracking backup" feature of LightFactory, but I think that's completely separate from the remote cueing feature. Of course, I might be wrong.

I configured SCS to connect as client to LightFactory using IP: 192.168.1.125 Port:3100. A "netstat -a" command on the LightFactory host shows an established telnet connection coming from the SCS host IP: 192.168.1.126 Port: XXXX (OS assigned transient port number). So, that tells me the SCS client is doing the right thing. However, the Test Telnet Connection window in SCS shows no characters coming from LightFactory, while a Windows telnet client utility terminal window shows the scsGo("x") commands.

IIRC, I have used the telnet link in the past with SCS as client and LF as server. It shouldn't matter which end open the session. Right?

[dbn]

The telnet test window doesn't show anything unless it receives a legitimate SCS command.

Ah, that's a valuable clue. Thank you! I didn't know that. I assumed it was just a display of the raw telnet stream. I think I'm using the correct syntax: scsGo ("x"). Not sure about the space character between o and ( though. The documentation says the command is not case sensitive. I'll double check the "space" character issue. That could be the whole problem.

[BCGTech]

As I mentioned in a reply email, please (pretty please) don't do that. As a long-time network software and protocol developer, with many years of experience in the industry, the IETF and IEEE standards organizations, I can say with assurance that the Telnet client and server roles are completely independent of which end of the connection (session) is the primary sender and which is the primary receiver. Telnet provides symmetrical, bi-directional communication, like a phone call. The client is the one who "dials" and the server is the one who "answers', but during the call, each end can speak freely to the other. It's just a two-way pipe. Having the ability for SCS to act as either client or server is a very valuable product feature, and removing it may inhibit interoperability with other products, such as Light Factory.

Dave,

I don't think Mike is advocating removing any code, just the selection option since there are separate tabs for control send devices and cue control devices. If you're setting up a cue control device, SCS will use the server function to listen for a connection from an external source and then establish the two-way link. If you're setting up a control send device, then SCS would initiate the connection to the service that's going to receive the commands.

Here's the way I set up LightFactory (LF) and SCS so I could trigger sound cues from LF:

On the SCS side: Set telnet In as a cue control device and set the "role" as server listening on port 3100.

On the LF side: I set up some shortcuts to connect to the SCS computer and send a generic 'Go' or if needed specific SCS cues. The connect shortcut would execute the LF command CONNECT <ip address>, (note: no port # - CONNECT uses port 3100 and there's no option to change it). The generic 'Go' shortcut would execute SEND scsGo("0"). I included the connect shortcut in Cue 0 so the connection would happen at the beginning of the show. The send shortcut would then be included in any cue that needs to trigger a sound.

The above setup should work, but in practice it's better to have LF trigger specific cues rather than send a generic 'Go' since it's too easy to get the two out of sync, especially if there are manual SCS cues being triggered by an operator in addition to the LF triggered ones. SCS now supports a cue activation type of "External (Trigger)", so what I tend to do is create cues "T1", "T2", etc. and hide them from the cue list (optional) to separate them from the manual cues. Another method is to make the external cues "Hot Key" cues, so you can fire them manually or from LF. This helps during rehearsals if you haven't quite got the exact coordination between LF and SCS set up yet.

I hope the above works for you. I've used it for several shows with good results.

Bruce

[dbn]

If you're setting up a control send device, then SCS would initiate the connection to the service that's going to receive the commands.

I understand the concept. I just disagree that there is a meaningful relationship between primary data flow (producer vs. consumer) and Telnet client vs. server roles. It's just a data pipe.

The connect shortcut would execute the LF command CONNECT <ip address>, (note: no port # - CONNECT uses port 3100 and there's no option to change it).

Cool. I had no idea that was possible.

My practice has been to configure SCS as the Telnet client and LF as the Telnet sever, because that can happen from the LF System Properties menu, and it doesn't require the creation of any shortcuts. I put the SCS commands in the "notes" field of the corresponding LF cues, and enable the "Send notes content to telnet peer" option. Personally, I think it's a simpler method. YMMV. It has worked in the past, and in this case I *think* the problems is that I put an extraneous space character in the SCS command string. I'll be able to verify that later tonight.

[dbn]

So, I was wrong about the SCS command format being the (only) problem. Feedback from the techs at the theater says removing the extra space character didn't fix the issue. I've been able to validate that locally on my laptop using a telnet connection via the localhost IP address (127.0.0.1). Once again, Windows telnet client displays the command coming from the telnet server on LF. The SCS acting as telnet client does't react to commands or display them in the Test Telnet Control window. In this case the SCS version is 11.3.3.2. In both cases the LF version is 2.15.1 Build 55.

I'll next try reversing the telnet roles, based on Bruce's suggestion of how to launch a client side telnet connection form LF via a command.

(I theoretically have other options available, such as using MIDI and DMX control, but the systems at the theatre are only currently interconnected by Ethernet.)

[dbn]

Ummm... That didn't work, either. The difference is in this case I see SCS LISTENING on port 3100, until I issue the LF command CONNECT 127.0.0.1, at which time is see the two processes with an ESTABLISHED session on port 3100. Once I send some commands to SCS, the state of that session changes to TIME_WAIT.

With SCS in telnet server role, I connect using the Windows telnet client utility (> telnet 127.0.0.1 3100) and type SCS commands (scsGo("1")) manually. Same non-reactive result in SCS. Is there any reason that would be an invalid test?

[dbn]

Another data point: SCS version 10.9.6 works just fine with LightFactory, with SCS playing the telnet client role, in exactly the way I remember it working. So, I know that version was released was a looong time ago, but something has changed that prevents the Telnet remote cuing from working the way it used to. (Sigh.) It's possible that I haven't tried using Telnet remote cue control since I updated to version 11.*.

[BCGTech]

With SCS in telnet server role, I connect using the Windows telnet client utility (> telnet 127.0.0.1 3100) and type SCS commands (scsGo("1")) manually. Same non-reactive result in SCS. Is there any reason that would be an invalid test?

Is the cue you're trying to trigger actually labelled "1" and not "Q1" for example? You need to send the exact label string, like (scsGo("Q1")) to trigger a specific cue. The exception is the generic Go which is (scsGo("0")) which will trigger whatever the next manual cue in the stack is.

I just tried running LF and SCS on the same PC and connecting via localhost (127.0.0.1) and it worked just fine for me.

Bruce

[dbn]

Bruce, what version are you running?