mrm@sceard.Sceard.COM (M.R.Murphy) (05/05/91)
I've a friend with a 3B1 using OBM to attempt UUCP connection to two systems, each with a TB (one TB+, one 2500). The TB+ system is HDB, locked interface speed 9600baud, hardware flow control. The TB2500 is HDB, locked interface speed 19.2Kbaud, hardware flow control. The TB systems talk fine with systems with 1200baud external Hayes clones, as well as with various 2400baud, 9600baud V.32, and PEP sites, and with each other. The 3B1 will not successfully complete a UUCP session with either TB system. A representative log entry from one of the TB sites is: uucp sitename (5/4-0:55:20,23357,0) OK (startup) uucp sitename (5/4-0:58:50,23357,0) BAD READ (expected 'H' got FAIL) uucp sitename (5/4-0:58:50,23357,0) FAILED (conversation complete) I've been told that the 3B1 is using 3.51. I thought I'd ask for words of wisdom before digging to find out what might be going amiss on the 3B1 (a machine I can recognize by sight:-) end. I figure this might be a common and easily recognizable symptom to folks with experience. Thanks for any help, Mike -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
zaft@slced1.nswses.navy.mil (Gordon C Zaft) (05/05/91)
In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >I've a friend with a 3B1 using OBM to attempt UUCP connection >to two systems, each with a TB (one TB+, one 2500). The TB+ >system is HDB, locked interface speed 9600baud, hardware flow >control. The TB2500 is HDB, locked interface speed 19.2Kbaud, >hardware flow control. The TB systems talk fine with systems >with 1200baud external Hayes clones, as well as with various >2400baud, 9600baud V.32, and PEP sites, and with each other. The >3B1 will not successfully complete a UUCP session with either TB >system. A representative log entry from one of the TB sites is: I believe the notes in osu-cis say that this won't work because the OBM makes noises that the TB+ thinks is PEP but aren't. Perhaps one of the Experts will elaborate further? -- + Gordon Zaft | zaft@suned1.nswses.navy.mil + + NSWSES, Code 4Y33 | suned1!zaft@elroy.jpl.nasa.gov + + Port Hueneme, CA 93043-5007 | Phone: (805) 982-0684 FAX: 982-8768 + ** ..et resurrexit tertia die secundum scripturas, et ascendit in coelum.. ***
bruce@balilly (Bruce Lilly) (05/05/91)
In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >I've a friend with a 3B1 using OBM to attempt UUCP connection >to two systems, each with a TB (one TB+, one 2500). The TB+ >system is HDB, locked interface speed 9600baud, hardware flow >control. The TB2500 is HDB, locked interface speed 19.2Kbaud, >hardware flow control. [ ... ] This is a well-known problem with Telebit modems (at least the TB+) when operated with the interface speed locked. The Telebit puts out a non-standard signal, which causes the 3B1's built-in modem to receive garbage (the 3B1's OBM is rather intolerant of non-standard signals). Telebit refers to this bug as "bit-shaving". If you turn on UUCP debugging, you'll see that the first couple of dozen characters are received OK, then only garbage is received. You can also verify this using cu. Your options are: 1) don't operate the Telebit's with interface speed locked 2) try to get Telebit to fix the problem (1-800-TEL-EBIT) (good luck) 3) trade in the Telebits for another brand of modem 4) use an external modem on the 3B1 which will accept the Telebit's non-standard timing Unfortunately, if you don't have control of the systems being dialed into, options 1,2, and 3, which are various attempts to solve the problem at the source, are not available. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
dave@das13.snide.com (Dave Snyder) (05/06/91)
In article <1991May4.210605.28387@sceard.Sceard.COM>, mrm@sceard.Sceard.COM (M.R.Murphy) writes: > I've a friend with a 3B1 using OBM to attempt UUCP connection > to two systems, each with a TB (one TB+, one 2500). The TB+ > system is HDB, locked interface speed 9600baud, hardware flow > control. The TB2500 is HDB, locked interface speed 19.2Kbaud, > hardware flow control. The TB systems talk fine with systems > with 1200baud external Hayes clones, as well as with various > 2400baud, 9600baud V.32, and PEP sites, and with each other. The > 3B1 will not successfully complete a UUCP session with either TB > system. A representative log entry from one of the TB sites is: > Interesting how this keeps coming up. I must confess, I asked the same question about six months ago. Anyway, the bottom line is... the OBM on a 3B1 will not connect to a Telebit if the modem is using locked interface speeds. The only way for an OBM to connect to a Telebit is to have the Telebit allow auto-bauding. I remember hearing of someone that rewrote getty (or was it uugetty?). I'm pretty sure that this getty (or whatever) solved the problem with out auto-bauding. DAS -- David A. Snyder @ Snide Inc. - Folcroft, PA UUCP: ..!uunet!das13!dave INTERNET: dave@das13.snide.com
bdb@becker.UUCP (Bruce D. Becker) (05/06/91)
In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: |I've a friend with a 3B1 using OBM to attempt UUCP connection |to two systems, each with a TB (one TB+, one 2500). The TB+ |system is HDB, locked interface speed 9600baud, hardware flow |control. The TB2500 is HDB, locked interface speed 19.2Kbaud, |hardware flow control. The TB systems talk fine with systems |with 1200baud external Hayes clones, as well as with various |2400baud, 9600baud V.32, and PEP sites, and with each other. The |3B1 will not successfully complete a UUCP session with either TB |system. A representative log entry from one of the TB sites is: The Telebit does something different when running with interface speed locked, such that connections to 3B1 OBM's won't work. Apparently connection is possible when it runs with unlocked interface, and without flow control.
gandrews@netcom.COM (Greg Andrews) (05/06/91)
In article <98083@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes: >In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >|I've a friend with a 3B1 using OBM to attempt UUCP connection >|to two systems, each with a TB (one TB+, one 2500). [parts of description deleted] >|The 3B1 will not successfully complete a UUCP session with either TB >|system. A representative log entry from one of the TB sites is: > > The Telebit does something different when > running with interface speed locked, such > that connections to 3B1 OBM's won't work. > Apparently connection is possible when it > runs with unlocked interface, and without > flow control. > The most common problem is that the OBM barfs big-time on the Telebit PEP answer tones. The normal way to handle this is to set the Telebit modems to issue the PEP answer tones last (S92=1). The OBM sees just the usual 2400/1200 answer tones and is happy ever after. The thing that Telebit modems do differently with a locked interface speed is perform "stop bit deletion". This is a condition where the transmitting modem leaves off a character's stop bit once in a while, and the receiving modem puts the stop bit back on the character before passing it on to the computer. This is done every 8th character by Telebit modems. However: Stop bit deletion is allowed in the 'specification' (actually the correct term is recommendation) for V.22bis, and that's the only type of connection where Telebit modems delete stop bits. V.22bis is the 2400 bps modulation. A modem that can't handle missing stop bits would seem to be not fully compliant with V.22bis. As far as I know, the OBM is a *1200* bps modem, using the Bell 212 or maybe the V.22 modulation. I'm not aware of any 2400 bps OBMs. Telebit modems don't do stop deletion for Bell 212 connections, so I can't see where that would affect an OBM. I think M.R.'s problem is more likely due to the OBM having trouble with the PEP answer tones rather than stop bit deletion. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
clewis@ferret.ocunix.on.ca (Chris Lewis) (05/06/91)
In article <1991May4.210605.28387@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >[Friend has difficulty between 3B1's OBM and trailblazers] This C program, in addition to setting the line to tone dial (mine won't thru "normal" channels for some reason, sets PIOCOVSPD on the modem which permits it to talk to trailblazers. #! /bin/sh # This is a shell archive. Remove anything before this line, then feed it # into a shell via "sh file" or similar. To overwrite existing files, # type "sh file -c". # The tool that generated this appeared in the comp.sources.unix newsgroup; # send mail to comp-sources-unix@uunet.uu.net if you want that tool. # Contents: phfix.c # Wrapped by clewis@ecicrl on Mon May 6 00:57:58 1991 PATH=/bin:/usr/bin:/usr/ucb ; export PATH echo If this archive is complete, you will see the following message: echo ' "shar: End of archive 1 (of 1)."' if test -f 'phfix.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'phfix.c'\" else echo shar: Extracting \"'phfix.c'\" \(1136 characters\) sed "s/^X//" >'phfix.c' <<'END_OF_FILE' X/* Sample program for bashing the OBM into tone dial and X setting PIOCOVSPD to permit talking to certain modems X (particularly telebits). X The documentation mentions 2.3% speed change for PIOCOVSPD. X That's all I know. X X You are free to do whatever you wish with this code, but X please leave this comment in. X X Chris Lewis, clewis@ecicrl.uucp, Jan 2 1991. X */ X#include <stdio.h> X#include <fcntl.h> X#include <sys/phone.h> X Xmain(argc, argv) Xint argc; char **argv; { X int f; X struct updata upd; X f = open("/dev/ph1", O_RDWR | O_NDELAY, 0); X if (f < 0) { X perror("/dev/ph1"); X exit(1); X } X ioctl(f, PIOCGETP, &upd); /* retrieve Phone parameters */ X upd.c_lineparam &= ~PULSE; /* reverse the sense to set to pulse dial */ X upd.c_lineparam |= DTMF; /* reverse the sense to set to pulse dial */ X X#ifdef NEVER X upd.c_feedback |= SPEAKERON; X upd.c_feedback |= LOUDSPK; X ioctl(f, PIOCDISC, &upd); /* apply PIOCOVSPD for talking to some modems*/ X#endif X X ioctl(f, PIOCOVSPD, &upd); /* apply PIOCOVSPD for talking to some modems, X eg: Telebits */ X ioctl(f, PIOCSETP, &upd); /* set phone parameters */ X} END_OF_FILE if test 1136 -ne `wc -c <'phfix.c'`; then echo shar: \"'phfix.c'\" unpacked with wrong size! fi # end of 'phfix.c' fi echo shar: End of archive 1 \(of 1\). cp /dev/null ark1isdone MISSING="" for I in 1 ; do if test ! -f ark${I}isdone ; then MISSING="${MISSING} ${I}" fi done if test "${MISSING}" = "" ; then echo You have the archive. rm -f ark[1-9]isdone else echo You still must unpack the following archives: echo " " ${MISSING} fi exit 0 -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
bdb@becker.UUCP (Bruce D. Becker) (05/06/91)
In article <1502@das13.snide.com> dave@das13.snide.com (Dave Snyder) writes: | The only way for an OBM to connect to a Telebit is to have the |Telebit allow auto-bauding. I remember hearing of someone that rewrote |getty (or was it uugetty?). I'm pretty sure that this getty (or whatever) |solved the problem with out auto-bauding. There is a uugetty which works with Telebits such that it looks at the modems connect message to find out which "gettydefs" entry to use. Currently the code is in "alpha" state and is tailored for 3B1's, although plans are afoot to generalize it for other versions of Unix and perhaps other modems (hayes-clones, etc). -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "The really important problems require greater earnestness" - J. Cage
clewis@ferret.ocunix.on.ca (Chris Lewis) (05/07/91)
Dave Snyder wrote: |>[about Mike Murphy's friend's failure to connect to a locked Telebit from the OBM] |I asked the same question about six months ago. Anyway, the bottom line is... |the OBM on a 3B1 will not connect to a Telebit if the modem is using locked |interface speeds. The only way for an OBM to connect to a Telebit is to have the |Telebit allow auto-bauding. Bruce Lilly wrote: |This is a well-known problem with Telebit modems (at least the TB+) when |operated with the interface speed locked. The Telebit puts out a |non-standard signal, which causes the 3B1's built-in modem to receive |garbage (the 3B1's OBM is rather intolerant of non-standard signals). |Telebit refers to this bug as "bit-shaving". |Your options are: |1) don't operate the Telebit's with interface speed locked |2) try to get Telebit to fix the problem (1-800-TEL-EBIT) (good luck) |3) trade in the Telebits for another brand of modem |4) use an external modem on the 3B1 which will accept the Telebit's | non-standard timing The phfix program I just posted solved Mike's friend's problem - I just got e-mail from him thanking me for it. I've been using it to connect to my feed (a Sun with a locked speed T2500) for about 5 months. The principle trick is the PIOCOVSPD ioctl. About 6 months ago someone posted something about a OBM utility that he was writing but hadn't finished and mentioned the PIOCOVSPD ioctl in passing, which is where I got the idea to try it. Thank you whoever you were. Phfix was written without docs (so I had to guess at the invocations) to solve the TB problem as well as for some reason the builtin software could no longer set the modem to tone dial. It could use some cleanup by someone who knows the right ioctl invocations. On my system I've installed the invocation of phfix in the /etc/rc near the end. It seems to work "permanently" - ie: it only has to be invoked once on boot. However, I seem to remember someone telling me that phfix will not work with HDB UUCP on the 3b1 because HDB clobbers the setting each time it starts. However, I've experimented a bit, and have found that you can invoke phfix *during* the uucico run to clear the problem. Ie: you start up uucico, and you notice that it's starting to alarm out - at this point you can invoke phfix and the uucico will resync and continue normally. So, you might be able to kludge in a mechanism by which phfix is invoked a fixed time after you've fired up uucico. Alternately, you could modify phfix into a "daemon" to sit quiescent, stat'ing (or access()) the LCK* file[s] for the TB sites every 30 seconds or so. Once it notices a LCK file for the site[s] that has the locked speed TB, then it starts PIOCOVSPD'ing the OBM every 10-15 seconds for 2 minutes. That oughta fix it without putting too much load on the machine. Alternately, those guys who seem to like doing binary debugging might want to work out a binary patch for HDB. I'll be installing HDB one of these days, so maybe I'll get to kludge phfix. Further, it may very well be that phfix will work "normally" even with HDB for incoming calls - because the uucico on the receiving side is unlikely to be as "violent" with its ioctls. If anybody alters phfix.c into a HDB daemon, or simply cleans it up, please let me know. BTW: My feed has informed me that he's set his TB to lock at 1200 when it calls my 3b1. He doesn't remember why he did that. But it is certainly locked at 9600 (or is it 19200 I disremember) when I call his TB. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
gandrews@netcom.COM (Greg Andrews) (05/08/91)
In article <1991May5.121256.4453@blilly.UUCP> bruce@balilly (Bruce Lilly) writes: > >This is a well-known problem with Telebit modems (at least the TB+) when >operated with the interface speed locked. The Telebit puts out a >non-standard signal, which causes the 3B1's built-in modem to receive >garbage (the 3B1's OBM is rather intolerant of non-standard signals). >Telebit refers to this bug as "bit-shaving". > >Your options are: >1) don't operate the Telebit's with interface speed locked >2) try to get Telebit to fix the problem (1-800-TEL-EBIT) (good luck) >3) trade in the Telebits for another brand of modem >4) use an external modem on the 3B1 which will accept the Telebit's > non-standard timing > "Good Luck" is a pretty good sentiment. Why? Because it's NOT a Telebit bug. Bruce, you can call it Telebit's "problem" and "non-standard timing" all day long, but that's simply not the case. As I mentioned in my other article, Stop Bit Deletion (and the corresponding Stop Bit Insertion) are a part of the modulation spec. The modem that can't handle re-inserting the stop bit is the one with the problem. Telebit modems can handle Stop Bit Insertion - guess which modem has the problem? As I'm at home tonight, I can't quote chapter and verse from the specs on this, but you can be certain that I will find it and quote it for you. If it turns out I'm wrong, I'll eat my words on it. My last posting was wrong on one point: Telebit modems perform Stop Bit Deletion in the Bell 212 and V.22 (1200 bps) modulations also - not just V.22bis (2400 bps). > > Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM > -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
jmm@eci386.uucp (John Macdonald) (05/09/91)
In article <1473@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: |The phfix program I just posted solved Mike's friend's problem - I just |got e-mail from him thanking me for it. [ ... ] It solved my problem too. I connect regularily now to a T2500 locked in at 19.2K baud. I just had to comment out the part that was trying to switch to tone dial - I'm too cheap to pay Bell extra money to provide a service that costs them less than the default :-). | [ ... ] About 6 months ago someone posted something about a OBM |utility that he was writing but hadn't finished and mentioned the PIOCOVSPD ioctl |in passing, which is where I got the idea to try it. Thank you whoever you |were. It was Emmet P. Gray (egray@fthood, unless that address is out of date), author of pcomm. I, too, thank you Emmet. |Phfix was written without docs (so I had to guess at the invocations) to |solve the TB problem as well as for some reason the builtin software could |no longer set the modem to tone dial. It could use some cleanup by someone |who knows the right ioctl invocations. On my system I've installed the |invocation of phfix in the /etc/rc near the end. It seems to work |"permanently" - ie: it only has to be invoked once on boot. Same here. |However, I seem to remember someone telling me that phfix will not work |with HDB UUCP on the 3b1 because HDB clobbers the setting each time it |starts. I've not had that happen. It does not seem to get lost for me. I am running HDB on a 3.5 system (soon to be 3.51m, but not yet). -- sendmail - as easy to operate and as painless as using | John Macdonald manually powered dental tools on yourself - John R. MacMillan | jmm@eci386