Re: NetworkManager signals global connectivity even when DNS is not yet ready

[Dan Williams <dcbw redhat com>]

On Wed, 2014-06-04 at 18:53 +0200, Marcel Dopita wrote:
> Hi Dan,
>
> Thanks for the fix. I was still experiencing the issue with Pidgin so I 
> installed patched NM and everything connected/got resolved after boot as 
> it should.
> I wanted to retest it with unpatched NM but I also ran system update 
> (silly me) and updated 15 packages thinking it shouldn't matter. Since 
> then I cannot duplicate the problem with unpatched version of NM even 
> when I downgrade all today installed packages.

I've pushed this to NM 0.9.8.x.  The fix for git master is a bit more
involved, still working on that.  Thanks for testing!

Dan

> Anyway, the important thing is that the signal is now sent after writing 
> DNS:
>
> With patch:
> čen 04 18:23:55 p8z77 NetworkManager[322]: <info> Policy set 'Wired 
> connection 1' (eno1) as default for IPv4 routing and DNS.
> čen 04 18:23:55 p8z77 NetworkManager[322]: <info> Writing DNS 
> information to /usr/bin/resolvconf
> čen 04 18:23:55 p8z77 NetworkManager[322]: <info> NetworkManager state 
> is now CONNECTED_GLOBAL
> čen 04 18:23:55 p8z77 NetworkManager[322]: <info> Activation (eno1) 
> successful, device activated.
>
> Without patch:
> čen 04 18:30:14 p8z77 NetworkManager[321]: <info> (eno1): device state 
> change: secondaries -> activated (reason 'none')
> čen 04 18:30:14 p8z77 NetworkManager[321]: <info> NetworkManager state 
> is now CONNECTED_GLOBAL
> čen 04 18:30:14 p8z77 NetworkManager[321]: <info> Policy set 'Wired 
> connection 1' (eno1) as default for IPv4 routing and DNS.
> čen 04 18:30:14 p8z77 NetworkManager[321]: <info> Writing DNS 
> information to /usr/bin/resolvconf
>
> Regards,
> Marcel
>
> On 2014-06-04 15:30, Dan Williams wrote:
> > On Wed, 2014-06-04 at 01:27 +0200, Marcel Dopita wrote:
> > > Hello,
> > >
> > > When trying to setup my desktop environment (Arch Linux & XFCE) I also
> > > enabled Pidgin (IM client) to launch in XFCE session. I noticed that
> > > Pidgin doesn't connect immediately after boot but it works either by
> > > manually forcing it to reconnect or waiting 30-45 seconds for next
> > > reconnect.
> > >
> > > I started debugging the issue and found that Pidgin is starting
> > > connection attempts based on event from NetworkManager:
> > >
> > > (00:09:44) network: Got StateChange from NetworkManager: 70.
> > >
> > > I understand that 70 is state "NM_STATE_CONNECTED_GLOBAL" - the global
> > > network connectivity. I'm no C developer but I added some addition 
> > > debug
> > > info to find out that it fails when calling function getaddrinfo() 
> > > (and
> > > maybe some other) which returns -2 (meaning "NAME or SERVICE is
> > > unknown.")
> >
> > It's a bug, good catch.  It looks like the bits in the Manager object
> > that update the NM state run immediately before the bits that write out
> > DNS information.
> >
> > Would you be able to try the attached patch and see if this fixes
> > things?
> >
> > Thanks!
> > Dan