Debian diald/pppd IPCP negotiation problem; fails first time, succeeds second time [db]
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.
daniel@compass-da.com Suite 100, 5457 Twin Knolls Rd. Columbia, MD 21045 USA
Reply to: