Mailing List Archive

Nice. Changes to login scripts always seems a lot like screwing with
nature - one wrong move and there is a pestilence upon the land, so ...
not being keen on riverstone myself and since rivlogin was contributed,
I am curious about it's relation to "Enterasys". It's not clear to me
what enterasys is; or if changes to rivlogin will alienate it.

Andrew (fort), perhaps you can take this?

Mon, May 23, 2005 at 10:58:44PM -0500, Mike McHenry:
> Rivlogin is currently in a sad state of functionality that doesn't
> support many of the things the newer clogin does; most notably SSH
> logins.
>
>
>
> I've remedied this on my systems by hacking up the latest version of
> clogin to support Riverstone equipment. The new expect script can be
> found here
>
> http://colossus.lh.net/rivlogin
>
>
>
> Also a patch in "diff -uNr" context
>
> http://colossus.lh.net/rivlogin-vs-clogin.patch
>
>
>
> Treat this code as beta quality. However it is working well on my
> network of RS3000s/RS38000s running 9.1 code. Any chance we can get this
> script into the mainline code releases?
>
>
>
> Mike McHenry (612) 252-2340
>
> mmchenry at lightedge.com
>
> Senior Network Engineer
>
> LightEdge Solutions
>
>
>
> "This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based on
> this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation."
>
>
>

john heasley wrote:
> Nice. Changes to login scripts always seems a lot like screwing with
> nature - one wrong move and there is a pestilence upon the land, so ...
> not being keen on riverstone myself and since rivlogin was contributed,
> I am curious about it's relation to "Enterasys". It's not clear to me
> what enterasys is; or if changes to rivlogin will alienate it.
>
> Andrew (fort), perhaps you can take this?

sure thing.. thanks for the updates and i'll test them here.

-andrew

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

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. :)

-----Original Message-----
From: Andrew Fort [mailto:afort@choqolat.org]
Sent: Tuesday, May 24, 2005 2:03 AM
To: john heasley
Cc: Mike McHenry; afort at shrubbery.net; rancid-discuss at shrubbery.net
Subject: Re: Rivlogin modifications

john heasley wrote:
> Nice. Changes to login scripts always seems a lot like screwing with
> nature - one wrong move and there is a pestilence upon the land, so
...
> not being keen on riverstone myself and since rivlogin was
contributed,
> I am curious about it's relation to "Enterasys". It's not clear to me
> what enterasys is; or if changes to rivlogin will alienate it.
>
> Andrew (fort), perhaps you can take this?

sure thing.. thanks for the updates and i'll test them here.

-andrew

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

Andrew,

We don't (as of yet) utilize Radius lookups on our Riverstone gear.
Perhaps it would be more helpful for me to give you access to one of my
pseudo-development Riverstone chassis so you can test out the SSH
sequence yourself. Please reply to me offline if you feel this would be
useful.

Here is an example login sequence on a RS3000 chassis running 9.1.2.8
code. Anything in << brackets >> indicates something typed in.

[mmchenry at unixhost]# << ssh -1 RIVERSTONEHOST >>


----------------------------------------------------------------------
RS 3000 System Software, Version 9.1.2.8
Copyright (c) 2000-2004 Riverstone Networks, Inc.
System started on 2004-10-11 20:18:49
----------------------------------------------------------------------


Press RETURN to activate console . . .
<< RETURN >>

Password: << login password >>
Password: << enable password >>
RIVERSTONEHOST#

Where the initial prompt for password is being pulled from
system set hashed-password login xxxxxxx

and the secondary enable password is pulled from
system set hashed-password enable xxxxxxx

>
> 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?
>


I never had problems in my testing either when I removed the "Press
RETURN" expect sequence and I agree that it could probably be removed
safely.

> - 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.
>

My longest hostname is 16 characters long and I haven't run into any
apparent problems so far.

> 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