Subject: (usr-tc) The connection for call id 219549253, on if slot:14/mod:23 was dr opped for user - after successful RADIUS authentication

From: Scott Trautman <[email-masked]>
Date: Wed, 13 Sep 2000 16:40:22 +0000

Hi, I seem to have seen this before, can't recall for the life of me what
this ended up meaning.

Sequence on this call:

Sep 13 08:53:19 lkm-ha1 At 13:49:00, Facility "Auth Facility", 
Level "VERBOSE":: A call, call id = 219549253, has arrived on interface 
slot:14/mod:23
Sep 13 08:53:38 lkm-ha1 At 13:49:19, Facility "Auth Facility", Level
"COMMON":: 
A call is established, call id 219549253, on interface slot:14/mod:23
Sep 13 08:53:38 lkm-ha1 At 13:49:20, Facility "Auth Facility", Level
"COMMON":: 
The connection for call id 219549253, on if slot:14/mod:23 was dropped for
user 
UNKNOWN

Doing a trace (mon ppp), I see:

 User Name: [Prrrrbj                         ]
 Monitoring user Prrrrbj.
Decode tracing started, press ESCAPE to stop; press X for hex tracing.
....Tracing for user "Prrrrbj"; Escape to stop...

Outgoing PPP Data on interface: slot:14/mod:23 
    PAP        ACK               
Outgoing PPP Data on interface: slot:14/mod:23 
    IPCP       CFG_REQ           COMPR_TYPE     00 2d 0f 00 
                                 NEW_ADDRS      9c 2e b9 01 

Incoming PPP Data on interface: slot:14/mod:23 
    LCP        TERM_REQ          

Outgoing PPP Data on interface: slot:14/mod:23 
    LCP        TERM_ACK  

It's saying to me the client is <requesting> to be terminated (suicide?)
All their settings appear to be correct...definately is set to "let server
assign" the IP address--

Any hints here as to what's going on?

I hate to have someone rip out their dialup networking if I don't have a
good reason for it.

Anyone seen this before

Thanks!!

Scott M. Trautman	 800-482-4638	
Global Dialog Internet 	608-240-4638,4637fax	
2810 Crossroads, STE LL2	 [email-masked]	
Madison WI 53718	 <http://www.gdinet.com/>	

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Veda Narayan <[email-masked]>
Date: Wed, 13 Sep 2000 20:48:07 +0000

Quoting Scott Trautman <[email-masked]>:

When a user dials in to the total control, if the call fails due to some 
modem/connection/user-error etc, the HiPer arc does not know the name of the 
person who called, thus it calls the user unknow.  In this case as you see you 
have got IPCP being sent out by the HiPer arc but you get a LCP termination 
request - thus the user asked for disconnection - at this point the PPP stack 
on the hiper arc does not know that a username thus the unknown user has been 
disconnected.

-V

>  "help" to the same address.  Do not use quotes in your message.

===========

-V

==========

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 13 Sep 2000 20:56:37 +0000

Also sprach Veda Narayan
>When a user dials in to the total control, if the call fails due to
>some modem/connection/user-error etc, the HiPer arc does not know the
>name of the person who called, thus it calls the user unknow.  In this
>case as you see you have got IPCP being sent out by the HiPer arc but
>you get a LCP termination request - thus the user asked for
>disconnection - at this point the PPP stack on the hiper arc does not
>know that a username thus the unknown user has been disconnected.

Uhm, yes it does know the username...he did a mon user with the username
to get the log, and IPCP occurs after PAP, (you can see the PAP auth
ack in the log), so the Arc does indeed know the userid if the drop
occured at the time that the ppp log shows.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Veda Narayan <[email-masked]>
Date: Thu, 14 Sep 2000 15:11:44 +0000

> occured at the time that the ppp log shows.

