Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, 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: Connman to control OpenVPN connection (Daniel Wagner)
2. Re: Monitoring online status (Daniel Wagner)
3. Re: Monitoring online status (Antoine Aubert)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 Feb 2017 07:41:03 +0100
From: Daniel Wagner <[email protected]>
To: Florent Le Saout <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Connman to control OpenVPN connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Florent,
Do not top post and no HTML please.
On 02/13/2017 09:53 AM, Florent Le Saout wrote:
> Thanks for spending some time trying reproducing that. :)
>
> I'm actually on 2.3.14 on both side, compiled for ARM for the client and
> x86_64 for the server.
>
> I could not migrate so far on 2.4
I am not aware of any 2.3 vs 2.4 issues so far. At least for ConnMan it
is the same, unless the few options we use got renamed or removed.
Though the there might be a different behavior between those two
versions, but that seem to me very likely.
> * _Regarding routes :_
>
>
> What I observe is that most of the times routes are properly set and
> connman is listing services in the right order :
>
> root # connmanctl services
> * R VPN vpn_192_168_4_201_test
> *AO Wired ethernet_7076ff010e20_cable
>
> # ip route
> default dev vpn0
> 10.8.0.1 dev vpn0
> 192.168.4.0/23 dev eth0 src 192.168.4.119
> 192.168.4.4 dev eth0
> 192.168.4.201 via 192.168.4.4 dev eth0
>
> But once in a while, it's not correct.
> How can we make sure that VPN will always be on top of the others, which
> is the default expected behavior from my perspectives ?
Can you send the log file generated by
sudo ./src/connmand -n -d src/service.c 2>&1 | ts '[%H:%M:%.S]' | tee
connman.log
one when it works and one for when it's wrong. If possible annotating
the time when the operations filed with the time stamp, so that we have
a chance to find the right spot.
> I will also try to reproduce it on my side and try to provide you with
> as much details as I can.
>
> * _Regarding Autoconnect :_
>
> When you say :
>
> The VPN Service itself has an AutoConnect property which tells
> ConnMan to start it automatically.
>
> Do you mean that this is set automatically by default for this type of
> service, or do I need to set it manually bu setting an option, because
> if this is the case I haven't found it ?
> See below the actual details of my connexion :
You need to set it per Service via the D-Bus API, e.g. using connmanctl
connmanctl config VPN_SERVICE_NAME --autoconnect yes
>
> /net/connman/service/vpn_192_168_4_201_test
> Type = vpn
> Security = [ ]
> State = ready
> Favorite = True
> Immutable = False
> AutoConnect = False
Consider this file as read only. It will be overwritten without warning.
If you edit by hand you need first to shutdown connman-vpn
Thanks,
Daniel
------------------------------
Message: 2
Date: Wed, 15 Feb 2017 07:48:19 +0100
From: Daniel Wagner <[email protected]>
To: Antoine Aubert <[email protected]>, [email protected]
Subject: Re: Monitoring online status
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Antoine,
On 02/14/2017 05:46 PM, Antoine Aubert wrote:
> Does connman can monitor 'online' service status ? When 'internet' can't
> be reached ? i.e loosing xDSL sync ...
>
> As I understand, once service became online (and all stuff checked), It
> never go backward, until hardware event. (unpluged ...) Am I wrong ?
>
> May we use wispr to check connectivity ? By polling ?
Unfortunately, you're observation is correct. The check is a one time
shot and it is not re-run again. We had quite a lot of discussion on
this topic. The main concern why we have only one shot, is how to get
the re-check implemented in a robust way.
Thanks,
Daniel
------------------------------
Message: 3
Date: Wed, 15 Feb 2017 17:05:28 +0100
From: Antoine Aubert <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Subject: Re: Monitoring online status
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Le 15/02/2017 ? 07:48, Daniel Wagner a ?crit :
> Hi Antoine,
>
> On 02/14/2017 05:46 PM, Antoine Aubert wrote:
>> Does connman can monitor 'online' service status ? When 'internet' can't
>> be reached ? i.e loosing xDSL sync ...
>>
>> As I understand, once service became online (and all stuff checked), It
>> never go backward, until hardware event. (unpluged ...) Am I wrong ?
>>
>> May we use wispr to check connectivity ? By polling ?
>
> Unfortunately, you're observation is correct. The check is a one time
> shot and it is not re-run again. We had quite a lot of discussion on
> this topic. The main concern why we have only one shot, is how to get
> the re-check implemented in a robust way.
>
> Thanks,
> Daniel
First, I add new public API:
int __connman_service_notify_become_unavailable(struct connman_service
*service,
enum connman_ipconfig_type type)
{
if (service->state == CONNMAN_SERVICE_STATE_ONLINE) {
DBG("");
nameserver_remove_all(service, type);
if (type == CONNMAN_IPCONFIG_TYPE_IPV4)
service->state_ipv4 = CONNMAN_SERVICE_STATE_READY;
else
service->state_ipv6 = CONNMAN_SERVICE_STATE_READY;
__connman_timeserver_sync(service);
return service_indicate_state(service);
}
return 0;
}
called on wispr_portal_error(...)
On the other side, I add a 60min polling time callback
static gboolean service_status_polling_callback(gpointer user_data)
{
DBG("");
GList *list;
for (list = service_list; list; list = list->next) {
struct connman_service *service = list->data;
if (__connman_service_is_connected_state(service,
CONNMAN_IPCONFIG_TYPE_IPV4))
__connman_wispr_start(service,
CONNMAN_IPCONFIG_TYPE_IPV4);
if (__connman_service_is_connected_state(service,
CONNMAN_IPCONFIG_TYPE_IPV6))
__connman_wispr_start(service,
CONNMAN_IPCONFIG_TYPE_IPV6);
}
return TRUE;
}
What's your opinion ?
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 18
***************************************
