Mauro Darida wrote:
Hello, I am experiencing a weird thing: I have got KDE kppp perfectly working but when it comes to use pppd directly with the pon script even from root pppd won't start. I have the following /var/log/ppp.log: Dec 29 19:49:50 ifi pppd[1302]: pppd 2.4.1 started by root, uid 0 Dec 29 19:49:50 ifi pppd[1302]: Serial connection established. Dec 29 19:49:50 ifi pppd[1302]: Using interface ppp0 Dec 29 19:49:50 ifi pppd[1302]: Connect: ppp0 <--> /dev/pts/5 Dec 29 19:50:22 ifi pppd[1302]: LCP: timeout sending Config-Requests Dec 29 19:50:22 ifi pppd[1302]: Connection terminated. Dec 29 19:50:52 ifi pppd[1302]: Serial connection established. Dec 29 19:50:52 ifi pppd[1302]: Using interface ppp0 Dec 29 19:50:52 ifi pppd[1302]: Connect: ppp0 <--> /dev/pts/0 Dec 29 19:51:23 ifi pppd[1302]: LCP: timeout sending Config-Requests Dec 29 19:51:23 ifi pppd[1302]: Connection terminated. Dec 29 19:51:53 ifi pppd[1302]: Serial connection established. Dec 29 19:51:53 ifi pppd[1302]: Using interface ppp0 Dec 29 19:51:53 ifi pppd[1302]: Connect: ppp0 <--> /dev/pts/5 Dec 29 19:52:24 ifi pppd[1302]: LCP: timeout sending Config-Requests Dec 29 19:52:24 ifi pppd[1302]: Connection terminated. Dec 29 20:40:02 ifi pppd[793]: pppd 2.4.1 started by root, uid 0 Dec 29 20:40:05 ifi chat[798]: abort on (BUSY) Dec 29 20:40:05 ifi chat[798]: abort on (NO CARRIER) Dec 29 20:40:05 ifi chat[798]: abort on (VOICE) Dec 29 20:40:05 ifi chat[798]: abort on (NO DIALTONE) Dec 29 20:40:05 ifi chat[798]: abort on (NO DIAL TONE) Dec 29 20:40:05 ifi chat[798]: abort on (NO ANSWER) Dec 29 20:40:05 ifi chat[798]: abort on (DELAYED) Dec 29 20:40:05 ifi chat[798]: send (ATZ^M) Dec 29 20:40:05 ifi chat[798]: expect (OK) Dec 29 20:40:05 ifi chat[798]: ATZ^M^M Dec 29 20:40:05 ifi chat[798]: OK Dec 29 20:40:05 ifi chat[798]: -- got it Dec 29 20:40:05 ifi chat[798]: send (ATDT7020001033^M) Dec 29 20:40:05 ifi chat[798]: expect (CONNECT) Dec 29 20:40:05 ifi chat[798]: ^M Dec 29 20:40:27 ifi chat[798]: ATDT7020001033^M^M Dec 29 20:40:27 ifi chat[798]: CONNECT Dec 29 20:40:27 ifi chat[798]: -- got it Dec 29 20:40:27 ifi chat[798]: send (\d) Dec 29 20:40:28 ifi pppd[793]: Serial connection established. Dec 29 20:40:28 ifi pppd[793]: using channel 1 Dec 29 20:40:28 ifi pppd[793]: Using interface ppp0 Dec 29 20:40:28 ifi pppd[793]: Connect: ppp0 <--> /dev/ttySHSF0 Dec 29 20:40:29 ifi pppd[793]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x67fdddb6> <pcomp> <accomp>] Dec 29 20:40:30 ifi pppd[793]: rcvd [LCP ConfReq id=0x1 <mru 1524> <asyncmap 0xa0000> <auth chap MD5> <pcomp> <accomp> <mrru 1524> <endpoint [local:73.74.61.63.6b.31]>] Dec 29 20:40:30 ifi pppd[793]: sent [LCP ConfRej id=0x1 <mrru 1524>] Dec 29 20:40:30 ifi pppd[793]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x67fdddb6> <pcomp> <accomp>] Dec 29 20:40:30 ifi pppd[793]: rcvd [LCP ConfReq id=0x2 <mru 1524> <asyncmap 0xa0000> <auth chap MD5> <pcomp> <accomp> <endpoint [local:73.74.61.63.6b.31]>] Dec 29 20:40:30 ifi pppd[793]: sent [LCP ConfAck id=0x2 <mru 1524> <asyncmap 0xa0000> <auth chap MD5> <pcomp> <accomp> <endpoint [local:73.74.61.63.6b.31]>] Dec 29 20:40:30 ifi pppd[793]: sent [LCP EchoReq id=0x0 magic=0x67fdddb6] Dec 29 20:40:30 ifi pppd[793]: rcvd [CHAP Challenge id=0x1 <67ebcc8735df1478486093c19f9e869c>, name = "apx-na1"] Dec 29 20:40:30 ifi pppd[793]: sent [CHAP Response id=0x1 <8b7464067e56bd43969a6f290ef2e077>, name = "robert210"] Dec 29 20:40:30 ifi pppd[793]: rcvd [LCP EchoRep id=0x0 magic=0x0] Dec 29 20:40:31 ifi pppd[793]: rcvd [CHAP Failure id=0x1 "\000"] Dec 29 20:40:31 ifi pppd[793]: Remote message: ^@ Dec 29 20:40:31 ifi pppd[793]: CHAP authentication failed Dec 29 20:40:31 ifi pppd[793]: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"] Dec 29 20:40:31 ifi pppd[793]: rcvd [LCP TermAck id=0x2] Dec 29 20:40:31 ifi pppd[793]: Connection terminated. Dec 29 20:40:31 ifi pppd[793]: Hangup (SIGHUP) Dec 29 20:40:31 ifi pppd[793]: Exit. Any clue?
Is this for a VPN connection? When I had this problem, I was forgetting to enable "refuse-eap" The server to which I was trying to connect would, for some reason, offer EAP and then refuse to authenticate with it. I simply had to disable it and then CHAP authentication mysteriously started functioning. -Roberto Sanchez
Attachment:
signature.asc
Description: OpenPGP digital signature