I think the right fix here is "the clock should link to libnm-glib and notice the online/offline state, and do the right thing when it changes"

Hi Dan,

I believe that the clock applet already attempts to do that, but please note that it does not address the use case that I described.

In my particular situation, when I initially connect to the wireless network I am walled behind a gateway that proxies all http requests to an authentication website. So when the clock applet tries to download weather information it fails (the response is most likely the HTML of the authentication page).

If you don't want to add a configuration or force update option, you could have the clock check if it receives _bogus_ data, and in that case set a retry timer.

Thanks
-ross

Yeah, the clock already uses NM -- so it should check for weather information when you get online.

> Yeah, the clock already uses NM -- so it should check for weather information
when you get online.

That is a little beside the point that the previous comment made. Being 'online' and having a working route to the internet are two different things in this case. The user must authenticate on the wireless network using the browser before anything works, but the machine is 'online' the whole time.

I seem to have a similar problem on my home wireless, for which NM negotiates WPA authentication automatically. It still seems to be too slow or something, since half the time the clock does not display the weather when the connection comes up. Killing the clock process and reloading does get me weather immediately, so the online service apparently is not the problem. In my case the weather also does not appear after 30 min if it has failed to show up in the first place. It just never appears. Does the clock poll at 30 min intervals if the initial attempt fails? It looks to me like it does not.

I have up-to-date Fedora 10 on i386. The package is 
gnome-applets-2.24.3.1-1.fc10.i386

How about this for an algorithm: if getting weather data fails, set the interval to 1 min. On each subsequent attempt, increase the interval by +1 min up to 30 min. If weather data is successfully received, set the interval immediately to 30 min. This should work in the case where there are various delays between the connection coming up and actual working routing getting configured, or, when the online service is slow to respond.

er, this was actually fixed in pretty much the way you describe in 2.24.1, but I'd forgotten about this bug report. What version are you using?

if NM is emitting the "network is up" signal before the network is actually up, then that seems like a NM bug. libgweather and the clock applet have code to notice when they're getting a wifi network auth web page rather than a weather report, and it retries much faster in that case.

if the weather never appears at all, that's a bug. it should retry every half hour regardless of what happens the first time.

> What version are you using?

Please read my comment.

> if NM is emitting the "network is up" signal before the network is actually up,
then that seems like a NM bug.

I repeat: the network really is up, there is no problem with NM. The router that connects the wireless access point to the wired net does not allow traffic to the rest of the world unless the user authenticates using the browser. Only after that the traffic from the authenticated user system is routed to the internet. This is the way wireless works e.g. in every hotel that I've ever visited that has wireless and probably most cafes, university campuses etc. As far as NM is concerned, the link and default route are both up, but the route does not actually work until after the user authenticates. (I'm not talking about my home wireless here. That may be a different problem.)

I definitely see periods much longer than 30 min where the weather data is not shown and where the online weather service definitely is up, since the weather immediately appears if I kill and reload the clock.

Two problems here:

    1. When the clock first starts, it makes a request whether or not the
       network is actually up

    2. glibc caches the contents of /etc/resolver.conf, so if the first
       lookup fails, all subsequent ones will too. THANKS, GLIBC!

> 2. glibc caches the contents of /etc/resolver.conf, so if the first
       lookup fails, all subsequent ones will too. THANKS, GLIBC!

I don't quite understand. Do you mean that if DCHP re-negotiates and gets a new address for the nameserver, glibc ignores it and keeps using a cached one? I have edited resolv.conf manually lots of times and the changes take effect immediately.

apparently many distros patch glibc to re-check resolv.conf on every lookup, but stock glibc does not do this

Ok. I'm on Fedora. In the case of people using NM on laptops and quite possibly various wired and wireless networks, I guess it is to be expected that the default route and nameserver will change during the GNOME session.

579092 has a patch

*** This bug has been marked as a duplicate of 579092 ***