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.