[rancid] Re: 'out of band' access script changes?

[Ed Ravin]

On Mon, Nov 20, 2006 at 03:33:22PM -0500, Sherrill, Justin wrote:
> Going by your example, it doesn't work, as the spawned process doesn't
> get a target router passed to it

Yes, I forgot the router argument won't get automatically generated as
it normally does for clogin.  But I see you figured that out already...

> As I understand it, the usercmd option that's been patched in supplies a
> new connection method for whatever server's being accessed, so I tried
> constructing this line:
> 
> add usercmd    192.168.249.11  {cmtslogin} {-c} {telnet 192.168.249.11}
> {192.168.248.1}
> 
> Am I correct in that this should say "Connect to 192.168.248.1 and issue
> 'telnet 192.168.249.11', in order to connect to 192.168.249.11"?
> 
> It works in that it eventually connects to the remote device, but the
> two connections seem to spawn and run in parallel - i.e. I see the
> username and password for the second device getting printed out while
> the first device is being logged into.
> 
> Has anyone done this in practice?  I'm wondering if I'm just
> syntax-impaired.

As far as I know, you're the first one to chain clogins together like
this.  It's been only an academic discussion until now. :-)

I'm guessing that clogin#1 sees the login dialogue of clogin#2 logging
into the gateway router, and thinks that is the login prompt of the
far-end device.  To fix that, we need some way for the patched clogin
to detect that you've gotten past the telnet command of clogin#1.  The
usercmd_chat feature should work for that.  Maybe if you match the
first Cisco's telnet command, like this:

  add usercmd_chat 192.168.249.11 {Trying.*192.168.249.11} {}

This waits for the "Trying" message Cisco's telnet command prints
just before connecting, and sends an empty string, then exits
chat mode and returns to the normal clogin login prompt detection
stuff.

If that fails, run the clogins with debug options and see if you can
find some output just before the far-end router's Username: prompt
to match.  If the far-end router has a login banner that is distinct
from that sent by the gateway router, you could try matching on that.

	-- Ed