Solaris 2.5.1 UUCP/PPP dialout problem.

Posted on 1997-11-18
Medium Priority
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
  • 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.
Industry Leaders: 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!


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 140 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

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

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

Unable to change the program that handles the scan event from a network attached Canon/Brother printer/scanner. This means you'll always have to choose which program handles this action, e.g. ControlCenter4 (in the case of a Brother).
How to fix a SonicWall Gateway Anti-Virus firewall blocking automatic updates to apps like Windows, Adobe, Symantec, etc.
In a previous video, we went over how to export a DynamoDB table into Amazon S3.  In this video, we show how to load the export from S3 into a DynamoDB table.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Suggested Courses

579 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