Re: Telnet.pm and IAC

Replies are listed 'Best First'.
Re^2: Telnet.pm and IAC by PaulNg (Novice) on Feb 24, 2012 at 16:29 UTC
Hi thundergnat, Thanks for the responses. From the client's side I can send 2 FFs to escape the escape that's not a problem, the problem comes in when I readback data from the controller, I can't control the output from the WATLOW and it won't print 2 FFs! Basically I need to get the data as it is but since Telnet.pm or Fedora interprets the IAC as a command its not going to work :( Hi Khen1950fx I'm not entirely sure how the options work. For my script I'm currently using Net::Telnet() module. As I am quite new to Perl, how do I go about including the extra options module to my script? Thanks!	[reply]
Re^3: Telnet.pm and IAC by Corion (Patriarch) on Feb 24, 2012 at 16:48 UTC
If you cannot change the sending side, I think that using Net::Telnet is the wrong tool. Have you considered using simple plain sockets, via connect? All more specific layers will likely have problems with the data potentially containing delimiters. Also see Modbus. Especially Modbus::Client seems to be a potential solution, if you open the socket first and then pass it in to the Modbus::Client constructor.	[reply]
Re^3: Telnet.pm and IAC by thundergnat (Deacon) on Feb 24, 2012 at 16:54 UTC
Actually the problem is not with the Watlow but with the Digi CM-32. The Watlow is communicating to the Digi CM-32 in Modbus RTU which has no issues with \xff characters. See if there is some option you can set in the Digi CM-32 to allow "raw" data mode or some such. If not, you may need to implement your ethernet communication with raw TCP sockets using IO::Socket::INET, which is what Net::Telnet uses under the hood.	[reply]
Re^4: Telnet.pm and IAC by PaulNg (Novice) on Feb 25, 2012 at 04:32 UTC
Hi thudergnat, I agree, but now I'm not sure if it's the CM-32's busybox OS is the one interpreting the IAC or is it Telnet.pm on my PC that's doing it. I'm actually leaning more towards Telnet.pm causing the problem. I tried Khen's fix earlier it didn't work. The output did not change at all. TCP protocol isn't recommended because there are other scripts that require the CM-32 to be in Telnet mode rather than RawTCP. Any suggestions? Thanks!	[reply]