Bug 481016 - dhclient started by system-config-network fails to create default route
dhclient started by system-config-network fails to create default route
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: system-config-network (Show other bugs)
10
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-21 13:32 EST by Oscar Valdez
Modified: 2009-12-18 02:40 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:40:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Oscar Valdez 2009-01-21 13:32:50 EST
Description of problem:

I use profiles with system-config-network, and keep the NetworkManager service
stopped at all times.

When I start device wlan0 from system-config-network, I get the following in
/var/log/messages:

NET: dhclient: failed to create default route: 192.168.167.30 dev wlan0 
NET[3612]: /sbin/dhclient-script : updated /etc/resolv.conf

If I run dhclient -v -d eth0 at a shell, the default route is created. The
output is as follows:

/var/lib/dhclient/dhclient.leases line 17: semicolon expected.
}
 ^
/var/lib/dhclient/dhclient.leases line 17: unterminated lease declaration.
}
 ^
Listening on LPF/wlan0/00:1a:92:54:d1:bb
Sending on   LPF/wlan0/00:1a:92:54:d1:bb
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16
DHCPOFFER from 192.168.167.53
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.167.53
bound to 192.168.167.210 -- renewal in 417053478 seconds.


Version-Release number of selected component (if applicable):
dhclient-4.0.0-33.fc10.i386


How reproducible:
Always when getting default route info via DHCP on wireless device.


Steps to Reproduce:
1. start system-config-network
2. start DHCP wireless device
3.
  
Actual results:
No default route in routing table

Expected results:
Default route created in routing table

Additional info:
Comment 1 das 2009-02-12 23:45:31 EST
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
>>
Comment 2 das 2009-02-13 07:08:00 EST
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.
Comment 3 Bug Zapper 2009-11-18 05:49:14 EST
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
Comment 4 Bug Zapper 2009-12-18 02:40:08 EST
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.

Note You need to log in before you can comment on or make changes to this bug.