(usr-tc) Dropped connections for 2nd login with same login ID. MPPP weird thing?
Hi- Okay, I am really stumped. As I'm sure most of you do, we have customers that have one login in use by more than one connection at a time, and not Multilink PPP, but separate connections. In all our locations but one, we haven't heard of any problems. In our one location, the first one logs on fine (Pstandish), then anyone after that on the SAME unit logging in as Pstandish, will authenticate just fine, then be dropped with: Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level "COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: Pstandish Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level "COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was dropped for user UNKNOWN It's like it's sitting there trying to negotiate something it can't and hangs up. There's nothing weird in HiperARC's that has some knowledge of a given login ID (Pstandish), and as it sees the next one trying to login, hey, they must want MPPP, why don't I start the LCP negotiation for that? I don't know this to be fact, It's just conjecture at this point. It definately authenticates, but doesn't assign an IP and drive on, it drops the connection for UNKNOWN (which is tre' odd...it isn't unknown...) If they dial into another on of our POP's (IE, any TC unit other than this one) with same Pstandish, no problem. Next line isn't the "dropped for user unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not tested for sure having them test the whole ball of wax at another POP, so can't say 100% it's just that site other than we do have lots of other users using the same way and don't seem to have that problem. Nope, no TSMON or anything forcing them off, it is only in the HiperARC and this particular unit that it seems to be a problem. Yep, HiperARC is: System Version: V4.2.32 Everything DSP, Quad, NMC, everything current as well. Man, anyone seen anything like this? Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718 - 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.
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Trautman |Sent: Friday, November 19, 1999 11:39 AM |To: 'usr-tc@lists.xmission.com' |Cc: 'standish@gdinet.com'; 'standish1@gdinet.com' |Subject: (usr-tc) Dropped connections for 2nd login with same login ID. |MPPP weird thing? | | |Hi- | |Okay, I am really stumped. As I'm sure most of you do, we have customers |that have one login in use by more than one connection at a time, and not |Multilink PPP, but separate connections. In all our locations but one, we |haven't heard of any problems. In our one location, the first one logs on |fine (Pstandish), then anyone after that on the SAME unit logging in as |Pstandish, will authenticate just fine, then be dropped with: | |Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level |"COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: |Pstandish |Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level |"COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was |dropped for user UNKNOWN | |It's like it's sitting there trying to negotiate something it can't and |hangs up. There's nothing weird in HiperARC's that has some knowledge of a |given login ID (Pstandish), and as it sees the next one trying to login, |hey, they must want MPPP, why don't I start the LCP negotiation for that? I |don't know this to be fact, It's just conjecture at this point. It |definately authenticates, but doesn't assign an IP and drive on, it drops |the connection for UNKNOWN (which is tre' odd...it isn't unknown...) | |If they dial into another on of our POP's (IE, any TC unit other than this |one) with same Pstandish, no problem. Next line isn't the "dropped for user |unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not |tested for sure having them test the whole ball of wax at another POP, so |can't say 100% it's just that site other than we do have lots of |other users |using the same way and don't seem to have that problem. | |Nope, no TSMON or anything forcing them off, it is only in the HiperARC and |this particular unit that it seems to be a problem. Yep, HiperARC is: | |System Version: V4.2.32 | |Everything DSP, Quad, NMC, everything current as well. | |Man, anyone seen anything like this? Are you using 4.2.32 in all the other HARCs? How about showing us a "MON PPP" for that users connection.. Try any get the inital LCP (before auth) if possible. -M - 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.
That user wouldn't happen to have a static IP address would they? That's the only really obvious case I can think of that I've seen here. Normally we don't allow people to have concurrent logins, so... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925 On Fri, 19 Nov 1999, Scott Trautman wrote:
Hi-
Okay, I am really stumped. As I'm sure most of you do, we have customers that have one login in use by more than one connection at a time, and not Multilink PPP, but separate connections. In all our locations but one, we haven't heard of any problems. In our one location, the first one logs on fine (Pstandish), then anyone after that on the SAME unit logging in as Pstandish, will authenticate just fine, then be dropped with:
Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level "COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: Pstandish Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level "COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was dropped for user UNKNOWN
It's like it's sitting there trying to negotiate something it can't and hangs up. There's nothing weird in HiperARC's that has some knowledge of a given login ID (Pstandish), and as it sees the next one trying to login, hey, they must want MPPP, why don't I start the LCP negotiation for that? I don't know this to be fact, It's just conjecture at this point. It definately authenticates, but doesn't assign an IP and drive on, it drops the connection for UNKNOWN (which is tre' odd...it isn't unknown...)
If they dial into another on of our POP's (IE, any TC unit other than this one) with same Pstandish, no problem. Next line isn't the "dropped for user unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not tested for sure having them test the whole ball of wax at another POP, so can't say 100% it's just that site other than we do have lots of other users using the same way and don't seem to have that problem.
Nope, no TSMON or anything forcing them off, it is only in the HiperARC and this particular unit that it seems to be a problem. Yep, HiperARC is:
System Version: V4.2.32
Everything DSP, Quad, NMC, everything current as well.
Man, anyone seen anything like this?
Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718
- 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.
- 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.
Thus spake Mike Andrews
That user wouldn't happen to have a static IP address would they? That's the only really obvious case I can think of that I've seen here. Normally we don't allow people to have concurrent logins, so...
Static IP address wouldn't cause the connection to be dropped...it would cause some really flakey connectivity at best, but the negotiation would continue normally. -- 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.
On Fri, 19 Nov 1999, Scott Trautman wrote:
Hi-
Okay, I am really stumped. As I'm sure most of you do, we have customers that have one login in use by more than one connection at a time, and not Multilink PPP, but separate connections. In all our locations but one, we haven't heard of any problems. In our one location, the first one logs on fine (Pstandish), then anyone after that on the SAME unit logging in as Pstandish, will authenticate just fine, then be dropped with:
Nov 19 11:16:10 lkm-ha1 At 17:16:09, Facility "Auth Facility", Level "COMMON":: Port slot:14/mod:3 successful RADIUS authentication for user: Pstandish Nov 19 11:16:13 lkm-ha1 At 17:16:12, Facility "Auth Facility", Level "COMMON":: The connection for call id 218234989, on if slot:14/mod:3 was dropped for user UNKNOWN
The first tell clearly talks about the user - The second one talks about user unknown - clearly some where in the mean time the hiper arc has lost the user info for some reason. All there should be some other messages in the same seqence which will talk about call id -218234989 - looking at them could be of some use.
It's like it's sitting there trying to negotiate something it can't and hangs up. There's nothing weird in HiperARC's that has some knowledge of a given login ID (Pstandish), and as it sees the next one trying to login, hey, they must want MPPP, why don't I start the LCP negotiation for that? I don't know this to be fact, It's just conjecture at this point. It definately authenticates, but doesn't assign an IP and drive on, it drops the connection for UNKNOWN (which is tre' odd...it isn't unknown...)
Do you have MPIP setup? If you do them dropping the user make sense, else if its plain MPPP then unless and untill the user has been setup for port limit or for max challenels with a limit of 1 dropping the user does not make sense.
If they dial into another on of our POP's (IE, any TC unit other than this one) with same Pstandish, no problem. Next line isn't the "dropped for user unknown", it's the usual...assigned IP x.x.x.x and they're fine. Have not tested for sure having them test the whole ball of wax at another POP, so can't say 100% it's just that site other than we do have lots of other users using the same way and don't seem to have that problem.
You need to get a mon ppp and look at the hiper arc settings first. Get a mom ppp to start krish
Nope, no TSMON or anything forcing them off, it is only in the HiperARC and this particular unit that it seems to be a problem. Yep, HiperARC is:
System Version: V4.2.32
Everything DSP, Quad, NMC, everything current as well.
Man, anyone seen anything like this?
Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718
- 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.
- 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)
-
Jeff Mcadams -
Mike Andrews -
Mike Wronski -
Scott Trautman -
Tatai SV Krishnan