Enabling Connectivity Checking in NetworkManager

[Scott Kitterman]

Mathieu Trudel-Lapierre <mathieu.tl at gmail.com> wrote:

>On Wed, Jul 11, 2012 at 1:22 AM, Scott Kitterman <ubuntu at kitterman.com>
>wrote:
>[...]
>> For hotels, I can't recall the last time I had one last less then 24
>hours.
>> Even on public wifi (as in coffee shops), the shortest I recall one
>lasting was
>> 4 hours.  I agree that every 5 minutes is excessive.
>>
>> The fundamental problem with periodics like this is that whatever
>$PERIOD you
>> pick, the situation can change immediately after a check. 
>Fundamentally, I
>> think that this check leaves you knowing less that it probably
>appears it
>> does.
>
>I don't disagree -- whatever $PERIOD chosen, the situation can change
>immediately after the check -- that works on both losing connectivity,
>and gaining connectivity.
>
>I think what probably needs to be clarified here is that it's in no
>way meant to be used by applications as "I don't have this, so I can't
>work", because we all know the actual usefulness of the connection may
>be different for different ports, between checks, etc.

I think the primary benefit is the initial connection. Doing this once when the network connection is established and perhaps once every 15 seconds until there is a success would cover the initial connect use case even better, which probably makes it a good 90% solution, and avoids most of the concerns expressed in this thread (I still think default off is the more socially correct choice, but I seem to be a minority).

>What we'd be gaining here would instead be the capacity to inform
>users that their connection might not be optimal, and that they may
>not have full connectivity.

I'm still not clear on how you distinguish between captive and merely not working very well?

>> If Ubuntu is going to work on mobile devices, it's going to have to
>deal with
>> intermittent apparent connectivity (it's not rare for me to have very
>similar
>> problems when tethered via my phone - I'm connected to the phone just
>fine, but
>> it's network connection dies for a bit).  Captive connections like
>hotels use
>> is only one, special case of this.  Even if I didn't have
>reservations about
>> phoning home as a concept, I don't think it solves enough of a
>problem to be
>> worth doing.
>
>When your phone's connection fails, doesn't it display a different
>signal level icon to indicate it's not connected? When tethered, this
>means you'd have to rely on watching your phone for connection changes
>since it probably always shows up as an ethernet connection (unless
>it's tethered over bluetooth DUN). In this case you could get notified
>about it, but yes, as of the current status of the NM code, you'd have
>to wait <= 5 minutes.

I do it via USB, so it shows up as a USE networking connection (similar to wired).  The phone doesn't indicate the change. 

What I do is run ping in a terminal and check it if it seems like there's a problem (anecdotally, it feels like it helps keep the connection working).  At the interval ping runs at, if things are marginal, the connection can come and go several times a minute.  This is part of why I'm sceptical about this helping much for anything beyond the initial connection.

>> If I've just connected to a hotel/public wifi, I know I need to go to
>a web
>> page and sign in.  I think anyone that's ever done this before on any
>> operating system knows this.  Intermittent 3G/4G connection loss
>produces
>> similar problems, but is completely unpredictable.  I think that's a
>more
>> important problem to solve.
>
>We have signal level icons for 3G/4G; I'm not sure what else there
>would be to do over that past using some form of external check to
>verify that the connectivity is proper.

Part of the discussion has been that some applications (e.g. Evolution) behave badly in the face of poor/no connectivity if NM thinks it's connected.  My point here is that independent of the captive connection issue, that's going to come up and those applications need to be fixed.

>Furthermore, facilitating sign in to portals is a feature that most
>connection managers have on their roadmap or implemented. We (speaking
>as a contributor to NM upstream) would like to implement it; ConnMan
>already has features to help with this (WISPr).

How do they do it?

Scott K