Re: NM using Option card

[Dan Williams <dcbw redhat com>]

On Thu, 2008-02-07 at 21:40 +0100, Markus Becker wrote:
> On Thu, 7 Feb 2008, Dan Williams wrote:
> 
> > On Thu, 2008-02-07 at 21:19 +0100, Markus Becker wrote:
> >> Feb  7 20:56:34 shelbyville pppd[10716]: Could not determine remote
> >> IP
> >> address: defaulting to 10.64.64.64
> 
> Searching the web for this, reveals, that this seems to be very common 
> with UMTS dialup, but works nevertheless, if the DNS is correct, e.g. 
> something like 194.48.139.254. If I enter that manually into 
> /etc/resolv.conf, the connection works. But why is ppp not getting DNS 
> addresses?

Any chance you could patch the nm-pppd-helper binary to write all the
options it gets out to a file somewhere and then send that to the list?
That's what I had to do when debugging the P-t-P address thing, because
pppd squelches any output the plugin might print.  That would help us
figure out if your remote side has the issue, or if it's a
NetworkManager problem, and if so where in NetworkManager the problem
lies.

Dan

> >
> > That bit looks suspect...  Never seen that message from pppd before, but
> > it might have something to do with it.  I had to modify the ppp helper
> > code when adding CDMA support to grab the remote IP address and set that
> > as the interface's P-t-P address, otherwise my Sprint cards wouldn't
> > work.  Previously to this, the interface's P-t-P address was getting set
> > to the same address as the interface address.
> >
> > Ultimate fail:
> >
> > pppd/ipcp.c
> >    if (ho->hisaddr == 0) {
> > 	ho->hisaddr = htonl(0x0a404040 + ifunit);
> > 	warn("Could not determine remote IP address: defaulting to %I",
> > 	     ho->hisaddr);
> >    }
> >
> > WTF?????
> >
> > Maybe NetworkManager should trap that magic and replace it with the
> > interface address like use to happen before.
> >
> > Dan
> >
> >