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: In case there are multiple context of cellular, how can tethering
select one as route context?
([email protected])
2. [HELP :-) ] 3g modem auto connect (nick83ola)
3. Re: [PATCH v4 0/8] Rewrite OpenConnect plugin and enhance support for VPN
auth errors
(Jussi Laakkonen)
4. Re: [PATCH v3 6/8] openconnect: Use interactive mode when input to stdin
is required
(Jussi Laakkonen)
----------------------------------------------------------------------
Date: Thu, 10 Oct 2019 09:11:59 -0000
From: [email protected]
Subject: Re: In case there are multiple context of cellular, how can
tethering select one as route context?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Thank you for reply.
Actually, I'm using two services with multiple apn.
root@p2382_t186:/etc/connman# connmanctl services
* O KT cellular_450087560197639_context1
*A KT cellular_450087560197639_context2
Since our modem supports dual APN, each context have different IP.
#ifconfig
wwan0 Link encap:Ethernet HWaddr 5a:e5:50:63:0c:d1
inet addr:100.106.186.203 Bcast:100.106.186.203 Mask:255.255.255.255
inet6 addr: fe80::58e5:50ff:fe63:cd1/64 Scope:Link
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:2148 errors:0 dropped:0 overruns:0 frame:0
TX packets:2655 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1137197 (1.0 MiB) TX bytes:505380 (493.5 KiB)
wwan0.1 Link encap:Ethernet HWaddr 5a:e5:50:63:0c:d1
inet6 addr: fe80::58e5:50ff:fe63:cd1/64 Scope:Link
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:7 errors:0 dropped:0 overruns:0 frame:0
TX packets:238 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:848 (848.0 B) TX bytes:48271 (47.1 KiB)
cellular_450087560197639_context1 is matched to 'wwan0' and
cellular_450087560197639_context2 is matched to 'wwan0.1'.
In this case, when tethering is enabled, tethering route
cellular_450087560197639_context1 because context1 is default route.
Could you let me know how can I change context2 as default route when tetheing
is enable?
Thanks,
DJ
------------------------------
Date: Thu, 10 Oct 2019 10:28:37 +0100
From: nick83ola <[email protected]>
Subject: [HELP :-) ] 3g modem auto connect
To: [email protected]
Message-ID:
<cabph3upstnhzopcmryynefczz2ppzi3zkrbfwl9tntujt+3...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="00000000000060740505948b0780"
--00000000000060740505948b0780
Content-Type: text/plain; charset="UTF-8"
Dear Connman developers,
I have a telit HE910-D modem that I need to make it work inside yocto.
the modem is correctly recognized both by connman and ofono
connmanctl services
*AO Wired ethernet_0001c021c253_cable
3 cellular_272023119202599_context1
...
And it work fine if I issue the command
connmanctl connect cellular_272023119202599_context1
And it also reconnect after reboot
My issue is that the first time that you connect the modem
(if there's no configuration folder for it in /var/lib/connman) it doesn't
connect automatically
I need a way to say to connman that if there's any cellular modem connected
just connect to it.
there's an option or something that I can do without monitoring connman
through dbus?
Is this the correct connman behaviour?
Kind Regards
Nicola Lunghi
cat /var/lib/connman/cellular_272023119202599_context1/settings
[cellular_272023119202599_context1]
Name=3
Favorite=true
AutoConnect=true
Modified=2019-10-12T09:23:12.647297Z
IPv4.method=fixed
IPv4.netmask_prefixlen=32
IPv4.local_address=100.71.238.126
IPv6.method=off
IPv6.privacy=disabled
cat /etc/connman/main.conf
[General]
SingleConnectedTechnology=false
FallbackTimeservers=
NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,ve-,vb-,wlanap
AllowHostnameUpdates=false
DefaultAutoConnectTechnologies=cellular,wifi,ethernet
AlwaysConnectedTechnologies=cellular,wifi
PreferredTechnologies=cellular,wifi,ethernet
--00000000000060740505948b0780
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Dear Connman developers,</div><div><br></div><div>I h=
ave a telit HE910-D modem that I need to make it work inside yocto.</div><d=
iv><br></div><div>the modem is correctly recognized both by connman and ofo=
no<br></div><div></div><div>=C2=A0=C2=A0=C2=A0 connmanctl services<br>=C2=
=A0=C2=A0=C2=A0 *AO Wired =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0ethernet_0001c021c253_cable<br>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0cellular_272023119202599_context1</div>...<br><d=
iv><br></div><div>And it work fine if I issue the command <br></div><div><b=
r></div><div>=C2=A0=C2=A0=C2=A0 connmanctl connect cellular_272023119202599=
_context1</div><div><br></div><div>And it also reconnect after reboot<br></=
div><div>My issue is that the first time that you connect the modem <br></d=
iv><div>(if there's no configuration folder for it in /var/lib/connman)=
it doesn't connect automatically</div><div><br></div><div>I need a way=
to say to connman that if there's any cellular modem connected just co=
nnect to it.</div><div>there's an option or something that I can do wit=
hout monitoring connman through dbus?</div><div>Is this the correct connman=
behaviour?<br></div><div><br></div><div>Kind Regards</div><div>Nicola Lung=
hi<br></div><div><br></div><div>cat /var/lib/connman/cellular_2720231192025=
99_context1/settings <br></div><div><br></div><div>[cellular_27202311920259=
9_context1]<br>Name=3D3<br>Favorite=3Dtrue<br>AutoConnect=3Dtrue<br>Modifie=
d=3D2019-10-12T09:23:12.647297Z<br>IPv4.method=3Dfixed<br>IPv4.netmask_pref=
ixlen=3D32<br>IPv4.local_address=3D100.71.238.126<br>IPv6.method=3Doff<br>I=
Pv6.privacy=3Ddisabled<br></div><br><div>cat /etc/connman/main.conf <br>[Ge=
neral]<br>SingleConnectedTechnology=3Dfalse<br>FallbackTimeservers=3D<br>Ne=
tworkInterfaceBlacklist=3Dvmnet,vboxnet,virbr,ifb,ve-,vb-,wlanap<br>AllowHo=
stnameUpdates=3Dfalse<br>DefaultAutoConnectTechnologies=3Dcellular,wifi,eth=
ernet<br>AlwaysConnectedTechnologies=3Dcellular,wifi<br>PreferredTechnologi=
es=3Dcellular,wifi,ethernet<br></div><div><br></div></div>
--00000000000060740505948b0780--
------------------------------
Date: Thu, 10 Oct 2019 14:32:07 +0300
From: Jussi Laakkonen <[email protected]>
Subject: Re: [PATCH v4 0/8] Rewrite OpenConnect plugin and enhance
support for VPN auth errors
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
On 10/10/19 10:31 AM, Daniel Wagner wrote:
> 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.
>
Sure, I'll try to do that tomorrow. I know it became a bit confusing
thread.. my bad, blind eye on taking changes from fork to upstream.
> 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?
Yeah, I can do that as well (tomorrow), no probs. Sleep usually helps to
rearrange this kind of stuff :)
Cheers,
Jussi
------------------------------
Date: Thu, 10 Oct 2019 14:36:31 +0300
From: Jussi Laakkonen <[email protected]>
Subject: Re: [PATCH v3 6/8] openconnect: Use interactive mode when
input to stdin is required
To: David Woodhouse <[email protected]>, [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi David,
On 10/10/19 10:42 AM, David Woodhouse wrote:
> On Wed, 2019-10-09 at 15:43 +0300, Jussi Laakkonen wrote:
>> Hi David,
>>
>> Thanks for the input, this is my first touch with OpenConnect. I wasn't
>> really aware that there is a library to use with it.
>>
>> Is the point of the OpenConnect library to assist in getting the cookie
>> regardless of the authentication type used. So the intention is to do
>> 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.
>
Ok, thanks. Good to know I'm on the right track here. I'll include
comments on how to change to libopenconnect into the TODO file as Daniel
suggested.
>> With quick look it seems that switching to that library from this
>> screenscraping approach I've built would not be straightforward.
>> However, it might simplify things there. But now I do not have time for
>> a yet another rewrite. Maybe somewhere in the near future I'll look that
>> library approach more closely and see how it can be used here and submit
>> 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.).
>
I'll keep that in mind, thanks. I'll let you know when I have something
prepared as continuum for this work.
Cheers,
Jussi
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 48, Issue 17
***************************************
