Description of problem: wvdial does not update /etc/resolv.conf, even when Auto DNS = 1 Version-Release number of selected component (if applicable): wvdial-1.61-4.fc15 How reproducible: Always Steps to Reproduce: 1. Plug a modem (or a celluar modem capable phone) and add a simple /etc/wvdial.conf, like the one in #701023 2. Run wvdial 3. Drink a cup of coffee, then update /etc/resolv.conf manually Actual results: wvdial does not update /etc/resolv.conf Expected results: wvdial updates /etc/resolv.conf Additional info: Since NetworkManager still does not recognice some Samsung Galaxy phones as celluar modems, wvdial seems the only option, and this should be fixed, see also #701023. According to this blog post; http://beaveryoga.wordpress.com/2009/04/14/wvdial-etcresolvconf-on-fedora-10/ , the reason for this is that /etc/ppp/ip-up is called with 5 arguments, missing the last one which probably is the name of the interface. Thus, a workaround is to add a file /etc/sysconfig/network-scripts/ifcfg- containing the following two lines: PEERDNS=yes DEFROUTE=yes
The 6th parameter passed to /etc/ppp/ip-up is the string defined by "ipparam" option of pppd (see 'man pppd'). So you can add 'ipparam ppp0' (or whatever your device is) to /etc/ppp/options or ~/.ppprc and /etc/sysconfig/network-scripts/ifcfg-ppp0 should contain PEERDNS=yes. A better solution might be usage of 'usepeerdns' pppd option that is designed for this purpose. (Again see manual page for pppd). This option is on by default through wvdial's file /etc/ppp/peers/wvdial. The only missing part is a script that makes use of it. One such example is present is ppp documentation: /usr/share/doc/ppp-2.4.5/scripts/ip-up.local.add. It can be copied as /etc/ppp/ip-up.local. ip-up.local script is checked and executed by /etc/ppp/ip-up. See also bug 517470. Maybe, /etc/ppp/ip-up.local could be part of standard installation of ppp or contained in wvdial as it sets 'usepeerdns' anyway. I've checked some other distros ppp packages and most contain a script that deals with resolv.conf when 'usepeerdns' option is set. E.g: Arch Linux - /etc/ppp/ip-up.d/00-dns.sh in ppp package Debian,Ubuntu - /etc/ppp/ip-up.d/0000usepeerdns in ppp package
CCing John based on comment http://beaveryoga.wordpress.com/2009/04/14/wvdial-etcresolvconf-on-fedora-10/#comment-8
Created attachment 529285 [details] Spec file patch, add install of ip-up.local and ip-down.local scripts As Jirka already pointed out we could copy ip-up.local and ip-down.local into /etc/ppp/ and make them standard part of ppp instalation just like other distros do. This is just simple spec file patch addressing this issue. Please feel free to discuss this issue further, I will be grateful for any feedback.
Adding these two scripts into package seems to resolve the issue, because wvdial sets usepeerdns and ip-up.local script makes use of it. I've build scratch build of ppp in koji http://koji.fedoraproject.org/koji/taskinfo?taskID=3507995 and tested it with wvdial. It's working properly so far. I'm not sure if this is the best solution, anyway, it works. Any further discussion is very welcome.
The same issue was discussed in #524767 closed as a 'notabug'. Please see mainly comments #{6,7,8}. I guess usage of '/usr/share/doc/ppp-2.4.?/scripts/ip-up.local.add' (also *down*) will fix this issue too. Please confirm it. Thanks, Jiri
I will try to sum-up and describe two possible approaches to resolve this issue: a) add line 'ipparam ppp0' to /etc/ppp/peers/wvdial and let the script /etc/sysconfig/network-scripts/ifup-post change the /etc/resolv.conf(file /etc/sysconfig/network-scripts/ifcfg-ppp0 must be present and must contain PEERDNS="yes" option) b) copy file /usr/share/doc/ppp-2.4.5/scripts/ip-up.local.add to /etc/ppp/ip-up.local and do the same for ip-down I've sent an email to maintainer of initscripts package and we've agreed that the a) is better solution and changing /etc/resolv.conf should be done this way. In the end I think that this bug report should be closed as a NOTABUG, but I admit that it would be nice to have a better documentation describing this problem, because DNS is a crucial part of functional network connection.
My 2 cents' worth. I was trying to connect with wvdial on a poor quality phone line without much success, prepared to edit /etc/resolv.conf from the connection dialogue. Suddenly, I found entries in /etc/resolv.conf. Subsequently, I found these were due to my having accidentally left the built-in wifi on. In other words, I hope the solution proposed will still work even if other processes might be affecting /etc/resolv.conf. I was also sometimes finding that even when wvdial actually seemed to make a connection, I got no-route-to-host errors, even though DNS was working. I was presuming this was a problem on my diaup ISP's side, but couldn't help wonder if there might not be a similar interference problem i.e the wifi connection being attempted might be interfering with the routing tables of the dialup connection.
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.