RE: (usr-tc) Dropped connections for 2nd login with same login ID . MPPP weird thing?
You've identified the essential problem. No, this <client> ISN'T trying to negotiate a multilink connection. Win95 client dialing, doesn't seem to matter what client dials, same result. IE, no the client isn't attempting to bond with another connection. It's picking up on something that makes it think this is a 2nd channel in a multilink connection, and that's not correct at all! SMT -----Original Message----- From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] Sent: Tuesday, November 23, 1999 10:23 PM To: Scott Trautman Cc: 'usr-tc@lists.xmission.com'; 'paul_steffen@planar.com' Subject: RE: (usr-tc) Dropped connections for 2nd login with same login ID . MPPP weird thing? On Wed, 24 Nov 1999, Scott Trautman wrote:
Okay, hup two three four ppp mon on your door.
slot:14/mod:21 is the Pstandish session in question. No data from slot:14/mod:5, which is the Pstandish already on. slot:4/mod:3 I believe you can ignore.
SMT
HiPer PPP Monitor
Select a letter for one of the following options: C) Monitor PPP Call Events. I) Monitor a specific interface. N) Monitor the next session that starts up. U) Monitor a specific user. X) Exit the monitor. Please Enter Your Choice :N Monitoring the next session to start up. Decode tracing started, press ESCAPE to stop; press X for hex tracing.
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP CALLBACK 06
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REJ CALLBACK 06
Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP
LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64
...
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REJ MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64
So here you client has rejected Multilink -- Why?
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP
Thus it is not a multilink call any more. Are you trying to have this connection as Multilink ? If so the client has rejected the same above. krish
Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP
Incoming PPP Data on interface: slot:14/mod:21 PAP REQUEST USERNAME = Pstandish PASSWORD = ******* (was unencrypted and correct) Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e b9 8f ...
Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e b9 8f ...
Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e b9 8f ...
Outgoing PPP Data on interface: slot:14/mod:21 PAP ACK Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00
- 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.
On Wed, 24 Nov 1999, Scott Trautman wrote:
You've identified the essential problem. No, this <client> ISN'T trying to negotiate a multilink connection. Win95 client dialing, doesn't seem to matter what client dials, same result. IE, no the client isn't attempting to bond with another connection.
Win 95 is capable of doing multilink - so it can negotiate, this normal, then rejecting this option is fine. However if a user with the same name is logged in and another user using the same name but from a different machine is trying to login and he fails - that problem would mean that either you have port limit or max-channels setup for the user or the default user.
It's picking up on something that makes it think this is a 2nd channel in a multilink connection, and that's not correct at all!
NO its not picking up anything, it clearly rejected multilink and told the hiper arc that it cannot do multilink, thats fine. The rejection of the call was not present in the ppp trace. So first check if the user has any port limit or any max-channel setup on this hiper arc - if you the call drop is valid. krish
SMT
-----Original Message----- From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] Sent: Tuesday, November 23, 1999 10:23 PM To: Scott Trautman Cc: 'usr-tc@lists.xmission.com'; 'paul_steffen@planar.com' Subject: RE: (usr-tc) Dropped connections for 2nd login with same login ID . MPPP weird thing?
On Wed, 24 Nov 1999, Scott Trautman wrote:
Okay, hup two three four ppp mon on your door.
slot:14/mod:21 is the Pstandish session in question. No data from slot:14/mod:5, which is the Pstandish already on. slot:4/mod:3 I believe you can ignore.
SMT
HiPer PPP Monitor
Select a letter for one of the following options: C) Monitor PPP Call Events. I) Monitor a specific interface. N) Monitor the next session that starts up. U) Monitor a specific user. X) Exit the monitor. Please Enter Your Choice :N Monitoring the next session to start up. Decode tracing started, press ESCAPE to stop; press X for hex tracing.
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP CALLBACK 06
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REJ CALLBACK 06
Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP
LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64
...
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REJ MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64
So here you client has rejected Multilink -- Why?
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP
Thus it is not a multilink call any more.
Are you trying to have this connection as Multilink ? If so the client has rejected the same above.
krish
Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP
Incoming PPP Data on interface: slot:14/mod:21 PAP REQUEST USERNAME = Pstandish PASSWORD = ******* (was unencrypted and correct) Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e b9 8f ...
Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e b9 8f ...
Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e b9 8f ...
Outgoing PPP Data on interface: slot:14/mod:21 PAP ACK Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00
- 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.
Scott, Post us this users radius config, or if they don't have a radius config, post us your default config. Like krish says chances are you have port-limit or max-channels settings going on that are causing this problem. Brian On Tue, 23 Nov 1999, Tatai SV Krishnan wrote:
On Wed, 24 Nov 1999, Scott Trautman wrote:
You've identified the essential problem. No, this <client> ISN'T trying to negotiate a multilink connection. Win95 client dialing, doesn't seem to matter what client dials, same result. IE, no the client isn't attempting to bond with another connection.
Win 95 is capable of doing multilink - so it can negotiate, this normal, then rejecting this option is fine. However if a user with the same name is logged in and another user using the same name but from a different machine is trying to login and he fails - that problem would mean that either you have port limit or max-channels setup for the user or the default user.
It's picking up on something that makes it think this is a 2nd channel in a multilink connection, and that's not correct at all!
NO its not picking up anything, it clearly rejected multilink and told the hiper arc that it cannot do multilink, thats fine. The rejection of the call was not present in the ppp trace. So first check if the user has any port limit or any max-channel setup on this hiper arc - if you the call drop is valid.
krish
SMT
-----Original Message----- From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] Sent: Tuesday, November 23, 1999 10:23 PM To: Scott Trautman Cc: 'usr-tc@lists.xmission.com'; 'paul_steffen@planar.com' Subject: RE: (usr-tc) Dropped connections for 2nd login with same login ID . MPPP weird thing?
On Wed, 24 Nov 1999, Scott Trautman wrote:
Okay, hup two three four ppp mon on your door.
slot:14/mod:21 is the Pstandish session in question. No data from slot:14/mod:5, which is the Pstandish already on. slot:4/mod:3 I believe you can ignore.
SMT
HiPer PPP Monitor
Select a letter for one of the following options: C) Monitor PPP Call Events. I) Monitor a specific interface. N) Monitor the next session that starts up. U) Monitor a specific user. X) Exit the monitor. Please Enter Your Choice :N Monitoring the next session to start up. Decode tracing started, press ESCAPE to stop; press X for hex tracing.
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP CALLBACK 06
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REJ CALLBACK 06
Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 05 ac 04 00 04 30 00 01 00
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 09 f5 c0 31 PROTO_COMP AC_COMP
LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64
...
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_REJ MPP_MRRU 05 ea MPP_ENDPTID 03 00 c0 49 11 58 64
So here you client has rejected Multilink -- Why?
Outgoing PPP Data on interface: slot:14/mod:21 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP
Thus it is not a multilink call any more.
Are you trying to have this connection as Multilink ? If so the client has rejected the same above.
krish
Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b2 e2 00 04 30 00 01 00
Incoming PPP Data on interface: slot:14/mod:21 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 ea d3 f3 PROTO_COMP AC_COMP
Incoming PPP Data on interface: slot:14/mod:21 PAP REQUEST USERNAME = Pstandish PASSWORD = ******* (was unencrypted and correct) Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d2 00 00 30 06 ac 6b 98 a3 b4 19 9c 2e b9 8f ...
Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d3 00 00 30 06 ac 6a 98 a3 b4 19 9c 2e b9 8f ...
Outgoing PPP Data on interface: slot:4/mod:3 IP_DATA 45 00 02 40 39 d4 00 00 30 06 ac 69 98 a3 b4 19 9c 2e b9 8f ...
Outgoing PPP Data on interface: slot:14/mod:21 PAP ACK Incoming PPP Data on interface: slot:4/mod:3 CTCP_DATA ff 03 00 2d 64 08 b0 ca 00 02 18 00 01 00
- 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.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal 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 (3)
-
Brian -
Scott Trautman -
Tatai SV Krishnan