Todo #6501

Tightening up subnet expansion

Added by Stilez y almost 3 years ago. Updated almost 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


A couple of days ago I put a PRE into Github to remove the subnet_expand() function. It isn't used anywhere in the codebase, isn't robust, and would need a complete rewrite to handle IPv6 anyway.

But then I noticed a few places exist where subnet expansion does happen - just not using this function. Typically this is related to subnet VIPs and in particular Radius or ARP Proxy config, where the user gets a drop-down list of interfaces which include VIPs generated from a subnet:

  • services_captiveportal.php - build_radiusnas_list()
  • pkg_edit.php - generic proxy-ARP GUI element
  • firewall_nat_edit/nat_out_edit/nat_1to1_edit.php - same code, proxy arp interface list

I'm not sure what would nee fixing in these, but some things do, and I;m happy to fix them if I know what's wanted. So this is a todo that I'm happy to do myself if someone can answer a couple of Q's:

  1. What is a "reasonably largest" number of values that should be autocreated in order that a <select> element remains tolerably long (and not too hard to generate/render, especially on nano-platforms)?
  2. As a user could have quite a large VIP subnet, what should the GUI do to make it easy for the user, if the number of interfaces+VIPs to be offered in a GUI form is more than this?
  3. Alternatively, any thoughts on a better way to offer a list of IPs/IFs/VIPs than a dropdown list, which saves the system having to manually create an arbitrary length dropdown list when it is very long?


#1 Updated by Stilez y almost 3 years ago

4. Is IPv6 catered for by its own functionality, if not does this need an IPv6 equivalent and what would that look like? (none of the above examples handle IPv6 and I can't be sure if they need to or if it's an IPv4-only matter)

Also available in: Atom PDF