Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: High CPU useage during DNS resolution over TCP (Daniel Wagner)
2. Re: [PATCH 0/7] Rewrite OpenConnect plugin and enhance support for VPN
auth errors
(Daniel Wagner)
3. Re: [PATCH v4 0/8] Rewrite OpenConnect plugin and enhance support for VPN
auth errors
(Daniel Wagner)
4. Re: In case there are multiple context of cellular, how can tethering
select one as route context?
(Daniel Wagner)
5. Re: [PATCH] vpnc: Implement disconnect function to cancel queued VPN
agent msg
(Daniel Wagner)
6. Re: [PATCH v3 6/8] openconnect: Use interactive mode when input to stdin
is required
(David Woodhouse)
----------------------------------------------------------------------
Date: Thu, 10 Oct 2019 09:12:29 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: High CPU useage during DNS resolution over TCP
To: "Blanquicet Melendez Jose (M)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
On Wed, Oct 02, 2019 at 01:17:06PM +0000, Blanquicet Melendez Jose (M) wrote:
> Digging into the DNS-Proxy implementation on ConnMan, we noticed a difference
> between TCP and UDP implementation. Unlike UDP, the TCP socket towards DNS
> server is configured to be called each time data can be written (GLib watch
> condition G_IO_OUT). The problem is that using such configuration, the
> callback is triggered each time data can be written without blocking, which
> means many many times in a second. According to our analysis, that is what
> could be taking that much CPU resources from the moment socket is open (DNS
> request from devices connected to tethering Technology or from target
> itself), until socket is closed (DNS server responses or 30 seconds of
> idle-timeout):
>
> src/dnsproxy.c:2510
> if (data->protocol == IPPROTO_TCP) {
> g_io_channel_set_flags(data->channel, G_IO_FLAG_NONBLOCK, NULL);
> data->watch = g_io_add_watch(data->channel,
> G_IO_OUT | G_IO_IN | G_IO_HUP | G_IO_NVAL | G_IO_ERR,
> tcp_server_event, data);
> data->timeout = g_timeout_add_seconds(30, tcp_idle_timeout,
> data);
> } else
> data->watch = g_io_add_watch(data->channel,
> G_IO_IN | G_IO_NVAL | G_IO_ERR | G_IO_HUP,
> udp_server_event, data);
I am not entirely sure why NONBLOCK is set. The initial commit message
doesn't explain how the stuff works. Anyway, I don't think it was
added accidentally. Removing it will probably break things.
[...]
} else if (condition & G_IO_IN) {
struct partial_reply *reply = server->incoming_reply;
int bytes_recv;
if (!reply) {
unsigned char reply_len_buf[2];
uint16_t reply_len;
bytes_recv = recv(sk, reply_len_buf, 2, MSG_PEEK);
if (!bytes_recv) {
goto hangup;
} else if (bytes_recv < 0) {
if (errno == EAGAIN || errno == EWOULDBLOCK)
return TRUE;
I assume we end here? If we can't work on the socket we should wait
until ready again?
According to GLib documentation, "the function should return FALSE if
the event source should be removed". If you return FALSE here, what
happens?
Thanks,
Daniel
------------------------------
Date: Thu, 10 Oct 2019 09:13:21 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH 0/7] Rewrite OpenConnect plugin and enhance
support for VPN auth errors
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Fri, Oct 04, 2019 at 04:50:06PM +0300, Jussi Laakkonen wrote:
> Please ignore this set of patches. I'll send an updated set soon, with
> amendments to functionality introduced by David Woodhouse's comment on PKCS.
Okay. No worries I am so slow :)
Thanks,
Daniel
------------------------------
Date: Thu, 10 Oct 2019 09:31:02 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH v4 0/8] Rewrite OpenConnect plugin and enhance
support for VPN auth errors
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Wed, Oct 09, 2019 at 11:32:08AM +0300, Jussi Laakkonen wrote:
> This set of patches contains almost complete rewrite of OpenConnect VPN
> plugin,
> introduces a method for informing VPN agent about authentication errors and
> adds support for easier use of boolean type setting strings.
>
> First of all, as the biggest change, OpenConnect VPN plugin is rewritten to
> support the different authentication methods, which is configurable in
> provider
> settings. If the configuration is omitted, cookie based authentication is set
> as default. Support for automatic cookie (first use credentials to get cookie
> and then connect with the cookie), credentials and separate public key with
> private key and PKCS credential authentication is introduced. Credentials
> and PKCS password are queried from VPN agent. Also support for the three
> openconnect protocols is added also as provider settings for the OpenConnect
> plugin. New options for OpenConnect are added as well to support allowing self
> signed certificates and to toggle connection parameters, which may be required
> with different server setups.
>
> Second, the authentication and connection errors are tracked by vpn-provider.c
> when vpn_provider_indicate_error() is called with appropriate error code.
> These
> errors can be utilized in VPN plugins to indicate VPN agent that saved
> authentication credentials should be cleared. After succesful connection or
> after saving provider settings the error counters are cleared. Main reason for
> implementing these into provider is that saving the values in plugin private
> data would be cleared after the connection is terminated, and provider is more
> permanent during the runtime of vpnd.
>
> And last, a new function to better support setting strings expected to be
> boolean in value ("true" or "false") is implemented. This function can be used
> to check if the setting string is explicitly the desired boolean value as the
> default value in case of missing or invalid value is to be given.
>
> Changes since V2 and V3:
> * Correct PKCS lines, remove PKCS#12 references.
> * Update changed file contents as V1 cover letter was apparently sent.
>
> Changes since V4:
> * Update list of commits and changes.
Could you send the whole series in the lastest version? I want to
avoid that I wpick up the wrong version from the mailing list.
Since you are running out of time for adapting the plugin to use
libopenconnect, I suggest to add the work item to the TODO file and
explain how to do it. Since this is a major update of the plugin which
improves a lot of things I don't want to hold back. And I suppose
changing the code base to use libopenconnect will be simpler on top of
it anyway. Thoughts, comments, rants?
Thanks,
Daniel
------------------------------
Date: Thu, 10 Oct 2019 09:40:56 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: In case there are multiple context of cellular, how can
tethering select one as route context?
To: ������ <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
On Tue, Oct 08, 2019 at 07:09:49AM +0000, ������ wrote:
> Hello connman,
>
> I��m focus on wifi tethering for embedded device with connman v1.33.
> I have two cellular contexts as below.
>
> #ls /var/lib/connman
> cellular_11111111111111_context1
> cellular_22222222222222_context2
>
> when I turn on the tethering, wifi as AP is connected to first
> context(cellular_11111111111111_context1) for WAN.
> So, all client use to cellular_1111111111111_context1 to access WAN.
>
> I want to second context(cellular_22222222222222_context2) instead
> cellular_11111111111111_context1 for this case.
>
> Could you let me know how can I select context2 as WAN?
> I��m looking for some reference, but I can��t find a clue.
I assume you just see one service and not two? The ofono plugin
detects both contexts and registers them at the core as two
networks. The core is likely to merge them together as one service.
Anyway, ConnMan does not expose the network interface to the user
(this was a design decission), instead ConnMan tries to be clever and
presenting the networks 'with higher abstraction'. That works not so
well with use cases as you described. This could be changed by
starting to expose the networks/devices to the D-Bus and not just the
Services (drop the design decission). Obviously, without breaking the
API.
Thanks,
Daniel
------------------------------
Date: Thu, 10 Oct 2019 09:42:17 +0200
From: Daniel Wagner <[email protected]>
Subject: Re: [PATCH] vpnc: Implement disconnect function to cancel
queued VPN agent msg
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Wed, Oct 02, 2019 at 12:13:39PM +0300, Jussi Laakkonen wrote:
> Queued VPN agent messages must be canceled if the plugin timeouts
> without starting the process. This fixes the issue of having multiple
> VPN agent queries stacked on another in such scenario, where VPNC is
> awaiting for user input.
Patch applied.
Thanks,
Daniel
------------------------------
Date: Thu, 10 Oct 2019 08:42:43 +0100
From: David Woodhouse <[email protected]>
Subject: Re: [PATCH v3 6/8] openconnect: Use interactive mode when
input to stdin is required
To: Jussi Laakkonen <[email protected]>, [email protected]
Message-ID:
<[email protected]>
Content-Type: multipart/signed; micalg="sha-256";
protocol="application/x-pkcs7-signature";
boundary="=-KC3Xtc3eP6diYHrEtmJr"
--=-KC3Xtc3eP6diYHrEtmJr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, 2019-10-09 at 15:43 +0300, Jussi Laakkonen wrote:
> Hi David,
>=20
> Thanks for the input, this is my first touch with OpenConnect. I wasn't=
=20
> really aware that there is a library to use with it.
>=20
> Is the point of the OpenConnect library to assist in getting the cookie=
=20
> regardless of the authentication type used. So the intention is to do=20
> the authentication first, then always use the cookie when connecting?
Yes, that is precisely the intent. Many VPNs require user interaction
at this point. It might be one-time passwords or other things. That
part can be done in the user session.
> With quick look it seems that switching to that library from this=20
> screenscraping approach I've built would not be straightforward.=20
> However, it might simplify things there. But now I do not have time for=
=20
> a yet another rewrite. Maybe somewhere in the near future I'll look that=
=20
> library approach more closely and see how it can be used here and submit=
=20
> the results for review.
OK. Please at least make sure it works with all kinds of
certificate/key storage. As a minimum, the set of key files in the
OpenConnect test suite; ideally also PKCS#11 URIs (also tested in
OpenConnect's test suite) as well as TPM keys.
All those things should ideally work for *all* parts of ConnMan which
accept certs (802.1x auth, other VPNs, etc.).
--=-KC3Xtc3eP6diYHrEtmJr
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCECow
ggUcMIIEBKADAgECAhEA4rtJSHkq7AnpxKUY8ZlYZjANBgkqhkiG9w0BAQsFADCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTkwMTAyMDAwMDAwWhcNMjIwMTAxMjM1
OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZyYWRlYWQub3JnMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAsv3wObLTCbUA7GJqKj9vHGf+Fa+tpkO+ZRVve9EpNsMsfXhvFpb8
RgL8vD+L133wK6csYoDU7zKiAo92FMUWaY1Hy6HqvVr9oevfTV3xhB5rQO1RHJoAfkvhy+wpjo7Q
cXuzkOpibq2YurVStHAiGqAOMGMXhcVGqPuGhcVcVzVUjsvEzAV9Po9K2rpZ52FE4rDkpDK1pBK+
uOAyOkgIg/cD8Kugav5tyapydeWMZRJQH1vMQ6OVT24CyAn2yXm2NgTQMS1mpzStP2ioPtTnszIQ
Ih7ASVzhV6csHb8Yrkx8mgllOyrt9Y2kWRRJFm/FPRNEurOeNV6lnYAXOymVJwIDAQABo4IB0zCC
Ac8wHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFLfuNf820LvaT4AK
xrGK3EKx1DE7MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUF
BwMEBggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3Js
LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWls
Q0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuY29tb2RvY2Eu
Y29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYI
KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAeBgNVHREEFzAVgRNkd213MkBpbmZy
YWRlYWQub3JnMA0GCSqGSIb3DQEBCwUAA4IBAQALbSykFusvvVkSIWttcEeifOGGKs7Wx2f5f45b
nv2ghcxK5URjUvCnJhg+soxOMoQLG6+nbhzzb2rLTdRVGbvjZH0fOOzq0LShq0EXsqnJbbuwJhK+
PnBtqX5O23PMHutP1l88AtVN+Rb72oSvnD+dK6708JqqUx2MAFLMevrhJRXLjKb2Mm+/8XBpEw+B
7DisN4TMlLB/d55WnT9UPNHmQ+3KFL7QrTO8hYExkU849g58Dn3Nw3oCbMUgny81ocrLlB2Z5fFG
Qu1AdNiBA+kg/UxzyJZpFbKfCITd5yX49bOriL692aMVDyqUvh8fP+T99PqorH4cIJP6OxSTdxKM
MIIFHDCCBASgAwIBAgIRAOK7SUh5KuwJ6cSlGPGZWGYwDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNV
BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDEwMjAwMDAwMFoXDTIyMDEwMTIz
NTk1OVowJDEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBALL98Dmy0wm1AOxiaio/bxxn/hWvraZDvmUVb3vRKTbDLH14bxaW
/EYC/Lw/i9d98CunLGKA1O8yogKPdhTFFmmNR8uh6r1a/aHr301d8YQea0DtURyaAH5L4cvsKY6O
0HF7s5DqYm6tmLq1UrRwIhqgDjBjF4XFRqj7hoXFXFc1VI7LxMwFfT6PStq6WedhROKw5KQytaQS
vrjgMjpICIP3A/CroGr+bcmqcnXljGUSUB9bzEOjlU9uAsgJ9sl5tjYE0DEtZqc0rT9oqD7U57My
ECIewElc4VenLB2/GK5MfJoJZTsq7fWNpFkUSRZvxT0TRLqznjVepZ2AFzsplScCAwEAAaOCAdMw
ggHPMB8GA1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBS37jX/NtC72k+A
CsaxitxCsdQxOzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEF
BQcDBAYIKwYBBQUHAwIwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAwUwKzApBggrBgEFBQcCARYd
aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2Ny
bC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp
bENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LmNvbW9kb2Nh
LmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZHdtdzJAaW5m
cmFkZWFkLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAC20spBbrL71ZEiFrbXBHonzhhirO1sdn+X+O
W579oIXMSuVEY1LwpyYYPrKMTjKECxuvp24c829qy03UVRm742R9Hzjs6tC0oatBF7KpyW27sCYS
vj5wbal+TttzzB7rT9ZfPALVTfkW+9qEr5w/nSuu9PCaqlMdjABSzHr64SUVy4ym9jJvv/FwaRMP
gew4rDeEzJSwf3eeVp0/VDzR5kPtyhS+0K0zvIWBMZFPOPYOfA59zcN6AmzFIJ8vNaHKy5QdmeXx
RkLtQHTYgQPpIP1Mc8iWaRWynwiE3ecl+PWzq4i+vdmjFQ8qlL4fHz/k/fT6qKx+HCCT+jsUk3cS
jDCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNV
BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp
b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYT
AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV
BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQPTRI5Or1u6zf
+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivlJTRENf+RKwrB6vcf
WlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG9qrxpZxyb4o4yNNwTqza
aPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDK
CMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAU
u69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1Ud
DwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8E
RTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9u
QXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29t
b2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz
cC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2
SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs
0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDM
KVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+
E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfH
M5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4
jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJM/1t
yZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJUmpvVdZ4o
gnzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTKTlL8YXLI8nAb
R9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDyjCCA8YCAQEwga0wgZcxCzAJBgNV
BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA4rtJSHkq7AnpxKUY8ZlYZjANBglghkgB
ZQMEAgEFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkx
MDEwMDc0MjQzWjAvBgkqhkiG9w0BCQQxIgQgyaWtVyD+4E77r6mzJRg2V+P3E+SFYWNFqUPLLtMI
wG8wgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
PTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEQDiu0lIeSrsCenEpRjxmVhmMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDiu0lIeSrsCenEpRjxmVhmMA0GCSqGSIb3
DQEBAQUABIIBAEznC5rszZjd+kqghIrIJkxZMx0AzsNfdUaOuFkc4gj9N6kMn7M4vOzeBWPzXnEQ
pzzqcVk3E8AU6uC87qKpQdpkCVqIuqBVgmobGfvomWi5GHcvU0IhFXz29G8TYG5xioGVDOP1kiJ8
/mR41WEVHkuy9zby9dvxD/Lw1YDcQ+eIqgzKnRrFTwFc7Rh1cX+AfoDkJCKVePVeBWkkrRed19rB
XtjzlsgqKxiS96VAU2gc06eYJKz5aVBUrAqo9YnZ0Om3HpUYekm4w5izRL646SjaqFJPNKiyLec4
V2bb6JCJbCvL8QNf6N5YdNCCfNNYi4GBpgNPEMN5AmBiZYu3Ks8AAAAAAAA=
--=-KC3Xtc3eP6diYHrEtmJr--
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 48, Issue 16
***************************************
