Path: utzoo!mnetor!intacc!mann From: mann@intacc.uucp (Jeff Mann) Newsgroups: comp.unix.aux Subject: Re: Scripts to deal with A/UX's buggy UUCP Message-ID: <1991Apr2.044623.299@intacc.uucp> Date: 2 Apr 91 04:46:23 GMT References: <1991Mar10.194813.10357@panix.uucp> <1991Mar27.014105.5418@intacc.uucp> <1991Mar28.003019.1764@mauxci.uucp> Organization: Inter/Access Artists' Centre Toronto Lines: 130 In article <1991Mar28.003019.1764@mauxci.uucp> dumais@mauxci.UUCP (Paul Dumais) writes: >In article <1991Mar27.014105.5418@intacc.uucp> mann@intacc.uucp (Jeff Mann) writes: >>I don't know if you've done something else to get around this, or what, >>but on my system uucico will die if there is a getty on the line, >>regardless of whether you do an stty -modem. In other words, your >>> # have to worry about a getty. If not, we need to handle the >>> # getty by doing a stty -modem. >>doesn't work for me. I have had to use the old method of specifiying >>run levels which getty can exist in, and using init to turn the getty >>on or off. Am I missing something? Anyone else with the same problem? >>I'm planning to post my code which handles this, but part of it runs >>suid root to handle the init, and if there's another way around it... >> > >I have UUCP working just fine for both dial-in and dial-out on mauxci.UUCP. >There is NO REASON to play with run levels. Alexis has >written some code to enhance the administration of UUCP but he is not mucking >around with gettys or run levels. Just because it works for you, doesn't mean it works for me! :-) The fact is that getty and uucico don't co-exist peacefully on my system, even using the gettydefs that you posted (except for the flow control, which creates a SERIOUS SECURITY PROBLEM - see below). This is as far as I've got debugging uucico/getty: uucico opens and writes to the port ok. However, if anything is received from the modem before connecting (eg. the RRING message), the line is immediately lost. (Paul, this is different from what I told you in e-mail, if you got my e-mail...) If I turn off echo and result codes from the modem, the connection is made by uucico, but then my own /etc/issue and login prompt is written to the port by getty. This really screws things up as far as expect/send sequences go! However, I then receive a message from getty on the console that the line is locked by the uucico process, and getty does not respawn. Looks like getty is sending out /etc/issue and the login prompt BEFORE checking whether the line is locked. Same behaviour with cu. Admittedly, I could re-write all my expect-send sequences to take this into account, but that's just too ugly for me, so I have arranged for getty to be shut off before calling out. Here is the debugging output of uucico with getty turned on: # stty -n /dev/tty0 -modem # /usr/lib/uucp/uucico -r1 -x4 -sweb finds called getto called call: no. tty0 for sys web fixline - speed= 11 login called wanted "" got that wanted help): got ? wanted help): ______System name: web______ userid: (? for help):got that wanted ssword: ame: web______ userid: (? for help): ___-=-=-=-=-=-=-=-___=System name: web______ userid: (? for help): ___System name: web______ userid: (? for help): -=-=-=-=-=-=-=-=-=-=-=-____= Welcome to Matrix! If you have any =____- problems or questions, call the -____= Inter/Access office at 535-got ? exit code 0 # Apr 1 20:29:36 getty[195]: line tty0 locked by pid 192 Note my system's (intacc's) banner and login prompt (stuff about Matrix and Inter/Access) mixed in with the one from the remote system (web). I am able to call web with no problem when getty is turned off. This is the expected behaviour on many older uucp systems (getty must be turned off before calling out), and is also mentioned in some places in the A/UX documentation. Other users (Richard Todd?) have reported being unable to call out with getty active. > >Here are my settings on mauxci: >(Macintosh IIfx, 8MbRAM, 500Mb, A/UX 2.0.1, TrailBlazer Plus) > Mine: Macintosh IIci, 8mbram, 650mb, A/UX 2.0, Trailblazer t2500 Maybe the ci acts differently (unlikely, I think). Maybe you have a different version of getty. Mine is: -rwx------ 1 bin bin 26988 Apr 10 1990 /etc/getty Maybe you are using a serial port board in the NuBus which fixes the problem. I am using the built-in modem port. Maybe you have echo and result codes turned off when calling out, and haven't noticed that your /etc/issue and login prompt are being sent to the port. Maybe it has something to do with the phase of the moon :-) Now, about that flow control - I have already e-mailed Paul about this, but I wanted to make it known to the net: >-- >GETTYDEFS >-- >pd_2400# B2400 # B2400 HUPCL SANE2 TAB3 # ~MODEM ~DTR ~FLOW #login: #pd_1200 > >[stuff deleted] > >BL_19200# B19200 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # B19200 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # FLOW ~DTR ~MODEM #Apple Canada, Inc. (mauxci) \r\n\nlogin: #BL_19200 > >Note: I only use the 19200 line for my TrailBlazer so it points back to itself. >The modem does the baud adjusting. I am using Hardware flow control. > This is a SERIOUS security problem. In order to get the hardware flow control working, you are disabling modem control. Modem control is absolutely essential on an incoming dial-up line. The system MUST have access to the carrier detect line from the modem (which is clipped on Paul's cable diagram). Otherwise, it will be unable to detect when someone has hung up without properly logging out. Humans, at least, do this all the time. That means that the next caller will get the previous caller's shell, including all priveleges!! This setup can also cause several other less serious but potentially nasty problems. DON'T DO THIS!!! Summary: 1. A/UX (at least with built-in serial ports) doesn't support modem control and hardware flow control at the same time. 2. You MUST have modem control on an incoming line. 3. Therefore, you CAN'T use hardware flow control. Period. 4. Therefore, if you are using a Telebit, you can't use auto baud rate adjusting on incoming uucp calls. You must set S50=0 and use the normal method of sending breaks to cycle getty until the proper speed is attained. >. Paul E. Dumais A/UX Specialist Apple Canada, Inc. . >. Internet: dumais@apple.com 7495 Birchmount Rd. . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann Inter/Access Artists' Computer Centre, Toronto [416] 535-8601 | | intacc!mann@cs.toronto.edu Matrix Artists' BBS: [416] 535-7598 2400 8N1 | | ...uunet!mnetor!intacc!mann mann@intacc.uucp [416] 535-1443 Telebit 8N1 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-