[rancid] Cisco Banner Issue

[Hans Mueller]

Hi,

I'm trying to migrate my rancid installation from one box to another.
Everything seems to work fine but there are login problems on some
routers (about 10 %). The problems seems to be the "motd banner". If i
try to login to these routers the login looks like this (the banner is
orginal, without any changes):
-------------------------------------------------------------
***@rancid(~)$ clogin g546.abcd.domain.net
g546.abcd.domain.net
spawn telnet g546.abcd.domain.net
Trying 172.24.999.999...
Connected to g546.abcd.domain.net.
Escape character is '^]'.
CC
**********************************************************
* *
* *
* Routername: g546.abcd.domain.net *
* *
* Kunde: Hans Mueller *
* Standort *
* Strasse 81 *
* 12345 Ortschaft *
* *
* *
* Ansprechpartner: Frau Mueller *
* Telefon: [phone] *
* *
* Kundennummer: 12436 *
* Auftragsnummer: XY#763743 *
* *
* *
**********************************************************


User Access Verification

Username:

User Access Verification

Username:
%
User Access Verification

Username: timeout expired!Connection closed by foreign host.

Error: EOF received
***@rancid(~)$

-------------------------------------------------------------

If i remove the banner, the login with clogin works fine. But i don't
want to remove the banner.

Rancid works fine on my old box but not on the new one.

Software versions:
Old debian box:
Rancid: 2.3.8
Expect: 5.44.1.15

New debian box:
Rancid: 2.3.7
Expect: 5.45

Here there any hints to solve this problem.

Best regards

Hans

[Alan McKinnon]

Post by Hans Mueller
Hi,
I'm trying to migrate my rancid installation from one box to another.
Everything seems to work fine but there are login problems on some
routers (about 10 %). The problems seems to be the "motd banner". If i
try to login to these routers the login looks like this (the banner is
-------------------------------------------------------------
g546.abcd.domain.net
spawn telnet g546.abcd.domain.net
Trying 172.24.999.999...
Connected to g546.abcd.domain.net.
Escape character is '^]'.
CC
**********************************************************
* *
* *
* Routername: g546.abcd.domain.net *
* *
* Kunde: Hans Mueller *
* Standort *
* Strasse 81 *
* 12345 Ortschaft *
* *
* *
* Ansprechpartner: Frau Mueller *
* Telefon: [phone] *
* *
* Kundennummer: 12436 *
* Auftragsnummer: XY#763743 *

^
|
|

Remove this character.

There's no easy way around this. clogin relies on a specific text
pattern to detect the exact prompt used by the router cli. It needs this
to know where one command starts and the next ends in the full output,
and it uses ">" and "#" to do this.

To have rancid (actually any product that works similarly to rancid)
work reliably at all, you must consider those two characters to be
banned in the banner.


I've seen patches around over the years that try work around this but
unfortunately they all seem to deal with specific cases on specific
hardware and won't work universally in the general case.

One possibility is ignore lines containing "#" that also have whitespace
earlier in the line. Those always seem to be banner text and real-life
cli prompts seldom contain whitespace

hth,

Post by Hans Mueller
* *
* *
**********************************************************
User Access Verification
User Access Verification
%
User Access Verification
Username: timeout expired!Connection closed by foreign host.
Error: EOF received
-------------------------------------------------------------
If i remove the banner, the login with clogin works fine. But i don't
want to remove the banner.
Rancid works fine on my old box but not on the new one.
Rancid: 2.3.8
Expect: 5.44.1.15
Rancid: 2.3.7
Expect: 5.45
Here there any hints to solve this problem.
Best regards
Hans
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Alex DEKKER]

Post by Hans Mueller
* Auftragsnummer: XY#763743 *
One possibility is ignore lines containing "#" that also have whitespace
earlier in the line. Those always seem to be banner text and real-life
cli prompts seldom contain whitespace

Yeah, surely the only time that the # is a prompt is when it's the last
character on a line *and* no further output is forthcoming?

alexd

[Alan McKinnon]

Post by Alex DEKKER

