Solaris 2.5.1 UUCP/PPP dialout problem.

Posted on 1997-11-18
Last Modified: 2013-12-23
While trying to establish a PPP link between two Solaris 2.5.1 machines, the dialout routine (config via /etc/uucp/*) appears to be sending ^M instead of the actual *function* of ^M, namely, the end-of-line.  As such, the receiving machine nevers finds EOL after the username is input, and therefore won't ask for the password.

I added \n after the username and password in the /etc/uucp/Systems login sequence, and sure enough, the username and password are now both prompted, and sent.  However, the login always fails, I presume due to the ^M (and now ^J in addition to it) which appear on the line.  (I am seeing these in the /etc/log/asppp.log file by the way, aspppd debug level set to 9.)  According to docs, I shouldn't need to add the \n at all.  I've also tried redefining CR and LF, as far as the modem was concerned, to no avail.  However, if I just use 'tip' and dial out by hand to the other Solaris machine, login is fine, no problems.  When aspppd tries, it fails the login every time.

So, how do I convince the dialout routine to handle the end-of-line like it should?
Question by:wmucs
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 3
  • 2
  • +1

Expert Comment

ID: 1582979
What does your ttymon entry look like in /etc/inittab for the destination port?

Use the -l argument from ttymon to find a corresponding entry in /etc/ttydefs.  What does this entry look like (am particularly interested in the initial settings; sounds like final settings are not a problem).

Author Comment

ID: 1582980
I'm not 100% sure what I'm seeing here.  I believe it's set up to use sac, so on all stations: the Sparc5 not working, the IPC to which it should dial, and my office Sparc5 which regularly runs PPP with no problems:

/etc/inittab contains:
   sc:234:respawn:/usr/lib/saf/sac -t 300

There isn't an entry specifically for ttymon in /etc/inittab on any of these stations.  Or, are you saying that because the one station is supposed to dial *out* it needs a ttymon entry?  I thought ttymon was to accept incoming requests.

Expert Comment

ID: 1582981
Could you post the chat sequence from the Systems file
(passwords edited out, of course) on the dial out machine?

I assume when you use tip sucessfully, you are dialing into
the same port which is  running the same login process (sac),
and using the same username and password as with the
unsuccessful ppp? If so it indicates the problem is with the dialout system.
Manage your data center from practically anywhere

The KN8164V features HD resolution of 1920 x 1200, FIPS 140-2 with level 1 security standards and virtual media transmissions at twice the speed. Built for reliability, the KN series provides local console and remote over IP access, ensuring 24/7 availability to all servers.


Author Comment

ID: 1582982
Nagus, you are correct; dialing by hand is to exactly the same
destination as the auto dialout is given.  Unfortunately, the faculty whose machine it is needed it back at home, even as it is; so I can't get a copy of the chat sequence.

I can tell you that I've done PPP for several years now, between a Solaris machine and a Linux machine (Linux dialing out, Solaris accepting the call), and have had no trouble at all.  The chat sequence looks fine, *except* for the ^M ^J chars, which I did not expect to see, and which refuse to be handled properly.  I'm convinced that the problem lies on the dialing machine, but I can't find *where*.  I've even tried to impose an environment on the autodial routine identical to my login environment, which is the only thing I can think of which would be effectively different between the tip and the PPP dialing; no good.

Some here suggested trying to trick the dialer into using imbedded backspaces to remove the bogus control chars and replace with the right stuff, but that as I recall just added the backspace control chars to the list of other unwanted visible control chars.  *sigh*

I'm beginning to wonder if this is going to take getting my hands on the dialer source code in order to fix it....

Expert Comment

ID: 1582983
What does the dial-in log file show when you log in using TIP?
Does it show usernameCR ? or usernameCRLF ?

As I recall tip uses /etc/remote for the modem setup,
which may be different than the /etc/uucp/* settings.
Make the /etc/uucp settings functionally match /etc/remote and
it should work. (unless this is different under Solaris,
I use SunOs)

Accepted Solution

heiko earned 70 total points
ID: 1582984
UUCP as delivered by SUN does not expect specials like ^M or ^J.

in send string you dont have to send \n or any other as end of line because dialer is sending end of line automaticaly as \n which can be converted depending on stty settings of this port.

for fast functioning dialer:
- test shortest significant part of expect strings (best at end of stream)
- send allways as you type in normaly whitout newlines
- login sequence must end with a valid expect (importend)

then you don't have any problems.


Author Comment

ID: 1582985

Looking back at my original question, perhaps I was a little ambiguous on one point.

I did *not* insert the ^M in the first place -- I had set up PPP exactly as you indicate that I should (which is the way I have known for some time).  The logs of what the dialout routine is actually sending are recorded with the ^M added to the string.  I see it in the logs, though I did not put it in the config files.  At that point, the strings are not being seen as complete by the receiving machine; i.e., when the username is sent, the receiving machine does not see a functional EOL, and waits until timeout for such a char, thus never prompting for the password.  I added the ^J to force the end of line, which resulted in the receiving machine seeing EOL and prompting for password, but the original ^M (which is what I did not add in the first place) is still going through as part of the string, therefore the login fails (no username or password has ^M in it as a significant char, and this problem is adding to the end of both).

The problem then, is since *I* have not put the ^M in any config file, yet it is appearing as converted-to-printable instead of being the effective EOL (which I'm sure the dialer uses of its own accord as a terminator on the string it sends out): What is causing the normal EOL to be converted to "visible" instead of "active", and how can one keep that from happening in this context?

Note that the modem config appears to be fine, since normal dial-out and login via tip has no problems at all.  One additional clarification, the modem is a Motorola Power 28.8, for which the documentation indicates Hayes command set compatibility.  I am therefore using the hayes dialer routine as provided in /etc/uucp/Dialers.


Expert Comment

ID: 1582986
fine ... so far so good

now check stty settings for both sites!!

specialy check OCRNL, ONLCR and same for input.

if both have settings so that \n is accepted as EOL and nothing is to convert, then all should be ok.

check with

stty -a < /dev/ttyxx

while dialer is running.

let me know about youre results.


Author Comment

ID: 1582987

I wasn't aware that stty settings were adjustable before a shell actually started.  I'll have to get the prof to bring the station back onsite and I'll check out those values.  It sounds like that just might be the "missing link" I've been searching for.  I won't be able to get my hands on the remote machine until the first week of January at this point, so I'll respond with my findings as early in January as I can.  Thanks!  :-)

Author Comment

ID: 1582988
I really appreciate your proposed answer and your comments.  I think that may indeed be the problem.  The stty settings for /dev/cua/a are fine *until* the dialer starts up.  Then onlcr becomes -onlcr.  I presume an entry in /etc/ttydefs appropriate for the case will be the fix then?  After having consulted the manpage and the ttymon tags, I plan to insert these lines to /etc/ttydefs:

ttya:38400 opost onlcr:38400 hupcl sane::ttyaB
ttyaB:19200 opost onlcr:19200 hupcl sane::ttyaC
ttyaC:9600 opost onlcr:9600 hupcl sane::ttyaD
ttyaD:4800 opost onlcr:4800 hupcl sane::ttya

Does this look like a reasonable search loop to handle such a case?


Expert Comment

ID: 1582989
definition as loop is ok so far. but i think it's not so good to set "sane" as final flag.
ttymon sets these final settings after a connection request has been made and immediately prior to invoking a port's service. (from manpage)
to ensure right settings leave tested settings for init and final same.


Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Setting out for Cisco UCS 2 64
Solaris acount issues 44 45
ASA NAT rule change 3 23
Citrix App 7 29
PRTG Network Monitor lets you monitor your bandwidth usage, so you know who is using up your bandwidth, and what they're using it for.
I had an issue with InstallShield not being able to use Computer Browser service on Windows Server 2012. Here is the solution I found.
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Internet Business Fax to Email Made Easy - With  eFax Corporate (, you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, f…

749 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question