This is a workaround for a bug where iperf3 will just block
randomly and no longer send data. It may effect the absolute
performance measurements compared to the default buffer value
although I didnt see that in my testing
* Deduplicate and sort tag names in Advanced DHCP Options selector.
* Only build the deduplicated list of tag names once.
* Build DHCP option tag table more efficiently.
* First draft of advanced DHCP option specification on Ports tab.
Allows the node administrator to specify additional DHCP options that
will be supplied to LAN clients in specific circumstances. This change
adds two tables to the Ports configuration tab.
The "Tags for Advanced DHCP Options" table allows the administrator to
specify DHCP tags that will be assigned to clients that identify
themselves with specific values for properties such as Vendor Class or
MAC address.
The "Advanced DHCP Options" table allows the administrator to specify
arbitrary DHCP options to send to any client, or only to clients with a
specific tag. Option numbers can be entered directly or chosen from a
list of well-known options. Option values are manually entered by the
administrator.
In-browser validation is implemented for all input fields with easily
recognizable content such as host names, MAC addresses, and port and
option numbers. Placeholders are also supplied for input fields, such as
MAC addresses with wildcard matching, that might otherwise be difficult
to describe.
Issues with the current version:
- Sending DHCP options not requested by the client is implemented using
the dhcp_option_force UCI configuration option, but does not currently
work.
- Tagging by client host name is supported by dnsmasq, but not yet by
UCI.
- DHCP option values must be entered manually by the administrator, but
are not currently validated.
* Better validation, placeholders, and hints for existing input fields.
* Remove junk accidentally inserted in comment.
* Preserve Advanced DHCP options across updates.
* Improve tunnel and xlink display information
* Also weight nlq.
This is assumed both ends of a tunnel are equally weighted as we
have no way to get this information directly.
Unfortunately there doesnt appear to be much flexibility in the various
hardware watchdogs on radios, so setting the watchdog > 60 seconds mostly
doesnt work. So rework the settings to allow for this and that our watchdog
tests must be frequent and quick.
* Watchdog support, initial version.
The watchdog monitors three things:
1. A set of important system daemons.
2. A set of pingable ip addresses.
3. A time the node should reboot everyday.
Tim Wilkinson