Discussion:
Can't get PPP 2.4.3 to do anything under Linux
(too old to reply)
c***@nycap.rr.com
2006-02-27 19:05:32 UTC
Permalink
I'm trying to get PPP 2.4.3 to link two Linux 2.6 systems via RS-232
without success. I've read this group's FAQ, read
http://www.linux.com/howtos/PPP-HOWTO/index.shtml, and Googled for
other hints but nothing seems to help.

With my new system, I try to follow the directions in section 29 of the
PPP-HowTo neither the preliminary test with no routing nor the more
complete client/server situation works. In both cases, pppd runs,
produces no errors, but there is no ppp0 interface on either system. I
configured and ran syslogd and ran ppp with debug and the log contains
nothing that seems unusual:

Jan 1 00:01:35 Test3 daemon.notice pppd[152]: pppd 2.4.3 started by
root, uid 0
Jan 1 00:01:36 Test3 daemon.notice pppd[152]: Removed stale lock on
ttyAM0 (pid 221)

I have an older system (PPP 2.4.2b3, Linux 2.4) which works but I had
nothing to do with its development and the developer isn't available
for consultation. Using two of the older systems, I can configure a
server and a client, connect them via serial, and ping between them.
I'd hoped to learn something from that. I only learned that the
previous developer got it to work. ;-)

I tarred up the configuration of my old client, restored it on one of
my new systems, adjusted for the difference in serial port device
names, and tried connecting it to my old server. Same results on the
new client: pppd runs but there is no ppp0 interface or helpful message
in the log.

I've got 20 years experience with lots of network systems but no
background with PPP. If someone could point me at a resource that can
explain the lack of activity and information, I would surely appreciate
it. Thanks.

Chris
James Carlson
2006-02-27 19:16:38 UTC
Permalink
Post by c***@nycap.rr.com
With my new system, I try to follow the directions in section 29 of the
PPP-HowTo neither the preliminary test with no routing nor the more
complete client/server situation works. In both cases, pppd runs,
produces no errors, but there is no ppp0 interface on either system. I
configured and ran syslogd and ran ppp with debug and the log contains
Jan 1 00:01:35 Test3 daemon.notice pppd[152]: pppd 2.4.3 started by
root, uid 0
Jan 1 00:01:36 Test3 daemon.notice pppd[152]: Removed stale lock on
ttyAM0 (pid 221)
If you're really running with the "debug" option and if your
syslog.conf file is configured properly, then that's a HIGHLY
suspicious and unusual result.

You should at least have an indication that pppd is opening the port
and attempting to dial or send LCP messages. If there's not even
that, then I'd suspect that the serial port itself is broken.

But, first, please post your complete pppd configuration. There's
little that can be done if complete information isn't provided.
Post by c***@nycap.rr.com
I've got 20 years experience with lots of network systems but no
background with PPP. If someone could point me at a resource that can
explain the lack of activity and information, I would surely appreciate
it. Thanks.
You might try doing 'strace' or whatever the Linux tool is that traces
system calls and see what pppd is doing when it gets stuck.
--
James Carlson, KISS Network <***@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
c***@nycap.rr.com
2006-02-27 19:41:33 UTC
Permalink
Post by James Carlson
... I configured and ran syslogd and ran ppp with debug and the log
Jan 1 00:01:35 Test3 daemon.notice pppd[152]: pppd 2.4.3 started by
root, uid 0
Jan 1 00:01:36 Test3 daemon.notice pppd[152]: Removed stale lock on
ttyAM0 (pid 221)
If you're really running with the "debug" option and if your
syslog.conf file is configured properly, then that's a HIGHLY
suspicious and unusual result.
My command line for invoking pppd is:

pppd debug file /etc/ppp/options.cli1
Post by James Carlson
You should at least have an indication that pppd is opening the port
and attempting to dial or send LCP messages. If there's not even
that, then I'd suspect that the serial port itself is broken.
There's no dialing becaue it's a direct serial connection through a
null-modem connection. Yes, it's possible my serial port is hosed
(though getty on it give me a login prompt and I can log in and work
without any problem).
Post by James Carlson
But, first, please post your complete pppd configuration. There's
little that can be done if complete information isn't provided.
/etc/ppp/options.cli1 (referenced in the command line above) is:

