Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Expect.pm CTRL Characters not being recognised by remote device

by set_uk (Pilgrim)
on Apr 11, 2007 at 11:08 UTC ( [id://609336]=perlquestion: print w/replies, xml ) Need Help??

set_uk has asked for the wisdom of the Perl Monks concerning the following question:

I have a utility which uses Expect.pm to send commmands to telecomms devices. It works really well most of the time but in some instances i cant get the end device to recognise the control character sequence to disconnect from the device.
I'm quite conversant with the Expect syntax for sending control characters and have tried various permutations but to no avail.
When logged in manually to the device when you type:-
CTRL (keep pressed then press) p d t It works.

In expect if i send - ^cp^cd^ct - it sends ^P^D^T and doesnt disconnec +t me. If i send \020\004\024 it sends ^P^D^T and doesnt disconnect me.

Ive also tried sending it using ->send_slow - but its not being recognised.
This is running from a Solaris box with TERM=vt220 - telnetting into a Windows telnet server and then using putty plink to rlogin into a remote switch.
A colleague of mine uses the same connectivity and an Aspect script to connect to these devices for a different purpose and to disconnect uses the sequence:-
TermKEY Ctrl 'p' TermKEY Ctrl 'd' TermKEY Ctrl 't'

I wonder if anyone else has had an issue with control characters not being acted upon correctly and what their resolution was.
Regards Simon

Replies are listed 'Best First'.
Re: Expect.pm CTRL Characters not being recognised by remote device
by BrowserUk (Patriarch) on Apr 11, 2007 at 11:19 UTC

    In the manual sequence, you show 'P', 'd' & 't'. Although you indicate that you continue to hold the control key down, as there is no such thing as a lower case control character, it seems likely that the device sees '^P' followed by 'd' & 't'.

    Try sending "^Pdt" (in the appropriate way), and see what happens?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      That was actually my initial attempt ^cpdt - which was sent as ^Pdt - this also didnt work. I believe the device needs ^P^D^T since this is what works manually and also via Aspect.
Re: Expect.pm CTRL Characters not being recognised by remote device
by sgifford (Prior) on Apr 11, 2007 at 14:55 UTC
    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!
      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
        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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://609336]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (2)
As of 2024-04-20 05:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found