jimb@faatcrl.UUCP (Jim Burwell) (07/04/89)
I'm having some strange problems with a Sun 3/160 running Sun OS 3.5/BSD4.3 Bnews 2.11... We have a genuine Hayes 2400 on cua0 and a Concord 224E on cua1.. We are on PBX system, and dial out over the Federal Telephone System. There are several problems: (1.) When a dialout or dialin is done at a specific baud rate, the modem stays locked at that baud rate. We have several people who call in at 1200 baud on both lines, and one uucp account we feed at 1200. After the session is over, the modem remains at 1200 baud, not allowing anyone to dialin again at 2400. (2.) The Concord line always answers with some garbage (usually the ascii string "20" + some \n's), and the "Password:" prompt. I assume this is because getty() is getting modem status strings from the Concord, such as "RING", "CONNECT ####", and so forth. I know the AT commands to shut this stuff off, but I have no idea how to make the system automatically initialize the modem with this command at startup and user logoff. If I could get the OS to send an init string, I could probably solve this problem, and the problem in #1, assuming it would let me send the string at 2400 baud. (3.) For some reason, uucico on our system REFUSES to receive a binary, 16 bit compressed file. The system batching our news must use the -C7 option of sendbatch to encode the file in 7 bit ASCII type format, otherwise, uucico chokes on the news-batch with a FAILED (conversation complete). I can't really figure this out, since our system seems to be able to SEND 8 bit data fine. I have a node off of this system which gets it's news in 16 bit compressed format, and I have no problems. I also just sent a 16 bit compressed file (uucp) to the system we are having trouble with, and THAT even worked.. The only thing that I can think of at the moment which would cause this problem is a modem connection which is using parity. Our system is set up to use 7E1 at login. I don't know if uucico changes the serial port options or not, but if it doesn't, parity (or the expectation of parity) would mess up a g-protocol transfer fast :-). Of course, this doesn't make sense, since we seem to be TRANSMITTING with no problem.. Perhaps this serial port can be configured to send w/o parity, and receive with it? naahh.. BTW, just recieved a 16 bit compressed binary file via UUCP back from the system were having trouble communicating with.. No problem. What is going on here? It only chokes on news? This is bizarre! :-) If anyone has any ideas or help, please get back to me via E-Mail.. I'll post a summary if there is "suitable interest"... Thanx, Jim "the padded cell beckons" Burwell <grin> jimb@faatcrl.UUCP