Hi, I'm having trouble connecting with ppp under diald, on Debian 1.2.x.
When I run pppd without diald (using Debian's pon command), pppd connects fine. When I use diald to run pppd, PPP won't connect the first time, but will the second time. (And if the connection goes idle for a while and diald hangs up, the first reconnection attempt fails, but the second works.) (This is not 100%, but about 95% of the time. That is, once in a while, it does connect the first time.) (Note: This is NOT the known diald problem of connecting the _first_ time and _not_ connecting subsequently.) So far, I have traced the problem to patterns in PPP's IPCP configuration negotation. However, I could use some explanation of exactly what the IPCP negotiation packets mean and what's going on. (See the system log data below. I could also use an explanation of the _LCP_ configuration rejection packets -- what is being rejected?) I suspect that part of the problem is at the other end, and part is at my end. It appears to me that the other end, for some reason, alternates between providing addresses and not providing addresses during IPCP configuration on subsequent connection attempts. (See "rcvd [IPCP ConfReq id=0x1]" in the failed attempt vs. "rcvd [IPCP ConfReq id=0x1 <addr xxx.yyy.30.109>]" in the successful attempt, below.) Is my interpretation of the IPCP packets correct? Does it sound like a configuration problem at the other end, or at my end? (The "other end" is an Ascend multiple-ISDN-modem box, a MAX 5000 or something, at my employer. We have static IP addresses.) At my end, it appears that some difference in my ppp, pon, and diald setup files lets PPP proceed with IPCP negotiation anyway when I use pon, but not when I use diald. The pon command uses local and remote IP addresses I have specified in the Debian PPP option file read by pon. (The addresses are not in the main pppd options file, but are added to the pppd command line by pon.) I have specified the local and remote IP addresses in the diald options file (and verified that diald is using that options file -- if I comment out the local and remote lines, diald notices and complains). However, it appears that diald doesn't pass these addresses to pppd (according to ps -ww... and to /proc/xxx/cmdline). (I thought diald passed the IP addresses to pppd when it ran pppd. Does it? Am I missing some diald configuration option to tell it to do so? Also, it there a debugging option to tell diald to log the options it passes to pppd?) So...does anyone have any ideas on this? I'm getting tired of having to wait for diald/pppd to try twice every time (especially given that diald won't seem to retry upon failure unless there's a _new_ packet transmitted by an application.) Thanks. Daniel ------------------------------------------------------------------------------ Example of failure: ...darkstar pppd[...]: Connect: ppp0 <--> /dev/ttyS1 ...darkstar pppd[...]: sent [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0x0> <magic 0x48d04f2a> <pcomp> <accomp>] ...darkstar pppd[...]: rcvd [LCP ConfReq id=0x4 <mru 1524> <asyncmap 0xa0000> <pcomp> <accomp> < 13 09 03 00 c0 7b 5d ae 4c>] ...darkstar pppd[...]: sent [LCP ConfRej id=0x4 < 13 09 03 00 c0 7b 5d ae 4c>] ...darkstar pppd[...]: rcvd [LCP ConfReq id=0x5 <mru 1524> <asyncmap 0xa0000> <pcomp> <accomp>] ...darkstar pppd[...]: sent [LCP ConfAck id=0x5 <mru 1524> <asyncmap 0xa0000> <pcomp> <accomp>] ...darkstar pppd[...]: sent [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0x0> <magic 0x48d04f2a> <pcomp> <accomp>] ...darkstar pppd[...]: rcvd [LCP ConfAck id=0x1 <mru 1500> <asyncmap 0x0> <magic 0x48d04f2a> <pcomp> <accomp>] ...darkstar pppd[...]: sent [IPCP ConfReq id=0x1 <addr xxx.yyy.30.95> <compress VJ 0f 01>] ...darkstar pppd[...]: rcvd [IPCP ConfReq id=0x1] ...darkstar pppd[...]: sent [IPCP ConfNak id=0x1 <addr 0.0.0.0>] ...darkstar pppd[...]: rcvd [IPCP ConfReq id=0x2] ...darkstar pppd[...]: sent [IPCP ConfAck id=0x2] ...darkstar pppd[...]: sent [IPCP ConfReq id=0x1 <addr xxx.yyy.30.95> <compress VJ 0f 01>] ...darkstar pppd[...]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>] ...darkstar pppd[...]: sent [IPCP ConfReq id=0x2 <addr xxx.yyy.30.95>] ...darkstar pppd[...]: rcvd [IPCP ConfAck id=0x2 <addr xxx.yyy.30.95>] ...darkstar pppd[...]: Could not determine remote IP address Example of success: ...darkstar pppd[...]: Connect: ppp0 <--> /dev/ttyS1 ...darkstar pppd[...]: sent [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0x0> <magic 0x44bd52ef> <pcomp> <accomp>] ...darkstar pppd[...]: rcvd [LCP ConfReq id=0x3 <mru 1524> <asyncmap 0xa0000> <pcomp> <accomp> < 13 09 03 00 c0 7b 5d ae 4c>] ...darkstar pppd[...]: sent [LCP ConfRej id=0x3 < 13 09 03 00 c0 7b 5d ae 4c>] ...darkstar pppd[...]: rcvd [LCP ConfReq id=0x4 <mru 1524> <asyncmap 0xa0000> <pcomp> <accomp>] ...darkstar pppd[...]: sent [LCP ConfAck id=0x4 <mru 1524> <asyncmap 0xa0000> <pcomp> <accomp>] ...darkstar pppd[...]: sent [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0x0> <magic 0x44bd52ef> <pcomp> <accomp>] ...darkstar pppd[...]: rcvd [LCP ConfAck id=0x1 <mru 1500> <asyncmap 0x0> <magic 0x44bd52ef> <pcomp> <accomp>] ...darkstar pppd[...]: sent [IPCP ConfReq id=0x1 <addr xxx.yyy.30.95> <compress VJ 0f 01>] ...darkstar pppd[...]: rcvd [IPCP ConfReq id=0x1 <addr xxx.yyy.30.109>] ...darkstar pppd[...]: sent [IPCP ConfAck id=0x1 <addr xxx.yyy.30.109>] ...darkstar pppd[...]: sent [IPCP ConfReq id=0x1 <addr xxx.yyy.30.95> <compress VJ 0f 01>] ...darkstar pppd[...]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>] ...darkstar pppd[...]: sent [IPCP ConfReq id=0x2 <addr xxx.yyy.30.95>] ...darkstar pppd[...]: rcvd [IPCP ConfAck id=0x2 <addr xxx.yyy.30.95>] ...darkstar pppd[...]: local IP address xxx.yyy.30.95 ...darkstar pppd[...]: remote IP address xxx.yyy.30.109 -- Daniel S. Barclay Compass Design Automation, Inc. [EMAIL PROTECTED] Suite 100, 5457 Twin Knolls Rd. Columbia, MD 21045 USA