Paul Mackerras wrote:
>
> > My idea for a quick repair for this situation is to extend
> > the function of the ipcp-accept-* options to not only
> > accept what they are told, but to not even let it be known
> > that there is any sort of idea of what the numbers should be
> > on this side at all.
>
> The noipdefault option does this.
>
> Paul.
No it doesn't.
The noipdefault option is concerned with whether we try to determine
what our local address is by making system calls that return such
information.
noipdefault
Disables the default behaviour when no local IP
address is specified, which is to determine (if
possible) the local IP address from the hostname.
With this option, the peer will have to supply the
local IP address during IPCP negotiation (unless it
specified explicitly on the command line or in an
options file).
"passive" doesn't do it either, haven't tried "silent" -- gonna
do that now --
Looks like "silent" has prevented the interface from coming up at all.
Removed. Here's what I'm getting. with both ipcp-accept options turned
on.
(without ipcp-accept-remote the connection drops, ipcp-accept-local has
no effect
since the peer in this case accepts my placeholder.)
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.10.10.10 P-t-P:134.193.216.254
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0
TX packets:0 errors:290 dropped:10 overruns:0
since the Cisco on the other end is being lax with its assignments. If
we could keep ppp0 without telling the kernel what its address is we'd
be okay,
but we can't. If we could patch IOS_12 to have an ipcp-assert option
we'd
be okay, but we can't. And is the cisco really doing wrong? It assigns
addresses
from its pool just fine except when the local end presents its IP, then
it
accepts it. Like, the remote end has ipcp-remote-accept turned on and
that is
not something I can change.
I might be able to add the option myself -- call it "ipcp-conf-only"
perhaps. Or "ipcp-silent" which would imply ipcp-accept-*. Or
noipcpassert. Or simply accepting ipcp-accept-* to not even assert
instead of accepting being overruled. (Because some times the
other end will not overrule -- whoever says first, gets it their way.)
Maybe "ipcp-lazy" which would mean not to give the ipcp data until
determining that the peer has no idea either.
Another annoyance with the current demand option is that "lock" no
longer seems to work; instead of instantly crapping out on starting
as pppd does without demand on second invocation, a ppp1 interface is
invented and configured. (so I have dropped all the pppd invoking lines
from my dialing out scripts and replaced them with `ping -c1
www.netscape.com`
which raises the interface without messing with the next instruction's
timing.
I could probably repair both of these, haven't looked at the source yet,
could you advise where a good place to start would be? And to whom do I
send my potential upcoming patch?
----
I don't want to appear too critical, the demand mode has substantially
reduced the amount of time my scripts are using the phone line, since
previously
I had a set of loops waiting for pings to succeed, and a cheap idle
implemented
with `netstat | wc -l` which would wait for all the dead connections to
time out before running /etc/ppp/ppp-down. Also the man page says quite
clearly that pppd is not reccommended for dynamicly assigned
connections.
Unfortuneately 98% of the isps in the world at this time use dynamicly
assigned
addresses.
Using a different ISP that does assert the ip address for my end in
an over-ruling statement, I have had success using pppd +demand with a
dynamicly assigning ISP. (a different ISP than the one I need the patch
to support.)
david nicol
________________________________________________________________________
David Nicol 816.235.1187 [EMAIL PROTECTED]
"Thou knowest full well that these idols do not speak!"
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
