PPP not exiting

I have a problem with a dialin setup I'm using. I do have the actual
dialin session working and traffic is going backwards and forwards,
however if the connection ends for any reason then pppd is left behind
doing squat.

I am using PPP 2.4.1 provided with Mandrake 9.2. I use this for my PPPoE
connection without any problem whatsoever.

The last bit of my log looks like:

Jun 9 22:13:05 natalie pppd[26963]: using channel 84
Jun 9 22:13:05 natalie pppd[26963]: Using interface ppp1
Jun 9 22:13:05 natalie pppd[26963]: Connect: ppp1 <--> /dev/tts/0
Jun 9 22:13:05 natalie pppd[26963]: sent [LCP ConfReq id=0x2 <mru 1432>
<asyncmap 0x0> <auth pap> <magic 0x28ba878a> <pcomp> <accomp>]
Jun 9 22:13:17 natalie last message repeated 4 times
Jun 9 22:13:18 natalie pppd[26963]: Hangup (SIGHUP)
Jun 9 22:13:18 natalie pppd[26963]: Modem hangup
Jun 9 22:13:18 natalie pppd[26963]: Connection terminated.

pppd then will just sit there as long as I let it. The only way I can get
rid of it is with a 'kill -9' and then mgetty will kick back into action.
The output of a ps x shows the following:

26963 tts/0 S 0:00 pppd modem file /etc/ppp/options.server

The /etc/mgetty+sendfax/mgetty.config file looks like this:

port ttyS0
modem-type data
speed 57600
init-chat "" \d+++\d\d\dATZ OK AT&C1 OK AT&D2 OK AT&K3Q0 OK AT OK

I have also tried passing &D3 with no change.

My /etc/mgetty+sendfax/login.config file only has this line uncommented:

/AutoPPP/ - a_ppp /usr/sbin/pppd modem file /etc/ppp/options.server

My /etc/ppp/options.server file has the following:

172.16.0.1:172.16.0.2
asyncmap 0
lock
debug
mtu 1432
mru 1432
passive
crtscts
proxyarp
auth
-chap
+pap

I have also tried the -detach option and this makes it even worse. So far
I read through the PPP, Modem & dialin howtos and scoured usenet for
someone else that has actually solved this problem. If it will help
anyone, when pppd does mention it hangs up the /var/run/ppp1.pid file
dissapears. The modem I am using is a standard 56K modem, a Netcomm
MegaModem, pretty generic. I have checked the serial cable to ensure all
the signal go through OK & have used that modem & cable for dialing out on
many occasions.

I don't know what else to do here. Any suggestions appreciated.

Michael Collard

On Wed, 09 Jun 2004 22:52:31 +0800, Michael Collard
<quadfour@iinet.net.au> wrote:
> I have a problem with a dialin setup I'm using. I do have the actual
> dialin session working and traffic is going backwards and forwards,
> however if the connection ends for any reason then pppd is left behind
> doing squat.
>
>
> My /etc/ppp/options.server file has the following:
>
> 172.16.0.1:172.16.0.2
> asyncmap 0
> lock
> debug
> mtu 1432
> mru 1432
> passive
> crtscts
> proxyarp
> auth
> -chap
> +pap
>
You might try adding these lines:
lcp-echo-interval 30
lcp-echo-failure 2


--
Simulations are like miniskirts, they show a lot and hide the essentials.
-- Hubert Kirrman

See below interleaved with teh text.


Michael Collard <quadfour@iinet.net.au> writes:

]I have a problem with a dialin setup I'm using. I do have the actual
]dialin session working and traffic is going backwards and forwards,
]however if the connection ends for any reason then pppd is left behind
]doing squat.

Tell us how you have the dialup setup set up. What you say below is not
standard. (You should have mgetty in inittab to answer the phone and then
pass off to pppd-- not pppd with the passive option)


]I am using PPP 2.4.1 provided with Mandrake 9.2. I use this for my PPPoE
]connection without any problem whatsoever.

]The last bit of my log looks like:

]Jun 9 22:13:05 natalie pppd[26963]: using channel 84
]Jun 9 22:13:05 natalie pppd[26963]: Using interface ppp1
]Jun 9 22:13:05 natalie pppd[26963]: Connect: ppp1 <--> /dev/tts/0
]Jun 9 22:13:05 natalie pppd[26963]: sent [LCP ConfReq id=0x2 <mru 1432>
]<asyncmap 0x0> <auth pap> <magic 0x28ba878a> <pcomp> <accomp>]
]Jun 9 22:13:17 natalie last message repeated 4 times
]Jun 9 22:13:18 natalie pppd[26963]: Hangup (SIGHUP)
]Jun 9 22:13:18 natalie pppd[26963]: Modem hangup
]Jun 9 22:13:18 natalie pppd[26963]: Connection terminated.

