Re: Expect.pm CTRL Characters not being recognised by remote device

[sgifford]

Three thoughts.

• Since this is all going over an unencrypted network session, you should be able to use a packet sniffer (like tcpdump or the GUI sniffer formerly known as Ethereal) to see exactly what is being sent. That should tell you definitively whether your script is sending the right thing or not.
• I'm not that familiar with Expect, but a quick look at the documentated method of sending control characters shows a different syntax than you are using. This syntax might be worth a try, even if the one you are using is also valid.
• Sometimes when sequences are meant to be sent by hand, they require a short pause before, after, or between the characters being sent (for example, many modems will do this with +++ to stop outgoing IP packets from sending a modem escape).

Good luck!

[set_uk]

All good points. I tried using the send_slow capability of expect to add a 1 sec delay between each character - didnt make a difference. Within my script the syntax does conform to the same as in the doc. With debug(3) discovered the following :-

Sending '\020\004\024' to spawn id(4)
Expect::print('Expect=GLOB(0xd67aac)','\x{10}\x{4}\x{14}') called at S
+DU/CommandIteratorSDU.pm line 1076

In the unix nutshell book i have:-

character  octal hex
ctrl p     020   10
ctrl d     004   04
ctrl t     024   14

So its sending the sequences as hex and the conversion looks good. Time to sniff the packets

[set_uk]

Managed to sort it by sniffing the packets. Wasnt the perl script it was the mode that telnet was running in - needed to be character mode - not line mode. Thanks for all your help