thanks for the response -

Your understanding is spot on - I am wanting to allow a user to access a router and immediately be passed back (via reverse-telnet) to a modem...  From there, I'd like to intercept the dial string BEFORE the modem is able to act on it.  All of this is alredy in place (except for intercepting the dial string).  From what I am hearing, this is not possible....

I have found that I can (using the 'send' cli command) initiate a dial to a modem from the CLI of the hosting router (once the reverse telnet session has been established) and that seems to work (manually - I have not tried to do so using EEM) -- so if I telnet to the device - get passed to the modem, and then hit 'ctrl-shift-6 x' to get back to the router - and from there type 'send tty xx' (xx being the tty line #) followed by a dial string, it does seem to dial out...

I guess the key is - I will be unable (or better stated, EEM will not be able) to 'see' any results on that tty - correct?

If all of this is correct, then it sounds as if I need to rethink what I have been doing.. .Instead of passing the user to the modem and allowing them to dial, I need to trap them into a menu, receive the dial string and inspect it.  If acceptable then initiate the reverse-telnet and pass the dial string using the send.  My main concern now would be a failure to connect would likely result in the user sitting on the modem and again able to dial manually (and perhaps dialing one of the incorrect numbers...)  My new goal would be to pass the dial string and upon failure immediatly be passed back to the router CLI (not sitting on the modem)

If you could pls confirm that there is no way for me to see what response may be presented on the TTY that would at least be helpful in knowing I can't rely on that.  If I am able to see the response, then I may be able to watch for a list of keywords that indicate a failed dial (no carrier, busy, etc) and kill the reverse telnet (from eem) hopefully presenting the user with the menu again...

I guess in a way I feel redeemed by there not being a simple and obvious way to do what I want - I have been searching and searching and not finding what I need... at least I now know why :)

thx Rob

You can intercept the starting telnet or send commands, then interact with the terminal and record all of the output.  However, you wouldn't be able to have the user interact with the terminal.

Said another way, you could design a custom command with EEM (e.g., dial) that invokes the reverse telnet session and dials a specific number that the user specifies on the command line.  Using THIS method, you would be able to do sanity checking on the data the user hands your policy.

So if I am reading you correctly, it would be possible for me to start the telnet and/or send command but after that - I would need to decide if the USER is to interact with the TTY or if EEM would interact?  If it is done such that EEM can record the output (and if he can record it, I assume he could act on it?) then the user would NOT be able to interact with that terminal?  And I assume there is no way to 'pass control back to the user' once a successful dial was confirmed?