fine. This is hardly a full debug.

]pppd then will just sit there as long as I let it. The only way I can get
]rid of it is with a 'kill -9' and then mgetty will kick back into action.
]The output of a ps x shows the following:

]26963 tts/0 S 0:00 pppd modem file /etc/ppp/options.server

]The /etc/mgetty+sendfax/mgetty.config file looks like this:

]port ttyS0
]modem-type data
]speed 57600
]init-chat "" \d+++\d\d\dATZ OK AT&C1 OK AT&D2 OK AT&K3Q0 OK AT OK

DO NOT use ATZ to initialize your modem. Use AT&F to reset factory
defaults. ATZ can leave the modem in a very very weird state.


]I have also tried passing &D3 with no change.

We have no idea what these options mean. They differ from modem to modem.


]My /etc/mgetty+sendfax/login.config file only has this line uncommented:

]/AutoPPP/ - a_ppp /usr/sbin/pppd modem file /etc/ppp/options.server

]My /etc/ppp/options.server file has the following:

What does /etc/ppp/options have?


]172.16.0.1:172.16.0.2
]asyncmap 0
]lock
]debug
]mtu 1432
]mru 1432
]passive

Get rid of passive.

]crtscts
]proxyarp
]auth

Do you really want the other side to authenticate themselves to you?

]-chap
]+pap

With pap?


]I have also tried the -detach option and this makes it even worse. So far
]I read through the PPP, Modem & dialin howtos and scoured usenet for
]someone else that has actually solved this problem. If it will help
]anyone, when pppd does mention it hangs up the /var/run/ppp1.pid file
]dissapears. The modem I am using is a standard 56K modem, a Netcomm
]MegaModem, pretty generic. I have checked the serial cable to ensure all
]the signal go through OK & have used that modem & cable for dialing out on
]many occasions.


Are you using the full serial cable ( at least 9 lines, not just 3?)
Anyway one way around non-hangups is to use the the LCP EchoReq options.
But I suspect a badly configured modem.






]I don't know what else to do here. Any suggestions appreciated.

]Michael Collard

Bill Unruh <unruh@string.physics.ubc.ca> wrote:
> Michael Collard <quadfour@iinet.net.au> writes:

> Do you really want the other side to authenticate themselves to you?

A dialin? I sure would.

> ]-chap
> ]+pap

> With pap?

Err... Info mgetty says mgetty uses PAP. If so then it's likely not
possible to use CHAP.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Speak softly and carry a +6 two-handed sword. */

Michael Collard <quadfour@iinet.net.au> wrote:
> I have a problem with a dialin setup I'm using. I do have the actual
> dialin session working and traffic is going backwards and forwards,
> however if the connection ends for any reason then pppd is left behind
> doing squat.

> I am using PPP 2.4.1 provided with Mandrake 9.2. I use this for my PPPoE
> connection without any problem whatsoever.

> The last bit of my log looks like:

> Jun 9 22:13:05 natalie pppd[26963]: using channel 84
> Jun 9 22:13:05 natalie pppd[26963]: Using interface ppp1
> Jun 9 22:13:05 natalie pppd[26963]: Connect: ppp1 <--> /dev/tts/0
> Jun 9 22:13:05 natalie pppd[26963]: sent [LCP ConfReq id=0x2 <mru 1432>
> <asyncmap 0x0> <auth pap> <magic 0x28ba878a> <pcomp> <accomp>]
> Jun 9 22:13:17 natalie last message repeated 4 times
> Jun 9 22:13:18 natalie pppd[26963]: Hangup (SIGHUP)
> Jun 9 22:13:18 natalie pppd[26963]: Modem hangup
> Jun 9 22:13:18 natalie pppd[26963]: Connection terminated.

This is not a disconnection during a working PPP session. It looks
like the other side abruptly hungup without starting it's PPP. But in
the case of an abrupt hangup at any stage I don't think there's any
way other to terminate pppd other than kill -9. Does "for any reason"
include one that does *not* involve an abrupt hangup? If so then show
us a log of the debug messages for such a session. And, please, NOT
hand-copied messages.

What bothers me is the /dev/tts/0 that appears in the output above. That
should read /dev/pts/0, or /dev/pts/<some integer> . I suppose Mandrake
could have mangled things and created /dev/tts but it's very doubtful that
it would be used by pppd. But if "looks like" means you hand-copied the
messages then that might explain it. In fact, comparing this with my
own logs strongly implies that it *is* a hand-copy. I'd expect a line
with "Using interface ppp1" before the "Connect" line and a 1-second
delay between the "Connect" and the first LCP request.

> I read through the PPP, Modem & dialin howtos and scoured usenet for
> someone else that has actually solved this problem. If it will help
> anyone, when pppd does mention it hangs up the /var/run/ppp1.pid file
> dissapears.