noipdefault
persist
/dev/ttyAM0
38400
name PPPLink

What else would you want to see?
Post by James Carlson
I've got 20 years experience with lots of network systems but no
background with PPP. If someone could point me at a resource that can
explain the lack of activity and information, I would surely appreciate
it. Thanks.
You might try doing 'strace' or whatever the Linux tool is that traces
system calls and see what pppd is doing when it gets stuck.
I tried strace and didn't see much (or saw too much and nothing seemed
to be helpful). I'll try again. Thanks.
James Carlson
2006-02-27 19:48:36 UTC
Permalink
Post by c***@nycap.rr.com
There's no dialing becaue it's a direct serial connection through a
null-modem connection. Yes, it's possible my serial port is hosed
(though getty on it give me a login prompt and I can log in and work
without any problem).
That's helpful to know.

Do the control lines work as well? Do you need to specify "local" to
avoid pppd's use of DCD?
Post by c***@nycap.rr.com
noipdefault
persist
/dev/ttyAM0
38400
name PPPLink
That seems mostly ok.
Post by c***@nycap.rr.com
What else would you want to see?
What's in /etc/ppp/options? There's no way to stop pppd from reading
that file -- it *always* reads it if it's present.

Do you have daemon.debug directed to a file in /etc/syslog.conf? And,
if you had to change that file, did you touch that file into existence
and SIGHUP syslogd?
Post by c***@nycap.rr.com
I tried strace and didn't see much (or saw too much and nothing seemed
to be helpful). I'll try again. Thanks.
Posting some actual output rather than a summary would be helpful.
--
James Carlson, KISS Network <***@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Chris Nelson
2006-02-27 19:59:36 UTC
Permalink
Post by James Carlson
Post by c***@nycap.rr.com
There's no dialing becaue it's a direct serial connection through a
null-modem connection. Yes, it's possible my serial port is hosed
(though getty on it give me a login prompt and I can log in and work
without any problem).
That's helpful to know.
Do the control lines work as well?
I'm not positive and I don't have my breakout box handy.
Post by James Carlson
Do you need to specify "local" to avoid pppd's use of DCD?
I can try that. Thanks for the suggestion.
Post by James Carlson
Post by c***@nycap.rr.com
noipdefault
persist
/dev/ttyAM0
38400
name PPPLink
That seems mostly ok.
Post by c***@nycap.rr.com
What else would you want to see?
What's in /etc/ppp/options? There's no way to stop pppd from reading
that file -- it *always* reads it if it's present.
lock
crtscts
asyncmap 0
modem

Bingo! "modem" seems wrong. Shouldn't that be "local". (Though this
same configuration works on my older system with PPP 2.4.2.)
Post by James Carlson
Do you have daemon.debug directed to a file in /etc/syslog.conf?
# more /etc/syslog.conf
daemon.* /var/log/pppd
Post by James Carlson
And,
if you had to change that file, did you touch that file into existence
and SIGHUP syslogd?
I had to start syslogd, it doesn't run by default on our embedded
system.
Post by James Carlson
Post by c***@nycap.rr.com
I tried strace and didn't see much (or saw too much and nothing seemed
to be helpful). I'll try again. Thanks.
Posting some actual output rather than a summary would be helpful.
No doubt. Though I'd have to limit strace's output to something
sensibly short.
Chris Nelson
2006-02-27 20:03:07 UTC
Permalink
Post by Chris Nelson
...
Post by James Carlson
Do you need to specify "local" to avoid pppd's use of DCD?
I can try that. Thanks for the suggestion.
...
Post by James Carlson
Post by c***@nycap.rr.com
What else would you want to see?
What's in /etc/ppp/options? There's no way to stop pppd from reading
that file -- it *always* reads it if it's present.
lock
crtscts
asyncmap 0
modem
Bingo! "modem" seems wrong. Shouldn't that be "local". (Though this
same configuration works on my older system with PPP 2.4.2.)
Changing "modem" to "local" in /etc/ppp/options gives:

