Re: NM using Option card

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
address: defaulting to

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 If I enter that manually into
/etc/resolv.conf, the connection works. But why is ppp not getting DNS

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

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


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
nm-pppd-plugin: DNS2

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
nm-pppd-plugin: DNS2

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?


If you mean ppp or something else, it would have to wait until tomorrow.


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


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:

   if (ho->hisaddr == 0) {
	ho->hisaddr = htonl(0x0a404040 + ifunit);
	warn("Could not determine remote IP address: defaulting to %I",


Maybe NetworkManager should trap that magic and replace it with the
interface address like use to happen before.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]