Bug 481016
Summary: | dhclient started by system-config-network fails to create default route | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Oscar Valdez <ovaldez> |
Component: | system-config-network | Assignee: | Harald Hoyer <harald> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | das, harald, jmoskovc |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-12-18 07:40:08 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Oscar Valdez
2009-01-21 18:32:50 UTC
In my Fedora 10 system I am getting a problem with 'system-config-network' and 'dhclient-script', and this problem is continuing from Fedora 8, and one of the reasons I updated the system to F10, but with no use. Whenever I am running 'ifup wlan0', it is getting active all right, but '/etc/resolv.conf' is getting replaced. The same thing is happening when with an weak signal, I have to issue the three commands one by one, 'iwlist wlan0 scan', 'iwconfig wlan0 essid <essid>' and 'dhclient wlan0'. Let me copy the replaced 'resolv.conf' here. << ; generated by /sbin/dhclient-script nameserver 218.248.240.135 >> This nameserver is coming from one datacard connection that I worked with for some time, I activated it with 'wvdial', and later brought in that connection into 'system-config-network'. I presumed that this was being done by NetworkManager, so first I did 'service NetworkManager stop' and then tried, still it did not work. I finally did 'yum erase NetworkManager', still no use. The same thing is happening with 'resolv.conf' and I have to replace with the normal 'resolv.conf' manually before connecting to Net. The same thing is happening with eth0 too. when I try to delete the datacard connection from 'system-config-network' and save the configuration, it is coming out with a message that I should report it to this site, and that is why I came. And the 'save report' option is generating this text. << Component: system-config-network Version: 1.5.95 Summary: TB3b3456f8 ConfPAP.py:114:getfields:BadFile: Error occured while parsing //etc/ppp/pap-secrets Traceback (most recent call last): File "/usr/share/system-config-network/netconfpkg/gui/maindialog.py", line 805, in on_activateButton_clicked self.activateButtonFunc[self.active_page](button) File "/usr/share/system-config-network/netconfpkg/gui/maindialog.py", line 1021, in on_deviceActivateButton_clicked if self.save() != 0: File "/usr/share/system-config-network/netconfpkg/gui/maindialog.py", line 411, in save self.saveDevices() File "/usr/share/system-config-network/netconfpkg/gui/maindialog.py", line 431, in saveDevices devicelist.save() File "/usr/share/system-config-network/netconfpkg/NCDeviceList.py", line 222, in save papconf.delallitem([key, server]) File "/usr/share/system-config-network/netconfpkg/conf/ConfPAP.py", line 245, in delallitem var = self.getfields() File "/usr/share/system-config-network/netconfpkg/conf/ConfPAP.py", line 114, in getfields raise Conf.BadFile, "Error occured while parsing %s" % self.filename BadFile: Error occured while parsing //etc/ppp/pap-secrets Local variables in innermost frame: var: [] regexp: <_sre.SRE_Pattern object at 0x9e958d8> self: <netconfpkg.conf.ConfPAP.ConfPAP instance at 0x9de3b8c> m: None >> The datacard connection that I used on the system for some time was named 'bsnl-nic'. And I saw that the '/etc/ppp/pap-secrets' was changed by it. The changed file was this: << # Secrets for authentication using PAP # client server secret IP addresses ####### system-config-network will overwrite this part!!! (begin) ########## "165" "bsnl_nic" "165" "165" * "165" ####### system-config-network will overwrite this part!!! (end) ############ \ 0 \ 165 0 165 >> Now I edited it and restored it to its default: << # Secrets for authentication using PAP # client server secret IP addresses ####### system-config-network will overwrite this part!!! (begin) ########## ####### system-config-network will overwrite this part!!! (end) ############ >> Exactly the same thing happened with '/etc/ppp/chap-secrets'. Restored that too the same way. After this I could delete the datacard connection named 'bsnl-nic' from 'system-config-network' without any error message the way I was getting them, as I reported earlier. But, 'ifup eth0' or 'ifup wlan0' are still happening with that '/etc/resolv.conf' getting replaced with a 'resolv.conf' that is coming from the times when I connected with 'bsnl-nic'. So, somehow the configuration of /sbin/dhclient-script has got corrupted too the way pap-secrets and chap-secrets did. This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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. |