conf/187457: ifconfig IP range assignment too restrictive

[Adam McDougall]

>Number:         187457
>Category:       conf
>Synopsis:       ifconfig IP range assignment too restrictive
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 11 22:10:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator:     Adam McDougall
>Release:        FreeBSD 10.0-STABLE
>Organization:
>Environment:
FreeBSD build10 10.0-STABLE FreeBSD 10.0-STABLE #0 r262298: Fri Feb 21 18:28:26 EST 2014     root at build10:/usr/obj/usr/src/sys/BUILD10  amd64
>Description:
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"

>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"
>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.

>Release-Note:
>Audit-Trail:
>Unformatted: