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
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.
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
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.
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.
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.
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)
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.
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
Button should only apply the change, not save it.
Save routine works fine already just need to remove the save commands from the apply box.
fixes BBHN->ticket:23
Based on testing airOS claims NSLM2's have a 2db amplifier it appears that they may actually have a 5db amp.
Since units keep reporting 3db lower than we expect them to we are increasing the txpower offset until we have confirmed power tests.
fixes BBHN->ticket:11, BBHN->ticket:22
Set default of using chains as more devices being presened rely on chains than those who don't.
Fixed the default antenna and chain support on NanoStataton M2 and NanoStation Loco M2
Added NanoStation Loco M2
board.sysid=0xe0a2
radio.1.txpower.max=23
radio.1.txpower.offset=2
radio.1.antennas=1
Chains are not 100% guranteed to be accurate.
Belive from http://community.ubnt.com/t5/airOS-Software-Configuration/chain-0-1/td-p/140354
that Chain0 is Vertical Chain1 Horizontal when mounted vertically
Chain Mask is pulled from the Rocket M mask as this is the only sample
we have in the database.
see BBHN->ticket:11
Refactor to create a central hash matrix that provides details on
devices.
The if else else else tree was going to get very messy based on
the realization that each device has custom attributes and the
need to provide diffrent settings for each unit.
Allows easier managment long term.
fixes BBHN->ticket:1
Units will show:
Yellow banner for devices we have not yet tested.
Red banner for devices we have confirmed do not work.
Relies on what Ubiquiti calls the board.sysid which is the
value of subsystem_device on the first PCI device.
Includes removing files that are provided by packages instead
of being embedded as binaries.
Changes made for UBNT hardware AND for newer base openwrt (Backfire)
Conrad Lara - KG6JEI