Rivlogin modifications

[Andrew Fort]

On 25/05/2005, at 1:27 AM, Mike McHenry wrote:

> Enterasys and Riverstone were both spun off divisions of Cabletron so
> they are somewhat similar but may not be identical anymore.
>

not to forget Aprisma, who were the division spun off for the  
Spectrum NMS.  these unfortunate souls were snaffled up by Netcool  
who were snaffled up by Computer Associates.

Riverstone is the NSP-focussed spin-off.
Enterasys is the Enterprise-focussed spin-off.

> I definitely don't think my rivlogin should replace the stock version
> without a good amount of testing. I would have rather patched the
> exiting rivlogin but it seemed like such a long road to go down when
> clogin was 95% of the way there. :)

it's actually preferred that all the *login programs are as similar  
as possible (i.e., it'd be really nice if there wasn't multiple login  
programs).

i had tried to initially do that, but had had a lot of problems with  
the escape characters for the line wrapping in EOS/ROS; problems I  
haven't had with the initial testing I've done of your offered  
rivlogin sofar.

I've run into a couple of things;

  - Do you use RADIUS for auth in your shop?  The 'userpassword'  
variable doesn't seem to be consulted in the same way as the existing  
rivlogin.

e.g. my .cloginrc stanzas look like

add user host {afort}
add userpassword host {radiuspass}
add password host {initial_login_password} {last_resort_password}

The initial password works, but when asked for RADIUS credentials  
after that, we send the username but not the correct password.

It appears that the variable used for the 'last_resort_password',  
above, is being used for any 'Password:' prompt.

I changed this behaviour a few releases back, because:

  - riverstone/enterasys CLI OSes ask for the initial_login_password  
BEFORE radius.
  - if radius is unreachable, you get a message indicating you need  
to use the last resort (enable) password now.
  - the user password for RADIUS is of course a seperate password.

Thus I figured the most logical mapping was the one, above.
So the logic changes to:
  - if we have seen a 'username' prompt, we're in radius/tac+ mode.
  - if we're in radius/tac+ mode, the password prompt is asking for  
the users' password.
  - if we see the message indicating we cannot reach radius, use the  
last_resort.

However, SSH logins are probably different.  Can you send me an  
example SSH login dialgoue with the switch so I can better understand  
the choices made in your patch?

  - On EOS 8.3 (we're running ancient code for stability reasons),  
there is a max login banner length which precludes us using our  
regular banner plus the "Press RETURN to Begin" prompt (it's like 4  
lines, perhaps 255 chars).  In any event, this means that our  
switches don't provide the initial prompt that is expected.  So, I  
have removed the expect and just have the program sleep 0.3 and then  
send \r to the switch.  Though this removes the stop-and-wait  
behaviour, I've never found it to cause problems, at least not with  
telnet.

One last question - what is the length of your _longest_ hostname on  
your switches, in characters?  The majority of terminal handling  
problems only appeared for me when using longer prompts (like, longer  
than about 9 characters, if my brain is working today).

thanks again,
-andrew