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 08/11] provider: Toggle IPv6 on the transport of IPv4 VPN
connection
(David Woodhouse)
2. Re: [PATCH 09/11] service: Change IPv6 support if split routing value
changes on IPv4 VPN
(Jussi Laakkonen)
3. Re: [PATCH 08/11] provider: Toggle IPv6 on the transport of IPv4 VPN
connection
(Jussi Laakkonen)
----------------------------------------------------------------------
Date: Thu, 08 Apr 2021 10:40:13 +0100
From: David Woodhouse <dw...@infradead.org>
Subject: Re: [PATCH 08/11] provider: Toggle IPv6 on the transport of
IPv4 VPN connection
To: Jussi Laakkonen <jussi.laakko...@jolla.com>, Daniel Wagner
<w...@monom.org>
Cc: connman@lists.01.org
Message-ID:
<c7ed0d8cf277784e8c05d0f6abdce8d7f8b4193d.ca...@infradead.org>
Content-Type: multipart/signed; micalg="sha-256";
protocol="application/x-pkcs7-signature";
boundary="=-Gl1iafZaM1b7Ob6Fnn4d"
--=-Gl1iafZaM1b7Ob6Fnn4d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, 2021-04-07 at 13:24 +0300, Jussi Laakkonen wrote:
> It is still a guess as I have no dual-stack VPN at my disposal but those=
=20
> should have IPv6 enabled (disable_ipv6 0) -> IPv6 is not getting=20
> disabled on such VPN.
The ocserv server is available in most Linux distributions; *everyone*
has a dual-stack VPN at their disposal.
It should be fairly simple to set up ocserv with three different login
modes giving Legacy IP only, IPv6 only, and dual stack.
You can then connect to each of them *over* Legacy IP or over IPv6,
giving you six test scenarios.
For OpenConnect we just use ocserv in our 'make check' test suite, and
connect to it in various ways. Perhaps that would make sense to test
the openconnect VPN plugin for ConnMan along with the routing behaviour
of the VPN/ConnMan core?
Or perhaps it makes more sense for unit testing to hook up a dummy VPN
plugin that just simulates all six modes without openconnect/ocserv?
It wouldn't need to actually pass traffic; the test could just validate
that it gets the right answers from 'ip route get'?=20
Either way it certainly seems to make sense to have some kind of unit
testing for the feature.
--=-Gl1iafZaM1b7Ob6Fnn4d
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
NDA4MDk0MDEzWjAvBgkqhkiG9w0BCQQxIgQguIxXYxmSOx4fU211qzv+mWfdVbs3LnaAYVHJDqe2
Tz4wgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg
TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
PTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEQDiu0lIeSrsCenEpRjxmVhmMIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG
A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDiu0lIeSrsCenEpRjxmVhmMA0GCSqGSIb3
DQEBAQUABIIBAJ/w1aSd58UVmzRpPr9HtE1EP9THdLVwsnADUzwgvmbc8gCpYWLcwudJrMpuQaKL
BhuOj+lVYLULdZOWI6cPo86w5+ll1NwobD2NTgwvj+/d2GDUmaj2C9A9UNMvnJEanJy7TAbGKH+c
TwG9MCFhGkg5o/N6ZnWOm7yKP8vrW2utcflgkjfFY9PDoyxAcG1RMARWXXnZvT3knlroEbghcs7L
Lz18IjcnItKjF/GUmnalwJXEcq7PW11iahRAon4Hm7e/dn4LYCMycKMZLcPUX+3oeqDohBKygjXj
fY7b2QR2lADpTO4dDTFdiDUSJa4MpzpcQxWDN05nvRGhsVGMdtwAAAAAAAA=
--=-Gl1iafZaM1b7Ob6Fnn4d--
------------------------------
Date: Thu, 8 Apr 2021 13:09:44 +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: <407997fd-b8aa-0b93-d856-fd1936892...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi David,
On 4/8/21 12:20 PM, David Woodhouse wrote:
> On Thu, 2021-04-08 at 11:35 +0300, Jussi Laakkonen wrote:
>> So in a nutshell:
>> - vpn_provider.c has a boolean with key "PreventIPv6Leak", accessible
>> by the VPN plugins via vpn_provider_{set,get}_boolean().
>> - Each plugin can then be amended with the call to set the value for
>> the "PreventIPv6Leak"
>> - When changed, simply send a PropertyChanged signal that is listened
>> by the connmand VPN plugin (plugins/vpn.c)
>> - By default the boolean in provider.c on connmand side is set as on
>> to indicate that IPv6 disabling is done by default, but with that signal
>> vpn.c does change the value according to the VPN plugins' preference
>> based usually on user selection.
>
> I'd suggest not calling it 'PreventIPv6Leak'. We need to prevent a leak
> to *any* unconfigured protocol, be it IPv6 or Legacy IP.
>
> Sure, the most common case these days might be a VPN that provides only
> Legacy IP traffic and wants to block the client from using local IPv6,
> but it's also *perfectly* feasible that a VPN could provide only IPv6
> and want to block Legacy IP.
>
I'm open for naming suggestions.
Well that is to be done with some other mechanism then. This change
relies on use of disable_ipv6 and autoconf to avoid getting IPv6 address
for an interface, and removing it when it already has the addresses.
There is no such direct mechanism for disabling IPv4 AFAIK that is that
straightforward to do. NetworkManager, for example, uses disable_ipv6.
In the RFC I mentioned that I did try to do this with DNS record
filtering (used by bind) as that poses the actual issue here. But I did
not get it working properly and decided to switch focus on getting IPv6
to be put off as when IPv6 is enabled Linux tends to favor it.
I wouldn't yet go that far. I'd guess disabling IPv4 on ConnMan may be
tricky and provide more error cases than it may solve.
> Remember, the blocker to "IPv6 everywhere" has been deployment to
> crappy end-user networks, random airports and hotels etc. — none of
> which matters when the client already established a VPN back to the
> "home" network. So a VPN which provides only IPv6 isn't even that
> unlikely. It wouldn't surprise me if Facebook are already doing it;
> isn't their network purely IPv6 internally, with proxying/NAT for
> incoming connections from the 1980s?
Yeah, well world isn't perfect and we are not getting rid of IPv4
anytime soon anyways, network techniques are mixed and will be mixed.
Did you know that in 2021 in Finland all of the ISPs do not support IPv6
on their vDSL?
I understand your concern but I tend to rely that Linux in general works
correctly and IPv6 will get preferred even if you have dual-stack
connection.
If IPv4 should be blocked then I'd suggest the DNS record filtering, to
simply ignore the A requests as well as responses if the VPN acting as
default service does not support it. If the user wishes to use a direct
IP then that should be still allowed I think. But that is a completely
different patch set, I had it almost working but there were some big
issues.. maybe I'll get back to it some day.
>
> Don't build asymmetric assumptions into the core of ConnMan. Make it
> capable of blocking Legacy IP when the VPN has only IPv6 as well.
>
> And don't forget to cope with the case of connecting *over* IPv6 to a
> Legacy-only VPN, and vice versa. You want to block everything in the
> unconfigured protocol *except* the actual VPN gateway in that case.
>
As I said, there is no straightforward way to disable IPv4 AFAIK. Using
disable_ipv6 with autoconf at this time when ConnMan relies on kernel on
IPv6 management seemed to be a proper solution as existing functionality
already supported more than half of it.
I've already spent too much time on this. Some things are good to have,
some may be theoretical only and some just work for the specific problem.
Cheers,
Jussi
------------------------------
Date: Thu, 8 Apr 2021 15:47:01 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: Re: [PATCH 08/11] provider: Toggle IPv6 on the transport of
IPv4 VPN connection
To: David Woodhouse <dw...@infradead.org>, Daniel Wagner
<w...@monom.org>
Cc: connman@lists.01.org
Message-ID: <8e808748-bbb2-733c-4cf4-2f136c4d3...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi David,
On 4/8/21 12:40 PM, David Woodhouse wrote:
> On Wed, 2021-04-07 at 13:24 +0300, Jussi Laakkonen wrote:
>> It is still a guess as I have no dual-stack VPN at my disposal but those
>> should have IPv6 enabled (disable_ipv6 0) -> IPv6 is not getting
>> disabled on such VPN.
>
> The ocserv server is available in most Linux distributions; *everyone*
> has a dual-stack VPN at their disposal.
>
Yes I'm aware of that and I have it running already. Not anywhere public
as I've got no time to maintain them. Nor I have really interest in such
either.
> It should be fairly simple to set up ocserv with three different login
> modes giving Legacy IP only, IPv6 only, and dual stack.
>
> You can then connect to each of them *over* Legacy IP or over IPv6,
> giving you six test scenarios.
>
One just cannot test everything that comes to mind. Time restricts it.
> For OpenConnect we just use ocserv in our 'make check' test suite, and
> connect to it in various ways. Perhaps that would make sense to test
> the openconnect VPN plugin for ConnMan along with the routing behaviour
> of the VPN/ConnMan core?
>
> Or perhaps it makes more sense for unit testing to hook up a dummy VPN
> plugin that just simulates all six modes without openconnect/ocserv?
> It wouldn't need to actually pass traffic; the test could just validate
> that it gets the right answers from 'ip route get'?
>
> Either way it certainly seems to make sense to have some kind of unit
> testing for the feature.
>
>
I know very well from my experience how long it takes to do that unit
test and I have no time for that. So help is welcome if you feel the
urge to create one.
I've already tested this on different networks in varying conditions and
even on badly functioning devices. Simulating all with unit tests is
just too much to do and error prone.
- Jussi
------------------------------
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 14
***************************************