Post by Hans Mueller
* Auftragsnummer: XY#763743 *
One possibility is ignore lines containing "#" that also have whitespace
earlier in the line. Those always seem to be banner text and real-life
cli prompts seldom contain whitespace

Yeah, surely the only time that the # is a prompt is when it's the last
character on a line *and* no further output is forthcoming?
alexd

In an ideal, theoretical world that is true. Neither of us live in such
a world and prompts are often not what they should be.

[Per-Olof Olsson]

Post by Alan McKinnon

Post by Alex DEKKER

Post by Hans Mueller
* Auftragsnummer: XY#763743 *
One possibility is ignore lines containing "#" that also have whitespace
earlier in the line. Those always seem to be banner text and real-life
cli prompts seldom contain whitespace

Yeah, surely the only time that the # is a prompt is when it's the last
character on a line *and* no further output is forthcoming?
alexd

In an ideal, theoretical world that is true. Neither of us live in such
a world and prompts are often not what they should be.

Yes and it's simple to fix.

*** clogin 2014-03-21 11:14:48.163493260 +0100
--- clogin.new 2014-03-21 11:06:19.711260482 +0100
***************
*** 572,577 ****
--- 572,580 ----
send -- "$passphrase\r"
exp_continue
}
+ -re "\[#>]+\[^\r\n]*\[\r\n]+" {
+ exp_continue
+ }
-re "$u_prompt" {
send -- "$user\r"
set uprompt_seen 1


Also tested and include in hlogin.

Then you can have how many # and > you like in banners.


/Peo
----------------------------------------------------------
Per-Olof Olsson Email: ***@chalmers.se
Chalmers tekniska högskola IT-service
Arvid Hedvalls backe 6 412 96 Göteborg
Tel: [phone] Fax: [phone]
----------------------------------------------------------

[heasley]

Post by Per-Olof Olsson

Post by Alan McKinnon

Post by Alex DEKKER

Post by Hans Mueller
* Auftragsnummer: XY#763743 *
One possibility is ignore lines containing "#" that also have whitespace
earlier in the line. Those always seem to be banner text and real-life
cli prompts seldom contain whitespace

Yeah, surely the only time that the # is a prompt is when it's the last
character on a line *and* no further output is forthcoming?
alexd

In an ideal, theoretical world that is true. Neither of us live in such
a world and prompts are often not what they should be.

Yes and it's simple to fix.
*** clogin 2014-03-21 11:14:48.163493260 +0100
--- clogin.new 2014-03-21 11:06:19.711260482 +0100
***************
*** 572,577 ****
--- 572,580 ----
send -- "$passphrase\r"
exp_continue
}
+ -re "\[#>]+\[^\r\n]*\[\r\n]+" {
+ exp_continue
+ }

i maintain the assertion that you can not rely upon receiving complete
lines. expect may see

b
or
blah#
or
blah#<space>
or
blah#<space><return><nl>

there is no way to know what will be in the input buffer. ie: you may get
lucky, but this is not a reliable fix. the only reliable fixes what i can
think of would be to be more specific about prompt match (eg: a new clogin
setting) for the given device or develop a process to wait to see if
anything follows the # or >, which has its own set of pitfalls.

if you disagree, please explain why.

Post by Per-Olof Olsson
-re "$u_prompt" {
send -- "$user\r"
set uprompt_seen 1
Also tested and include in hlogin.
Then you can have how many # and > you like in banners.
/Peo
----------------------------------------------------------
Chalmers tekniska högskola IT-service
Arvid Hedvalls backe 6 412 96 Göteborg
Tel: [phone] Fax: [phone]
----------------------------------------------------------
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Alex DEKKER]

Post by heasley
develop a process to wait to see if
anything follows the # or >, which has its own set of pitfalls.

I [sitting in my armchair, not being the developer] think this idea has
some mileage. Would it be unreasonable to wait n seconds after a # to
determine that it's a prompt? Obviously if you do this then you'd have
to add a knob to tweak for those who are taking backups over satellite
links &c.

