4:46 p.m.
Hi,
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 ?
Regards,
--
Antoine Aubert
a.aubert(a)overkiz.com
6:48 a.m.
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
4:05 p.m.
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 ?
8:02 a.m.
On Wed, 2017-02-15 at 17:05 +0100, Antoine Aubert wrote:
On the other side, I add a 60min polling time callback
Unfortunately this is a can of worms. 60 min detection is the next
point to argue about. Of course people then want a very accurate online
status, which brings this timer down to, what, tens of seconds? And to
really move status back and forth between online and ready states. On
another note, online status cannot verify connectivity to the
destination desired by the application, as this destination may have
its own set of rules from where access is allowed.
The only networks where this is a perceived problem are those where
connectivity is sporadic for one reason or another. All networks that
work in a stable manner and are designed to allow Internet connectivity
with minimum fuss have no problem in letting ConnMan move to the online
state properly. If the connectivity is sporadic, then ready is actually
the correct state to be in from the start. There is no loss of features
in ConnMan, the same set of functionality is available in both ready
and online states, so from an application perspective this is not a lot
of a problem either.
A bigger point of failure than re-checking for online status is the
presence of a captive portal. When the online check fails, ConnMan
detects the captive portal and sends a RequestBrowser method call to
the Agent. If there is no Agent or the Agent does not implement this
feature, then the connection status stays as ready. I have not heard of
any Agent UI that implements RequestBrowser to this day, unfortunately
[1].
Yet another almost equally big cause failure is to be in a network
walled up with a proxy and not having pacrunner installed. This also
causes the state to stay as ready. With pacrunner installed, ConnMan
will go to state online as the proxy is either detected or configured
in advance. In this setup, applications need to be compiled against
libproxy, and libproxy needs to be configured with pacrunner as the
back end. For example Fedora implements pacrunner support already, and
there a proxy is not a problem for ConnMan or the libproxy enabled
applications.
Cheers,
Patrik
[1] I did try this for the Gnome Shell extension, though. I got stuck
at the part where I was unable to embed a GTK WebKit WebView into a
Clutter -something, run out of my javascript mojo and did not find the
correct APIs/objects to do this.
1:09 a.m.
On 2/17/2017 3:02 AM, Patrik Flykt wrote:
...
A bigger point of failure than re-checking for online status is the
presence of a captive portal. When the online check fails, ConnMan
detects the captive portal and sends a RequestBrowser method call to
the Agent. If there is no Agent or the Agent does not implement this
feature, then the connection status stays as ready. I have not heard of
any Agent UI that implements RequestBrowser to this day, unfortunately
[1]
....
Patrik,
Point of information: CMST does implement RequestBrowser with its
Agent. When triggered a search of the users path is made looking for
common browsers and a dialog is shown listing those found with a request
to select one to continue the login process.
Just thought I'd let you know.
Andrew Bibb
9:36 a.m.
On Wed, 2017-02-22 at 01:09 +0000, Andrew Bibb wrote:
Patrik,
Point of information: CMST does implement RequestBrowser with its
Agent. When triggered a search of the users path is made looking
for common browsers and a dialog is shown listing those found with a
request to select one to continue the login process.
Just thought I'd let you know.
Very cool! Thanks!
Patrik
1999
days inactive
2007
days old
5 comments
4 participants
participants (4)
-
Andrew Bibb -
Antoine Aubert -
Daniel Wagner -
Patrik Flykt