An interesting telnet IP issue

Kenny

I recently needed to control a device via IP.
I programmed the usual IP_Client_Open(3,'192.168.14.181,54774,1), downloaded and waited for the port to come online. Everything seemed fine.
Via telnet I sent the properly formatted string which I double/quadruple checked but nothing worked.
2 hours later I decided to add the send_string to code and send it via a normal Button_Event.
SUCCESS!!!
It seems that you can not send strings out ethernet when those strings come from a telnet client.

Hope this helps someone else

Kenny

a_riot42

Kenny wrote: »

I recently needed to control a device via IP.
I programmed the usual IP_Client_Open(3,'192.168.14.181,54774,1), downloaded and waited for the port to come online. Everything seemed fine.
Via telnet I sent the properly formatted string which I double/quadruple checked but nothing worked.
2 hours later I decided to add the send_string to code and send it via a normal Button_Event.
SUCCESS!!!
It seems that you can not send strings out ethernet when those strings come from a telnet client.

Hope this helps someone else

Kenny

Not sure I understand. I have code that sends strings to telnet clients without issue.
Paul

Hedberg

He opens an ip client in his program and then connects to the master via telnet and types:

send_string dvIP_Client,'Some Damned String'

and it doesn't work.

If you have an rs232 port and connect to the master via telnet and type:

send_string dvRS232Port,'Some Damned String'

you get 'Some Damned String' out the RS232 port. Not so with an IP Client port.

Auser

I'm pretty sure that if you use the D:P:S address of the device instead of the device name the string will get sent to the socket.

Kenny

I'm pretty sure that if you use the D:P:S address of the device instead of the device name the string will get sent to the socket.

You can not use device names from Telnet.
I have tried using 0:3:0 and also just the port number without the D or S.
This is only an issue during development and debug. It works fine when sent from code.

Colzie

Kenny wrote: »

You can not use device names from Telnet.

Perhaps for IP devices (I haven't verified), but you definitely can use device names from Telnet for other devices.

tracktoys

So you have some code that opens the desired port of a third party device you want to control (I assume). You load the code and wait awhile. You then open a telnet window in NS and try to send the string from there to test the device and get nothing? After you load the code, are you tracking the online/offline status with a variable? How have you verified that the connection was accepted before trying anything through NS telnet?

Could you use a third party program like Hyperterminal to test strings and such? Might be less work if that's all you need to do. It sounds like you've isolated a short-fall of NS telnet? I have only used it for communications to masters and have not had any issues to date. Pretty convenient actually (thanks AMX).

Kenny

Wasn't using NS Telnet. I used PUTTY and MS Telnet. Neither would work.
I could use telnet and send strings out a serial port.
I was able to telnet into the IP device to be controlled and that worked fine.
The way that I knew it was only was by turning a relay ON when I got an online notification. It turned the relay off when the port was closed.

Joe Hebert

Kenny wrote: »

Via telnet I sent the properly formatted string which I double/quadruple checked but nothing worked.
2 hours later I decided to add the send_string to code and send it via a normal Button_Event.
SUCCESS!!!
It seems that you can not send strings out ethernet when those strings come from a telnet client.

The problem is not just with telnet, it?s IP comms in general. The real issue is the lack of any built-in diagnostic tools for sending and monitoring IP traffic.

When you connect to the master via telnet and try to do a Send_String to an IP port from the command prompt, in essence it?s the same thing as trying to do a Send_String to an IP port with Control A Device via Netlinx studio. We aren?t allowed to do this. I?m not sure why we?re crippled this way, maybe it?s a security thing?

I?ve done something like the following in the past.

DEFINE_DEVICE

dvIP = 0:3:0

DEFINE_VARIABLE _

VOLATILE CHAR cTest[128]
VOLATILE INTEGER nSendIt

DEFINE_PROGRAM

WAIT 5 {

   //assuming the code to open the port is already in place
   IF (LENGTH_STRING(cTest) && nSendIt) {
   
      SEND_STRING 0, "'Out the door: ',cTest"
      SEND_STRING dvIP,cTest
      nSendIt = 0
   }

}

I turn debugging on and then I drop cTest and nSendIt into watch variables. When I want to send a string I modify cTest as needed and then set nSendIt to 1.

It?s only a few lines of code and you don?t have to bother with setting up button events and then emulating them just to fire off test strings.

HARMAN_shane-a-roo

This limitation is due to the architecture of the master. By entering control commands in a Telnet session (or Control a Device in NetLinx Studio) you tap into the master controller's device management component and effectively bypass the NetLinx Interpreter. You're actually spoofing the commands that would be coming from the NetLinx Interpreter. The problem is that IP functionality is completely contained within the NetLinx Interpreter. The device management component has no knowledge of 0:x:0 devices. So attempting to have any control over these devices externally (telnet, Studio) is futile.

cbutcher

I have been able to send commands to IP devices using the device name and have it do what I want.

What I ussually find is that it boils down to proper formatting of the command. Couple of examples are:
Icluding a "GET " if your device uses GET posts.
Or adding a needed <CR><LF> or what ever your device wants. I've seen several combinations includeing <LF><LF>, <CR><CR> as well.

Once you define your device and open the port via normal methods you should be able to enter something like this from Telnet:

SEND S dvDEV_NAME,"'SOME COMMAND',13,10"

DHawthorne

It seems it depends on the device. I have many, many times sent commands from Telnet with no difficulty to various devices, but just recently had a device where it simply would not work. I thought I had the wrong protocol, until I realized it worked just fine from code. I have to think it's a timing issue, and the command simply isn't recognized at the speed the Telnet client sends it.

chill

shane-a-roo wrote: »

This limitation is due to the architecture of the master. By entering control commands in a Telnet session (or Control a Device in NetLinx Studio) you tap into the master controller's device management component and effectively bypass the NetLinx Interpreter. You're actually spoofing the commands that would be coming from the NetLinx Interpreter. The problem is that IP functionality is completely contained within the NetLinx Interpreter. The device management component has no knowledge of 0:x:0 devices. So attempting to have any control over these devices externally (telnet, Studio) is futile.

Thanks, that's very good to know; I've been dealing with a similar issue. My only question is "why doesn't Tech Support know this?"
.