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.
Darryl Quinn