Re: (RADIUS) Re: How R things

Jeff Woods ( )
Tue, 03 Feb 1998 08:11:47 -0500

At 02:47 PM 2/2/98 -0700, you wrote:
>>Only problem I currently have is a RADIUS issue, which I'm not certain is
>>your problem.... It manifests itself MOST in Win95 Dialup Networking 1.2,
>>where not even *I* can get a connection from my home when the
>>authentication happens automatically (if I leave it to do its dialing, its
>>an error 426, familiar unable to negotiate a compatible....). However, if
>>I tell it to bring up a terminal window after dialing, and I MANUALLY key
>>in my login name and password, and then press F7 when PPP negotiation
>>begins, it lets me in.
>Boy, am I glad to see that someone *else* has this problem. I've tried
>everything I can think of -- even switched to SLIP -- and could not get
>Win95 to complete a network connection. My Mac works fine with the same
>dialup username/password. I've been told to make sure I turn off the
>option to log on to the network, but I tried that a long time ago -- no

I figured out this one late last night. My MODEM connection WORKED but my
ISDN connection in the same DUN did NOT, so I compared, found the
difference, and changed the ISDN setting that differed, and then the ISDN
worked, too.

To solve this problem, ensure that "REQUIRE ENCRYPTED PASSWORD" is turned
OFF in the DUN item.... Right click, Properties, Server Type Tab. It has
nothing to do with "log onto network".

>What does F7 do? I've been using a script, and Win95 is supposed to start
>the PPP negotiation after the "end proc".

When you bring up a terminal window after dialing (right click connection,
Click on Configure the modem, Options tab, bring up terminal after
dialing), it will show you the actual "login" prompt. You can enter a
username and password here, as if you were telnetting to the PM-3, and then
it will go into the {#&{#[{:{8:[((9{{{ stuff -- the actual PPP negotiation.
If you get that sort of "garbage", then you successfully entered a
password. At this point, DUN asks you to press F7 to continue. THAT is
how I was getting on before on my ISDN. Note that this makes PERFECT
sense now above..... With "require encrypted password" turned on, you
might have told DUN to send "quickbrownfox" but with that option turned on,
the remote side is EXPECTING "JHugB6754c/*&$" since it requires an
ENCRYPTED password.... So DUN used the standard UNIX password encryption
(ever looked inside /etc/pwrd?) BEFORE sending the password, and of COURSE
they didn't match...... Why it was giving me the odd error, I don't
know.... It should have simply told me that the passwords didn't match, and
asked me to try again, but the problem probably runs deeper than the simple
explanation above. In any case, if you turn off the "Encrypted password"
option, your problem will be solved, for you and your users.

>My next step is to go out to this customer's site with a datascope.
>Diagnosing PPP with a datascope is one of my least favorite activities,
>so I'm hoping for some inspiration before then.

I hope I was in time.....

Now if I could just solve the disconnects -- the idle-timeout seems to be
RANDOM and ALWAYS early....