Bug 73236 - Configuring an interface with valid IP and valid subnet mask but no default gateway causes anaconda to crash
Summary: Configuring an interface with valid IP and valid subnet mask but no default g...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: anaconda
Version: null
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks: 67217
TreeView+ depends on / blocked
 
Reported: 2002-09-01 14:38 UTC by Terry Froy
Modified: 2007-04-18 16:46 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-09-03 00:00:48 UTC
Embargoed:


Attachments (Terms of Use)

Description Terry Froy 2002-09-01 14:38:31 UTC
Description of problem:
anaconda detects my onboard NIC (8139too) but as I do not use DHCP, I 
configured the interface with a spare IP address from my subnet and used the 
correct subnet mask but as I did not want the machine to have Internet 
connectivity (just talk to my local subnet), I omitted the gateway.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Boot with Null CD #1.
2. Accept default options until eth0 configuration is displayed.
3. Unselect DHCP, specify IP address and subnet mask but leave default gateway 
empty.
4. Allow package installation to complete.
5. 'Post-install configuration' takes place.
6. The 'Post-install configuration' progress bar disappears...	

Actual Results:  The 'unhandled exception' dialog appears with the traceback 
information which I enclose.

Expected Results:  If the interface configuration portion of anaconda genuinely 
requires the supply of a default gateway (shouldn't really - a machine with no 
default gateway is still a valid TCP/IP configuration), then the interface 
configuration dialog should throw up an error message stating that a default 
gateway is required.

Of course, the other thing which should have happened is for anaconda to have 
merely configured the interface correctly but not set a default route 
in /etc/sysconfig/network.  This is the behaviour which I would have expected 
to occur (this is what happens in Mandrake 8.2).

Additional info:

The anacdump.txt file which I wrote to floppy contains the following traceback:

Traceback (most recent call last):
  File "/usr/lib/anaconda/gui.py", line 778, in handleRenderCallback
    self.currentWindow.renderCallback()
  File "/usr/lib/anaconda/iw/progress_gui.py", line 149, in renderCallback
    self.intf.icw.nextClicked()
  File "/usr/lib/anaconda/gui.py", line 631, in nextClicked
    self.dispatch.gotoNext()
  File "/usr/lib/anaconda/dispatch.py", line 150, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/dispatch.py", line 215, in moveStep
    rc = apply(func, self.bindArgs(args))
  File "/usr/lib/anaconda/packages.py", line 68, in writeConfiguration
    id.write(instPath)
  File "/usr/lib/anaconda/instdata.py", line 106, in write
    self.network.write (instPath)
  File "/usr/lib/anaconda/network.py", line 279, in write
    ip = self.lookupHostname()
  File "/usr/lib/anaconda/network.py", line 186, in lookupHostname
    self.gateway)
  File "/usr/lib/anaconda/isys.py", line 379, in configNetDevice
    return _isys.confignetdevice(device, ip, netmask, gw)
TypeError: argument 4 must be string, not None

Local variables in innermost frame:
gw: None
ip: 193.195.23.177
netmask: 255.255.255.240
device: eth0

Although I am no Python guru, I recognize a function prototype mismatch when I 
see one.  I would guess that the function which is being called to configure 
the device is expecting a default gateway but b0rks when it is supplied with 
null (quite amusing.. considering the name of the beta ;-) ) instead of the IP 
address in a string.

Comment 1 Michael Fulbright 2002-09-02 15:12:43 UTC
Thanks for this report - I've seen it reported before but your instructions on
how to reproduce it are good.


Comment 2 Michael Fulbright 2002-09-03 00:00:40 UTC
Verified this no longer crashes.

Comment 3 Ben Levenson 2002-09-03 21:21:05 UTC
fix verified.


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