billb@amcad.UUCP (Bill Burton) (04/12/88)
Hello fellow netlanders. I'm trying to get our SysV.2 machine to talk to an SCO Xenix 2.2.1 system at 2400 baud. However, the Xenix system answers the phone at 1200 baud. After connecting, I send a break to change baud rates. The modem on the Xenix system immediately hangs up. This happens whether using cu or uucp. The following is the L.sys entry on the SysV machine: /usr/lib/uucp/L.sys: ksgbbs Any,1 ACU 2400 1234567 "" BREAK ogin:-BREAK-ogin: uucp Here is the ttys file on the Xenix machine: /etc/ttys: 1mtty01 1mtty02 1mtty03 1mtty04 1mtty05 1mtty06 1mtty07 1mtty08 1mtty09 1mtty10 1mtty11 1mtty12 06tty1a 06tty2a 12tty1A <- modem port 1 12tty2A <- modem port 2 Interestingly enough, when the Xenix system dials our SysV machine, and sends a break to skip to 2400 baud the line drops. I'm wondering if the break is causing the problem. I call our SysV machine regularly and send a break from Kermit 2.30, Pibterm, and Procomm without a problem. Xenix doesn't appear to be able to handle it in either direction. Also, the Xenix machine is devoid of any scripts to clean up the uucp log. Does anyone have a scripts to do this? Thanks, Bill ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Name: William D. Burton US Mail: American Academy of Arts and Sciences 136 Irving St., Cambridge, MA 02138-1996 Audible: 1-617-576-5023 UUCP: ...!husc6!amcad!billb ARPANET: billb%amcad.uucp@husc6.harvard.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
donegan@stanton.TCC.COM (Steven P. Donegan) (04/12/88)
In article <151@amcad.UUCP>, billb@amcad.UUCP (Bill Burton) writes: > Hello fellow netlanders. I'm trying to get our SysV.2 machine to talk to > an SCO Xenix 2.2.1 system at 2400 baud. However, the Xenix system > ksgbbs Any,1 ACU 2400 1234567 "" BREAK ogin:-BREAK-ogin: uucp I use the followin entry on my xenix system to talk to other xenix systems, perhaps this will help: sysname Any,2 ACU 2400 1234567 ogin:-@-ogin:-@-ogin: uucp > 12tty1A <- modem port 1 > 12tty2A <- modem port 2 I have modified the /etc/gettydefs file on my system to start the cycle at 2400, then 1200, then 300 and back to 2400. Modify entry 3 to cycle 3-2-1 in yours and you shouldn't have any problem (a 'feature'/bug of SCO xenix is that a framing error will be interpreted like a break, so sending any character at the wrong baudrate will cause the system to cycle to the next baudrate) > Also, the Xenix machine is devoid of any scripts to clean up the uucp > log. Does anyone have a scripts to do this? I use my own cleanup script, but the xenix command uuclean does a fair job. -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/13/88)
I think the problem you are seeing is caused by initialization noise as
the connect is made. Two suggestions on fixing it:
A) don't send the initial break, use a return instead, like:
"" "" gin:--gin:-BREAK-gin:--gin:
I have no idea why this works better.
B) unless there is a political reason for doing things low to high,
change the speeds to cycle from highest to lowest, repeating the first
one. This takes care of connect noise. I have been running a BBS for
several years, and I use 2400-2400-1200-300 without problems. It will
require minor changes in others login scripts if they're still using
1200.
good luck
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mejohn@jclyde.UUCP (John B. Meaders Jr.) (04/14/88)
In article <151@amcad.UUCP> billb@amcad.UUCP (Bill Burton) writes: >Here is the ttys file on the Xenix machine: >/etc/ttys: >12tty1A <- modem port 1 >12tty2A <- modem port 2 ^ You need to make sure this 2 in /etc/gettydefs is pointed to the 2400 baud sequence. I use 3 on my system here (2400 baud) and then cycle to 1200 and 300 and back to 2400 baud. Hope this helps. -- John B. Meaders, Jr. 1114 Camino La Costa #3083, Austin, TX 78752 ATT: Voice: +1 (512) 451-5038 Data: +1 (512) 371-0550 UUCP: ...!uunet!utastro!bigtex!jclyde!john or john@jclyde.UUCP
jack@turnkey.TCC.COM (Jack F. Vogel) (04/15/88)
In article <10387@steinmetz.ge.com> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes: > >I think the problem you are seeing is caused by initialization noise as >the connect is made. No, the problem is not noise, the problem is as a couple of posters have suggested, without knowing why, the login script. > "" "" gin:--gin:-BREAK-gin:--gin: > I have no idea why this works better. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The original posters login script started like this: "" BREAK ogin:....... The reason this causes problems is that it says "expect nothing, send a break". But this never gives time for getty to get its login prompt out the port, it then gets "confused" and drops the line. As the original poster also noticed it happened in both directions, nobody's getty likes to be interrupted before its had its say :-} :-}. Your modified script, Bill, has the same effect as saying: ogin:-\b-ogin:.....It gives the getty the time to put out a prompt and if it's gibberish it sends a break. The whole question of what direction to cycle the baud rates depends on convenience for a particular system (i.e., do you have more 2400 or 1200 connections). Hope this helps explain, -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...{nosc|uunet}!turnkey!jack Internet: jack@turnkey.TCC.COM
mdc@mcp.entity.com (Marty Connor) (04/18/88)
In article <10387@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > B) unless there is a political reason for doing things low to high, > change the speeds to cycle from highest to lowest, repeating the first > one. This takes care of connect noise. I have been running a BBS for > several years, and I use 2400-2400-1200-300 without problems. It will > require minor changes in others login scripts if they're still using > 1200. > "We've got to stop meeting like this." I was trying to call up random at 1200 baud on its 2400 baud modems today and was having a lot of trouble getting the autobauding to work right. After reading your message it occured to me that the /etc/gettydefs file was set up to do: 2400-300-1200, so if a person dialed in at 1200 he or she had to hit break twice (and this didn't work right 100% of the time either!). so I made the relevant gettydefs lines look like: # # 3-2-1: 2400 - 1200 - 300 baud cycle (dialin modems) # 1 # B300 HUPCL OPOST CR1 NL1 # B300 CS8 SANE HUPCL TAB3 IXANY #\r\n@!login: # 3 2 # B1200 HUPCL OPOST CR1 ECHOE NL1 # B1200 CS8 SANE HUPCL TAB3 ECHOE IXANY #\r\n@!login: # 1 3 # B2400 HUPCL OPOST CR1 ECHOE NL1 # B2400 CS8 SANE HUPCL TAB3 ECHOE IXANY #\r\n@!login: # 2 so that when you call in, you get a getty listening at 2400 baud, and then 1200, and then 300. Makes a little more sense. If you have people complaining that reaching your system at 1200 baud is a pain, you might try this little tweak to your gettydefs file. Double your money back guarantee. ahem. Anyway, random.entity.com and mcp.entity.com seem to like it... -- ---------------- Marty Connor Director of Innovation, The Entity mdc@mcp.entity.com, ...{harvard|uunet}!mit-eddie!spt!mcp!mdc
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/19/88)
In article <179@turnkey.TCC.COM> jack@turnkey.TCC.COM (Jack F. Vogel) writes: [ lots of useful info ] | time to put out a prompt and if it's gibberish it sends a break. The | whole question of what direction to cycle the baud rates depends on | convenience for a particular system (i.e., do you have more 2400 or | 1200 connections). Well... not entirely. If you have a line answer at 1200, it will take a break to get it to 2400 (or higher). However, if the line is at a higher speed, say answers at 2400 and you want 1200, a RETURN will generate a framing error, which is how BREAK is detected, and cause the speed to shift. Because (a) this is more intuitive for humans, and (b) some old version of SCO don't seem to send real breaks, I went with high speed first on all of the systems I operate. Like all hardware characteristc, this may vary, and you may get an upshift on RETURN just fine. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me