Bug 14933 - Linuconf segfaults with emty subnet entry in dhcp.conf
Summary: Linuconf segfaults with emty subnet entry in dhcp.conf
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: linuxconf
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-31 22:32 UTC by dbelliz
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-08-22 01:50:22 UTC
Embargoed:


Attachments (Terms of Use)

Description dbelliz 2000-07-31 22:32:35 UTC
My DSL provider has given me a stub network with a netmask of /30. Since
both valid addresses are already taken by my DSL router and my dhcp server,
there are no free addresses to assign to a range.  

Dhcpd fails to start with 

Internet Software Consortium DHCP Server 2.0
No subnet declaration for eth0 (192.0.0.196).
Please write a subnet declaration for the network segment to
which interface eth0 is attached.
exiting.

if the there isn't a subnet entry in /etc/dhcp.conf like

subnet 192.168.0.196 netmask 255.255.255.252{
}

Linuxconf however will not let me assign a dhcp subnet with a range of 0. 

If I manually edit the file and put the above subnet entry in the
/etc/dhcp.conf linuxconf will allways segfault.  


This is reproducable with 

linuxconf-1.17r2-6
linuxconf-1.19r2-1

Comment 1 Larry Adams 2000-08-22 01:50:18 UTC
I have a similar problem.  I have a subnet mask of 255.255.255.192.  When I 
setup the network settings below and then run "netstat -nr" I receive invalid 
information and routing outside the subnet does not work.

IP Address:  148.98.150.138
NetMask:     255.255.255.192
Gateway:     148.98.150.1

netstat -nr reports

IP Address:  148.98.150.138
Genmask:     255.255.255.255 (What's This Netmask ??????)
IP Address:  148.98.150.129  (This IP Address does not exist on the Network)
Genmask:     255.255.255.192 (Should have been assigned to 138 above)

I am screwed!  Can not make networking work.

Larry.J.Adams


Comment 2 Nalin Dahyabhai 2000-09-12 19:50:37 UTC
A range cannot have zero addresses.  If you mean to not have
dynamically-allocated addresses, just omit the range altogether.  If you want to
assign one address dynamically, then it is both the upper and lower bound of the
range you want to make available, so use either 1 address or specifiy the same
number for both the beginning and end of the range.

Larry, your problem is different.  With and IP of 148.98.150.138 and a netmask
of 255.255.255.192, your gateway cannot be anything outside the range
148.98.150.128 to 148.98.150.191, so you've been given bad data.  The first line
from netstat is the address of your interface, the second is the network of
addresses that its interface and netmask show would be "local", and can
therefore be reached without having to go through a gateway.

Comment 3 dbelliz 2000-09-13 01:33:36 UTC
Pardon me but, thats bull.  All I was asking for is the same functionality with
linuxconf as with manual configuration. If I can specify a blank range (a range
of zero addresses or how ever you want to say it) with the following in the
dhcpd.conf file, why then can't I do it with linuxconf. 

subnet 192.168.0.196 netmask 255.255.255.252{
}

My bug is still valid. If you manually configure dhcpd.conf with above and run
linuxconf with the dhcpd module active it will segfault.  

I can't see why you labeled it as not a bug when it's completely reproduceable.

You say to "just omit the range altogether" linuxconf will not let you do this. 
have you tried to repro the problem or are you just cleaning old bugs?



Comment 4 Ken 2000-10-01 05:00:54 UTC
dbellize is right.  If I have a subnet {} statement with nothing inside, or in
my case just 'option netmask 255.255.255.248;' within, Linuxconf crashes, and
dumps core.

Once I commented out the 'offending' subnet statement, Linuxconf works.  This is
a bug with Linuxconf, not dhcpd (since it functions fine with the statement in)

linuxconf-1.17r2-6
linuxconf-devel-1.17r2-6



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