|
Bugzilla – Full Text Bug Listing |
| Summary: | ppp dialup does no longer modify resolv conf | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x> |
| Component: | Network | Assignee: | Tambet Ingo <tambet> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | forgotten_2Bw2fCSUmf, gp, hpj, mc, msvec, mt, radmanic |
| Version: | Factory | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
bash -x /etc/netconfig.d/dns-resolver
/var/run/netconfig directory tar'd up. |
||
|
Description
Forgotten User ZhJd0F0L3x
2008-09-25 06:47:06 UTC
How netconfig and networkmanager work together is tracked by Marius. I am not fully informed about the agreement between Marius and Tambert. re-assign to mt. Note that it fails both for NetworkManager and if I am starting pppd all by myself (with wvdial or umtsmon for example). It works with umtsmon if I set "NETWORKMANAGER=no", but I do not want to do that. IMVHO, the code in /etc/netconfig.d/dns-resolver is responsible. Ahm... I've an idea what could break this: changes done for bug #401648... Tambet: Where does NetworkManager read the PPP dns server from - /etc/ppp/resolv.conf? This file is not written any more - see bug #401648. Stefan: Can you attach a "bash -x /etc/netconfig.d/dns-resolver" output and the files from /var/run/netconfig/ ? (In reply to comment #3 from Marius Tomaschewski) > Stefan: Can you attach a "bash -x /etc/netconfig.d/dns-resolver" output and > the files from /var/run/netconfig/ ? Sure. At what time? (Right now I'm in the office without PPP, would it still be useful?) NM implements a pppd plugin that receives the IP configuration directly from pppd. NM log file includes the netconfig command line and lines it wrote to netconfig to make debugging easier. OK. As Tamber writes, the NetworkManager should have the settings and it starts "netconfig modify"; this means, the settings should be in /var/run/netconfig. NetworkManager.netconfig. The netconfig "dns-resolver" module should write them to resolv.conf. (In reply to comment #4 from Stefan Seyfried) > (In reply to comment #3 from Marius Tomaschewski) > > Stefan: Can you attach a "bash -x /etc/netconfig.d/dns-resolver" output and > > the files from /var/run/netconfig/ ? > > Sure. At what time? (Right now I'm in the office without PPP, would it still > be useful?) Another idea/reason could be bug 429132; please update to sysconfig-0.71.7. If it still not works, yes - please provide the requested output and the netconfig files. Please provide also the output of grep -E "^NETCONFIG|^NETWORKMANAGER" /etc/sysconfig/network/config (so we have all together). Note that I am not dialing in via Networkmanager but via plain pppd (umtsmon). I will verify if things are fixed in 0.71.7 today. with 0.71.7 it still does not work, using umtsmon to dial in (plain pppd) and with "NETWORKMANAGER=yes". root@stoetzler:~# grep -E "^NETCONFIG|^NETWORKMANAGER" /etc/sysconfig/network/config NETWORKMANAGER="yes" NETCONFIG_MODULES_ORDER="dns-resolver dns-bind dns-dnsmasq ntp-runtime nis" NETCONFIG_DNS_POLICY="auto" NETCONFIG_DNS_FORWARDER="resolver" NETCONFIG_DNS_STATIC_SEARCHLIST="" NETCONFIG_DNS_STATIC_SERVERS="" NETCONFIG_NTP_POLICY="auto" NETCONFIG_NTP_STATIC_SERVERS="" NETCONFIG_NIS_POLICY="auto" NETCONFIG_NIS_SETDOMAINNAME="yes" NETCONFIG_NIS_STATIC_DOMAIN="" NETCONFIG_NIS_STATIC_SERVERS="" Will attach files and bash -x output. Created attachment 244120 [details]
bash -x /etc/netconfig.d/dns-resolver
Created attachment 244121 [details]
/var/run/netconfig directory tar'd up.
During the installation, on the yast2 network proposal page in "General Network
Settings" you're asked if you want to use the NetworkManager or the traditional
"ifup" method. Using a combination of both is not supported any more without
customization.
The implementation in netconfig scripts is as requested by the NetworkManager.
For proper functionality of the NetworkManager, it is required, that the
NetworkManager is maintaining / merging the settings using an own policy and
netconfig is just using the results 1:1 when the netconfig policy is "auto".
Now you have the choice to:
1a) use NetworkManager only
1b) turn off NetworkManager and use ifcfg-* only
2) change to a custom netconfig policy, e.g.
NETCONFIG_DNS_POLICY="STATIC *" or "STATIC ppp0" ... or
NETCONFIG_DNS_POLICY="STATIC_FALLBACK *"
3) write own netconfig modules to apply the settings.
This is no solution that can be used in real-world setups. You will always have the situation where NM cannot handle a specific ppp (or other) device and people will need to resort to wvdial or umtsmon or whatever for dialing in. We need to find a work around to allow the DNS servers to be set in this case. One example: I was not able to dial up with NM via bluetooth / rfcomm / mobile phone. (Maybe I just did not find it, but it works fine with smpppd). I don't really understand most of the comments in this page. From my perspective, if NetworkManager is used and it calls netconfig with correct arguments (which can be verified from /var/log/NetworkManager) and that does not result in these entries in /etc/resolv.conf, there is something wrong with netconfig. NetworkManager does not use _any_ settings from /etc/sysconfig/network, that includes NETCONFIG_DNS_*. Maybe it's time to make NM update /etc/resolv.conf directly again... See comment #11. NM and ifup are two concurrent network setup mechanizms and you have to choose one of them. The bug is not invalid. The bug is maybe "WONTFIX" if you really want to document that you don't care about the user experience. Currently there is no way to use both wireless LAN (where you need NetworkManager) and certain kinds of dialup (which are not supported by NetworkManager yet but for which solutions exist, e.g. kinternet, wvdial and umtsmon), which, for a user, makes for a very bad experience. So If you close the bug, close it as WONTFIX since this documents the "We don't care" best. (In reply to comment #16 from Stefan Seyfried) > The bug is not invalid. The bug is maybe "WONTFIX" if you really want to > document that you don't care about the user experience. > > > Currently there is no way to use both wireless LAN (where you need > NetworkManager) and certain kinds of dialup (which are not supported by > NetworkManager yet but for which solutions exist, e.g. kinternet, wvdial and > umtsmon), which, for a user, makes for a very bad experience. > > So If you close the bug, close it as WONTFIX since this documents the "We don't > care" best. > I understand your disappointment in this case, but the issue is not that we don't want to fix something that is broken, it is more that your request hits a crucial point. Network Manager comes with its own code for managing many aspects of the network. This functionality is separate and additional to the "traditional" setup routines. Network Manager is not a remote control for the board utilities it does the tricks on its own. As such we cannot guarantee proper operation if we mix authorities. Whenever Network Manager is set to rule the network, the traditional setup has to stay away and vice versa. Your request would result in a hybrid which can't be kept consistent. The solution is either Network Manager gets enabled to support the lacking ppp-connections and/or the traditional setup tools learn how to setup wlan accordingly. WONTFIX sounds fair then. I don't understand why this bug is marked as RESOLVED. I had the same problems described above (umtsmon without working DNS) with 11.1 final and after a lot of testing I finally found seifes hack here: http://seife.kernalert.de/blog/2008/12/ . It can't be so difficult to let other programs change the DNS even if Network-Managar is enabled. There are so much people using NM at home or office and umtsmon or kinternet for mobile communication. And this works well in openSUSE 11.0. *** Bug 465679 has been marked as a duplicate of this bug. *** *** Bug 466038 has been marked as a duplicate of this bug. *** Let's place the information how to setup the custom netconfig policy
here:
When the connection is configured using the NetworkManager, a ppp plugin
provides the DNS settings to the NetworkManager and netconfig writes the
settings to the files (/etc/resolv.conf).
While NETWORKMANAGER=yes, the DNS settings from connections that are _not_
configured using the NetworkManager, are discarded in the netconfig "auto"
DNS policy, because it resolves to ”STATIC_FALLBACK NetworkManager”.
_But_ the ppp (ip-up) scripts still provide the DNS settings to netconfig,
that writes them to a file in e.g.
/var/run/netconfig/ppp0
^^^^
and is generally able to use them.
Note: ppp0 is just example -- it may be also e.g. modem0 or dsl0
(check using "ls -1 /var/run/netconfig/*" while the connection is up)
How to change this behavior:
Edit /etc/sysconfig/network/config (use yast2 sysconfig editor) and
change the policy from "auto" to a custom one:
NETCONFIG_DNS_POLICY=”STATIC_FALLBACK ppp0 NetworkManager”
or (accept settings from all ppp, modem, dsl interfaces)
NETCONFIG_DNS_POLICY=”STATIC_FALLBACK ppp* modem* dsl* NetworkManager”
or (accept settings from all interfaces)
NETCONFIG_DNS_POLICY=”STATIC_FALLBACK * NetworkManager”
See also "man 8 netconfig".
It would be good to add that info to wiki, to /etc/resolv.conf comments (or to man page or any other suitable place) so it is easily found by users. Well, I'm not against adding it to wiki, but we've to include also a warning there, that this type of configurations may/will break the NetworkManager, because the nameserver that is provided by the NetworkManager may be not applied correctly (note, that there is a limit of 3 nameservers in /etc/resolv.conf and ppp may provide two) or never used, because they 2nd and 3rd nameserver are used only when the 1st one does not answer. See also comment #17. *** Bug 462686 has been marked as a duplicate of this bug. *** |