From 0018d1f3cf71d680d7b6bceda55a5717244d8b26 Mon Sep 17 00:00:00 2001
From: Michael Biebl <biebl@debian.org>
Date: Tue, 16 Aug 2022 18:24:19 +0200
Subject: New upstream version 1.39.90

---
 docs/libnm/html/libnm-nm-dbus-interface.html | 97 ++++++++++++++++++++++++++++
 1 file changed, 97 insertions(+)

(limited to 'docs/libnm/html/libnm-nm-dbus-interface.html')

diff --git a/docs/libnm/html/libnm-nm-dbus-interface.html b/docs/libnm/html/libnm-nm-dbus-interface.html
index e7ca0035..1585ca83 100644
--- a/docs/libnm/html/libnm-nm-dbus-interface.html
+++ b/docs/libnm/html/libnm-nm-dbus-interface.html
@@ -512,6 +512,10 @@
 <td class="datatype_keyword">enum</td>
 <td class="function_name"><a class="link" href="libnm-nm-dbus-interface.html#NMRadioFlags" title="enum NMRadioFlags">NMRadioFlags</a></td>
 </tr>
+<tr>
+<td class="datatype_keyword">enum</td>
+<td class="function_name"><a class="link" href="libnm-nm-dbus-interface.html#NMMptcpFlags" title="enum NMMptcpFlags">NMMptcpFlags</a></td>
+</tr>
 </tbody>
 </table></div>
 </div>
@@ -545,6 +549,7 @@
     <span class="lineart">├──</span> NMDeviceModemCapabilities
     <span class="lineart">├──</span> NMDeviceWifiCapabilities
     <span class="lineart">├──</span> NMManagerReloadFlags
+    <span class="lineart">├──</span> NMMptcpFlags
     <span class="lineart">├──</span> NMRadioFlags
     <span class="lineart">├──</span> NMSecretAgentCapabilities
     <span class="lineart">├──</span> NMSecretAgentGetSecretsFlags
@@ -4084,6 +4089,98 @@ is detected in the system.</p>
 </div>
 <p class="since">Since: 1.38</p>
 </div>
+<hr>
+<div class="refsect2">
+<a name="NMMptcpFlags"></a><h3>enum NMMptcpFlags</h3>
+<div class="refsect3">
+<a name="NMMptcpFlags.members"></a><h4>Members</h4>
+<div class="informaltable"><table class="informaltable" width="100%" border="0">
+<colgroup>
+<col width="300px" class="enum_members_name">
+<col class="enum_members_description">
+<col width="200px" class="enum_members_annotations">
+</colgroup>
+<tbody>
+<tr>
+<td class="enum_member_name"><p><a name="NM-MPTCP-FLAGS-NONE:CAPS"></a>NM_MPTCP_FLAGS_NONE</p></td>
+<td class="enum_member_description">
+<p>The default, meaning that no MPTCP flags are set.</p>
+</td>
+<td class="enum_member_annotations"> </td>
+</tr>
+<tr>
+<td class="enum_member_name"><p><a name="NM-MPTCP-FLAGS-DISABLED:CAPS"></a>NM_MPTCP_FLAGS_DISABLED</p></td>
+<td class="enum_member_description">
+<p>don't configure MPTCP endpoints on the device.</p>
+</td>
+<td class="enum_member_annotations"> </td>
+</tr>
+<tr>
+<td class="enum_member_name"><p><a name="NM-MPTCP-FLAGS-ENABLED-ON-GLOBAL-IFACE:CAPS"></a>NM_MPTCP_FLAGS_ENABLED_ON_GLOBAL_IFACE</p></td>
+<td class="enum_member_description">
+<p>MPTCP handling is enabled
+or disabled depending on whether a /0 default route (either IPv4 or IPv6) is
+configured in the main routing table.</p>
+</td>
+<td class="enum_member_annotations"> </td>
+</tr>
+<tr>
+<td class="enum_member_name"><p><a name="NM-MPTCP-FLAGS-ENABLED:CAPS"></a>NM_MPTCP_FLAGS_ENABLED</p></td>
+<td class="enum_member_description">
+<p>MPTCP is enabled and endpoints will be configured.
+This flag is implied if any of the other flags indicate that
+MPTCP is enabled and therefore in most cases unnecessary.</p>
+</td>
+<td class="enum_member_annotations"> </td>
+</tr>
+<tr>
+<td class="enum_member_name"><p><a name="NM-MPTCP-FLAGS-SIGNAL:CAPS"></a>NM_MPTCP_FLAGS_SIGNAL</p></td>
+<td class="enum_member_description">
+<p>Flag for the MPTCP endpoint. The endpoint will be
+announced/signaled to each peer via an MPTCP ADD_ADDR sub-option.</p>
+</td>
+<td class="enum_member_annotations"> </td>
+</tr>
+<tr>
+<td class="enum_member_name"><p><a name="NM-MPTCP-FLAGS-SUBFLOW:CAPS"></a>NM_MPTCP_FLAGS_SUBFLOW</p></td>
+<td class="enum_member_description">
+<p>Flag for the MPTCP endpoint. If additional subflow creation
+is allowed by the MPTCP limits, the MPTCP path manager will try to create an
+additional subflow using this endpoint as the source address after the MPTCP connection
+is established.</p>
+</td>
+<td class="enum_member_annotations"> </td>
+</tr>
+<tr>
+<td class="enum_member_name"><p><a name="NM-MPTCP-FLAGS-BACKUP:CAPS"></a>NM_MPTCP_FLAGS_BACKUP</p></td>
+<td class="enum_member_description">
+<p>Flag for the MPTCP endpoint. If this is a subflow endpoint, the
+subflows created using this endpoint will have the backup flag set during the connection
+process. This flag instructs the peer to only send data on a given subflow when all
+non-backup subflows are unavailable. This does not affect outgoing data,
+where subflow priority is determined by the backup/non-backup flag received
+from the peer</p>
+</td>
+<td class="enum_member_annotations"> </td>
+</tr>
+<tr>
+<td class="enum_member_name"><p><a name="NM-MPTCP-FLAGS-FULLMESH:CAPS"></a>NM_MPTCP_FLAGS_FULLMESH</p></td>
+<td class="enum_member_description">
+<p>Flag for the MPTCP endpoint. If this is a subflow endpoint and additional
+subflow creation is allowed by the MPTCP limits, the MPTCP path manager will try to create an
+additional subflow for each known peer address, using this endpoint as the source address.
+This will occur after the MPTCP connection is established. If the peer did not announce
+any additional addresses using the MPTCP ADD_ADDR sub-option, this will behave the same
+as a plain subflow endpoint. When the peer does announce addresses, each received ADD_ADDR
+sub-option will trigger creation of an additional subflow to generate a full mesh topology.</p>
+</td>
+<td class="enum_member_annotations"> </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<p class="since">Since: 1.40</p>
+</div>
 </div>
 </div>
 <div class="footer">
-- 
cgit 1.3.0-6-gf8a5