* Simplify the OLSR watchdog
* Dont pull the routing table into LQM for supernodes.
LQM tracks routes on nodes to help keep leaf nodes connected even
when circumstances would probably prevent this. However on supernodes
the routing table is massive and pulling this into LQM will frequently
crash OLSRD. As we dont need this for supernode just dont do it for them.
- The "Always" checkbox now works for options with an explicit tag, and
is disabled for untagged options; the latter cannot be supported because
of a limitation in the OpwnWRT configuration language.
- Tagging by host name has been removed; it didn't work before and isn't
particularly useful in the AREDN context.
- Tagging by Agent Circuit ID, Agent Remote ID, and Subscriber-ID are
now supported so that a DHCP Relay Agent can be used to extend the LAN
across multiple subnets.
- Small improvements were made to error handling and hints.
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.
* 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.
Tim Wilkinson