Bug 187457 - ifconfig(8): ifconfig IP range assignment too restrictive
Summary: ifconfig(8): ifconfig IP range assignment too restrictive
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: Normal Affects Some People
Assignee: Hiroki Sato
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-11 22:10 UTC by Adam McDougall
Modified: 2015-04-02 23:37 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam McDougall 2014-03-11 22:10:00 UTC
Recently I came up with the need to assign almost every IP in a /24 subnet
to an interface.  I wanted to avoid 250+ lines in /etc/rc.conf so I read
the rc.conf manpage and discovered the wonderful range feature where I
thought I could use:

ifconfig_lagg0_alias0="inet 10.0.30.2-254/24"

I found out it only creates addresses up to around .34 and prints "Range
specification is too large", all as an anti foot-shooting protection due
to _IPEXPANDMAX=31 in /etc/network.subr.  Could the code be changed to
allow for example a whole /24 to be created with a single range?

Looking at SVN, this appears to apply to 9 as well.

Workaround: define a bunch of smaller ranges:
ifconfig_lagg0_aliases="inet 10.0.30.2-31/24 inet 10.0.30.32-63/32 \
inet .... etc etc"

Fix: 

Raise _IPEXPANDMAX=31 in network.subr?  Untested but seems logical since
the only apparent purpose is to prevent accidental misconfiguration.
It is easy to see if the range is defined too large then it might make
a poor choice regarding broadcast IPs, oversized netmasks or something.
I didn't check exactly how many IPs it assigned, it should be near 32.
I was in a rush and had to settle for a workaround that evening.
How-To-Repeat: Try to set a large range in /etc/rc.conf and reboot.
ifconfig_interfacename0="up"
ifconfig_interfacename0_alias0="inet 10.0.30.2-254/24"
Comment 1 Adam McDougall 2014-09-27 22:09:17 UTC
r271424 from head should directly address this issue.  Could it be merged to 10-STABLE for 10.1-RELEASE?  Another report 186841 was mentioned in the commit.  Thanks.
Comment 2 Adam McDougall 2014-10-06 13:55:48 UTC
The new implementation was committed to stable/10 as r272577 and stable/9 as r272581.  I have no idea if it can or will be requested to be in 10.1-RELEASE.  I will be using -stable, but others depend on releases.
Comment 3 Adam McDougall 2015-04-02 23:37:23 UTC
This did make it into 10.1-RELEASE as r273039.  I didn't check 9.  Good enough for me, marking closed, fixed.