control char with cli_exec

[dmitry]

Hi,

I'm trying to put together an EEM based TCL script for a "call home" like feature (if a client's VPN router behind NAT is not reachable via VPN tunnel, the router would get the backdoor open from inside to netcat), all works except passing control chars (ctrl-C, ctrl-Z, up arrow, etc), I see the commands arrive at TCL via a socket properly encoded (regexe properly identified utf-8 or octet coding), however when passed to CLI using cli_exec or cli_write, not treated as controls.

The TCL opens a TCP socket to xinetd with NCAT without any TELNET negotiations

The absence of the controls is not a huge issue, more like "nice to have"

appreciate any feedback

[Joe Clarke]

Can you share your code?  Control characters definitely work on a socket, but if you have to go through the CLI, you may have to use some tricks to pass them along.   It would be useful to see what you have now.

[dmitry]

Sure, the tcl script is attached. The way it works is a VPN router runs the script on EEM cron every 15 min. the script opens a socket to a jump server's xinetd on tcp 80, xinetd starts a shell wrapper around ncat (the one that comes with nmap). The launched instance of ncat starts listening on tcp 8001 - 8999 (the wrapper finds an available port for it from the given range, also collects the router's name and logs in a file). At this point an operator can telnet to let's say 8001 on the jumper box and get cli of the VPN router

[Joe Clarke]

So is Ctrl+C/Z coming through as binary from the socket?  What other things are you trying to send?  Are you trying to do a send command or something within config mode?  If they are coming through in binary, you might try special casing them, and send the literal character using Ctrl+V+Ctrl+Z/C.

[dmitry]

in the fconfigure tried -encoding binary, utf-8, no -encoding, does not seem to make any difference

had a temp regexe;

} else {

set data1 $data

+ if {[regexe {(\u0010|\u001a)} $data1 ]}  {

 + ....

# the $data1 came from the socket, the unicode properly matches to the pressed keys on the client: \u0010 - ctrl-P , \u001a - ctrl-z. $data1 then gets to cli_write and gets echoed (clie_read_drain) as CC8

regsub -all {[\n\r]+} $data1 {} data1

will try the ctrl-V escape

[dmitry]

update:

the ctrl-Z (\001a) seem to work (even without ctrl-V prepended), although with a bit of decoded garbage: it goes to cli_write as C?C8^Z, the cli_read_drain returns:

call    call-history-mib  call-home  cdp
cef     chat-script       class-map  clock
cns     config-register   connect    control-plane
crypto  cwmp

testrtr01(config)#                   ^
% Invalid input detected at '^' marker.

testrtr01#
testrtr01#

Nov 13 10:53:28.449: %SYS-5-CONFIG_I: Configured from console by  on vty0 (EEM:eemcat.tcl)

so, CLI takes the first C as the beginning of the command then evaluates ^Z and gets out of config mode 

The ctrl-V (\u0016) is not working,

The ctrl-P (\u0010) or up arrow (\u001b[A) no working with ctrl-V (\u0016) pre pended or without:

with ctrl-V in front getting

% Bad IP address or host name
% Unknown command or computer name, or unable to find computer address

without, no output

giving up on this

On the other note, is there a way to make cli_read* async, so it could read debug messages as they show up. If I put it in while loop, it will block the socket's fileevent (or is it even possible to have more than one vwait forever in tcl)?

Thanks

[Joe Clarke]

I had kind of meant like special casing things in your callback, then doing:

cli_exec $cli1(fd) "Ctl+V+Ctl+Z"

Where those are the literal characters you typed into the text file.  Make sense?

Unfortunately, no, cli_read is sync.  I have requested this to be more of an async thing or at least something you can time out, but that has not been implemented.

[dmitry]

nope, did not work, intercepted ctrl-p (\u0010) (same as up arrow action) and replaced with "Ctl+V+Ctl+P", then "Ctrl+V+Ctrl+P", then just "Ctrl+P", the CLI evaluates it with 

% Bad IP address or host name
% Unknown command or computer name, or unable to find computer address

in return

Thanks for the info about cli_read, the async option would have been very handy