As you state - I could come up with a custom command that does the reverse telnet + dial.. .My only concern is for a failed dial (perhaps the # was busy for example, or the user fat fingered the # resulting in RNA) the user being dropped on the modem and able to dial what ever number they wish. 

I guess - if I can't read and act on the response from the TTY (saying for example 'NO CARRIER' then I need to find a way to force the reverse telnet session to end after that dial - and I am not sure that is possible... :(

thx, Rob

Ah, I understand a bit more.  There is no way to do a send/expect like dialog where you leave the user interacting with the modem session.  You can either manage the end-to-end session for the user using EEM, or the user would need to do it.  You can't create a hybrid.

It sounds like what you want is more of an expect script off-box.

Honestly - I only care to the point where the user connects (modem to remote router)... 

My concern is with potential 911 calls....  I have some users with need to grab a line and dial internationally - so those calls are prefixed with 9,011<number> however --- I can see where it would be very easy for a user to accidentally enter 9,911<number> which obviously would be unacceptable. 

Once connected to the remote system I have no further need to monitor.  I just need to ensure that users can't accidentally dial a 911 number.  I wrote a policy that catches any combination (that I can conceive of) that would result in a 911 call, however it was written using a cli pattern event and obviously I learned that wont work if the user is already reverse-telnetted and sitting on a modem...  so I need to find a way to capture an offending call before it happens - and if the dial string is acceptable - establish the reverse telnet and pass the dial string...  I dont believe this will be too difficult actually - but my issue now is the circumstance where a user receives 'busy' or 'no carrier' etc and is left sitting on the modem (where they will no doubt enter 'atdt 9,<whatever> -- this time to my blind eye....

UNLESS I can find a way to kill the reverse telnet session as soon as the modem disconnects...  So that may be my next approach - I need to see if there is a way I can determine (from hosting router CLI) if/when the modem disconnects.  Once the modem disconnects, I need to disconnect the reverse telnet session. 

I can see where there may be a stat change that I am watch for using the cli command "show line xx" where xx = the modem line # - then parse out the state.  I know I could do this with internal modem, not so sure that I'll see a state change on an external modem...

any ideas would be happily accepted!

thx, Rob

I suggest you go with your CLI policy approach.  Have that policy install another timer policy before returning control to the user that uses a watchdog timer to look at the specific modem line to see if it changes back to hangup, then clear the line.  That's the best I can think of off the top of my head.

drew up a flow for that last night... 

the main roadblock I hit was the fact that apparently random text entered at the cli is not ALWAYS considered (by EEM) to be cli input - I had planned on spoofing the user such that he thought he was on the modem when in fact he would still be on the routers CLI - user would enter dial string (atdt 9,xxxxxxxxxxxxxxxxxxxxx) - eem cli policy with pattern match would be in place to intercept that command, determine if it is a valid number, and if so - perform the reverse telnet at that time, and send the $_cli_msg to the tty associated with this users modem.  What I found is that _cli_msg is empty unless it is a valid cli command (so modem commands/dial strings do NOT get captured).  Is there a variable that would contain this info (raw data entered onto CLI by user - without expanding into full CLI Command)?  I have not found one - at least not yet...

After finding _cli_result would not hold the dial string (so I have no way that I know of to capture that command using the method described above) I think I need to drop the user at a menu upon telnet into the router and provide option to set modem commands and enter OOB Number (setting them to variables).  Once the menu item to enter the OOB# is chosen, the menu will manually run an eem policy that would parse the dial string (to validate the number) and if the number is valid, perform the reverse telnet, then send the dial string to the appropriate tty line and end...

At the same time - have a timed policy that scans every modem ilne every 15 seconds (guessing that would be a good time - may have to tune it one way or the other)

I have found that the ONLY attribute I can find about the state of the modem connection is - when an active call is in place, DSR is raised.  If I have an active line (meaning there is a reverse netnet to the line) and the line has been active for more than say 30 seconds, and DSR is set to noDSR, then I need to kill the reverse telnet and notify user that the dial failed...  Otherwise it would appear they have a valid connection to remote device.

I am sure there are other hidden surprises that I'll stumble into - any holes you see pls feel free to comment on... 

If I do get this working, I'll post whatever I end up doing for benefit of anyone trying to do something similar...

I notice there is also EMM -- I have not messed with it - have setup simple menu's on a router before - not sure if there would be any added benefit of using EMM here or not - looking into that as well..

thx Rob

You can have EEM intercept random CLI commands by adding the keyword "enter" to your event registration line:

event cli pattern "my_command" enter

Right - I got that - and it works fine - the problem is that I can't then pull out what was entered.  I want to be able to pass that cli command (which might be something like 'atdt 9,17273334444' using the cli 'send' command.

problem is - that string (atdt 9,17273334444) does not seem to be in an environment variable (I was expecting it to be in _cli_msg, but it is empty -- running other tests then, if I enter valid CLI Commands such as a show command or whatever, _cli_msg is populated with the full extended cli command.  So - I can intercept the cli command, in order to trigger an event, but I have not found a way to then do anything with the command that was entered (because as far as I can tell - it does not seem to be in a variable I can call on).  Perhaps there is an attribute somewhere that would change that behavior (?)

thx Rob

The $_cli_line variable will give you the whole command entered.