Jan 1 01:21:05 Test3 syslog.info -- MARK --
Jan 1 01:26:33 Test3 daemon.notice pppd[238]: pppd 2.4.3 started by
root, uid 0Jan 1 01:26:33 Test3 daemon.notice pppd[238]: Removed stale
lock on ttyAM0 (pid 225)
Jan 1 01:26:33 Test3 daemon.debug pppd[238]: using channel 1
Jan 1 01:26:33 Test3 daemon.info pppd[238]: Using interface ppp0
Jan 1 01:26:33 Test3 daemon.info pppd[238]: Connect: ppp0 ->
/dev/ttyAM0
Jan 1 01:26:33 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:36 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:39 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:42 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]

(though still no ppp0 interface).
Chris Nelson
2006-02-27 20:37:46 UTC
Permalink
Post by Chris Nelson
...
Jan 1 01:21:05 Test3 syslog.info -- MARK --
Jan 1 01:26:33 Test3 daemon.notice pppd[238]: pppd 2.4.3 started by
root, uid 0Jan 1 01:26:33 Test3 daemon.notice pppd[238]: Removed stale
lock on ttyAM0 (pid 225)
Jan 1 01:26:33 Test3 daemon.debug pppd[238]: using channel 1
Jan 1 01:26:33 Test3 daemon.info pppd[238]: Using interface ppp0
Jan 1 01:26:33 Test3 daemon.info pppd[238]: Connect: ppp0 ->
/dev/ttyAM0
Jan 1 01:26:33 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:36 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:39 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:42 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
(though still no ppp0 interface).
After a while, the log contains:

Jan 1 00:17:28 Test3 daemon.warn pppd[177]: LCP: timeout sending
Config-Requests
Jan 1 00:17:28 Test3 daemon.notice pppd[177]: Connection terminated.
Jan 1 00:17:28 Test3 daemon.debug pppd[177]: using channel 8
Jan 1 00:17:28 Test3 daemon.info pppd[177]: Using interface ppp0
Jan 1 00:17:28 Test3 daemon.info pppd[177]: Connect: ppp0 ->
/dev/ttyAM0
Jan 1 00:17:28 Test3 daemon.info pppd[177]: sent [LCP ConfReq id=0x2
syncmap 0x0> agic 0x5f371907> comp> ccomp>]
Jan 1 00:17:28 Test3 daemon.warn pppd[177]: tcflush failed: Bad file
descriptor
Jan 1 00:17:28 Test3 daemon.warn pppd[177]: tcsetattr: Invalid
argument (line 1001)
Jan 1 00:17:28 Test3 daemon.info pppd[177]: Exit.

So it seems to be trying to create the interface.
James Carlson
2006-02-27 20:53:34 UTC
Permalink
Post by Chris Nelson
Post by Chris Nelson
Bingo! "modem" seems wrong. Shouldn't that be "local". (Though this
same configuration works on my older system with PPP 2.4.2.)
It sounds to me like something is wrong with that serial port or with
the wiring.

Try also "nocrtscts" to disable hardware flow control, at least for
now.
Post by Chris Nelson
Jan 1 01:26:33 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:36 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:39 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:42 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Other than the _really_ odd text corruption, which I'll just blame on
your non-emacs posting software for now ;-}, that looks normal. Pppd
is now sending data out the serial port. Nothing is arriving on the
serial port, so either PPP isn't running on that peer system or the
underlying driver or physical link is broken.