Perhaps you could be a bit cleverer - if a router is delivering 20
lines/sec of output, then you'll know within 0.5sec if it's finished,
although some seem to always be slow when delivering certain sections of
config. Pitfalls indeed!

alexd

[Alan McKinnon]

Post by Alex DEKKER

Post by heasley
develop a process to wait to see if
anything follows the # or >, which has its own set of pitfalls.

I [sitting in my armchair, not being the developer] think this idea has
some mileage. Would it be unreasonable to wait n seconds after a # to
determine that it's a prompt? Obviously if you do this then you'd have
to add a knob to tweak for those who are taking backups over satellite
links &c.
Perhaps you could be a bit cleverer - if a router is delivering 20
lines/sec of output, then you'll know within 0.5sec if it's finished,
although some seem to always be slow when delivering certain sections of
config. Pitfalls indeed!

There have been many good suggestions on dealing with prompts, and all
of them are quite workable when the prompt behaves as it should. Some
solutions are tweaked for specific hardware but they still work within
that definition.

The downfall however is this thing called real life, it seldom does what
it should. I've lost count of the number of bizarre behaviours I see in
real life around prompts: here's a common one our entire team has given
up on and learned to just live with:

^C^C^C^<hostname> #^C^C^C

What on earth is 0x03 doing in there? I really have no idea, but I have
to deal with it, and with similar junk. Eventually I had to get
pragmatic and issue a decree from on high that the first > and # will
indicate the prompt. I'm lucky in that I can get away with this, other
sites are not so lucky.

All in all I believe John's stance is the correct one for the supported
shipped versions of *login. However a case can be made for hosting a few
patchsets that modify prompt detection and clearly document the
requirements that must be in place to use them properly. Admins can then
use these at their discretion.

[heasley]

Post by Alan McKinnon
However a case can be made for hosting a few
patchsets that modify prompt detection and clearly document the
requirements that must be in place to use them properly. Admins can then
use these at their discretion.

i'm willing to do this too; just dont be offended if i comments about
corner cases. :)

[Per-Olof Olsson]

This post might be inappropriate. Click to display it.

[heasley]

Post by Alex DEKKER

Post by heasley
develop a process to wait to see if
anything follows the # or >, which has its own set of pitfalls.

I [sitting in my armchair, not being the developer] think this idea has
some mileage. Would it be unreasonable to wait n seconds after a # to
determine that it's a prompt? Obviously if you do this then you'd have
to add a knob to tweak for those who are taking backups over satellite
links &c.
Perhaps you could be a bit cleverer - if a router is delivering 20
lines/sec of output, then you'll know within 0.5sec if it's finished,
although some seem to always be slow when delivering certain sections of
config. Pitfalls indeed!

Something like this could [mostly] work.

Index: clogin.in
===================================================================
--- clogin.in (revision 2802)
+++ clogin.in (working copy)
@@ -575,7 +575,21 @@
}
-re "$prompt" {
set prompt_match $expect_out(0,string);
- break;
+ expect {
+ " " { exp_continue }
+ -re ".+" {
+ unset prompt_match;
+ break
+ }
+ timeout { set to 1;
+ break
+ }
+ }
+ if {$to == 1} {
+ unset to;
+ break
+ }
+ exp_continue;
}
"Login invalid" {
send_user "\nError: Invalid login: $router\n";

but without constraining the timeout somehow, thats much to slow for my
patience. it also doesnt deal with eof.

how to arrive at a reliable timeout is a another question. what is too long
or short? can the previous input rate simply be measured? is the link
congested or is there routing instability producing massively variable
throughput? maybe some would argue that last bit can be ignored; i think
that makes it unreliable and more difficult to support.

i am far more inclined to say dont do it (or have banners at all); the price
of admission. or, if you must have #s in your banner, do not use autoenable,
so its looking for >s - which is also a poor solution, as it would be better
for clogin not to care about autoenable, so it would be looking for [>#] by
default.

i am however open to adding a cloginrc variable to constrain the prompt
match; eg: "^[ \n\r]+[#>]". thereby, you could have whatever you wanted
in your banner as long as the first character of the line is a space - for
example.

and open to other suggestions or proving me wrong :)