Re: (PM) Avalanche! Help! (fwd)

Jose de Leon (jadiel@thevision.net)
Fri, 30 Jan 1998 12:25:20 -0800

What you have to say seems to make sense.

Could it be that my recent solution of downgrading to ComOS 3.5 has a speedier
"login:" prompt?

Derric Scott wrote:

> > >>In light of all the helpful information regarding "Dialup networking can
> > >not negotiate..." ...
> ...
> > >memory at all. It is usually slow modem training, or the Windows box
> > >asking for all kinds of crap in PPP that fails.
>
> So... see #5 and #6 below for sure (ugly) fixes.
>
> After reading all the posts on this again and thinking on it some more, I
> think that the main reason the "Login:" prompt is slow to come up sometimes
> MUST be due to slow modem training. That slow "Login:" prompt then causes
> Dial Up Networking (and others?) to timeout the PPP/PAP attempt. My reasoning:
> 1. It is a fact that you can manually dial in and see widely
> varying "Login:" prompt appearance times on occasion.
> 2. It isn't a Radius issue because Radius hasn't even come into play
> before the "Login:" prompt is issued, so the Radius server
> speed isn't important.
> 3. For the same reason as #2, your LAN congestion/speed isn't
> important yet either.
> 4. The poster below mentions specific time of day (3AM) as well as
> problems across all platforms, and that scripted login
> WILL work. That makes sense because the scripted logins
> are simply set to wait longer for the Login: prompt than
> the PAP dialers do. The PM is waiting for DCD to come
> up before it issues the prompt and the DCD is just slow
> in coming up.
> 5. That also explains why our last ditch fix always works too...
> That being: turn on the "Bring up termnial window after
> dialing" box and just click "Continue." This holds the
> PAP attempt until after the "Login:" prompt appears, so
> the modem negotiation time isn't a factor!
> 6. Similarly a scripted login will always work too (assuming the
> timeout wait for the "Login:" prompt is long enough). In
> the old Trumpet, you could script to the "Login:" and then
> exit and let PAP take over. That would work fine.
> 7. The ideal fix is to increase the PAP timeout in Win95 (and other
> dialers), but I doubt that could ever be done - anyone have
> a guess that it could be a registry setting or something?
>
> Later.
>
> Derric
>
> > On 27-Jan-98 MegaZone wrote:
> > >Once upon a time Jose shaped the electrons to say...
> > >>In light of all the helpful information regarding "Dialup networking can
> > >not negotiate..." and that it may be caused by a slowdown of the PM.
> > >
> > >Actually I would not spend a lot of time on that path, I disagree. While
> > >it is possble I almost never see this come down to the PM - none in recent
> > >memory at all. It is usually slow modem training, or the Windows box
> > >asking for all kinds of crap in PPP that fails.
> >
> > We've been fighting this for awhile. It's not just MS, WebTV and Mac's
> > have the problem at the same time. The only way we have found to get
> > around it is to ditch PAP and script the logins. Of course, this doesn't
> > help the WebTV folks.
> >
> > It seems to get worse around 3AM, and often is preceded by customers
> > getting cut off.
> >
> > I even called Livingston (#50737) and have never received a call back. I
> > didn't give them a hard time about it since I believe it is the local
> > phone companies, but I still think it's funny that not using PAP solves
> > the problem.
>
> --
> Derric Scott Scott Network Services, Inc. P. O. Box 361353
> derric@scott.net (205)987-5889 Birmingham, AL 35236
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe portmaster-users' in the body of the message.

-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.