Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH 09/11] service: Change IPv6 support if split routing value
changes on IPv4 VPN
(Jussi Laakkonen)
2. Re: [PATCH 09/11] service: Change IPv6 support if split routing value
changes on IPv4 VPN
(David Woodhouse)
3. Re: [PATCH] service: Prevent auto connection during passphrase request
(Daniel Wagner)
4. Re: WiFi P2P connection (Daniel Wagner)
----------------------------------------------------------------------
Date: Tue, 6 Apr 2021 17:00:23 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: Re: [PATCH 09/11] service: Change IPv6 support if split
routing value changes on IPv4 VPN
To: David Woodhouse <dw...@infradead.org>, connman@lists.01.org
Message-ID: <4917f9de-be6c-d9e3-3bef-84e36c8b1...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi David,
Thanks for the feedback.
On 4/6/21 12:17 PM, David Woodhouse wrote:
> On Tue, 2021-04-06 at 09:34 +0100, David Woodhouse wrote:
>> On Thu, 2021-04-01 at 17:46 +0300, Jussi Laakkonen wrote:
>>> Enable/disable IPv6 on VPNs transport when the split routing value
>> is
>>> changed. This is important in both cases when a connected IPv4 VPN
>> has
>>> the value changed as with split routing -> non-split routing IPv6
>> should
>>> be disabled as well as non-split-routing -> split routed IPv6
>> should be
>>> re-enabled.
>>
>> Not necessarily. In the Cisco AnyConnect protocol there's a separate
>> flag to indicate whether IPv6 should be blocked or not, even when the
>> VPN does take the default Legacy IP route.
>>
>> Surely this should be just part of the routing information that the
>> protocol-specific VPN provider itself passes back to ConnMan? It just
>> needs a way to request a default IPv6 'unreachable' route?
>>
>> Likewise, if a VPN is IPv6-only it *might* or might not want to add a
>> default Legacy IP 'unreachable' route.
>>
I was really under the assumption that provider's family dictates which
of the IP-families can be used.
>> Just expose that facility from core ConnMan and let the VPN providers
>> use it as they desire.
I actually had this in mind as a next step to have a per provider option
to really control whether to disable IPv6 or not. Some amount of work
goes to that as well and I think OpenConnect and WireGuard plugins are
ones that are capable of both v4 and v6.
What do you Daniel say, should I try to include that per provider option
here or work it as later, and perhaps amend the TODO on that part?
> >
> Don't forget to also test the cases where the VPN *transport* is Legacy
> IP but it provides only IPv6 and wants Legacy IP (other than to itself)
> to be unreachable. As well as the converse where the VPN transport is
> IPv6 but it provides only Legacy IP and wants other Legacy IP addresses
> to be unreachable.
>
Well Daniel indirectly suggested similar thing, to check which ipconfigs
are enabled on the actual VPN service. I guess using the provider
information was too narrow-minded but I earlier had relied on that. Oh
well, every time I touch ConnMan code it teaches me new things, at least
in review if nowhere else.
Cheers,
Jussi
------------------------------
Date: Tue, 06 Apr 2021 15:31:28 +0100
From: David Woodhouse <dw...@infradead.org>
Subject: Re: [PATCH 09/11] service: Change IPv6 support if split
routing value changes on IPv4 VPN
To: Jussi Laakkonen <jussi.laakko...@jolla.com>, connman@lists.01.org
Message-ID:
<d3c0e728a4a5d85748ba3deb817880a99629b3e2.ca...@infradead.org>
Content-Type: multipart/signed; micalg="sha-256";
protocol="application/x-pkcs7-signature";
boundary="=-qNNYu2YEODFauPHB9yAY"
--=-qNNYu2YEODFauPHB9yAY
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, 2021-04-06 at 17:00 +0300, Jussi Laakkonen wrote:
> Hi David,
>=20
> Thanks for the feedback.
>=20
> On 4/6/21 12:17 PM, David Woodhouse wrote:
> > On Tue, 2021-04-06 at 09:34 +0100, David Woodhouse wrote:
> > > On Thu, 2021-04-01 at 17:46 +0300, Jussi Laakkonen wrote:
> > > > Enable/disable IPv6 on VPNs transport when the split routing value
> > >=20
> > > is
> > > > changed. This is important in both cases when a connected IPv4 VPN
> > >=20
> > > has
> > > > the value changed as with split routing -> non-split routing IPv6
> > >=20
> > > should
> > > > be disabled as well as non-split-routing -> split routed IPv6
> > >=20
> > > should be
> > > > re-enabled.
> > >=20
> > > Not necessarily. In the Cisco AnyConnect protocol there's a separate
> > > flag to indicate whether IPv6 should be blocked or not, even when the
> > > VPN does take the default Legacy IP route.
> > >=20
> > > Surely this should be just part of the routing information that the
> > > protocol-specific VPN provider itself passes back to ConnMan? It just
> > > needs a way to request a default IPv6 'unreachable' route?
> > >=20
> > > Likewise, if a VPN is IPv6-only it *might* or might not want to add a
> > > default Legacy IP 'unreachable' route.
> > >=20
>=20
> I was really under the assumption that provider's family dictates which=
=20
> of the IP-families can be used.
Definitely not. The protocol family that used to connect to the VPN
server is *entirely* orthogonal to the protocol families that the VPN
might provide within that tunnel.
Note that the protocol used for the connection might change from one
connection to the next; depending on DNS round robin and network
environment and many other things.
> > > Just expose that facility from core ConnMan and let the VPN providers
> > > use it as they desire.
>=20
> I actually had this in mind as a next step to have a per provider option=
=20
> to really control whether to disable IPv6 or not. Some amount of work=20
> goes to that as well and I think OpenConnect and WireGuard plugins are=
=20
> ones that are capable of both v4 and v6.
>=20
> What do you Daniel say, should I try to include that per provider option=
=20
> here or work it as later, and perhaps amend the TODO on that part?
I think you should *only* do the per-provider thing. Just give
providers a way to request 'unreachable' routes on Legacy IP and/or
IPv6 as part of their routing configuration, and that's all we want in
the core.
Except... while we're at it, we should also have the facility to allow
or deny access to the local subnet. Some VPN configurations permit it,
some request that it be blocked. By default, I think we always allow it
as an implicit "split exclude" but we shouldn't.
--=-qNNYu2YEODFauPHB9yAY
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
ZQMEAgEFAKCCAe0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEw
NDA2MTQzMTI4WjAvBgkqhkiG9w0BCQQxIgQg6bDmUt/wzk2Q9YCqA50fCXH8GBt4rxgDakXx8FtV
c7Ewgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
PTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEQDiu0lIeSrsCenEpRjxmVhmMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDiu0lIeSrsCenEpRjxmVhmMA0GCSqGSIb3
DQEBAQUABIIBAHhDfGWRIZZ1doRc2nWPMGvfIIn+CMb6nknAVYwG9SLDN1SKduPpUX3sM+p9OgTG
cUT29Y2Ro3vZhWZdt+Jb5eKi+gpuBUYIwyuB4ID4LI5OzqH6+y7P2urFDSXQ91u0iaRIgOfJEiwn
Rf/k+3ybMLdKTEoWlnP5poNHuTJDVa/VSfgLHd+XJ1qcdUW0TimMEHWhg1f9GaFR8ubABLYO/RGs
O3XEx5rF13PngYQxeU+WrDX4tQ3SqlDSRz1yrqHL3w0szEiJ7KWEeP6f2M8+gVwsiioec1MMcRta
v7c8IEsol39jaUIYJ7gnXY1QTBCwaGi3dwJ14VwHaKeI5eXlDR0AAAAAAAA=
--=-qNNYu2YEODFauPHB9yAY--
------------------------------
Date: Tue, 6 Apr 2021 19:56:07 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: [PATCH] service: Prevent auto connection during
passphrase request
To: "VAUTRIN Emmanuel (Canal Plus Prestataire)"
<emmanuel.vaut...@cpexterne.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Message-ID: <c5d7c32e-a2d1-0092-e08d-24ef7a7d7...@monom.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Emmanuel,
On 06.04.21 11:19, VAUTRIN Emmanuel (Canal Plus Prestataire) wrote:
> Hi Daniel,
>
> As a reminder, I send these information again.
>
>> src/service.c: In function ‘__connman_service_connect’:
>> src/service.c:6723:31: warning: passing argument 3 of ‘g_hash_table_replace’
>> makes pointer from integer without a cast [-Wint-conversion]
>> 6723 | GINT_TO_POINTER(index), true);
>> | ^~~~
>> | |
> In fact, I have copied the similar code from wispr_portal_browser_reply_cb.
> Maybe a global fix is necessary on this part.
It's similar but not the same. The wispr code inserts a pointer and
not a bool. That's why the compiler complains.
>
>> I think you could just insert the service instead of the bool
>> and use g_hash_table_remove() when done instead the bool. This would
>> also release the hash table resources.
> The aim is to avoid a new connection on the same interface, whichever > the
> service is, so the index, representative of the interface, shall
be used.
And the wispr code removes the entry at the end of usage, see
g_hash_table_remove. This code wont remove the entries after use, it
just sets to false, which could possible leaking memory.
Thanks,
Daniel
------------------------------
Date: Tue, 6 Apr 2021 19:59:23 +0200
From: Daniel Wagner <w...@monom.org>
Subject: Re: WiFi P2P connection
To: Jupiter <jupiter....@gmail.com>, connman <connman@lists.01.org>
Message-ID: <e76b00bf-2e44-69f6-5fb1-524af6302...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 06.04.21 04:23, Jupiter wrote:
> I now need to set up a WiFi P2P connection, my WiFi module supports
> P2P, what should I change to set up a WiFi P2P connection in a connman
> setting?
Try in 'connmanctl enable p2p'. If successful, the settings file should
be updated IIRC. I've never played with p2p, so I can't help a lot.
HTH!
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- connman@lists.01.org
To unsubscribe send an email to connman-le...@lists.01.org
------------------------------
End of connman Digest, Vol 66, Issue 9
**************************************
