Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!ucbvax!UTAH-CS.ARPA!cetron%utah-ced From: cetron%utah-ced@UTAH-CS.ARPA (Ed Cetron) Newsgroups: mod.computers.vax Subject: Re: Excelan TCP/IP Message-ID: <8701201644.AA23244@utah-ced.ARPA> Date: Tue, 20-Jan-87 11:44:08 EST Article-I.D.: utah-ced.8701201644.AA23244 Posted: Tue Jan 20 11:44:08 1987 Date-Received: Wed, 21-Jan-87 01:58:32 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 33 Approved: info-vax@sri-kl.arpa I saw a similar problem with telnet using the wollongong and tektronix software when inbound from 4.3bsd unix sites.... seems that the mil-std spec for telnet connections is to never send just a by itself....if what is desired is a 'newline' meta-character, then should be sent. If what is desired is really just the then should be sent..... So far so good. Now the early wollongong and tektronix tcp/ip's tried to emulate 4.2bsd WHICH DOES NOT FOLLOW THE SPEC'S. 4.2bsd sends either or just .... What now happens is the following when a 4.3bsd site sends : Loginout is spawned and the gets the string name from the tcp/ip software. It parses out the name and treats this as proper input for the username prompt. It then prompts for the password and parses out the which IS an acceptable password input even though it isn't the correct one and one gets the old 'user authorization failure'..... The correction is to have the tcp/ip code brought up to mil-std and strip out the characters IF they follow a .... What does this have to do with FTP, well, supposedly, FTP uses telnet protocols on the control channel and therefore could be bombing in the same way as telnet did. A good test for this is to turn on log failure alarms, turn on a security operator terminal and bang into it a couple of times and the look at the security log files. -ed cetron center for engineering design Univ of Utah cetron%utah-ced@utah-cs.arpa cetron@utahcca.bitnet