Hi,

This sort of thing (22 Seconds) often happens when a remote device is attempting to 
authenticate say a Cisco router.  Linux is often one I come across another is when 
logging into a group of routers then using RDIUS or similar to allow access.

The remote device attemts to authenticate the called router but it does not 
necessarily reply the way the remote device wants to see it.  In a number of cases it 
is easier to have the called device to the 'chap' authentication and not have the 
remote device do the authentication as well (no auth in Linux ppp setup) don't add the 
'ppp auth chap' in the dialer of the calling router.  This of course assumes you are 
only interested in a remote connection calling to central site and the central site 
being the device interested in controlling security.

Debug PPP neg shows the attempt.

Just a thought,

It is one I have come across on several occasions.

Teunis,
Hobart, Tasmania
Australia


On Friday, March 09, 2001 at 09:09:50 AM, [EMAIL PROTECTED] wrote:

> I have no experience with the US telco environment, but looking at this
> from another angle...
> You say that the PPP negotiation is timing out.  Is this because the
> negotiation traffic is being dropped (dodgy ISDN line), or is it because
> it's not negotiating properly in the first place?
> Debug ppp negotiation and debug ppp packet (I think - going from memory
> here) can be quite useful if you haven't already used them.  At both ends.
> I have had problems with a bug where prioritisation and PPP multilink could
> not be used on the same link.  If they were, PPP negotiation failed (timed
> out after about 22 seconds) - one side simply failed to reply to the other
> once the virtual link was set up.  Similarly, changing the encapsulation of
> an interface to PPP without shutting/no shutting the interface can give
> negotiation problems.  If this is a new link, what order did you enter
> commands in?  Was 'no shut' the first or last thing you did?
> If the problem is with the negotiation process itself, then you can
> probably stop pestering the telco and start pestering the TAC instead.
> 
> JMcL
> 
> ---------------------- Forwarded by Jenny Mcleod/NSO/CSDA on 09/03/2001
> 09:01 am ---------------------------
> 
> 
> Dan West <[EMAIL PROTECTED]>@groupstudy.com on 09/03/2001 03:15:44 am
> 
> Please respond to Dan West <[EMAIL PROTECTED]>
> 
> Sent by:  [EMAIL PROTECTED]
> 
> 
> 
> To:   Kurt Bailey <[EMAIL PROTECTED]>
>       [EMAIL PROTECTED]
> cc:
> 
> 
> Subject:  Re: ISDN 22 second PPP Negotiation Time-out, help...
> 
> 
> I have done this *type* of work before.... Get ready.
> Ask telco to trace out the carrier for you from their
> demarc and find every mux point or switch AND ask them
> IF the circuit gets HANDED OFF to another CARRIER at
> some point.
> 
> If so, your nice 64k digital line might be stepping
> down to analog within another telco (CARRIER) so your
> LEC might not even care or say they have control over
> it.... It's oh so much fun working with the phone
> companies. Although I must say I have worked with some
> really good, qualified people there who have been
> extremely helpful....
> 
> 
> --- Kurt Bailey <[EMAIL PROTECTED]> wrote:
> > I have mutliple ISDN lines in the US that seem to be
> > UN-Fixable...
> > Calls time-out after 22 seconds. We use Cisco. Some
> > locations work when you
> > call in-bound but fail on out bound calls, while
> > others fail both in and out
> > bound. We order the ISDN 64k DATA/DATA. It must be
> > 64k DATA/DATA in order to
> > work with our access-servers, VOICE/DATA will not
> > work. Local and Long
> > distance teclo SAY they are configured right... Long
> > distance telco says
> > they are handing a 64k data call to local and local
> > says they are recieving
> > a 64k data call and vise versa. Now for some issues
> > I have been able to set
> > the call speed to 56k to get the call working. My
> > main point for posting
> > this is to find help in how I can talk to the telco
> > and make them look at
> > the line and be absolutly sure that our calls are
> > traveling a 64k DATA/DATA
> > trunk and not being routed over ANALOG or
> > VOICE/DATA. Or if there are any
> > config changes that can be made local or on the
> > access-servers.
> >
> > Thanks,
> >
> > Kurt
> >
> _________________________________________________________________
> > Get your FREE download of MSN Explorer at
> > http://explorer.msn.com
> >
> > _________________________________
> > FAQ, list archives, and subscription info:
> > http://www.groupstudy.com/list/cisco.html
> > Report misconduct and Nondisclosure violations to
> [EMAIL PROTECTED]
> 
> 
> =====
> from The Big Lebowski...
> 
> The Dude: You sure he won't mind?
> Bunny: Dieter doesn't care about anything. He's a nihilist.
> The Dude: Ohhh, that must be exhausting...
> 
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
> 
> _________________________________
> FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> 
> 
> _________________________________
> FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> 
> 


--
www.tasmail.com


_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to