Folks, We have a customer who is currently using MSn but wants to switch over to us. We are running TC racks with HiPerArcs. I've done everything with this guy (delete DUN, delete dialup adapter, delete TCP/IP etc..). The problem is (I think) is that he is requesting a callback under LCP. I cannot find anyweher in Windows 98 where he has this setup. Here is the HiPerArc trace: Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:5/mod:4 007d 21 7d 21 7d 7e 00 00 01 Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP CALLBACK 06 Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REJ CALLBACK 06 Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP CALLBACK 06 Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REJ CALLBACK 06 Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP CALLBACK 06 Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REJ CALLBACK 06 Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 9f 85 df 0b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Then it disconnects with a 650 error on his end. Can someone poit me in the right direction ? Thanks, Jeff CMPQwk 1.42-21 9999 - 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 Jeff Binkley
Incoming PPP Data on interface: slot:5/mod:4 007d 21 7d 21 7d 7e 00 00 01
Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP CALLBACK 06
Outgoing PPP Data on interface: slot:5/mod:4 LCP CFG_REJ CALLBACK 06
They request callback and you send a Reject back for it...that they send it a couple more times is a broken implementation.
Incoming PPP Data on interface: slot:5/mod:4 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 d0 77 PROTO_COMP AC_COMP
But...eventually it does give up on it...so...while this will slow down the login process eventually (once they get the point where they are successfully logging in)...its not preventing it. If you can fix this, great, it'll prevent a couple of round-trip times, but it won't prevent them from logging in.
Then it disconnects with a 650 error on his end. Can someone poit me in the right direction ?
You're going to need to get a log from their end probably. Here's the problem that I see in your trace. Their side seems to not being responding in any way to what you're sending. This actually will probably change my above advice. From what I've seen, Windows DUN tries to negotiate callback control protocol, but will drop it, as should be the case when it gets a config reject. Based on the rest of the trace though, the doze machine is not responding to your config requests at all (no acks, naks or even rejs), it also seems to not be seeing your rejects to its initial rejects (as discussed above), and also not seeing your acks once it drops the callback as it continues to send new requests. Its odd, but it looks like you've got one-way communications here, but not two-way. You're seeing what they're sending, but they're not seeing what you're sending. I guess there is a possibility that their system is seeing your packets as corrupt or something like that for some reason and is thus silently dropping them. That's why I suggest getting a log from their side. There's an option in DUN (don't ask me where to find it) to record a PPP log (note, this is *NOT* the modem log file that is much easier to find). Enable that and look at the output...that might give you some insight into what's happening. Feel free to drop a line to me or the list and someone (myself, if noone else gets to it) can help decipher it. -- 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.
Also sprach Jeff Mcadams
Also sprach Jeff Binkley
Incoming PPP Data on interface: slot:5/mod:4 007d 21 7d 21 7d 7e 00 00 01
Dang! Forgot to comment on this one... I haven't a clue what this packet it. The HiPer Arc flags it as packet type 007d which rfc1661 says is "reserved (Control Escape)" What on earth in doze is using that? I haven't a clue...it doesn't seem to be a significant problem though as its not repeated and doesn't through the Arc off its stride in any way. -- 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.
participants (2)
-
Jeff Mcadams -
jeff.binkleyļ¼ asacomp.com