On 2012-03-15 Dan Williams wrote: > The only effect this checking will have is to change NetworkManager's > state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It > doesn't do anything odd like disconnect and retry some other connection, > which wouldn't make much sense. It just changes some state which apps > can use to figure out whether they'd connect to say your IRC server or > your email or whatever automatically. Hi Dan, I suggest that is something the application should determine, not NetworkManager. Take the case where a ISP loses international connectivity, then a NetworkManager-informed application won't connect to the in-country ISP's IRC/e-mail/... server even though those servers are available. Thus connectivity detection worsens a partial loss of connectivity into a full loss of connectivity. The app has to be able to handle no connectivity anyway: just because Network Manager can HTTP GET the URI doesn't mean that IRC works. For example, a corporate firewall could allow HTTP but block IRC. Both the end-to-end argument and occam's razor argue for the application gracefully handling no connectivity. The current situation is that many apps don't handle a lack of connectivity with grace. But I suggest that this isn't NetworkManager's problem to solve. Even the current situation isn't great. NetworkManager shouldn't be telling applications that the network is available. That DBUS message should be triggered by the insertion into the main forwarding table of a default route. Then any source of global connectivity will set the app connecting (NM, NM work alikes, "ip route add", ospfd, tunnels, etc). Best wishes, Glen PS: I really don't understand the operation of dnssec-triggerd. The paths for HTTP and DNS traffic through an enterprise network can be very different so testing one protocol doesn't say a huge amount about the availability of the other protocol. But then I don't even understand the desirability of that program: allowing an external event (eg an access list on a router or a DoS attack) to trigger a reconfiguration from a DNSSEC-validating to a non-validating configuration seems more of a security bug than a feature. But I'm likely missing something here. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
