Mathieu Trudel-Lapierre <[email protected]> wrote:
>On Wed, Jul 11, 2012 at 1:22 AM, Scott Kitterman <[email protected]> >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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
