On Sat, 22 Jan 2000, Terry Kennedy wrote:
I'l chime in here. Just recently we put together the stats to confirm the same drop rates, at the same time we implemented a survey to our customers. Guess what? they get dropped all the time. Different ones at different times in differing amounts. This by and large the single greatest complaint against this ISP. A lot of these same people have more than one one accont and are glad to point out the it doesn't happen with their "other" ISP. These are people who connect, auth and pass data. I haven't had the chance yet to together stats on the disconnect reason tied directly to calls, I can tell you that I see a lot of v42DisconnectCmd. I am thinking of disabling it.
Disable v.42? Uh... not a good idea. v.42bis maybe, if your DSP cards have a dead CPU (like one of mine appears to), but not v.42. To really get to the bottom of the disconnect stuff, you have to look at BOTH disconnect reasons -- one logged by the ARC, one logged by the modems. You have to look at the two together to see why the connection dropped... otherwise you'll NEVER be able to figure out what to blame on the customer, or the customer's modem, or 3Com's code, or your own setup. Here's an abridged version of something I wrote for our support people that might help. If anyone's got any corrections I'd like to hear 'em... ---------------- ARC disconnect reasons: User-Request: NORMAL disconnect -- the user's computer specifically requested to shut the PPP session down gracefully. If the user did not, maybe Windows did without their consent. Check the "idle timeout" setting, because on many versions of Windows 95/98 it's broken and disconnects non-idle sessions. Also Outlook Express 5 seems to default to "hang up after sending and receiving mail" for some dumb reason. There are other reasons Windows can hang up when it shouldn't, but I won't get into the rest of these here -- the point is the Total Control thinks it's a clean disconnect so it's not at the ISP end generally. Lost-Carrier: Customer's modem hung up unexpectedly, without requesting a clean shutdown of the PPP session. See the modem disconnect reason (below) for why. Idle-Timeout: Self explanatory, I hope. Session-Timeout: Also self explanatory, I hope. PAP-Auth-Failure: They connected and started PPP negotiation but never entered a correct username/password. CHAP-Auth-Failure: If you are like us and don't support CHAP, tell the user to turn off "require encrypted password" in their Dial-Up Networking settings. Admin-Reboot: You rebooted the ARC. Admin-Reset: You rebooted a modem card. NAS-Request: You typed "disconnect user jimbob". NAS-Error: PPP negotiation failed. This can be lots of things... user trying to use a specific IP address instead of the one you assign them, screwed up TCP/IP stack, screwed up dial-up networking, connecting without error correction, trying to use SLIP... Radius-Timeout: The ARC can't talk to your Radius server. User-Error: Not sure. ----------------- Modem disconnect reasons: v.42 Normal Disconnect Command Received MNP Normal Link Disconnect Command Received Gateway Disconnect Command Received Normal User Call Clearing DTR Dropped These are all NORMAL. The first two indicate the customer's modem requested a disconnect (usually DTR was dropped to their modem), the others indicate the ARC specifically dropped DTR to your modem card. Almost always this is paired with "User-Request" from the ARC, and the same gotchas apply if the user insists they did not disconnect. Carrier Loss DS0 Teardown v.32/GSTN cleardown These mean the user's modem hung up abruptly. If this is paired with "User-Request" from the ARC, then it's normal. (Sometimes the line drops before the v.42 disconnect command arrives, and that's normal.) Otherwise it could be almost anything: Call Waiting, computer got turned off/rebooted, unplugged the phone, or sometimes a cheap Winmodem will do this too. Retransmit limit Unable to Retrain v.42 SABME Timeout These mean there was too much noise on the line to successfully send data -- it kept retrying and failed, so it gave up and hung up. Again, Call Waiting or phone line problems can cause this. Protocol Error Event 95% of the time this is a Rockwell HCF modem. Send the user to http://808hi.com/56k/rockhcf.htm and have them download newer drivers. DSP Reboot Obvious. v.42 Invalid Codeword v.42 Invalid Command v.42 String Too Long/rootless tree Link Security Abort This is a v.42bis compression problem. Turn off v.42bis hardware compression, or have the user do it. According to 3Com, this means you've got a blown CPU on your DSP card, so if you see this on either the first 12 or last 12 modems of a DSP card, get it replaced -- but until you can do that, disabling compression will solve it. Packet bus generic error Packet bus received LS while link up Something got screwed up between the DSP and the ARC. We don't see this much but it is a 3Com-related problem. 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 "Don't sweat the petty things, and don't pet the sweaty things." - 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.