1.. _conn_mgr_overview: 2 3Overview 4######## 5 6Connection Manager is a collection of optional Zephyr features that aim to allow applications to monitor and control connectivity (access to IP-capable networks) with minimal concern for the specifics of underlying network technologies. 7 8Using Connection Manager, applications can use a single abstract API to control network association and monitor Internet access, and avoid excessive use of technology-specific boilerplate. 9 10This allows an application to potentially support several very different connectivity technologies (for example, Wi-Fi and LTE) with a single codebase. 11 12Applications can also use Connection Manager to generically manage and use multiple connectivity technologies simultaneously. 13 14Structure 15========= 16 17Connection Manager is split into the following two subsystems: 18 19* :ref:`Connectivity monitoring <conn_mgr_monitoring>` (header file :file:`include/zephyr/net/conn_mgr_monitoring.h`) monitors all available :ref:`Zephyr network interfaces (ifaces) <net_if_interface>` and triggers :ref:`network management <net_mgmt_interface>` events indicating when IP connectivity is gained or lost. 20 21* :ref:`Connectivity control <conn_mgr_control>` (header file :file:`include/zephyr/net/conn_mgr_connectivity.h`) provides an abstract API for controlling iface network association. 22 23.. _conn_mgr_integration_diagram_simple: 24 25.. figure:: figures/integration_diagram_simplified.svg 26 :alt: A simplified view of how Connection Manager integrates with Zephyr and the application. 27 :figclass: align-center 28 29 A simplified view of how Connection Manager integrates with Zephyr and the application. 30 31 See :ref:`here <conn_mgr_integration_diagram_detailed>` for a more detailed version. 32 33.. _conn_mgr_monitoring: 34 35Connectivity monitoring 36####################### 37 38Connectivity monitoring tracks all available ifaces (whether or not they support :ref:`Connectivity control <conn_mgr_control>`) as they transition through various :ref:`operational states <net_if_interface_state_management>` and acquire or lose assigned IP addresses. 39 40Each available iface is considered ready if it meets the following criteria: 41 42* The iface is admin-up 43 44 * This means the iface has been instructed to become operational-up (ready for use). This is done by a call to :c:func:`net_if_up`. 45 46* The iface is oper-up 47 48 * This means the interface is completely ready for use; It is online, and if applicable, has associated with a network. 49 * See :ref:`net_if_interface_state_management` for details. 50 51* The iface has at least one assigned IP address 52 53 * Both IPv4 and IPv6 addresses are acceptable. 54 This condition is met as soon as one or both of these is assigned. 55 * See :ref:`net_if_interface` for details on iface IP assignment. 56 57* The iface has not been ignored 58 59 * Ignored ifaces are always treated as unready. 60 * See :ref:`conn_mgr_monitoring_ignoring_ifaces` for more details. 61 62.. note:: 63 64 Typically, iface state and IP assignment are updated either by the iface's :ref:`L2 implementation <net_l2_interface>` or bound :ref:`connectivity implementation <conn_mgr_impl>`. 65 66 See :ref:`conn_mgr_impl_guidelines_iface_state_reporting` for details. 67 68A ready iface ceases to be ready the moment any of the above conditions is lost. 69 70When at least one iface is ready, the :c:macro:`NET_EVENT_L4_CONNECTED` :ref:`network management <net_mgmt_interface>` event is triggered, and IP connectivity is said to be ready. 71 72Afterwards, ifaces can become ready or unready without firing additional events, so long as there always remains at least one ready iface. 73 74When there are no longer any ready ifaces left, the :c:macro:`NET_EVENT_L4_DISCONNECTED` :ref:`network management <net_mgmt_interface>` event is triggered, and IP connectivity is said to be unready. 75 76.. _conn_mgr_monitoring_usage: 77 78Usage 79===== 80 81Connectivity monitoring is enabled if the :kconfig:option:`CONFIG_NET_CONNECTION_MANAGER` Kconfig option is enabled. 82 83To receive connectivity updates, create and register a listener for the :c:macro:`NET_EVENT_L4_CONNECTED` and :c:macro:`NET_EVENT_L4_DISCONNECTED` :ref:`network management <net_mgmt_interface>` events: 84 85.. code-block:: c 86 87 /* Callback struct where the callback will be stored */ 88 struct net_mgmt_event_callback l4_callback; 89 90 /* Callback handler */ 91 static void l4_event_handler(struct net_mgmt_event_callback *cb, 92 uint32_t event, struct net_if *iface) 93 { 94 if (event == NET_EVENT_L4_CONNECTED) { 95 LOG_INF("Network connectivity gained!"); 96 } else if (event == NET_EVENT_L4_DISCONNECTED) { 97 LOG_INF("Network connectivity lost!"); 98 } 99 100 /* Otherwise, it's some other event type we didn't register for. */ 101 } 102 103 /* Call this before Connection Manager monitoring initializes */ 104 static void my_application_setup(void) 105 { 106 /* Configure the callback struct to respond to (at least) the L4_CONNECTED 107 * and L4_DISCONNECTED events. 108 * 109 * 110 * Note that the callback may also be triggered for events other than those specified here! 111 * (See the net_mgmt documentation) 112 */ 113 net_mgmt_init_event_callback( 114 &l4_callback, l4_event_handler, 115 NET_EVENT_L4_CONNECTED | NET_EVENT_L4_DISCONNECTED 116 ); 117 118 /* Register the callback */ 119 net_mgmt_add_event_callback(&l4_callback); 120 } 121 122See :ref:`net_mgmt_listening` for more details on listening for net_mgmt events. 123 124.. note:: 125 To avoid missing initial connectivity events, you should register your listener(s) before Connection Manager monitoring initializes. 126 See :ref:`conn_mgr_monitoring_missing_notifications` for strategies to ensure this. 127 128.. _conn_mgr_monitoring_missing_notifications: 129 130Avoiding missed notifications 131============================= 132 133Connectivity monitoring may trigger events immediately upon initialization. 134 135If your application registers its event listeners after connectivity monitoring initializes, it is possible to miss this first wave of events, and not be informed the first time network connectivity is gained. 136 137If this is a concern, your application should :ref:`register its event listeners <conn_mgr_monitoring_usage>` before connectivity monitoring initializes. 138 139Connectivity monitoring initializes using the :c:macro:`SYS_INIT` ``APPLICATION`` initialization priority specified by the :kconfig:option:`CONFIG_NET_CONNECTION_MANAGER_MONITOR_PRIORITY` Kconfig option. 140 141You can register your callbacks before this initialization by using :c:macro:`SYS_INIT` with an earlier initialization priority than this value, for instance priority 0: 142 143.. code-block:: C 144 145 static int my_application_setup(void) 146 { 147 /* Register callbacks here */ 148 return 0; 149 } 150 151 SYS_INIT(my_application_setup, APPLICATION, 0); 152 153If this is not feasible, you can instead request that connectivity monitoring resend the latest connectivity events at any time by calling :c:func:`conn_mgr_mon_resend_status`: 154 155.. code-block:: C 156 157 static void my_late_application_setup(void) 158 { 159 /* Register callbacks here */ 160 161 /* Once done, request that events be re-triggered */ 162 conn_mgr_mon_resend_status(); 163 } 164 165.. _conn_mgr_monitoring_ignoring_ifaces: 166 167Ignoring ifaces 168=============== 169 170Applications can request that ifaces be ignored by Connection Manager by calling :c:func:`conn_mgr_ignore_iface` with the iface to be ignored. 171 172Alternatively, an entire :ref:`L2 implementation <net_l2_interface>` can be ignored by calling :c:func:`conn_mgr_ignore_l2`. 173 174This has the effect of individually ignoring all the ifaces using that :ref:`L2 implementation <net_l2_interface>`. 175 176While ignored, the iface is treated by Connection Manager as though it were unready for network traffic, no matter its actual state. 177 178This may be useful, for instance, if your application has configured one or more ifaces that cannot (or for whatever reason should not) be used to contact the wider Internet. 179 180:ref:`Bulk convenience functions <conn_mgr_control_api_bulk>` optionally skip ignored ifaces. 181 182See :c:func:`conn_mgr_ignore_iface` and :c:func:`conn_mgr_watch_iface` for more details. 183 184.. _conn_mgr_monitoring_api: 185 186Connectivity monitoring API 187=========================== 188 189Include header file :file:`include/zephyr/net/conn_mgr_monitoring.h` to access these. 190 191.. doxygengroup:: conn_mgr 192 193.. _conn_mgr_control: 194 195Connectivity control 196#################### 197 198Many network interfaces require a network association procedure to be completed before being usable. 199 200For such ifaces, connectivity control can provide a generic API to request network association (:c:func:`conn_mgr_if_connect`) and dissasociation (:c:func:`conn_mgr_if_disconnect`). 201Network interfaces implement support for this API by :ref:`binding themselves to a connectivity implementation <conn_mgr_impl_binding>`. 202 203Using this API, applications can associate with networks with minimal technology-specific boilerplate. 204 205Connectivity control also provides the following additional features: 206 207* Standardized :ref:`persistence and timeout <conn_mgr_control_persistence_timeouts>` behaviors during association. 208* :ref:`Bulk functions <conn_mgr_control_api_bulk>` for controlling the admin state and network association of all available ifaces simultaneously. 209* Optional :ref:`convenience automations <conn_mgr_control_automations>` for common connectivity actions. 210 211.. _conn_mgr_control_operation: 212 213Basic operation 214=============== 215 216The following sections outline the basic operation of Connection Manager's connectivity control. 217 218.. _conn_mgr_control_operation_binding: 219 220Binding 221------- 222 223Before an iface can be commanded to associate or dissasociate using Connection Manager, it must first be bound to a :ref:`connectivity implementation <conn_mgr_impl>`. 224Binding is performed by the provider of the iface, not by the application (see :ref:`conn_mgr_impl_binding`), and can be thought of as an extension of the iface declaration. 225 226Once an iface is bound, all connectivity commands passed to it (such as :c:func:`conn_mgr_if_connect` or :c:func:`conn_mgr_if_disconnect`) will be routed to the corresponding implementation function in the connectivity implementation. 227 228.. note:: 229 230 To avoid inconsistent behavior, all connectivity implementations must adhere to the :ref:`implementation guidelines <conn_mgr_impl_guidelines>`. 231 232.. _conn_mgr_control_operation_connecting: 233 234Connecting 235---------- 236 237Once a bound iface is admin-up (see :ref:`net_if_interface_state_management`), :c:func:`conn_mgr_if_connect` can be called to cause it to associate with a network. 238 239If association succeeds, the connectivity implementation will mark the iface as operational-up (see :ref:`net_if_interface_state_management`). 240 241If association fails unrecoverably, the :ref:`fatal error event <conn_mgr_control_events_fatal_error>` will be triggered. 242 243You can configure an optional :ref:`timeout <conn_mgr_control_timeouts>` for this process. 244 245.. note:: 246 The :c:func:`conn_mgr_if_connect` function is intentionally minimalistic, and does not take any kind of configuration. 247 Each connectivity implementation should provide a way to pre-configure or automatically configure any required association settings or credentials. 248 See :ref:`conn_mgr_impl_guidelines_preconfig` for details. 249 250.. _conn_mgr_control_operation_loss: 251 252Connection loss 253--------------- 254 255If connectivity is lost due to external factors, the connectivity implementation will mark the iface as operational-down. 256 257Depending on whether :ref:`persistence <conn_mgr_control_persistence>` is set, the iface may then attempt to reconnect. 258 259.. _conn_mgr_control_operation_disconnection: 260 261Manual disconnection 262-------------------- 263 264The application can also request that connectivity be intentionally abandoned by calling :c:func:`conn_mgr_if_disconnect`. 265 266In this case, the connectivity implementation will disassociate the iface from its network and mark the iface as operational-down (see :ref:`net_if_interface_state_management`). 267A new connection attempt will not be initiated, regardless of whether persistence is enabled. 268 269.. _conn_mgr_control_persistence_timeouts: 270 271Timeouts and Persistence 272======================== 273 274Connection Manager requires that all connectivity implementations support the following standard key features: 275 276* :ref:`Connection timeouts <conn_mgr_control_timeouts>` 277* :ref:`Connection persistence <conn_mgr_control_persistence>` 278 279These features describe how ifaces should behave during connect and disconnect events. 280You can individually set them for each iface. 281 282.. note:: 283 It is left to connectivity implementations to successfully and accurately implement these two features as described below. 284 See :ref:`conn_mgr_impl_timeout_persistence` for more details from the connectivity implementation perspective. 285 286.. _conn_mgr_control_timeouts: 287 288Connection Timeouts 289------------------- 290 291When :c:func:`conn_mgr_if_connect` is called on an iface, a connection attempt begins. 292 293The connection attempt continues indefinitely until it succeeds, unless a timeout has been specified for the iface (using :c:func:`conn_mgr_if_set_timeout`). 294 295In that case, the connection attempt will be abandoned if the timeout elapses before it succeeds. 296If this happens, the :ref:`timeout event<conn_mgr_control_events_timeout>` is raised. 297 298.. _conn_mgr_control_persistence: 299 300Connection Persistence 301---------------------- 302 303Each iface also has a connection persistence setting that you can enable or disable by setting the :c:enumerator:`~conn_mgr_if_flag.CONN_MGR_IF_PERSISTENT` flag with :c:func:`conn_mgr_binding_set_flag`. 304 305This setting specifies how the iface should handle unintentional connection loss. 306 307If persistence is enabled, any unintentional connection loss will initiate a new connection attempt, with a new timeout if applicable. 308 309Otherwise, the iface will not attempt to reconnect. 310 311.. note:: 312 Persistence not does affect connection attempt behavior. 313 Only the timeout setting affects this. 314 315 For instance, if a connection attempt on an iface times out, the iface will not attempt to reconnect, even if it is persistent. 316 317 Conversely, if there is not a specified timeout, the iface will try to connect forever until it succeeds, even if it is not persistent. 318 319 See :ref:`conn_mgr_impl_tp_persistence_during_connect` for the equivalent implementation guideline. 320 321.. _conn_mgr_control_events: 322 323Control events 324============== 325 326Connectivity control triggers :ref:`network management <net_mgmt_interface>` events to inform the application of important state changes. 327 328See :ref:`conn_mgr_impl_guidelines_trigger_events` for the corresponding connectivity implementation guideline. 329 330.. _conn_mgr_control_events_fatal_error: 331 332Fatal Error 333----------- 334 335The :c:macro:`NET_EVENT_CONN_IF_FATAL_ERROR` event is raised when an iface encounters an error from which it cannot recover (meaning any subsequent attempts to associate are guaranteed to fail, and all such attempts should be abandoned). 336 337Handlers of this event will be passed a pointer to the iface for which the fatal error occurred. 338Individual connectivity implementations may also pass an application-specific data pointer. 339 340.. _conn_mgr_control_events_timeout: 341 342Timeout 343------- 344 345The :c:macro:`NET_EVENT_CONN_IF_TIMEOUT` event is raised when an :ref:`iface association <conn_mgr_control_operation_connecting>` attempt :ref:`times out <conn_mgr_control_timeouts>`. 346 347Handlers of this event will be passed a pointer to the iface that timed out attempting to associate. 348 349.. _conn_mgr_control_events_listening: 350 351Listening for control events 352---------------------------- 353 354You can listen for control events as follows: 355 356.. code-block:: c 357 358 /* Declare a net_mgmt callback struct to store the callback */ 359 struct net_mgmt_event_callback my_conn_evt_callback; 360 361 /* Declare a handler to receive control events */ 362 static void my_conn_evt_handler(struct net_mgmt_event_callback *cb, 363 uint32_t event, struct net_if *iface) 364 { 365 if (event == NET_EVENT_CONN_IF_TIMEOUT) { 366 /* Timeout occurred, handle it */ 367 } else if (event == NET_EVENT_CONN_IF_FATAL_ERROR) { 368 /* Fatal error occurred, handle it */ 369 } 370 371 /* Otherwise, it's some other event type we didn't register for. */ 372 } 373 374 int main() 375 { 376 /* Configure the callback struct to respond to (at least) the CONN_IF_TIMEOUT 377 * and CONN_IF_FATAL_ERROR events. 378 * 379 * Note that the callback may also be triggered for events other than those specified here! 380 * (See the net_mgmt documentation) 381 */ 382 383 net_mgmt_init_event_callback( 384 &conn_mgr_conn_callback, conn_mgr_conn_handler, 385 NET_EVENT_CONN_IF_TIMEOUT | NET_EVENT_CONN_IF_FATAL_ERROR 386 ); 387 388 /* Register the callback */ 389 net_mgmt_add_event_callback(&conn_mgr_conn_callback); 390 return 0; 391 } 392 393See :ref:`net_mgmt_listening` for more details on listening for net_mgmt events. 394 395.. _conn_mgr_control_automations: 396 397Automated behaviors 398=================== 399 400There are a few actions related to connectivity that are (by default at least) performed automatically for the user. 401 402.. _conn_mgr_control_automations_auto_up: 403 404.. topic:: Automatic admin-up 405 406 In Zephyr, ifaces are automatically taken admin-up (see :ref:`net_if_interface_state_management` for details on iface states) during initialization. 407 408 Applications can disable this behavior by setting the :c:enumerator:`~net_if_flag.NET_IF_NO_AUTO_START` interface flag with :c:func:`net_if_flag_set`. 409 410.. _conn_mgr_control_automations_auto_connect: 411 412.. topic:: Automatic connect 413 414 By default, Connection Manager will automatically connect any :ref:`bound <conn_mgr_impl_binding>` iface that becomes admin-up. 415 416 Applications can disable this by setting the :c:enumerator:`~conn_mgr_if_flag.CONN_MGR_IF_NO_AUTO_CONNECT` connectivity flag with :c:func:`conn_mgr_if_set_flag`. 417 418.. _conn_mgr_control_automations_auto_down: 419 420.. topic:: Automatic admin-down 421 422 By default, Connection Manager will automatically take any bound iface admin-down if it has given up on associating. 423 424 Applications can disable this for all ifaces by disabling the :kconfig:option:`CONFIG_NET_CONNECTION_MANAGER_AUTO_IF_DOWN` Kconfig option, or for individual ifaces by setting the :c:enumerator:`~conn_mgr_if_flag.CONN_MGR_IF_NO_AUTO_DOWN` connectivity flag with with :c:func:`conn_mgr_if_set_flag`. 425 426.. _conn_mgr_control_api: 427 428Connectivity control API 429======================== 430 431Include header file :file:`include/zephyr/net/conn_mgr_connectivity.h` to access these. 432 433.. doxygengroup:: conn_mgr_connectivity 434 435.. _conn_mgr_control_api_bulk: 436 437Bulk API 438-------- 439 440Connectivity control provides several bulk functions allowing all ifaces to be controlled at once. 441 442You can restrict these functions to operate only on non-:ref:`ignored <conn_mgr_monitoring_ignoring_ifaces>` ifaces if desired. 443 444Include header file :file:`include/zephyr/net/conn_mgr_connectivity.h` to access these. 445 446.. doxygengroup:: conn_mgr_connectivity_bulk 447