[rancid] Cisco Banner Issue

[Per-Olof Olsson]

On 03/31/2014 05:57 AM, heasley wrote:
> Fri, Mar 21, 2014 at 11:22:31AM +0100, Per-Olof Olsson:
>> Alan McKinnon skrev 2014-03-20 16:26:
>>> On 20/03/2014 16:13, Alex DEKKER wrote:
>>>> On 20/03/14 09:59, Alan McKinnon wrote:
>>>>> On 20/03/2014 11:27, Hans Mueller wrote:
>>>>>> *     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.
100% strict/safe programming, NO
but consider if you can tolerate 99% safe.

1.
Rancid will retry more then ones to login.
Weak help for buffering problems.

2.
Expect is a nice tool to handle and sync buffers.
Possible that I trust it for more then I should.
Hope new faster devices and network will make buffering problem less noticeable

3.
Will this code harm login for any device?
Even if it not 100% safe I think it will help a lot.
You can also add a warning when *login skips a line.

-re "\[#>]+\[^\r\n]*\[\r\n]+" {
  send_user "\nWARNING harmful prompter character found at login before command prompt\n"
  exp_continue
}

If you have a company wide banner you will hopefully see the warning from your devices.
Also possible that you have more the one of a type, and one is lucky to show a warning.


4.
I like to push he idea of having for prompt defined in clogrc as far away as possible for now.
Just think how to write a quoted expect regexp for a unix based device using full prompt
with text, time stamp, command number, bells and other control characters.
Possible needed anyhow.

Just some argues
/Peo

> 
>>          -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: peo at chalmers.se
>> Chalmers tekniska högskola    IT-service
>> Arvid Hedvalls backe 6        412 96 Göteborg
>> Tel: 031/772 6738  Fax: 031/772 8680
>> ----------------------------------------------------------
>> _______________________________________________
>> Rancid-discuss mailing list
>> Rancid-discuss at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/rancid-discuss