Okay! Ask ye for a mon ppp, gets ye a mon ppp: slot:14/mod:17 is the already-logged-on session slot:14/mod:9 is the new session that (per below), gets the PAP ACK then boom, dropped, no more PPP messages about it. What does the IP_DATA mean for the other? Same message over and again, before and after the event. So is the dropping of the connection a "non PPP" event? Like the ARC taking a whack at it? The disconnection reason, shown by RADIUS, is LOST_CARRIER, which of course means any number of things, rarely that <we> dropped them in any administrative way. Any clues? god save me to call into 3Com support on this one; I may open the ticket and try King George directly. Man, I don't know what more data possibly could be gotten other than what I've got here. Other than duplicating it at another site. Which we review each day from customers as not happening anywhere else. ...related perhaps; anyone have a quick way to read out the entire config of an ARC? If I can do that quick I can look for any setting changes with diff between the two. SMT
>Output of mon ppp<<<<<<<<<<<<
Monitor a specific user Enter the user name to monitor below: Press Escape to return to the previous screen. Press Enter/Return to enter the name. User Name: [Pstandish ] Monitoring user Pstandish. Decode tracing started, press ESCAPE to stop; press X for hex tracing. Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e ca 3b 00 00 80 11 7e 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e cb 3b 00 00 80 11 7d 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e cc 3b 00 00 80 11 7c 5a 9c 2e b9 ac 9c 2e ff ff ... ########################This is it for this session! Boom! Dropped!############ Outgoing PPP Data on interface: slot:14/mod:9 PAP ACK Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 01 82 d4 3b 00 00 80 11 73 26 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e d6 3b 00 00 80 11 72 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e d8 3b 00 00 80 11 70 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e da 3b 00 00 80 11 6e 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e db 3b 00 00 80 11 6d 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e dc 3b 00 00 80 11 6c 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e dd 3b 00 00 80 11 6b 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 01 82 ed 3b 00 00 80 11 5a 26 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e ef 3b 00 00 80 11 59 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f1 3b 00 00 80 11 57 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f3 3b 00 00 80 11 55 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f4 3b 00 00 80 11 54 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f5 3b 00 00 80 11 53 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e f6 3b 00 00 80 11 52 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 01 82 fe 3b 00 00 80 11 49 26 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 00 3c 00 00 80 11 48 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 02 3c 00 00 80 11 46 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 04 3c 00 00 80 11 44 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 05 3c 00 00 80 11 43 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 06 3c 00 00 80 11 42 5a 9c 2e b9 ac 9c 2e ff ff ... Incoming PPP Data on interface: slot:14/mod:17 IP_DATA 45 00 00 4e 07 3c 00 00 80 11 41 5a 9c 2e b9 ac 9c 2e ff ff ... -----Original Message----- From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] Sent: Saturday, November 20, 1999 9:16 PM To: Scott Trautman Cc: 'usr-tc@lists.xmission.com'; 'standish@gdinet.com'; 'standish1@gdinet.com' Subject: Re: (usr-tc) Dropped connections for 2nd login with same login ID. MPPP weird thing? 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. - 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.