Re: NM using Option card

[Dan Williams <dcbw redhat com>]

On Fri, 2008-02-08 at 09:45 +0100, Markus Becker wrote:
> 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?

Yeah, that looks like an accurate assessment.  pppd ties those two
options together, requesting a default route from the peer and setting
the default route itself in ipcp_up().  Also, apparently your ppp peer
doesn't send the correct DNS servers when you don't request defaultroute
during the negotiation.  And we don't really want pppd messing with the
routing table; so maybe we'll have to patch pppd with a --dont-modify
switch to turn of it making any changes to anything.

Dan

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