Solaris 2.5.1 UUCP/PPP dialout problem.

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?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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).
wmucsAuthor Commented:
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.
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.
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

wmucsAuthor Commented:
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....
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)
Heiko BialozytLeiter ITCommented:
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.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
wmucsAuthor Commented:

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.

Heiko BialozytLeiter ITCommented:
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.

wmucsAuthor Commented:

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!  :-)
wmucsAuthor Commented:
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?

Heiko BialozytLeiter ITCommented:
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.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.