karl@uhpgvax.UUCP (Karl Hinck) (10/09/85)
I recently got a telephone bill for one of our dial-outs (a 202c
compatible) that came to over $1000. Most of that was for a 26 hour
call and a 20 hour call, plus some other shorter long calls. No call
on this line has ever lasted more than 50 minutes for the last 3 years,
and the long calls only happened over about a 7 day period (May 28 to
June 3). Everything just went back to normal after that and no one knew
about it until the bills came in. Nothing was changed in our system.
The people on the other end tell me that they reboot their system
every shift (8 hours) and that this hangs up all the lines. They
also hang up if no data is transferred for 2 min.
What I'm leading up to is: Does anyone have any good advice on
how to handle the phone company? They were nice but basically said,
"So What!! Pay up!", and I am not convinced the error is not theirs.
Thanks for listening
--
Karl Hinck
ihnp4!islenet!uhpgvax!karl University of Hawaii
sdcsvax!noscvax!uhpgvax!karl Planetary Geosciences Division
2525 Correa Rd.
(808) 948-6321 Honolulu, Hi. 96822lauren@vortex.UUCP (Lauren Weinstein) (10/15/85)
While any sort of billing error CAN happen, the sort of error you describe, in the time range described (and not involving collect or third party billing) would be very rare. Are you sure there's no chance that the modems wedged and kept the connections open? What kind of modems were on each end? --Lauren--
piet@mcvax.UUCP (Piet Beertema) (10/18/85)
>I recently got a telephone bill for one of our dial-outs (a 202c >compatible) that came to over $1000. Most of that was for a 26 hour >call and a 20 hour call, plus some other shorter long calls. >Nothing was changed in our system. >What I'm leading up to is: Does anyone have any good advice on >how to handle the phone company? They were nice but basically said, >"So What!! Pay up!", and I am not convinced the error is not theirs. Absolutely? We've had this problem long, long ago: transatlantic links lasting for hours.... It turned out uucico was the culprit, hanging indefinitely on noisy lines. Check that your uucico doesn't do the same (pk1.c: routine pkgetpack() should have a "noise count", not looking indefinitely for a SYN char). -- Piet Beertema, CWI, Amsterdam (piet@mcvax.UUCP)
lauren@vortex.UUCP (Lauren Weinstein) (10/20/85)
First of all, I note that the original poster said the problem was with a 202C type modem. This is a half-duplex modem, not used in "normal" applications with Unix, and implies that some specialized application was in use. But in any case, regardless of the type of modem or the application that was running, the original poster said that the computer on one end was rebooted, dropping all the dialup lines, at intervals considerably shorter than the period of time telco claimed the call was in progress. This would seem to absolve software on those machines of responsibility for the problem. If the modem on either side hungup, the phone connection would be broken (and charging stopped) within 30 seconds or less. One likely possibility is that a modem on one side or the other triggered remote self-test mode among both modems. Depending on the modems, this can sometimes cause even DTR to be IGNORED. Some modems spontaneously drop in/out of this mode under certain conditions. I've seen a pair of modems merrily chattering at each other for hours even when the systems at both ends were completely down and DTR was down on both modems. Suddenly, both modems just cleared and went back to normal. The moral is to ALWAYS jumper OFF remote self-test mode within the modems! --Lauren--
smb@ulysses.UUCP (Steven Bellovin) (10/21/85)
> First of all, I note that the original poster said the problem was with > a 202C type modem. This is a half-duplex modem, not used in "normal" > applications with Unix, and implies that some specialized application > was in use. But in any case, regardless of the type of modem > or the application that was running, the original poster said that the > computer on one end was rebooted, dropping all the dialup lines, at > intervals considerably shorter than the period of time telco claimed the > call was in progress. > > This would seem to absolve software on those machines of responsibility > for the problem. If the modem on either side hungup, the phone connection > would be broken (and charging stopped) within 30 seconds or less. The problem with many models of 202 (I don't know for certain about the 202C so I won't be that specific) is that there's no carrier present except when transmitting. Remember that this is a half-duplex modem, and hence does not -- nay, cannot -- transmit a tone when the other end is doing so. It is thus quite difficult to tell when the remote end has hung up, since all the local end can do is (a) let its protocols time out when they don't get ackknowledgements; or (b) *try* to detect dial tone or whatever other random noises your local CO will throw at you when the far end has gone to sleep.
lauren@vortex.UUCP (Lauren Weinstein) (10/22/85)
It's certainly true that the 202 is half duplex and that you cannot get a positive indication of hangup simply from "loss of carrier." However, in the case we're talking about, it doesn't matter. We were told that the far end reset and hung up its modems at a fixed interval. This action ALONE, regardless of what the other end does with ITS modem, will break down the phone connection and stop charging. If party A calls party B and party B hangs up (more than 15 to 30 seconds or so) the call will be terminated. Party A might still have his or her "phone" off hook (if they were a brain-damaged 202 modem, for example) but it'll just be looking into a dial tone or (shortly thereafter) a dialtone timeout siren or recording. The point is that when party A hangs up, the call is broken down immediately. If party B hangs up but party A stays offhook, the call will STILL break down (and charging stopped) after a relatively few seconds. It doesn't matter what party A does at that point. The only case where this doesn't happen is in local calls in extremely old-style step-by-step telephone exchanges, which are few and far between these days. In particular, the sequence I outlined above will definitely break down calls on any conventional long distance circuits, including international circuits, of course. So, if it is indeed true that party B definitely hung up its modems every 8 hours or so, the 24 hour+ phone call could only be explained by a telco billing error, regardless of the type of software or modems in use. --Lauren--
piet@mcvax.UUCP (Piet Beertema) (10/22/85)
>The moral is to ALWAYS jumper OFF remote self-test mode within >the modems! Iff the modem has such a jumper....! Better is to fix your uucico. -- Piet Beertema, CWI, Amsterdam (piet@mcvax.UUCP)
lauren@vortex.UUCP (Lauren Weinstein) (10/24/85)
The case in question (the 24+ hour phone call) was on a 202C modem and nothing to do with uucico or anything similar. I've gotten direct mail from the person with the modem confirming that the application was specialized and half-duplex. Secondly, no changes to any software are going to help get you out of many modem self-test lockup situations, since DTR is frequently IGNORED by the modems in such instances. This is a situation where the hardware must take the responsibility, not the software. All software can do is try drop DTR to try hangup, but if the modem ignores that and keeps the call up the charges are going to continue. Moral: Don't buy modems that force you to keep remote-test enabled! --Lauren--
johnl@ima.UUCP (10/26/85)
> [Hanging up the receiving end usually breaks the circuit.] > The only case where this doesn't happen is in local calls in extremely > old-style step-by-step telephone exchanges, which are few and far between > these days. I note that this problem occurred in Hawaii, where the phone company is a traditionally sleepy subsidiary of ITT. Perhaps there really is an ancient step exchange there. John Levine, ima!johnl