Skip to content
Snippets Groups Projects
Commit d76f7744 authored by Jakob Olsson's avatar Jakob Olsson
Browse files

update README

parent b94b561b
No related branches found
Tags 16.24.0-rc1
1 merge request!171update README
......@@ -5,20 +5,47 @@
## Introduction
This package provides the `mapagent` daemon, which is responsible for
configuring wireless credentials, vlans etc.
Today map-agent is bridge centered, and it is expected that there is a 'main'
bridge which holds the uplink interface, as specified by `al_bridge` in the
mapagent config.
This package provides the mapagent daemon, which implements the WiFi Alliances
Easymesh Agent component.
## Overview
This README will show how to properly setup the mapagent configuration file
and explain some key features of map-agent.
and explain some key features of map-agent:
* Onboarding
* AP-Autoconfiguration
* Controller Discovery
* Dynamic Controller Sync
* Dynamic Backhaul Upgrade
* Island Prevention
## UCI Configuration
For full documentation of UCI configuration options, see
[UCI docs](./docs/api/mapagent.md).
When setting up the boot-up map-agent configuration file it must contain
an `ap` section for each interface that is supposed to be a part of the mesh
and managed by map-agent. Additional interfaces may be generated at runtime, as
dictated by mapcontroller.
Existing interfaces not included in the configuration will not be a part of the
mesh, meaning no statistics will be gathered, clients steered and the interface
will never be torn down or otherwise configured by mapagent. This means, if
desired, interfaces may left out of multi-ap management by excluding them from
the map-agent configuration.
To summarize:
* Mapagent will manage all interface provided in its configuration file
* Mapagent will not touch interfaces not in its configuration file. They will
be left intact (and outside of the mesh) and be interleaved with any additional
interfaces provided by mapcontroller
* Mapagent will create interfaces as necessary, adding them to both mapagent
and wireless configuration files
### Example Start Configurations
A default configuration file may look as such:
```
......@@ -29,6 +56,10 @@ config agent 'agent'
option brcm_setup '1'
option al_bridge 'br-lan'
option netdev 'wl'
option island_prevention '0'
config dynamic_backhaul
option missing_bh_timer '60'
config controller_select
option local '0'
......@@ -71,13 +102,6 @@ config radio
option dedicated_backhaul '1
```
The important part of this configuration file is to properly align the
wireless configuration with the mapagent configuration for the default setup.
Interface which are not included in the config will never be torn down or
modified by mapagent, thus if desired, interfaces may left out of multi-ap
management.
The above example of a mapagent config would map properly against the
following wireless configuration file:
......@@ -164,15 +188,16 @@ config wifi-iface 'default_sta_wl2'
### Radios
The `radio` section will primarily hold the band, device and whether the
radio is a dedicated backhaul, meaning no fronthaul interfaces will be
configured on this radio via AP-Autoconfig. This section will be auto-generated
on startup by mapagent if not present.
The `radio` section will primarily hold the band, device name and whether the
radio is a dedicated backhaul. Dedicated backhaul means no fronthaul interfaces
will be configured on the radio via AP-Autoconfig.
Radio sections will be auto-generated on startup by mapagent if not present.
An example config:
```
config radio
option device 'wl2'
option device 'wl0'
option band '5'
option dedicated_backhaul '1'
```
......@@ -180,21 +205,40 @@ config radio
### Interfaces
When specifying an interface in the mapagent configuration file, there are four
parameters that must be kept in consideration:
parameters that must be set.
Map-agent configuration divides interfaces into different section types, based
on the interface type. Backhaul station interfaces are created with the section
type `bsta`:
```Minimum BSTA configuration
config bsta
option ifname 'wl1'
option band '2'
option device 'wl1'
```
Fronthaul and backhaul BSS are created with the section type `ap`:
```Minimum AP configuration
config ap
option ifname 'wl1.1'
option band '2'
option device 'wl1'
```
1. Whether the interface is backhaul/fronthaul (`ap`) or backhaul station
interfaces (`bsta`).
2. Band of the interface, to be provided as i.e. `option band '2'`
3. Interface name, to be provided as i.e. `option ifname 'wl0.1'`
4. Device that the interface belongs to, to be provided as i.e. `option device 'wl0'`
Each interface section must at minimum contain the options:
* `band` - Set `2` for 2.4GHz and `5` for 5GHz
* `ifname` - Interface name
* `device` - Device name (i.e. radio name)
#### Fronthaul Interfaces
Fronthaul interfaces are `ap` sections with `type 'fronthaul'` set. This
section may also include the options `ssid`, `key`, `encryption`, and `vid`.
Today these are not mandatory, but will be written automatically during
AP-Autoconfiguration.
These are not mandatory in the default configuration, but will be written
automatically during AP-Autoconfiguration.
```
config ap
......@@ -208,13 +252,12 @@ config ap
option vid '1'
```
#### Backhaul Interfaces
Backhaul interfaces are `ap` sections with `type 'backhaul'` set. This
section may also include the options `ssid`, `key`, `encryption`, `enabled`,
`vid` and a `disallow_bsta` list. Today these are not mandatory, but will be
written automatically during AP-Autoconfiguration.
`vid` and a `disallow_bsta` list. These are not mandatory in the default
configuration, but will be written automatically during AP-Autoconfiguration.
```
config ap
......@@ -235,8 +278,9 @@ config ap
Combined fronthaul/backhaul interfaces are `ap` sections with
`type 'combined'` set. This section may also include the options `ssid`, `key`,
`encryption`, and `vid`. Today these are not mandatory, but will be
written automatically during AP-Autoconfiguration.
`encryption`, and `vid`. These are not mandatory in the default
configuration, but will be written automatically during AP-Autoconfiguration.
```
config ap
......@@ -256,55 +300,62 @@ config ap
Backhaul station interfaces are `bsta` sections.
Backhaul interface sections will be generated automatically by map-agent upon
startup. This is because it is assumed a backhaul station is only relevant in
a multi-ap network scenario.
If not present in map-agent configuration, all interfaces in the wireless
configuration with `option mode 'sta'` will be automatically added to map-agent
configuration.
Once onboarded, map-agent will set `option onboarded '1'` along with the passed
credentials.
Once onboarded, a bsta may be marked as `option onboarded '1'` by map-agent,
along with the respective `radio` section. An onboarded backhaul station
may look as follows:
An onboarded backhaul station may look as follows:
```
config bsta
option ifname 'wl0'
option band '5'
option device 'wl0'
option ifname 'wl1'
option band '2'
option device 'wl1'
option priority '2'
option encryption 'sae-mixed'
option ssid 'MAP-021000000001-BH-2.4GHz'
option key '569dfdc9447e494da231d4def3441ed92c8f63985d8992cb521d77e1763c00d'
option onboarded '1'
option priority '0'
option vid '1'
option bssid '0e:10:00:00:00:04' # set upon connection
option enabled '1' # managed by mapagent for dynamic backhaul
```
The option `priority` will default to 2.
## Onboarding
Onboarding encompasses WPS pushbutton event, backhaul credential exchange and
establishment of the wireless link between two devices.
Onboarding includes backhaul credential exchange and establishment of the
wireless link between two devices.
The prerequisites will be written from a dedicated backhaul and fronthaul
interface. If using a combined fronthaul/backhaul interface the steps still
This guide will focus on onboarding from a backhaul STA towards a
backhaul BSS. If using a combined fronthaul/backhaul interface the steps still
apply, with the exception of the uci options `multi_ap_backhaul_ssid` and
`multi_ap_backhaul_key` may be left out, and WPS be started on the combined
interface.
`multi_ap_backhaul_key` may be left out, and WPS be started directly on the
combined interface.
### Prerequisites
* To perform onboarding, mapagent must be running at both the registrar
and enrollee node.
* The registrar radio and enrollee radio must be running in a
compatible band and channel for the WPS exchange to take place.
compatible band
* The wireless uci configuration must have the backhaul credentials in the
fronthaul secition under the keys `multi_ap_backhaul_ssid` and
fronthaul section under the keys `multi_ap_backhaul_ssid` and
`multi_ap_backhaul_key`.
* Enrollee backhaul sta interface must not be a part of a bridge
* Enrollee and registrar interface must both have the multi_ap options set
in the wireless config (1 and 2 respectively) for the multiap IE to be passed.
* The enrollee backhaul STA interface must not be a part of a bridge
* Enrollee and registrar interface must both have the multi_ap options properly
set in the wireless config (multi_ap '1' for STA and backhaul BSS, multi_ap '2'
for fronthaul BSS) for the multiap IE to be passed.
* It is recommended that `option channel 'auto'` is set for the backhaul STA
radio in its wireless configuration.
### How to Start
With the prerequisites in place, on the registrar, WPS must be started on the
fronthaul interface with role registrar (default), as backhaul interfaces do not
fronthaul interface with role registrar (default), as backhaul BSS do not
support WPS. However, with the `multi_ap` options set appropriately in the
wireless configuration file a multiap IE will be passed with the WPS and the
backhaul credentials be provided to the enrollee.
......@@ -312,7 +363,7 @@ backhaul credentials be provided to the enrollee.
Registrar:
* `ubus call wifi.wps start '{"ifname":"wl0"}'`
On the enrollee side, wps must be performed over the backhaul station interface,
On the enrollee side, wps must be performed over the backhaul STA interface,
and the role `bsta` must be passed.
Enrollee:
......@@ -323,79 +374,82 @@ When the devices pair, the credentials will be published as ubus event:
{ "wps_credentials": {"ifname":"wl0","encryption":"psk2", "ssid":"iopsysWrt-BACKHAUL-5GHz","key":"12345678BACKHAUL" }}
```
Mapagent will pick up this ubus event and add these credential to the uci
wireless section and reload wifi, after which wpa_supplicant will establish a
connection to the backhaul interface, over the backhaul station interface.
Mapagent will pick up this ubus event and add these credential to the mapagent
and wireless configuration and load them in-memory to wpa_supplicant
(backhaul STA), after which wpa_supplicant will establish a connection.
When the `wifi.bsta` connection event comes over ubus:
```
{ "wifi.bsta": {"ifname":"wl0","event":"connected","data":{"macaddr":"0a:10:00:00:00:03","ssid":"iopsysWrt-BACKHAUL-5GHz"}} }
```
mapagent will issue DHCP to verify that it has entered 4address mode
(wds link is up and added to the bridge on registrar) before adding the backhaul
station to the bridge.
Mapagent will then wait till that interface has fully transitioned into 4address
mode before adding the backhaul station to the bridge.
Once backhaul station is in the bridge, onboarding is complete.
Once the backhaul station is in the bridge, connectivity to the upstream device
is established and onboarding is complete.
## AP-Autoconfig
AP-Autoconfig includes the triggering of AP-Autoconfig Search, AP-Autoconfig
Response and AP-Autoconfig WSC and the configuration of the credentials provided
Response, AP-Autoconfig WSC and the configuration of the credentials provided
with the AP-Autoconfig WSC.
This will not include how to configure mapcontroller.
For how to configure mapcontroller for AP-Autoconfiguration, see
[map-Controller](https://dev.iopsys.eu/iopsys/map-controller).
### Prerequisites
* Mapcontroller must be active in the network.
### Mechanics
AP-Autoconfig has a certain set of triggers with slight behavior differences.
When understanding the different triggers, it is necessary to understand that
during AP-Autoconfig, every radio will do its independent process, meaning
AP-Autoconfig Search, Response and WSC.
Map-agent is periodically sending AP-Autoconfig Search messages, to find the
map-controller, as well as other agents in the mesh. When an
AP-Autoconfiguration Response is received, map-agent will send an AP-Autoconfig
WSC M1 if it has not been configured already.
The periodicity of AP-Autoconfig Search messages is set by `probe_int`
(defaults to 20s if not set) in the mapagent configuration. Once configured, an
interval of 70s will be used as heartbeat timer.
#### Radio State
When a radio is available to be configured, will be consiered in an 'active'
state, and when it is periodically probing it is considered to be in a
'heartbeat' state.
Map-agent maintains a radio state for each radio, to prevent redundent
configurations messages. A radio can be in one of two states:
* `AUTOCFG_ACTIVE` - If an AP-Autoconfig Response is received from a mapcontroller
in this state, map-agent will send back an AP-Autoconfig WSC M1
* `AUTOCFG_HEARTBEAT` - Map-agent is only sending AP-Autoconfig Searches in order
to establish that mapcontroller is still available. No further action upon
responses.
Some conditions that will set map-agent to an 'active' state
Some conditions that will set map-agent radios to an active state
* Upon mapagent (re)start
* Establishing a connection over backhaul interface
* No mapcontroller is observed for `probe_int` * `retry_int`
* New mapcontroller is discovered
#### Search Triggers
* Establishing a first-time connection
* No mapcontroller is observed for `probe_int` * `retry_int` seconds
* New mapcontroller is discovered (almac of controller changed)
* Connection was lost for `missing_bh_timer` + 15 seconds
* Backhaul STA connects to an entirely new BSSID
All the triggers listed in [Radio State](#radio-state) will trigger
AP-Autoconfig Search within a set time out (at most 5 seconds, depending on
the event). Additionally it may be triggered by:
* Periodic interval `probe_int` (defaults to 20s)
* Connecting ethwan port.
#### Upon Receival of AP-Autoconfig WSC M2
After map-agent finds a controller and it has sent an AP-Autoconfig WSC (M1) to
which the mapcontroller will answer with an AP-Autoconfig WSC (M2).
#### Upon Completion
After AP-Autoconfig is completed, for a respective radio, there will be an event
published over ubus:
Within the M2 map-agent will find credentials which it will write to the
mapagent and wireless configurations. After, it will schedule a wifi reload in 5
seconds. The timeout is to account for any delayed CMDUs and batch the
credentials rather than doing restarts one radio at a time. When a radio has
been configured via an M2 there will be an event published over ubus:
```
{ "wifi.radio": {"ifname":"wl0","event":"ap-autoconfiguration","data":{"status":"success","reason":"completed"}} }
{ "map.agent": {"ifname":"wl0","event":"ap-autoconfiguration","data":{"status":"success","reason":"completed"}} }
```
Map-agent will wait for 5 seconds to account for any disruption and delayed
CMDUs and then restart wifi - to be sure that all WSC that are coming over the
link are received and processed.
After processing of the WSC CMDUs the mapagent config will have changed
according to the received WSC:
After processing of the WSC CMDUs, mapagent config will have changed according
to the received WSC:
```
config agent 'agent'
......@@ -405,8 +459,12 @@ config agent 'agent'
option brcm_setup '1'
option al_bridge 'br-lan'
option netdev 'wl'
option island_prevention '0'
option controller_macaddr 'ee:6c:9a:52:b0:27'
config dynamic_backhaul
option missing_bh_timer '60'
config controller_select
option local '0'
option id 'auto'
......@@ -636,8 +694,6 @@ config wifi-iface 'wl1_2_ap'
option hidden '0'
```
Do note that a backhaul station interface will never be torn down by mapagent.
## Controller Discovery
......@@ -707,16 +763,15 @@ While the aim for this controller discovery is to support the same configuration
across all devices, one may want to have a designated mapcontroller device, then
the following configuration may be used:
Main Device (i.e. SmartHub3/Fibertwist): Controller to be run in a designated
node only.
Main Device: Controller to be run in a designated node only.
```
config controller_select
option local ‘true’
```
Repeater Device (Disc/EX600): Controller start/stop automatically if another is
not detected in the network.
Repeater Device: Controller start/stop automatically if another is not detected
in the network.
```
config controller_select
......@@ -724,23 +779,241 @@ config controller_select
option autostart ‘true’
```
## Dynamic Controller Sync
In a mesh where the controller node may change and taken up by any of the
nodes in the mesh, it is important to keep all mapcontroller configs in sync. If
not, when the controller role is taken by another node the credentials, polices
etc. may change resulting in disruption for the clients in the network.
This feature has to be compiled into multiple components by its compile-time
flags.
This compile-time flag are:
* map-agent - `AGENT_SYNC_DYNAMIC_CNTLR_CONFIG`
* map-controller - `CONTROLLER_SYNC_DYNAMIC_CNTLR_CONFIG`
* ieee1905 - `MULTIAP_DYNAMIC_CNTLR_SYNC_CONFIG`
This feature is additionally enabled or disabled via UCI configuration:
```
onfig agent 'agent'
option dyn_cntlr_sync '1'
```
### Algorithm
Dynamic controller sync leverages Higher Layer Data CMDUs to sync the
credentials across the network. It uses a two or three step process, depending
on who initiates the communication.
If map-controller initiates the communication it will first send a message
letting the mapagent know that it has updated its configuration file. After
which the map-agent will generate an M1, similar to AP-Autoconfig. The
map-controller will then generate keys and encrypt the configuration file and
pass it to the map-agent in an M2 message.
The M2 is decrypted on the agent and written to its mapcontroller
configuration file, if any. While persisting its `enabled` option so it is not
re-enabled if it was previously disabled.
If sync is triggered via UBUS API of map-agent the first message is skipped.
```
root@iopsys-ec6c9a52acb7:~# ubus -v list map.agent
'map.agent' @be66d606
...
"sync":{}
...
```
#### Summary
1. Mapcontroller configuration file is modified, send multicast HLD message
2. Mapagent responds with M1
3. Mapcontroller encrypts configuration file within M2, sends to agent
4. Mapagent decrypts configuration file and writes to file system
## Dynamic Backhaul Upgrade
Dynamic backhaul upgrade logic will make sure that if a backhaul link drops, it
will attempt to re-establish connection over other backhaul STAs. Additionally,
it will periodically try to upgrade an existing link to a better one, if
available.
### Backhaul Priority
Each backhaul STA can be assigned with a priority from its configuration:
```
config radio
option device 'wl0'
option band '5'
option priority '0'
config radio
option device 'wl1'
option band '2'
option priority '1'
```
Lower priority is better. This is the value which will decide which backhaul STA
is used, if multiple connections are available.
### Algorithm
#### Trigger - Onboarding
When WPS onboarding is performed, once the first credentials are received, if
any other backhaul STA has activated WPS, an additional 15 seconds are allows
for additional credentials to come through. After the 15 seconds pass, or till
all backhaul STAs has received credentials, they are written to the wireless
configuration and loaded in-memory to the supplicants, and they may begin
scanning and finding the APs.
Upon receiving the first connection from a now configured supplicant, map-agent
will write the BSSID to the configuration, locking the topology. Additionally,
another 15 second timer is triggered, which allows better connections to come
before map-agent locks this backhaul STA till next upgrade window.
Once the 15 second timer expires, map-agent will disable the other supplicants
and set `option enabled '0'` in the map-agent configuration for all the worse
priority backhaul STAs.
## uBus
#### Trigger - Priority and Run-time Upgrade
Periodically, map-agent will start scanning on all backhaul STAs with a better
priority set than the one currently connected. This gives a 15 second window
for each backhaul STA with a better priority to find a connection, at the end
of the 15 seconds the best connected backhaul STA will be used and all others
disabled till next periodicity.
The upgrade logic gets triggered after a connection is made, at timeouts of
30 seconds, 5 minutes and 30 minutes, after which it will remain at 30 minutes
till a better connection is made.
The timers can be observed via the map-agent UBUS API, which has a
dynamic_backhaul object with time till next upgrade window, and how long ago
last one took place:
```
root@iopsys:~# ubus -v list map.agent
'map.agent' @21e6fc02
root@iopsys-ec6c9a52acb7:~# ubus call map.agent timers
{
"autoconfig_trigger": 33603,
"dynamic_backhaul": {
"next_attempt": 997139,
"last_attempt_start": 818163,
"last_attempt_end": 802861
},
"bh_lost_timer": -1,
"disable_unconnected_bstas_scheduler": -1,
"onboarding_scheduler": -1
}
```
If another mesh device is wirelessly connected (i.e. forming a daisy chain),
link upgrade logic will not take place till it is removed.
#### Trigger - Link loss
If the active backhaul STA loses connectivity, map-agent will after some time
start scanning on all configured backhaul STAs to find another available band.
This timer can be set via configuration, and defaults to 60s if not set.
```
config dynamic_backhaul
option missing_bh_timer '60'
```
The option will accept any value between 1 and 255.
This timer can also be observed via the timers UBUS API, as `"bh_lost_timer"`:
```
root@iopsys-ec6c9a52acb7:~# ubus call map.agent timers
{
"autoconfig_trigger": 40774,
"dynamic_backhaul": {
"next_attempt": 421485,
"last_attempt_start": 1393815,
"last_attempt_end": 1378515
},
"bh_lost_timer": 222084,
"disable_unconnected_bstas_scheduler": -1,
"onboarding_scheduler": -1
}
```
#### Seamless Swapping Between Eth and Wi-Fi Uplink
When an ethernet WAN port is connected, as inferred either by dedicated WAN
port or by dynbhd (see
[dynbhd](https://dev.iopsys.eu/iopsys/map-agentsrc/dynbh/README)), it will take
priority and all backhaul STAs will be in-memory disabled in supplicant. While
the ethernet backhaul is active, all scanning by the backhaul STAs will be
stopped by map-agent, and any re-connection will be terminated.
If the ethernet backhaul is disconnected, the backhaul STAs are immediately
enabled and start scanning to find a connection.
## Island Prevention
In the case of a repeater device losing its connectivity to the master/controller
device it is no longer a part of the mesh. Therefore it is undesireable to keep
any Wi-Fi clients connected to this node, as well as beaconing to attract new
clients. This is where island prevention will kick in and disconnect any
associated clients and stop APs from beaconing.
Island prevention is compile-time selected and enabled via UCI configuration.
The compile-time flag is `AGENT_ISLAND_PREVENTION` and the uci option is:
```
config agent 'agent'
option island_prevention '0'
```
### Algorithm
Once a the uplink is lost, the island prevention logic will allow some time for
the link to be re-established, based on the `missing_bh_timer`. After the time
configured has passed (default to 60s if not set), mapagent will trigger a BTM
request to all connected stations with imminent disassociation and incoming BSS
terminiation.
After an additional 30 seconds has passed and the link has not been
re-established, map-agent will disconnect the client directly via UBUS APIs.
Mapagent will then allow two seconds for all the clients to disassociate before
disabling all APs.
#### Summary
1. Uplink is lost
2. `missing_bh_timer` timer expires and BTM requests are issued
3. Additional 30 seconds pass and all clients are disconnected
4. Additonal 2 seconds pass and all APs are disabled
If at any time link is re-established the following step will not be triggered
and APs will be enabled.
## UBUS
```
root@iopsys-ec6c9a52acb7:~# ubus -v list map.agent
'map.agent' @be66d606
"apconfig":{"band":"Integer"}
"steer_policy":{"vif":"String","rule":"String"}
"steer":{"vif":"String","type":"String","sta":"String","to_bss":"Array","optime":"Integer"}
"assoc_control":{"vif":"String","sta":"String","enable":"Boolean","time":"Integer"}
"toggle_fh":{"ifname":"String","enable":"Boolean"}
"toggle_fh":{"enable":"Boolean", "prevent_island":"Boolean", "ifname":"String"}
"bcn_metrics_query":{"agent":"String","sta":"String","opclass":"Integer","channel":"Integer","bssid":"String","reporting_detail":"Integer","ssid":"String","channel_report":"Array","request_element":"Array"}
"unassoc_sta_lm_query":{"agent":"String","opclass":"Integer","metrics":"Array"}
"topology_query":{"agent":"String"}
"cmd":{"id":"Integer","data":"String"}
"higher_layer_data":{"agent":"String","protocol":"Integer","data":"String"}
"backhaul_info":{}
"status":{}
"info":{}
"assoc_notify":{"bss_status_list":"Array"}
"pref_channels":{"radio":"String","mode":"Integer"}
"sync":{}
"timers":{}
"dynamic_backhaul_upgrade":{}
```
......@@ -572,26 +572,26 @@ Do note that a backhaul station interface will never be torn down by mapagent.
### UCI
The following UCI config section in mapagent config is used to control how a
The following UCI config section in "mapagent" config is used to control how a
MAP Controller is discovered and (auto)started/stopped on demand in a MAP
network.
```
config controller_select
option local true
option id auto
option probe_int 20
option retry_int ‘3’
option autostart true
option local 'true'
option id 'auto'
option probe_int '20'
option retry_int '3'
option autostart 'true'
```
| Name | Type | Required | Default | Description |
| ------------- |---------------| ----------|-------------|---------------|
| local | Boolean | yes | false | When set to true, the MAP Controller running in the same 1905 device as the MAP Agent, will be treated as the main or primary Controller. It takes precedence over others discovered in the network. |
| id | Mac address | no | auto-detect | User can provide the 1905 ALID of the device that will have the MAP Controller service. When set to auto, the MAP Agent will discover the MAP Controller ID. OPTION NOT YET SUPPORTED. |
| id | Mac address | no | auto-detect | User can provide the 1905 ALID of the device that will have the MAP Controller service. When set to 'auto', the MAP Agent will discover the MAP Controller ID. OPTION NOT YET SUPPORTED. |
| probe_int | Integer | no | 20s |The time interval in seconds between controller discovery by the MAP Agent |
| retry_int | Integer | no | 15 |After these many failed attempts to discover a controller in the network, the agent will infer that the controller is not available and accordingly takes the next action. |
| autostart | Boolean | no | false |When this is set to true, the agent will try to start the controller after not finding one in the network. |
| autostart | Boolean | no | false |When this is set to 'true', the agent will try to start the controller after not finding one in the network. |
### Algorithm
......@@ -610,7 +610,7 @@ notify the detected Controller to user (e.g.: over UBUS).
3. If a MAP controller is running in its own device, and local = false, then
stop the local Controller. Update the Controller-ID and the last-seen timestamp.
If after retry_int number of times, the MAP Agent cannot discover a MAP
If after 'retry_int' number of times, the MAP Agent cannot discover a MAP
Controller in the network, then take one of the following actions:
1. When autostart = true, the MAP Agent will try to start the MAP Controller
......@@ -642,7 +642,7 @@ node only.
```
config controller_select
option local true
option local 'true'
```
Repeater Device (Disc/EX600): Controller start/stop automatically if another is
......@@ -650,10 +650,32 @@ not detected in the network.
```
config controller_select
option local false
option autostart true
option local 'false'
option autostart 'true'
```
## Misc
### Netdev Format
Some platforms require the base interface set to i.e. wl0_0, old format would
always assume wl0 as base interface. New format allows adding a '%' identifier
to the format which will explicitly be replaced with numerical values. This also
allows a separator to be set from configuration and not be assumed
(i.e. ".", "-", "_" etc.):
* wl%_% - wl1_0 and wl0_0 as base interfaces
* wl0_ - wl0 and wl1 as base interface, followed by wl0_1 and wl1_1
* wl0 - wl0 and wl1 as base interface, followed by wl0.1 and wl1.1
An example config:
config agent 'agent'
option enabled '1'
option debug '0'
option profile '2'
option brcm_setup '1'
option al_bridge 'br-lan'
option netdev 'wl%_%'
## uBus
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment