hartzell@boulder.colorado.edu (George Hartzell) (08/10/90)
I have two related problems/questions. I'm using an M-2000 running
RISC/os 4.50. I have 48 serial lines strung out through a large
building (almost certainly out of rs232 spec). Some of these serial
lines are connected to PC's and MACs. When some of these machines are
turned off login/getty tries to log in "people" with names like
"mkmkk[m[". Some of my ee type friends tell me that this is because
the M-2000's receive line is no longer tied to ground, and that I can
fix it by placing an "appropriately sized" resistor across the grnd
and receive lines (only definition of appropriate is "one that
works"). I've had mixed success with this, but hope to be able to get
it with a bit of work.
Here are my questions:
1) Does this sound like the best fix?
2) Can someone tell me how to get syslog to ignore/dump to
/dev/null the following messages? I don't need them
cluttering up my log files, I *KNOW* it's happening.
Aug 9 00:16:27 beagle login: LOGIN TIMEOUT ON /dev/ttyi11, mkmkk[m[
Aug 9 00:16:27 beagle login: LOGIN TIMEOUT ON /dev/ttyj9, mkmkk[m[
Aug 9 00:16:41 beagle login: LOGIN TIMEOUT ON /dev/ttyh4, MJMJJRIS
Any help/suggestions appreciated.
g.
George Hartzell (303) 492-4535
MCD Biology, University of Colorado-Boulder, Boulder, CO 80309
hartzell@Boulder.Colorado.EDU ..!ncar!boulder!hartzelljay@mips.COM (Jay McCauley) (08/10/90)
In article <24581@boulder.Colorado.EDU> hartzell@beagle (George Hartzell) writes: <<original problem deleted>> > 2) Can someone tell me how to get syslog to ignore/dump to > /dev/null the following messages? I don't need them > cluttering up my log files, I *KNOW* it's happening. > >Aug 9 00:16:27 beagle login: LOGIN TIMEOUT ON /dev/ttyi11, mkmkk[m[ >Aug 9 00:16:27 beagle login: LOGIN TIMEOUT ON /dev/ttyj9, mkmkk[m[ >Aug 9 00:16:41 beagle login: LOGIN TIMEOUT ON /dev/ttyh4, MJMJJRIS > These are LOG_WARNING messages, and can be ignored by changing /etc/syslog.conf to toss auth.warning. Here is the default syslog.conf: *.err;kern,mark.debug;auth.notice ?/dev/console *.err;kern,mark.debug;auth.notice /usr/adm/console_log *.err;kern.debug;daemon,auth.notice;mail.crit /usr/adm/messages lpr.debug /usr/adm/lpd-errs mail.debug /usr/spool/mqueue/syslog *.alert;kern.err;daemon.err operator *.alert root *.emerg * Change it to: *.err;kern,mark.debug ?/dev/console *.err;kern,mark.debug /usr/adm/console_log *.err;kern.debug;daemon.notice;mail.crit /usr/adm/messages lpr.debug /usr/adm/lpd-errs mail.debug /usr/spool/mqueue/syslog *.alert;kern.err;daemon.err operator *.alert root *.emerg * This does toss the baby with the bathwater, and as soon as you get the wiring fixed somehow (I only do software 8-)), I'd recommend turning back on the auth stuff, as it does provide useful system administrative input. After changing /etc/syslog.conf, you need to tap syslogd on the shoulder with a SIGHUP to get it to reread the file. Alternatively, you can kill syslogd and restart it. >Any help/suggestions appreciated. >g. >George Hartzell (303) 492-4535 > MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 >hartzell@Boulder.Colorado.EDU ..!ncar!boulder!hartzell -- Jay McCauley MIPS Computer Systems, 928 E. Arques, Sunnyvale, CA 94086 (408)524-8211 {decwrl,pyramid,ames}!mips!jay jay@mips.com
jsdy@hadron.COM (Joseph S. D. Yao) (08/17/90)
In article <24581@boulder.Colorado.EDU> hartzell@beagle (George Hartzell) writes: >I have two related problems/questions. ... > ... I have 48 serial lines strung out through a large >building (almost certainly out of rs232 spec). ... >turned off login/getty tries to log in "people" with names like >"mkmkk[m[". ... Tying a resistor across two leads of an EIA RS-232 serial line is a very bad idea. Your EE friends know about "ringing" and things that I don't really understand, but they don't know the EIA standard. DISCLAIMER: I'm a "software engineer" (whatever that is), so I tell people I don't know anything about hardware so they don't expect me to fix the filthy stuff. What I know, I've garnered by research and experience. Your best fix is to use cables that tie the DTR (Data Terminal Ready) lead of your remote terminal or terminal emulator to the DSR (Data Set Ready) lead of your serial port. Then tell your serial board (if you can) that this is a "modem" port, and so should be ignored while the DSR lead is not on. Many people figure they are winning by tying together pins 1 (FRAME ground) and 7 (SIGNAL ground), which is quite illegal by the standard, or leaving pin 1 off entirely; and by putting a lump of solder over pins 4, 5, 6, 8, 20, and 22, to keep the line up all the time. What they win in copper savings, they lose in aggravation such as yours. The DEC 1976 Peripherals Handbook is the last one that had a nice diagram of which pin should be crossed with what in a "null modem" - type cable; I try not to remember these things any more. Joe Yao jsdy@hadron.COM ( jsdy%hadron.COM@{uunet.UU.NET,decuac.DEC.COM} ) arc,arinc,att,avatar,blkcat,cos,decuac,\ dtix,ecogong,grebyn,inco,insight,kcwc, \ lepton,lsw,netex,netxcom,phw5,research, >!hadron!jsdy rlgvax,seismo,sms,smsdpg,sundc,telenet, / uunet / (Last I counted ...)
brudley@mips.COM (Brett Rudley) (08/20/90)
In article <905@hadron.COM> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: >In article <24581@boulder.Colorado.EDU> hartzell@beagle (George Hartzell) writes: >>I have two related problems/questions. ... >> ... I have 48 serial lines strung out through a large >>building (almost certainly out of rs232 spec). ... >>turned off login/getty tries to log in "people" with names like >>"mkmkk[m[". ... > ... > >Your best fix is to use cables that tie the DTR (Data Terminal Ready) >lead of your remote terminal or terminal emulator to the DSR (Data Set >Ready) lead of your serial port. Then tell your serial board (if you >can) that this is a "modem" port, and so should be ignored while the >DSR lead is not on. Many people figure they are winning by tying >together pins 1 (FRAME ground) and 7 (SIGNAL ground), which is quite >illegal by the standard, or leaving pin 1 off entirely; and by putting >a lump of solder over pins 4, 5, 6, 8, 20, and 22, to keep the line up >all the time. What they win in copper savings, they lose in aggravation >such as yours. The DEC 1976 Peripherals Handbook is the last one that >had a nice diagram of which pin should be crossed with what in a "null >modem" - type cable; I try not to remember these things any more. > Yes, I agree using a modem port is a good idea. However MIPS ports do not pay any attention to DSR, they only watch DCD to decide whether or not to complete an open on a modem port. This really should not matter however because a 'standard' null modem will tie DTR (pin 20) to both DSR (pin 6) and DCD (pin 8). On MIPS machines, serial ports can be accessed as either local or modem ports. Device files that refer to the port with a minor number of < 128 (high bit off) are local. If the device file refers to that port with a minor number > 127 (high bit on), it is a modem port. These ports usually have the letter 'm' to signify it is a modem port, ie: crw-rw-rw- 1 root bin 0, 1 Jun 8 08:38 /dev/tty1 crw-rw-rw- 1 root bin 0,129 Jun 8 08:38 /dev/ttym1 Your gettys will now ignore any input until you activate the port on your MAC and it turns on DTR. > Joe Yao jsdy@hadron.COM > ( jsdy%hadron.COM@{uunet.UU.NET,decuac.DEC.COM} ) > arc,arinc,att,avatar,blkcat,cos,decuac,\ > dtix,ecogong,grebyn,inco,insight,kcwc, \ > lepton,lsw,netex,netxcom,phw5,research, >!hadron!jsdy > rlgvax,seismo,sms,smsdpg,sundc,telenet, / > uunet / >(Last I counted ...) -- Brett Rudley {ames,decwrl,pyramid,prls}!mips!brudley MIPS Computer Systems - or - 930 Arques Avenue brudley@mips.com Sunnyvale, CA 94086 (408)524-8151
k2@charly.bl.physik.tu-muenchen.de (Klaus Steinberger) (08/20/90)
jsdy@hadron.COM (Joseph S. D. Yao) writes: >In article <24581@boulder.Colorado.EDU> hartzell@beagle (George Hartzell) writes: >>I have two related problems/questions. ... >> ... I have 48 serial lines strung out through a large >>building (almost certainly out of rs232 spec). ... >>turned off login/getty tries to log in "people" with names like >>"mkmkk[m[". ... >Tying a resistor across two leads of an EIA RS-232 serial line is a >very bad idea. Your EE friends know about "ringing" and things that I >don't really understand, but they don't know the EIA standard. Yeah, but it works, we use that on our old DEC10, there we have similar problems. (10k from send to gnd, and receive to gnd) >Your best fix is to use cables that tie the DTR (Data Terminal Ready) >lead of your remote terminal or terminal emulator to the DSR (Data Set >Ready) lead of your serial port. Then tell your serial board (if you >can) that this is a "modem" port, and so should be ignored while the >DSR lead is not on. Many people figure they are winning by tying That's nice, but impossible most time, because many wirings in the buildings don't have enough wires. Best solution on the long term, I think is to eliminate all those long EIA lines by locally placed Terminalservers. In our installation most of those long lines will go away through servers, and through replacement by PC's and X-Terminals (directly tied to the ethernet). Sincerely, Klaus Steinberger Klaus Steinberger Beschleunigerlabor der TU und LMU Muenchen Phone: (+49 89)3209 4287 Hochschulgelaende, D-8046 Garching, West Germany BITNET: K2@DGABLG5P Internet: k2@charly.bl.physik.tu-muenchen.de