(usr-tc) The connection for call id 219549253, on if slot:14/mod:23 was dr opped for user - after successful RADIUS authentication
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 scott@gdinet.com Madison WI 53718 <http://www.gdinet.com/> - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Quoting Scott Trautman <scottt@corp.gdinet.com>: 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
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 scott@gdinet.com Madison WI 53718 <http://www.gdinet.com/>
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
=========== -V ========== - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Quoting Jeff Mcadams <jeffm@iglou.com>:
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 LCP reject being received - yes then the user name know. -V
-- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
=========== -V ========== - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Also sprach Veda Narayan
Quoting Jeff Mcadams <jeffm@iglou.com>:
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 LCP reject being received - yes then the user name know.
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Can I set the MAX CHANNELS based on DNIS or DSP or anything else to make it selective? thank you, - Marcelo - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 > thank you,
- Marcelo
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
----------------------------------------------- Brian Feeny, CCNP, CCDA signal@shreve.net Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Thu, 5 Oct 2000, Marcelo Souza wrote:
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?
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
- Marcelo
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
----------------------------------------------- Brian Feeny, CCNP, CCDA signal@shreve.net Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
participants (5)
-
Brian -
Jeff Mcadams -
Marcelo Souza -
Scott Trautman -
Veda Narayan