Early merge of 3.15.1.0 into develop due to a large number of code changes in the release branch.
Will merge again in the future when the branch is closed but want to pull in changes now from release.
Not getting much debug information at moment, would like to put this in uci-defaults but with issues that I can't seem to log at moment (and not having serial cable for this device) I'm going with lets put it in /etc/init.d/local before nvram and similar gets set.
ref AREDN->ticket:115
Due to issues we are pulling the showing of tunnels untill we can better detect them.
We are also pulling dtdlink as all AREDN nodes should have dtdlink enabled.
Old code would set mac on the sub-vlan not the master interface which could cause issues.
Rework to be more functional in the future and to work correctly on vlan interfaces.
ref AREDN->ticket:115
Switch to iw over iwinfo because it handles the new channels better.
Partially reverts changeset:808a8d5019fce4a7ca2c027ea7838d43c6d8cad0/aredn_ar71xx
fixes AREDN->ticket:129
Trying to registry over-write the antenna setting has never been a good idea in the first place.
The hardware fully handles antenna selection without forcing it already.
ref AREDN->ticket:120
To overhaul the system to allow "0" would take a significant re-write of kernel code. At this time its best to pull channel '0' as it is not in any clear RF space (channel 1 overlaps it)
ref AREDN->ticket:114
Firewall rules don't get called because vtund is at /usr/sbin/vtund not /usr/bin/vtund
Also make the check if line posix compatible while we are chaning the path to be sure it works in the future too.
add nodename and tstamp to default filename to reduce chance of submitting wrong file
timestamp may not always be 'real' time if a node does not have ntp access
Remove the chmod step inside of setup.
Came across one time where this didn't trigger.
In addition this saves us from using additional storage space on the node as a +x creates a duplicate file.
When calling uci commit the file gets overwritten and as such the additional file lines are discarded because the active /etc/config/firewall is diffrent than the open file.
Use the uci commit further down in node setup.
All node type's except mesh have been deprecated.
In a future release we will remove them (and the associated code) to streamline the project.
It is recommended to use a dedicated purpose driven device for these modes in the future
wifi detect is called in /etc/init.d/boot before uci_apply_defaults is called.
Because of this if we don't have the data about the radio0path we need to remove the wifi config file first before calling wifi detect.
Needs to be in uci-defaults to be sure these data sets execute BEFORE the OS boots
We also need to get radio0 path because its mandatory for wifi to work.
Needed for sysupgrade from 3.0.2 to latest version.
Allows nodes to default to a common channel that is in the most common bandplan space for Part 97 usage.
Local cordination is still needed by users to make sure the channel matches the local deployment.
Defaults are as follows:
Band : Channel Freq : Bandwidth
900 : 912MHz : 5MHz
2400 : 1 2412MHz : 20MHz
3400 : 3420MHz : 5MHz
5800 : 149 5745MHz : 5MHz
2.4GHz keeps channel 1 at 20MHz because it is the standard deployment.
All other bands are still 'new' and no standard exist so we are creating one.
5MHz chosen because it better fits the emcomm goal. Smaller width should be stronger allowing for better networks.
Local networks can change as they see fit.
Remove setting RF channel on first boot in uci-defaults.
This should allow the node to use standard wifi channels when it boots allowing mesh setup to be run from a laptop or mobile device.
We will later move them to a real mesh channel during the mesh setup page.
Should also resolv issue where nodes were booting up on channel -2 and similar and wifi would refuse to start due to regdomain.
When a node is first setup (unconfigured) the rf channel or when user presses reset button the wifi channel and bandwidth will be set to mesh default even if it does not match the current RF channel.
Spectrum testing proved to work out well. Merge code into mainline so we can better test with the rest of the hardware.
Also extends ability for 3.4 GHz devices (3.38=3.50)
Adds 5MHz spacing options for 5.8Ghz and allows more channels
Adds -2,-1,0 channel support on 2.4GHz
Conflicts:
files/www/cgi-bin/channelmaps.pm
Add the NLQ to the remote neighbors display so users can see both directions of the path from the mesh status screen.
ETX is dependent upon both directions of the path.
Config file is present upon initial start and in mesh mode.
Daemon still starts up in other modes but will not function w/o settings.
Firewall:
Permit access for UDP:161 (SNMPD) on WIFI and DTDLINK
Lan is permitted by default allow rules.
LINK1 LED was based on Ubiquiti file names, changed to determine base on file name instead.
This should open up more device support long term as well as solve the initial issue.
Testing mode for CPE510
Offset needs to be looked into, OS reports a max power of 23dbm need to see if this is kernel, or offset related.
Should provide enough details for the board to be registered in the UI
When a device does not have a subsystem device ID we will fall back to the board_detect routine.
In the case of a TPLink CPE510 the model will be along the lines of "TP-Link CPE510 v1.0"
In the case of TPLink CPE510 this also includes a hardware version so should the hardware be changed in the future we will be able to key off that as well.
Returns the same data for devices as CPUInfo would of returned for previous devices and for new devices like the CPE510 causes the system to list the exact model instead of of the family.
M3 is a 5.8GHz unit with a 2GHz offset transverter.
5MHz width is recomended on these channels.
Send to spectrum analysis for verification that output looks clean.
Stepping stone to working on the wider width of the full 3.4GHz band which has more channels but unlike channels 95-100 (added in this commit) the rest are outside the normal 5.8GHz cal range (but are between two cal points so may be fine)
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).
Program went GPLv3 last year but license text was never added to files
Default text to give credit to David as he is listed in all commits and to reference the BBHN Austin team at the same time as they were part of the group of HAM's that started this project.
Using the method suggested by Henning Rogge in 2014
{{{
1) remove file
2) wait 2 intervals
3) if file exists, go to 1)
4) restart olsr, then go to 1)
}}}
With the exception that we currently wait more than 2 intervals.
Even if the script hits a collision at the same time the file is being written the file will already exist from one of the previous writes or the current write.
Removing a file in use is safe as once the FD closes the file contents are fully released.
Additional Advantages:
* Should be more efficient to check if file exists instead of reading the file and comparing date stamps.
* Removing the Perl code moves us one step closer to retiring Perl in the future.
Removing the offset and increasing max power so we have full range avaliable to us.
This may not help us figure out the offset but will allow us a wider range of options.
ref BBHN->ticket:71
Reported information and board information do not appear to line up, device will need further testing to verify actual details.
Max Power and Power Offset are of concern.
ref BBHN->ticket:71
When a non mesh-gw node has a route via the WAN interface and through a mesh-gw it will choose the mesh-gw instead of the local WAN connection.and
We change the routing list to prefer the WAN link.
When the WAN is static configured the user will need to disable the WAN interface for the mesh internet to be chosen.
When the WAN is configured to dynamic the loss of a DHCP lease will allow the node to chose the remote mesh internet.
The simple solution would be to change the WAN to disabled and reboot to ensure a remote node is used instead if the local internet fails.
Thanks to Joe AE6XE and Clint AE5CA for pointing out this scenario.
By checking the "Keep Settings" box the node will run sysupgrade instead of mtd. Core settings are stored between installs and the _setup files are updated by pulling in missing items from the _setup.default files.
The olsrd watchdog module truncates and writes the latest timestamp every 5 seconds. The olsrd-watchdog script could catch the file during write causing an instant restart.
Changed to want 3 failures before restarting olsrd reducing the chance of collision based restarts.
fixes BBHN->ticket:68
Using a press of around 5 seconds (3-7) the node will reset the passord to BBHN default and enable dhcp on the lan interface.
A press of around 10 seconds (8-12) will cause the node to reset the node to 'just flashed' status and cause the node to reboot.
Unknown networks are not quoted like known networks are.
This caused a bug where the last network name may be incorrectly used in place of the words 'unknown'
fixes: BBHN->ticket:58
Due to multiple issues that olsrd secure seems to make occur more often (but is not soley caused by OLSR Secure) causing olsr to crash olsr secure is being pulled while we work on the module.
This partialy reverts commit 553c126490.
tag: RequiresProtocolIncrement
Required for 900mhz devices to be supported due to band size.
This can also be useful for allowing more devices to fit into the same amount of RF space as nodes may often not need full 20mhz wide channels.
2.4ghz while using standard BBHN SSID is restricted to 20mhz for compatibility.
ref BBHN->ticket:50
Has been seen with yes, and echo y, etc. Loops do not return.
In order to allow packages that do not need interaction to install we have pulled out 'yes' for now.
Officaly now supporting (XM series only for all the below):
{{{
Rocket M5
Bullet M5
AirGrid M5
NanoBridge M2
AirGrid M2
AirGrid M5 HP
NanoBridge M5
Bullet M2 Titanium
Bullet M5 Titanium
PicoStation M2
NanoStation M5
NanoStation Loco M5
}}}
mid hostname entries are only created on remote nodes and are not created on the local node (by design of nameservice module)
In order to allow links on remote nodes olsr status screens and potentionaly other locations to resolve correctly we must add a hostname for the dtdlink interface into the name service beacons.
In addtion we need to ensure the UI looks at these links instead.
This feature will need to be looked at for long in the mesh status screen to find a better method to display these connections.
ref BBHN->ticket:47
Conrad Lara - KG6JEI