Re: NM using Option card

[Dan Williams <dcbw redhat com>]

On Thu, 2008-02-07 at 21:59 +0100, Markus Becker wrote:
> On Thu, 7 Feb 2008, Dan Williams wrote:
> 
> > 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?
> 
> You mean nm-ppp-manager.c or the ppp executable? nm-ppp-manager already 
> outputs the command line:
> Feb  7 21:38:35 shelbyville NetworkManager: <debug> [1202416715.931005] 
> nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock ttyUSB0 
> noauth refuse-eap refuse-chap nodeflate usepeerdns plugin 
> /home/mab/install/lib/pppd/2.4.4/nm-pppd-plugin.so

nm-pppd-plugin, basically print out the stuff that this function stuffs
into the hash table:

src/ppp-manager/nm-pppd-plugin.c::nm_ip_up()

You're interested in opts.dnsaddr[0] and opts.dnsaddr[1], and possibly
opts.dnsaddr[2] as well if that exists.  Log those integers to a file,
or if you want to get fancy, run them through inet_ntop() and get the
real address string.

Dan

> If you mean ppp or something else, it would have to wait until tomorrow.
> 
> Thanks,
> Markus
> 
> > 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
> >>>
> >>>
> >