2009/12/3 Martin Owens <[email protected]> > Hey Darren, > > On Wed, 2009-12-02 at 16:48 -0500, Darren Albers wrote: > > There are a number of challenges here and it has been discussed in the > > past on this list which might help provide some more details. At a > > high level: > > 1) Sites that require a proxy or sites that use captive portals will > > give inaccurate results > > Sites that require proxy or sites that use captive portals should be > reported as such, this shouldn't be too difficult to work out when you > make a http request and it fails to get the information it expected. > > I think proxies are going to be the tricky one, requires someone who > knows about them tbh. But in any case, reporting that your not online > when you are is slightly more desirable that reporting that your online > when your not. > > > 2) Needless traffic for people in countries with costly access charges > > That's a concern, although many tools and services already attempt to > make requests, updates etc and people from these countries have learned > how to turn things off they find undesirable. Although making the tests > use the smallest amount of bandwidth is also important. > > > 3) Who would host this site that is checked? > > You'd have a number of them, mirrors of the same file or the same > challenge script that returns a predictable result. > > > 4) Do we want to rely on an internet hosted site to determine our > > network status? What happens when the site goes down or is otherwise > > unavailable? > > When it's down, you check the second mirror, then the third and then > conclude that your offline (or the internet has been destroyed by > skynet) > > > 5) For most "Home" users if they have a link they are "Online" for all > > intents and purposes. > > That isn't true, I work with home users all the time and one of their > problems is the inaccurate reporting of what they want (to be online) > and what the computer can tell them (that they're on a network) there > are all sorts of problems that crop up in all sorts of situations, > especially for people with laptops on wifi networks. > > To think that network link is the same as online is to go against the > evidence of user behviour. It's also making it hard to teach, what do I > tell my users? lie to them and say that when it's link they're online? > or tell them the truth and spend 40 mins explaining the complexity of > when they won't be online? > > > It might be better to have a troubleshooter > > option that they can run if they can't connect that checks what type > > of link (PPPOE, Wireless etc..) that gives them instructions on how to > > connect and can ping internet sites to determine connectivity and > > suggest options etc... This way it is more of a troubleshooting tool > > and the items above don't matter. > > Instructions for how to fix the problem is a good idea, possibly a > second phaise that you can implement higher up once you have the lower > level detection. > > > I personally don't see this as being very valuable and causing > > potential confusion but I am not a developer so my opinion doesn't > > carry much weight ;-) > > Unfortunately experienced users won't find value because they're used to > how it works already. New and casual users on the other hand (and even I > who is a programmer) have had examples of trying to check my email in > evolution and it not getting a connection because my wifi has been stuck > behind a paywall. > > It's most definitely a feature which should have always existed. > > Martin, > > > I think you need to be really careful about the use-case here. I think the blueprint is aiming this feature at home users, so the issue of proxies is vastly reduced. Also, there's no reason why a tiered approach couldn't be used :
1. Test for http://amionline.ubuntu.com 2. If (1) fails, test for any site and see if the response headers include a 302 or similar code (which many inline proxies will use to redirect you to an accept page - usually for terms and conditions, or possibly to enter your username/password) 3. If (2) fails, test for ping against the default gateway. 4. Report findings back to user appropriately. And example error messages could be, based on the above, All fail : "Your router appears to be down" 3 works, 1 and 2 fail : "Your router does not appear to be connected to the internet" 3 and 2 work, 1 fails : "You appear to be behind a firewall/proxy which requires authentication" All work : "You are connected to the internet". That would be a million miles more useful than Vista's vague "Local/Limited Connectivity" rubbish. I mean, you could probably test for DHCP failing too? Doesn't network-manager just fail silently in that case (unless you have "static" version of the same network defined)?
_______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
