Re: NM using Option card

[Markus Becker <mab comnets uni-bremen de>]

On Thu, 7 Feb 2008, Dan Williams wrote:

> 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.

OK, done that and investigated further on the web. When you are not giving 
the option "defaultroute" it will give you the following DNS entries:
nm-pppd-plugin: DNS1 10.11.12.13
nm-pppd-plugin: DNS2 10.11.12.14

When you are providing the option "defaultroute" (I patched 
nm-ppp-manager.c), it will give you the correct DNS addresses:
nm-pppd-plugin: DNS1 139.7.30.125
nm-pppd-plugin: DNS2 139.7.30.126

With this option, it works perfectly for me. However, I think you do not 
want ppp to modify the routes, but rather handle the routes from NM. Why 
is ppp not returning the right DNS addresses, when it is not allowed to 
modify the routes?

> 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