At a guess, the driver you're using isn't completely compatible with
the kernel you have. It isn't some third-party add-on, is it?
Drivers notoriously need recompilation for each kernel version on
Linux because there's no stable DDI/DKI.
--
James Carlson, KISS Network <***@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Chris Nelson
2006-02-27 21:03:56 UTC
Permalink
Post by James Carlson
Post by Chris Nelson
Post by Chris Nelson
Bingo! "modem" seems wrong. Shouldn't that be "local". (Though this
same configuration works on my older system with PPP 2.4.2.)
It sounds to me like something is wrong with that serial port or with
the wiring.
Except that the same cable works between my old systems.
Post by James Carlson
Try also "nocrtscts" to disable hardware flow control, at least for
now.
I'll try that. Thanks.
Post by James Carlson
Post by Chris Nelson
Jan 1 01:26:33 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:36 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:39 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:42 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Other than the _really_ odd text corruption, which I'll just blame on
your non-emacs posting software for now ;-},
That must be it. ;-)
Post by James Carlson
that looks normal.
Thanks.
Post by James Carlson
Pppd
is now sending data out the serial port. Nothing is arriving on the
serial port, so either PPP isn't running on that peer system or the
underlying driver or physical link is broken.
I found that the PPP server _had_ given up but even when I restart it,
it doesn't work. I have some reason to believe that the driver is
deficient (though I'd be led to believe it was sufficient for my
immediate purposes). I'll try nocrtscts and if that doesn't work, I'll
look into the driver.
Post by James Carlson
At a guess, the driver you're using isn't completely compatible with
the kernel you have. It isn't some third-party add-on, is it?
Drivers notoriously need recompilation for each kernel version on
Linux because there's no stable DDI/DKI.
Thanks.
Unruh
2006-02-28 22:26:58 UTC
Permalink
Post by Chris Nelson
Post by James Carlson
Post by Chris Nelson
Post by Chris Nelson
Bingo! "modem" seems wrong. Shouldn't that be "local". (Though this
same configuration works on my older system with PPP 2.4.2.)
It sounds to me like something is wrong with that serial port or with
the wiring.
Except that the same cable works between my old systems.
Post by James Carlson
Try also "nocrtscts" to disable hardware flow control, at least for
now.
I'll try that. Thanks.
Post by James Carlson
Post by Chris Nelson
Jan 1 01:26:33 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:36 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:39 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
Jan 1 01:26:42 Test3 daemon.info pppd[238]: sent [LCP ConfReq id=0x1
syncmap 0x0> agic 0x3fea5345> comp> ccomp>]
It is sending out but getting no reply.

OK, you have to remember that ppp is a two way protocol, and thus you must
also have pppd running at the remote end. Also at the remote end it needs
to be listening and waiting to get a request from this end.

Thus, at the remote end run
pppd silent debug /dev/tty???
(Are you really sure that ttyAM0 is the serial port which you have the
cable plugged into?)

They after you started pppd that way on the remote system, run
pppd debug tty???

on this side.
Note that you should in /dev/syslog.conf have a line
daemon.*;local2.* /var/log/daemonlog
and after inserting in run
killall -1 syslogd
on both machines.

This will put the debugging info into /var/log/daemonlog

Look at the log on both machines. If the log on the far machines seens
nothing, make sure that the serial ports and cable work.
on the far machine run
cat /dev/tty??
and on the local machine run
echo Hello /dev/tty??

Does anything, even garbage, come out on the remote machine? If it is
garbage you probably have a rate mismatch between the two serial ports


So far all the evidence is that
a) No pppd is running on the remote machine to link with this one.
of
b) your serial ports are broken, you cable is defective, or some other
physical problem.
Post by Chris Nelson
Post by James Carlson
Other than the _really_ odd text corruption, which I'll just blame on
your non-emacs posting software for now ;-},
That must be it. ;-)
Post by James Carlson
that looks normal.
Thanks.
Post by James Carlson
Pppd
is now sending data out the serial port. Nothing is arriving on the
serial port, so either PPP isn't running on that peer system or the
underlying driver or physical link is broken.
I found that the PPP server _had_ given up but even when I restart it,
it doesn't work. I have some reason to believe that the driver is
deficient (though I'd be led to believe it was sufficient for my
immediate purposes). I'll try nocrtscts and if that doesn't work, I'll
look into the driver.
Post by James Carlson
At a guess, the driver you're using isn't completely compatible with
the kernel you have. It isn't some third-party add-on, is it?
Drivers notoriously need recompilation for each kernel version on
Linux because there's no stable DDI/DKI.
Thanks.
Loading...