Nope - It still does not know the user name - the arc uses message passing.
So each module has to send the info to the other module to let PPP module to 
know the user name.  CIP tells PPP module about the call, PPP module starts LCP 
and then informs the radius/user module - this is where the authentication 
takes place, then radius/user module tells IP about the call to complete IPCP, 
if the call fails at that point IP does not say call complete - so radius/user 
will not tell PPP that there is a particular user tried to login.  If the IP 
was nacked or rejected or even if IPCP had taken place for some time before the 
LCP reject being received - yes then the user name know.

-V

===========

-V

==========

-

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 14 Sep 2000 16:34:40 +0000

Also sprach Veda Narayan
>> Uhm, yes it does know the username...he did a mon user with the
>> username to get the log, and IPCP occurs after PAP, (you can see the
>> PAP auth ack in the log), so the Arc does indeed know the userid if
>> the drop occured at the time that the ppp log shows.

>Nope - It still does not know the user name - the arc uses message
>passing.  So each module has to send the info to the other module to
>let PPP module to know the user name.  CIP tells PPP module about the
>call, PPP module starts LCP and then informs the radius/user module -
>this is where the authentication takes place, then radius/user module
>tells IP about the call to complete IPCP, if the call fails at that
>point IP does not say call complete - so radius/user will not tell PPP
>that there is a particular user tried to login.  If the IP was nacked
>or rejected or even if IPCP had taken place for some time before the

Wow...not sure how you know so much about the internals of the Arc code,
but that's impressive.

Regardless though, sounds like a bug to me.  The *Arc* does know the
username...it has already completed PAP...though it might be in the
wrong module of the Arc code.  In my opinion, if PAP returns with an
authentication OK, then the Arc should use that username in whatever
logs from that point on.  The user may not be authorized to do IP, or
the peer may refuse IP, but they are authenticated, so the Arc does know
what the userid is and *should* include it in any logs to help diagnose
what the problem is.

On an only tangentially related note...

Anyone know what the deal is with the news server on totalservice?  It
seems to have been refusing connections for over a day now.  Given the
shoot-themselves-in-the-foot-concerning-customer-service-what-else-is-new
decision by 3Com to forbid participation in this list of techies and
others within 3Com (yes, I did confirm this to be the case, to my
satisfaction at least), and the totalservice news server software not
accepting connections, and continued incredible lameness concerning
software contracts; 3Com seems to be actively shutting down every
possible avenue of customer support.  I guess 3Com really doesn't want
customers after all.  *sigh*
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Marcelo Souza <[email-masked]>
Date: Wed, 04 Oct 2000 19:40:18 +0000

Can I set the MAX CHANNELS based on DNIS or DSP or anything else
to make it selective?

thank you,

- Marcelo

-

---

From: Brian <[email-masked]>
Date: Wed, 04 Oct 2000 21:04:58 +0000

> 	Can I set the MAX CHANNELS based on DNIS or DSP or anything else

if you have coolio radius software then you can do just about anything
like this..........dynamic reply attributes.  Supported by radius software
like Radiator http://www.open.com.au/radiator > thank you,
>  "help" to the same address.  Do not use quotes in your message.

-----------------------------------------------
Brian Feeny, CCNP, CCDA       [email-masked]   
Network Administrator	      
ShreveNet Inc. (ASN 11881)	      

-

---

From: Marcelo Souza <[email-masked]>
Date: Thu, 05 Oct 2000 16:52:56 +0000

On Wed, 4 Oct 2000, Brian wrote:

|On Wed, 4 Oct 2000, Marcelo Souza wrote:
|> 
|> 	Can I set the MAX CHANNELS based on DNIS or DSP or anything else
|> to make it selective?
|> 
|
|if you have coolio radius software then you can do just about anything
|like this..........dynamic reply attributes.  Supported by radius software
|like Radiator http://www.open.com.au/radiator 

	That's my problem. I still use a customized version of Livingston
Radius 2.x, that does not support such attributes.
	Via CLI no chance?

- Marcelo

-

---

From: Brian <[email-masked]>
Date: Fri, 06 Oct 2000 04:54:22 +0000

> Radius 2.x, that does not support such attributes.

I don't believe you can.  Although I think newer ARC code (newer by my
standards, probably old for most) does allow some call control
(authentication?) based on dnis.

Brian

-