* Cache the last wifi scan and update it when a re-scan is requested.
This change was suggested as a way of handling Ubiquiti AC devices
which disconnect while scanning and making retrieving the results
problematic if that was your connection. Now we scan and store the
results so they can be retrieved later. In fact we no longer scan when
navigating to this page but require an explicity scan button push.
This make the page generally more responsive when initially navigated
to.
* Reboot/reflash progress bar, time remaining in MM:SS
When rebooting or reflashing the node, display a progress bar as
well as the estimated time remaining. Also show the time remaining
in MM:SS format.
* Fix indentation error.
* Minor changes to improve browser compatibility.
Experimental wifi research reports that increased retries (rather than decreased as I originally
thought) improves tcp throughput on multi-hop wifi networks.
On some devices the hardware MAC for the WLAN and ETH are the
same so the 10.DTD and 10.WLAN addresses are identical. If we
detect this, bump the DTD address.
Commonly seen on TP-Link devices (but there are others)
Too many retries appears to cause network congestion issues slowing down
links with multiple hops, but reducing this to 1 then caused single links
to have poor performance. Try a rety of 2 as a better compromise.
* Revert hAP AC Lite xlink support
* Support CIDR (e.g. /24, /16, etc) on a xlink
Xlink had originally been envisaged as a point-to-point connection
leaving the "how" of that to other software. However, there's a use case
where the non-AREDN radios in the xlink need to be accessed, and allocating
addresses within the xlink's address range is a good way to do that.
By supporting a a subnet on a xlink we can enable this.
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