UUCP problems between AIX and AT&T after 4.1.4 upgrade


desc:  The customer is trying to transfer files between a rs/6000 to
       a unix system running at&t unix but it fails with an error
       message of:  failed (login failed)

act:  I asked the customer to read to me his Systems file entry:
      manco Any Acu Any phone\# "" \\r\\d\\r\\d in:--:in: nuucp word: comm
      The customer will fax in his uutry but he says that it stops
      at the point where it expects to receive a login but it never
      gets it, it just hangs there expecting to receive a login.
      The customer can cu to the other machine and get a clean login
      with no problem.  I had the customer check the other system
      and for one thing, it didn't have his correct machine name so
      we corrected that but of course it made no difference when he
      did his uutry.  The user 'nuucp' is a valid user also.  He can
      login using nuccp and he gets the 'shere' back.  The customer
      is going to fax in his Systems, Permissions, Devices, and Dialers
      files from both systems and his Uutry from the risc to this unix

      The customer can use uucp from this risc to other aix and sco
      machines, he only has a problem when going from this risc to
      to other at&t unix systems.  I told the customer a number of times
      to let's try setting up uucp between his system and one of our
      lab systems but the customer never even acknowledged that idea,
      so we tried to continue working on the problem.  I tried to 
      dial from a modem on a 4.1 machine here and I got garbage 
      characters.  I lowered my baud rate down to 1200 (because the
      customer said that the modem on the at&t system is a 2400 modem)
      but even at that speed, I got garbage characters.  I asked the
      customer is there anyone there that can check the setup of the
      tty for the modem on the at&t system but he said no one there
      could.  This does seem like it would be a problem in his Systems
      file entry and we have played around a little with the chat
      script and it has made no difference.  We tried taking away the
      ""\\r\\d\\r\\d  entry comlpletely and then ran the uutry but the
      same thing happened.  I had the customer use this sequence also:
      ""\\d\\d\\d\\r  but again there was no change, we still never 
      receive a login prompt.  The customer still hasn't faxed in
      all of his files, so, he will do that and speak with someone
      who works with the at&t system.

      I had the customer run the command lslpp -l and
      it is at version  I had the customer check the nuucp
      user on the remote machine and it has a uid of 10.   I had the
      customer attempt to use the 'uucp' user but still we hang
      waiting for the login prompt.  I worked on setting up uucp from 
      the customer's rs/6000 to one of the lab systems here at 4.1.4
      and the same thing happend when the  the customer did the uutry. 

Customer is trying to dial from his AIX system to the AT&T system
is the AT&T system's TTY was configured at 7,even,1 and not 8,none,1.
I sent you /usr/sbin/uucico from an AIX 3.2.5 system and put it on
your AIX 4.1.4 machine and your transfers started working fine.

You need the following uucico fix:

4.1 uucico has changed in that:

 In 3.2.5, uucico would strip the high bit from incoming
 data during the connection phase (when executing the
 chat script). This was removed in 4.1, with the result
 that if the other system is set to use 7 bits with parity
 we won't be able to communicate with them.
 uucico now handles incoming data that is 7 bits with parity
 during the connection phase.

This is apar IX53737.

U440344|IX53737|186061|bos||bos41C|aix@ausaix02@2035|UUCICO NO LONGE
U440406|IX53737|186061|bos||bos41C|aix@ausaix02@2035|UUCICO NO
U440931|IX53737|170935|IPP|IPP|bos41C|aix@ausaix02@2035|Create 4.1 IPPs|

This has resolved the problem.

Support Line: UUCP problems between AIX and AT&T after 4.1.4 upgrade ITEM: BR6483L
Dated: December 1996 Category: N/A
This HTML file was generated 99/06/24~13:30:20
Comments or suggestions? Contact us