Makes the nodes advertise using DHCP Options 121 and 249 routes to the mesh (10.0.0.0/8) and the reserved (172.16.0.0/12) address ranges.
This change allows directing systems to prefer the mesh node for mesh ranges unless another network rule is more specific (such as a directly connected network)
This is mostly useful where a PC may have multiple network connections active as it improves the desire for the packets to travel via the mesh network.
Currently the:
10.0.0.0/8 range is used by mesh nodes and dtdlinking of mesh nodes.
172.27.0.0/16 is used for default LAN network on NAT nodes.
172.33.0.0/16 is for ad-hoc tunnels
All others in the advertised range are reserved for future network use.
nvram-setup may be the only script we have to worry about as it may call configs for interfaces that do not exist in the current mode.
By default get_interface will return a static mapping when it can't find an active config entry meaning that eventually get_interface will need an update routine to pull out of local running config
The lack of this update routine should be acceptable for now as we have no GUI for users to change the mapping.
Create get_interface which will lookup in the current uci network config the realname for the logical interface name.
When the interface is not found it will fall back to a hard coded list.
Configure the UI to use the new get_interface function.
Under Barrier Breaker sometimes OLSRD gets started before any interface is up causing OLSRD to shutdown because no interfaces exist.
Forces OLSRD to stay on and wait for the interfaces to come online.
Nodes sometimes show up as a mid1 entry when dtdlink and RF connected.
Sometimes the nodes will get the eth0 ip because wlan0 is not up yet.
Under Barrier Breaker the MainIP option is now supported as part of the uci system which allows us to restore using this setting.
We can now force the IP address that is claimed (wlan0) for the primary IP of the node.
Since a large number of the BBHNDev team has decided to create firmware fully independent of the BBHN Project the decision has been made to rebrand the firmware to differentiate from the origional BBHN work.
We would like to thank all those whom have worked on the BBHN firmware over the years and all those who continue to work on the firmware under AREDN(TM).