jim (04/22/83)
This is not really a bug in uucp, but in 4.1bsd getty. It is a long story, so you may want to skip to the end of this message if you aren't interested in grungy details. The folks at Berkeley apparently have all their terminals ports wired up to ignore DCD and assume that the terminal is always ready. This means that if you unplug a Berkeley terminal, the system still thinks there is a terminal connected to the line, and it will send a "login:" prompt down the disconnected line. The problem with this is that an unconnected line of sufficient length will "ring", and the login prompt will echo back to the computer. The computer will see the prompt and echo it right back down the unconnected line. You end up with a steady stream of characters in and out the port, and a steady stream of dying and restarted gettys, which puts a big load on the system. Berkeley's "solution" to this problem was not to connect up DCD, but rather to put a 1 second delay into getty after displaying the prompt and before turning on echoing. It flushes any characters received during the delay. Not only is this confusing to the users, it is also confusing to uucp, which tries to send the login name right after it sees the login prompt. The login name gets dropped by the one second delay. I have countered this by putting my own one second delay into uucp after getting the login prompt. When I did this, my percentage of failed logins dropped from 30% to 5% (actual figures, taken from LOGFILE -- at the time, all our neighbors were 4.1bsd sites). The standard uucp does not support delays, unfortunately, but there are a lot of modified conn.c's floating around that do. Our L.sys line now look like this: blah blah login: \duucp word: uucp In our case, the "\d" provides the one second delay. Alternatively, you could modify conn.c to always put in a delay before it sends anything.
smh (04/23/83)
My experience is also that the right magic can greatly decrease the probability of unsuccessful login negotiations in uucp. In particular, some long distance connections are prone to inserting a few garbage characters at startup, and these can get seen by the called login process. If the timings of the two systems are right (or actually, wrong), the uucp and getty/login can get out of phase, particularly if the uucp login gets eaten by the stty noecho after the password prompt. (I had the greatest problems with this uucp'ing to Europe!!!) Anyway, the fix is to start the login script with something like: \n delay \n delay One might even want to throw in an EOT at the start, in case the called system doesn't implement SIGHUP on carrier lossage, but I have not found this to be necessary. I have a few trivial modifications to conn.c which allow both delays in the login script and arbitrary C-style \000 escapes. Anyone who wants a copy is welcome to request by mail. I also have various programs and code to support dialin and dialout using a Racal-Vadic PA3451 autodial for both cu and uucp. As above, distribution to anyone who asks. Steve Haflich MIT Experimental Music Studio ...!genrad!mit-eddie!smh smh@mit-eddie@mit-xx