Path: utzoo!utgpu!water!watmath!uunet!lll-winken!pacbell!att!gladys!rbdc!andy From: andy@rbdc.UUCP (Andy Pitts) Newsgroups: unix-pc.general Subject: Re: (Long) Why can't I get PCOMM to work with my Trailblazer? Summary: More unknown bugs. Message-ID: <562@rbdc.UUCP> Date: 16 Sep 88 08:41:05 GMT References: <454@kosman.UUCP> <559@rbdc.UUCP> <456@kosman.UUCP> Reply-To: andy@rbdc.UUCP (Andy Pitts) Organization: Red Barn Data Center, Winston-Salem, NC. Lines: 53 In article <456@kosman.UUCP> kevin@kosman.UUCP (Root) writes: > >All the rest of what Andy wrote made good sense, and some of it made me blush. >Here, however, he falls prey to the RTFM trap: he believed what he read. >In a long debugging session with Telebit, we found that in certain config- >urations, S92 causes the firmware to go south on outgoing calls. >[...] Gee, I didn't know about that one. Thanks, it could explain the occasional bug I am seeing. I'm sorry if I made you blush, it was not my intent. While we are on the subject of hidden bugs, maybe we should post these little pieces of information when we find them. It may help someone. On that theory here are a few more. According to Telebit, if S58 is set to something other than 0 when making using uucp 'g' protocol spoofing, the modems attempt to flow control can mess things up. It usually just cuts throughput but can sometimes cause the transfer to fail. I have tried sending files using uucp with S58 set to 0 and 2 and found that there is about a 5 - 10% improvement with S58=0. The following is unconfirmed by Telebit. I posted it to comp.dcom.modems a few days ago and should have cross posted it here for those who don't get comp.dcom.modems. I'll apologize in advance if you have seen it before. There appears to be a bug in the firmware when S52=2 (restore EEROM parameters when DTR drops). I have talked with Telebit about this, but they have never let me know if they confirmed this. If the Telebit is connected to a distant modem and the distant modem drops carrier there appears to be a period of time following loss of carrier that the Telebit will ignore DTR. This means that if you establish a PEP connection with another Telebit by temporarily setting S50=255 as part of the dialing sequence, and the distant system drops carries, the Telebit will not be reset when your system drops DTR immediately after DCD drops. This leaves S50=255 and the Telebit will continue to answer with PEP tones until the modem is powered off or DTR is forced high and dropped again. The problem could be duplicated on my system as follows: Use cu to call a distant Telebut in PEP mode (cu sets S50=255 in its dialing sequence). Login to the other system and type ^D forcing the other system to drop carrier. My system sees DCD drop and drops DTR. The Telebit will not be reset. Use cu as above and login. Now drop the connection by exiting cu (~.) forcing my system to drop DTR while the connection is up. The Telebit will be reset. This problem also showed up with uucp. Frequently the modem would not be reset after a uucp call to another Telebit because the distant uucico would drop carrier first. -- Andy Pitts andy@rbdc.UUCP : "The giant Gorf was hit in one eye by a stone, bakerst!rbdc!andy : and that eye turned inward so that it looked kd4nc!gladys!rbdc!andy : into his mind and he died of what he saw there." pacbell!gladys!rbdc!andy : --_The Forgotten Beast of Eld_, McKillip--