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.
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
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.
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
Made adjustmetns to code that calls wifi_txpoweroffset() to ensure we minimize the number of calls that spawn a shell.
Also adjust the setting of $wifi_txpower to handle the fact that iwinfo returns the known offset.
NOTE: This patch requires a kernel upgrade to fully work.
Adds new value wifi_country.
Country HX is being chosen for HAM band use.
Country selection is needed to help the device stay withing regulatory domain for worldwide use.
ref BBHN->ticket:29
The dtdlink interface is vlan 2 on eth0 and is used for linking two or more devices together.
This will allow for band-to-band repeaters, sector antenna setups, etc.
see BBHN->ticket:28
Includes band/channel mapping
Code to set default RF channel on first boot
Add many 5ghz Ubiquiti devices in a testing phase including:
NanoBeam M5 (Intl), NanoBridge M5, AirGrid M5 HP, AirGrid M5, NanoStation M5, NanoStation Loco M5, Bullet M5, Rocket M5
see BBHN->ticket:29
In order to maintain compatibility with existing deployed nodes, known common encrypted ports will NOT be blocked by default.
Users will receive a message during first setup encouraging them to review the rules that apply to how they intend to use their node and that laws very by country and frequency.
A package blockknownencrypted has been created in changeset:123a521df2b63ba1c5bdd6ad94ac402b86394579/bbhn_packages to be used in blocking known encrypted ports if the user feels it is necessary.
As developers we are not stating an opinion as to what the rules say or do not say in relationship to the traffic this deals with. Each user will need to make their own determination of the rules.
This has been the current case since day one.
New file fwinfo page shows if the package is installed AND displays the active firewall rules at the time of the access. This allows future grown to help test (because of the adhoc nature of the mesh) if packet filtering is the cause of a connection not working.
see BBHN->ticket:3
Conrad Lara - KG6JEI