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