RE: IPE Section 22 - ISDN issue

From: Hunt Lee (huntl@webcentral.com.au)
Date: Wed May 21 2003 - 00:58:16 GMT-3


Sorry, I didn't see that you need to implement callback while doing the 1
way authentication...
 
So yes, you are right.
 
You will need that ppp callback accept statement too.

-----Original Message-----
From: Jason Cash [mailto:cash2001@swbell.net]
Sent: Wednesday, 21 May 2003 1:56 PM
To: Hunt Lee
Cc: ccielab@groupstudy.com
Subject: RE: IPE Section 22 - ISDN issue

Well, without 'ppp callback accept' how is the router to know that it should
callback? I understand that the map-class dialer defines a 'dialer
callback-server' but I thought you needed the accept.

 

At any rate what you are suggesting:

Ppp auth chap callin

 

I don't think that would accomplish the task because R5 would be
authenticating in your instance not as instructed:

 

"config R2 to authenticate r5 only when R5 calls r2"

 

From the deb ppp auth screens it seems like this:

 

r5(config)#int s0

r5(config-if)#shut

r5(config-if)#^Z

r5#

10:53:48: %OSPF-5-ADJCHG: Process 1, Nbr 110.90.4.4 on Serial0 from FULL to
DOWN, Neighbor Down: Interface down or detached

10:53:48: %SYS-5-CONFIG_I: Configured from console by console

10:53:50: %LINK-5-CHANGED: Interface Serial0, changed state to
administratively down

10:53:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed
state to down

10:53:54: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

 

ON CALLOUT R5 OUTPUTS A CHALLENGE TO R2 WHICH R2 RESPONDS AND IS SUCCESSFUL
(no challenge/auth.on R2's part)

10:53:54: BR0:1 PPP: Treating connection as a callout

10:53:54: BR0:1 CHAP: O CHALLENGE id 55 len 23 from "r5"

10:53:54: BR0:1 CHAP: I RESPONSE id 55 len 23 from "r2"

10:53:54: BR0:1 CHAP: O SUCCESS id 55 len 4

10:53:54: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358661 r2

10:53:54: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

R5 THEN HANGS UP THE CALL AFTER REQUESTING A CALLBACK

10:54:09: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

10:54:09: BR0:1 PPP: Treating connection as a callin

10:54:09: BR0:1 CHAP: O CHALLENGE id 56 len 23 from "r5"

10:54:09: BR0:1 CHAP: I CHALLENGE id 6 len 23 from "r2"

10:54:09: BR0:1 CHAP: Waiting for peer to authenticate first

10:54:09: BR0:1 CHAP: I RESPONSE id 56 len 23 from "r2"

10:54:09: BR0:1 CHAP: O SUCCESS id 56 len 4

10:54:09: BR0:1 CHAP: Processing saved Challenge, id 6

10:54:09: BR0:1 CHAP: O RESPONSE id 6 len 23 from "r5"

10:54:09: BR0:1 CHAP: I SUCCESS id 6 len 4

10:54:09: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up

10:54:09: Vi1 PPP: Treating connection as a callin

10:54:10: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed
state to up

10:54:10: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1,
changed state to up

 

Is my logic sckewed? Later at night am I am seeing double. Could someone
elaborate.

 

-----Original Message-----
From: Hunt Lee [mailto:huntl@webcentral.com.au]
Sent: Tuesday, May 20, 2003 9:52 PM
To: 'Jason Cash'
Cc: 'ccielab@groupstudy.com'

 

Hi Jason,

 

From what I understand (please correct me if I am wrong)...

 

You don't even need ppp callback accept,

 

And the callin should be used on r5, not r2.

 

Regards,

Hunt

 

-----Original Message-----

From: Jason Cash [mailto:cash2001@swbell.net]

Sent: Wednesday, 21 May 2003 11:54 AM

To: ccielab@groupstudy.com

Subject: IPE Section 22 - ISDN issue

 

 

The task instructs:

 

config R2 to authenticate r5 only when R5 calls r2

 

 

 

the solution on r2 is:

 

ppp callback accept

 

ppp authentication chap callback

 

 

 

Won't this have R2 authenticate R5 when it is calling back? That would be

auth. two times (once on the callback request and once on the callback). I

don't think this would accomplish the task.

 

 

 

Wouldn't this be better:

 

 

 

R2

 

ppp callback accept

 

ppp authentication chap callin

 

 

 

This way it only authenticates on the callin. Am I right in this logic?



This archive was generated by hypermail 2.1.4 : Mon Jun 02 2003 - 15:13:45 GMT-3