Project

General

Profile

Actions

Todo #6501

open

Tightening up subnet expansion

Added by Stilez y almost 8 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Web Interface
Target version:
-
Start date:
06/19/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:

Description

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?
Actions

Also available in: Atom PDF