wmucs
asked on
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?
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?
ASKER
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/sa
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.
/etc/inittab contains:
sc:234:respawn:/usr/lib/sa
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.
(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.
ASKER
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....
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)
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)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Heiko,
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.
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.
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.
Heiko
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.
Heiko
ASKER
Ahh!
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! :-)
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! :-)
ASKER
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?
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?
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.
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.
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).