That's surprising; I'd expect the PID file to be around after an abrupt
hangup. Or does "it hangs up" mean that it is pppd that actually hangs
up, after closing the PPP session?

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

Clifford Kite <kite@see.signature.id> writes:

]Bill Unruh <unruh@string.physics.ubc.ca> wrote:
]> Michael Collard <quadfour@iinet.net.au> writes:

]> Do you really want the other side to authenticate themselves to you?

]A dialin? I sure would.

It was not clear to me who was dialing in to whom.


]> ]-chap
]> ]+pap

]> With pap?

]Err... Info mgetty says mgetty uses PAP. If so then it's likely not
]possible to use CHAP.

mgetty has nothing to do with it. mgetty just opens pppd and all control
passes to pppd. You can use pap, chat MD5, MSchap or whatever else your
pppd can handle.

I was just checking to make sure that he knew what he was doing.
Having passive in there for example did not seem a good idea.

On Wed, 09 Jun 2004 14:01:49 -0500, Clifford Kite wrote:


> This is not a disconnection during a working PPP session. It looks
> like the other side abruptly hungup without starting it's PPP. But in
> the case of an abrupt hangup at any stage I don't think there's any
> way other to terminate pppd other than kill -9. Does "for any reason"
> include one that does *not* involve an abrupt hangup? If so then show
> us a log of the debug messages for such a session. And, please, NOT
> hand-copied messages.

Sure, that last connection was a test one only. A demo of a connection
where we did a little traffic etc is here:

