DanielEFriedman
asked on
PPP defaultroute problem(s) (?)
I'm using PPP (specificly, pppd v. 2.2.0f), and I use the defaultroute option. My problem is that, oftentimes, the default route doesn't get set up.
I have used the "debug" and "kdebug 7" options for pppd. In
/var/adm/syslog, this is the error message which seems relevant (the machine name is linuxer):
Jul 9 22:10:51 linuxer pppd[286]: Could not determine remote IP address
Looking at the pppd source code (in ipcp.c), it seems the remote IP address seen by pppd is 0. However, sometimes pppd manages to recover and successfully establish the defaultroute through the PPP connection. For example, in establishing the PPP connection I'm using at this moment,
/var/adm/debug shows:
Jul 9 23:28:54 linuxer pppd[7747]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
Jul 9 23:28:54 linuxer pppd[7747]: rcvd [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 128.8.10.106>]
Jul 9 23:28:54 linuxer pppd[7747]: sent [IPCP ConfAck id=0x3 <compress VJ 0f 01> <addr 128.8.10.106>]
Another example (of success):
Jul 9 22:59:05 linuxer pppd[7057]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
Jul 9 22:59:05 linuxer pppd[7057]: rcvd [IPCP ConfNak id=0x1 <addr 128.8.140.111>]
Jul 9 22:59:05 linuxer pppd[7057]: sent [IPCP ConfReq id=0x2 <addr 128.8.140.111> <compress VJ 0f 01>]
Jul 9 22:59:05 linuxer pppd[7057]: rcvd [IPCP ConfAck id=0x2 <addr 128.8.140.111> <compress VJ 0f 01>]
As an example in which the default route doesn't get set up, there's one facility at which I've *never* been able to establish a default route using pppd. However, I'm told this facility is identical to the one I use successfully, and I can use this site just fine if I connectthrough Windows 3.1 (Trumpet Winsock). Here is what /var/adm/debug
shows for the unsuccessful connection with Linux/pppd:
Jul 9 22:59:02 linuxer pppd[7057]: rcvd [LCP ConfReq id=0x2 <mru 576> <asyncmap 0x0> <magic 0x49cac9bd> <pcomp> <accomp>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [LCP ConfAck id=0x2 <mru 576> <asyncmap 0x0> <magic 0x49cac9bd> <pcomp> <accomp>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
Jul 9 22:59:02 linuxer pppd[7057]: rcvd [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 0.0.0.0>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [IPCP ConfRej id=0x3 <addr 0.0.0.0>]
Jul 9 22:59:02 linuxer kernel: ppp_tty_ioctl: get flags: addr bffff4ec flags f000010
Jul 9 22:59:02 linuxer kernel: ppp_tty_ioctl: get flags: addr bffff500 flags f000013
Jul 9 22:59:02 linuxer pppd[7057]: rcvd [IPCP ConfReq id=0x4 <addrs 0.0.0.0 128.8.140.111> <compress VJ 0f 01>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [IPCP ConfRej id=0x4 <addrs 0.0.0.0 128.8.140.111>]
Jul 9 22:59:02 linuxer pppd[7057]: rcvd [IPCP ConfReq id=0x5 <compress VJ 0f 01>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [IPCP ConfAck id=0x5 <compress VJ 0f 01>]
-----(end of examples)-----
I've tried fiddling with various pppd options (e.g. -vj) but I still have no success. What am I doing wrong here?
BTW, here are all the pppd options I'm using:
debug kdebug 7 asyncmap 0 noipdefault lock crtscts 57600
...and I'm running Linux kernel version 2.0.27, with PPP support compiled as a module in the kernel.
Many thanks for any and all help,
--daniel
I have used the "debug" and "kdebug 7" options for pppd. In
/var/adm/syslog, this is the error message which seems relevant (the machine name is linuxer):
Jul 9 22:10:51 linuxer pppd[286]: Could not determine remote IP address
Looking at the pppd source code (in ipcp.c), it seems the remote IP address seen by pppd is 0. However, sometimes pppd manages to recover and successfully establish the defaultroute through the PPP connection. For example, in establishing the PPP connection I'm using at this moment,
/var/adm/debug shows:
Jul 9 23:28:54 linuxer pppd[7747]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
Jul 9 23:28:54 linuxer pppd[7747]: rcvd [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 128.8.10.106>]
Jul 9 23:28:54 linuxer pppd[7747]: sent [IPCP ConfAck id=0x3 <compress VJ 0f 01> <addr 128.8.10.106>]
Another example (of success):
Jul 9 22:59:05 linuxer pppd[7057]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
Jul 9 22:59:05 linuxer pppd[7057]: rcvd [IPCP ConfNak id=0x1 <addr 128.8.140.111>]
Jul 9 22:59:05 linuxer pppd[7057]: sent [IPCP ConfReq id=0x2 <addr 128.8.140.111> <compress VJ 0f 01>]
Jul 9 22:59:05 linuxer pppd[7057]: rcvd [IPCP ConfAck id=0x2 <addr 128.8.140.111> <compress VJ 0f 01>]
As an example in which the default route doesn't get set up, there's one facility at which I've *never* been able to establish a default route using pppd. However, I'm told this facility is identical to the one I use successfully, and I can use this site just fine if I connectthrough Windows 3.1 (Trumpet Winsock). Here is what /var/adm/debug
shows for the unsuccessful connection with Linux/pppd:
Jul 9 22:59:02 linuxer pppd[7057]: rcvd [LCP ConfReq id=0x2 <mru 576> <asyncmap 0x0> <magic 0x49cac9bd> <pcomp> <accomp>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [LCP ConfAck id=0x2 <mru 576> <asyncmap 0x0> <magic 0x49cac9bd> <pcomp> <accomp>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
Jul 9 22:59:02 linuxer pppd[7057]: rcvd [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 0.0.0.0>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [IPCP ConfRej id=0x3 <addr 0.0.0.0>]
Jul 9 22:59:02 linuxer kernel: ppp_tty_ioctl: get flags: addr bffff4ec flags f000010
Jul 9 22:59:02 linuxer kernel: ppp_tty_ioctl: get flags: addr bffff500 flags f000013
Jul 9 22:59:02 linuxer pppd[7057]: rcvd [IPCP ConfReq id=0x4 <addrs 0.0.0.0 128.8.140.111> <compress VJ 0f 01>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [IPCP ConfRej id=0x4 <addrs 0.0.0.0 128.8.140.111>]
Jul 9 22:59:02 linuxer pppd[7057]: rcvd [IPCP ConfReq id=0x5 <compress VJ 0f 01>]
Jul 9 22:59:02 linuxer pppd[7057]: sent [IPCP ConfAck id=0x5 <compress VJ 0f 01>]
-----(end of examples)-----
I've tried fiddling with various pppd options (e.g. -vj) but I still have no success. What am I doing wrong here?
BTW, here are all the pppd options I'm using:
debug kdebug 7 asyncmap 0 noipdefault lock crtscts 57600
...and I'm running Linux kernel version 2.0.27, with PPP support compiled as a module in the kernel.
Many thanks for any and all help,
--daniel
ASKER
<sauron> has asked if the problem sites assign a dynamic or a
static IP address.
The answer: dynamic IP addresses are assigned in all cases described in my question: the always-good, the always-bad, and the flaky.
static IP address.
The answer: dynamic IP addresses are assigned in all cases described in my question: the always-good, the always-bad, and the flaky.
Hy,
have you tried ipcp-accept-local
and ipcp-accept-remote
Here is my /etc/ppp/options
user jhonny
ipcp-accept-local
ipcp-accept-remote
noipdefault
defaultroute
debug
-detach
lock
-vj
-bsdcomp
modem
and btw, you can't have ppp compiled in the kernel AND as a module. It is one or the other, but not the 2 at the same time.
have you tried ipcp-accept-local
and ipcp-accept-remote
Here is my /etc/ppp/options
user jhonny
ipcp-accept-local
ipcp-accept-remote
noipdefault
defaultroute
debug
-detach
lock
-vj
-bsdcomp
modem
and btw, you can't have ppp compiled in the kernel AND as a module. It is one or the other, but not the 2 at the same time.
ASKER
<cedric> has offered an answer which I'd grade as "B" except
that I tried his suggestions and my problem remains (and I'd
still really like to get an answer).
(And what I meant to say regarding PPP support is that I'm running PPP as a module and that the kernel
is compiled to support PPP as a module.)
that I tried his suggestions and my problem remains (and I'd
still really like to get an answer).
(And what I meant to say regarding PPP support is that I'm running PPP as a module and that the kernel
is compiled to support PPP as a module.)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I have had trouble in the past, using a static ip. SPecifying the IP on the pppd command line fixed the problem.