Jun 9 14:14:45 natalie pppd[19803]: pppd 2.4.1 started by root, uid 0
Jun 9 14:14:45 natalie pppd[19803]: using channel 81
Jun 9 14:14:45 natalie pppd[19803]: Using interface ppp1
Jun 9 14:14:45 natalie pppd[19803]: Connect: ppp1 <--> /dev/tts/0
Jun 9 14:14:45 natalie pppd[19803]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xde1cf632> <pcomp> <accomp>]
Jun 9 14:14:45 natalie pppd[19803]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0xde1cf632> <pcomp> <accomp>]
Jun 9 14:14:48 natalie pppd[19803]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xbc137772> <pcomp> <accomp>]
Jun 9 14:14:48 natalie pppd[19803]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xbc137772> <pcomp> <accomp>]
Jun 9 14:14:48 natalie pppd[19803]: rcvd [PAP AuthReq id=0x1 user="vert" password=<hidden>]
Jun 9 14:14:48 natalie pppd[19803]: sent [PAP AuthAck id=0x1 "Login ok"]
Jun 9 14:14:48 natalie pppd[19803]: sent [IPCP ConfReq id=0x1 <addr 172.16.0.1> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jun 9 14:14:48 natalie pppd[19803]: sent [IPCP ConfReq id=0x1 <addr 172.16.0.1> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jun 9 14:14:48 natalie pppd[19803]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Jun 9 14:14:48 natalie pppd[19803]: rcvd [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jun 9 14:14:48 natalie pppd[19803]: sent [IPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jun 9 14:14:48 natalie pppd[19803]: rcvd [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Jun 9 14:14:48 natalie pppd[19803]: sent [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Jun 9 14:14:48 natalie pppd[19803]: rcvd [IPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jun 9 14:14:48 natalie pppd[19803]: sent [IPCP ConfReq id=0x2 <addr 172.16.0.1> <compress VJ 0f 01>]
Jun 9 14:14:48 natalie pppd[19803]: rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Jun 9 14:14:48 natalie pppd[19803]: Deflate (15) compression enabled
Jun 9 14:14:48 natalie pppd[19803]: rcvd [IPCP ConfReq id=0x2 <addr 0.0.0.0> <compress VJ 0f 01>]
Jun 9 14:14:48 natalie pppd[19803]: sent [IPCP ConfNak id=0x2 <addr 172.16.0.2>]
Jun 9 14:14:48 natalie pppd[19803]: rcvd [IPCP ConfAck id=0x2 <addr 172.16.0.1> <compress VJ 0f 01>]
Jun 9 14:14:48 natalie pppd[19803]: rcvd [IPCP ConfReq id=0x3 <addr 172.16.0.2> <compress VJ 0f 01>]
Jun 9 14:14:48 natalie pppd[19803]: sent [IPCP ConfAck id=0x3 <addr 172.16.0.2> <compress VJ 0f 01>]
Jun 9 14:14:48 natalie pppd[19803]: local IP address 172.16.0.1
Jun 9 14:14:48 natalie pppd[19803]: remote IP address 172.16.0.2
Jun 9 14:14:48 natalie pppd[19803]: Script /etc/ppp/ip-up started (pid 20406)
Jun 9 14:14:50 natalie pppd[19803]: Script /etc/ppp/ip-up finished (pid 20406), status = 0x0
Jun 9 17:40:16 natalie pppd[19803]: rcvd [LCP TermReq id=0x2 "User request"]
Jun 9 17:40:16 natalie pppd[19803]: LCP terminated by peer (User request)
Jun 9 17:40:16 natalie pppd[19803]: Script /etc/ppp/ip-down started (pid 23969)Jun 9 17:40:16 natalie pppd[19803]: sent [LCP TermAck id=0x2]
Jun 9 17:40:16 natalie pppd[19803]: Script /etc/ppp/ip-down finished (pid 23969), status = 0x0
Jun 9 17:40:19 natalie pppd[19803]: Connection terminated.
Jun 9 17:40:19 natalie pppd[19803]: Connect time 205.6 minutes.
Jun 9 17:40:19 natalie pppd[19803]: Sent 1825263 bytes, received 578076 bytes.
Jun 9 17:40:19 natalie pppd[19803]: using channel 82
Jun 9 17:40:19 natalie pppd[19803]: Using interface ppp1
Jun 9 17:40:19 natalie pppd[19803]: Connect: ppp1 <--> /dev/tts/0
Jun 9 17:40:19 natalie pppd[19803]: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <auth pap> <magic 0xc52c931f> <pcomp> <accomp>]
Jun 9 17:40:46 natalie last message repeated 9 times
Jun 9 18:17:45 natalie pppd[19803]: Hangup (SIGHUP)
Jun 9 18:17:45 natalie pppd[19803]: Modem hangup
Jun 9 18:17:45 natalie pppd[19803]: Connection terminated.

Just noticed the end of that log, pretty strange stuff. Maybe its related to the
passive option? I will remove it and observe the next connection's hanup.
I've also just created a script that will kill -9 pppd's PID at the point
where it runs the ip-down script. That should help me out :)

> What bothers me is the /dev/tts/0 that appears in the output above. That
> should read /dev/pts/0, or /dev/pts/<some integer> . I suppose Mandrake
> could have mangled things and created /dev/tts but it's very doubtful
> that it would be used by pppd. But if "looks like" means you
> hand-copied the messages then that might explain it. In fact, comparing
> this with my own logs strongly implies that it *is* a hand-copy. I'd
> expect a line with "Using interface ppp1" before the "Connect" line and
> a 1-second delay between the "Connect" and the first LCP request.

It wasn't hand copied, straight from the logs :)

> That's surprising; I'd expect the PID file to be around after an abrupt
> hangup. Or does "it hangs up" mean that it is pppd that actually hangs
> up, after closing the PPP session?

I think its a case where it hangs up but maybe crashes on terminating? I really
don't know though. Perhaps its something to do with Mandrake's PPP. On a couple
of times only when it hung, there was also an ip-down <defunct> process but I
couldn't kill this directly, had to kill pppd.

Thanks for your help thus far. I will let you know how I go with the disconnect
script I made.

Michael Collard

On Wed, 09 Jun 2004 11:38:57 -0400, Bill Marcum wrote:

> You might try adding these lines:
> lcp-echo-interval 30
> lcp-echo-failure 2

I did give something similar a go but it didn't help because the problem
is after pppd has already hung up :(. Still, now I've made a script to
kill pppd for me so this should work around the problem.

Regards
Michael Collard

Bill Unruh <unruh@string.physics.ubc.ca> wrote:
> Clifford Kite <kite@see.signature.id> writes:
> ]Bill Unruh <unruh@string.physics.ubc.ca> wrote:

> ]> ]-chap
> ]> ]+pap

> ]> With pap?

> ]Err... Info mgetty says mgetty uses PAP. If so then it's likely not
> ]possible to use CHAP.

> mgetty has nothing to do with it. mgetty just opens pppd and all control
> passes to pppd. You can use pap, chat MD5, MSchap or whatever else your
> pppd can handle.

You are right. A quick grep of some mgetty code showed no "+pap" or
"require-pap," so it can use whatever is specified by the AutoPPP line
in login.config. The info pages are a bit misleading.

[Sorry about the email in addition to this reply. Sometimes I don't
pay enough attention to what I'm doing and this time I sent the email
instead of this usenet reply.]

-- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

On Thu, 10 Jun 2004 07:22:03 +0800, Michael Collard wrote:

> Just noticed the end of that log, pretty strange stuff. Maybe its related to the
> passive option? I will remove it and observe the next connection's hanup.
> I've also just created a script that will kill -9 pppd's PID at the point
> where it runs the ip-down script. That should help me out :)
>
>
> Thanks for your help thus far. I will let you know how I go with the disconnect
> script I made.

I know its bad to reply to myself but that little script did the trick
well. Still its a shame that pppd couldn't exit itself ;)

If anyone wants a copy of what I've done, please email me.

Kind Regards
Michael Collard