Re: Diskless clients and NetworkManager

["Andrew Bird (Sphere Systems)" <ajb spheresystems co uk>]

Hi Pablo,
	Speaking as a developer of VMC, I find NM's position of being the well known 
place for applications to find out if they have network connectivity logical, 
but also frustrating. Not providing an interface for 3rd party connection 
managers to publish their status means we have to ship our product in a 
condition that almost all users will find bewildering. Currently we can 
successfully make a connection to a mobile network, the user then opens 
Firefox and he is told that it's offline; now that's not user friendly. Of 
course there are workarounds for Firefox, but there are other apps that do a 
similar thing, surely we don't have to go and modify them all. Doing that 
would throw away all the benefit of NM being the well known interface it is. 
	In the future I'd like a dbus interface fitting to NM that allows 3rd party 
apps to publish their online status. Nothing too fancy is required, just a 
possibility to get ourselves out of the hole we find ourselves in.


Best regards,


Andrew




On Thursday 30 April 2009, Pablo Martí Gamboa wrote:
> 2009/4/30 Dan Williams <dcbw redhat com>
>
> > On Thu, 2009-04-30 at 14:06 +0100, Marc Herbert wrote:
> > > David Sundqvist a écrit :
> > > > If I set it to be managed by NM, will NM try to manage it in any way?
> > > > Can I set it to be seen, but still unmanaged? Or maybe I could get NM
> > > > to always output a connected status instead of a no-connection which
> > > > triggers firefox offline mode, etc. (should the connection be lost,
> > > > well, then NM won't be able to detect it anyway due to being frozen
> > > > on the first page touch).
> > >
> > > There seems to be something fundamentally wrong in this no-connection/
> > > /offline thing. Since NM can be configured to manage _not all_
> > > interfaces (including none at all) then why are some applications
> > > wrongly assuming NM is always managing the entire network
> > > configuration? This seems to be where the bug lies and should be
> > > fixed.
> >
> > Its mostly a distro problem; if NM is not managing your default internet
> > connection, then you should probably turn NM off when setting up the
> > machine.
>
> Unfortunately, in today's Linux Desktop this will yield some main
> application unusable, they all rely on the NetworkManager interface for
> connectivity status. For projects that provide connectivity (ConnMan,
> Wader, VMC, K-MobileTools, gnome-ppp, etc.) is a frustrating situation.
>
> Even thou NetworkManager is the de-facto standard tool for managing
> connectivity, NetworkManager won't always be the solution for everyone. Say
> you have a token ring connection, NetworkManager doesn't have plans to
> support it. Say you provide dial up capabilities, like VMC, Wader, etc. It
> ain't gonna be nice, users have connectivity but applications are not
> aware. There are workarounds for applications like Firefox, but it is not
> something that a noob user will understand or do. For other apps like
> pidgin, there's no workaround AFAIK. Perhaps Moblin has patched Firefox,
> pidgin, etc. to listen for ConnMan's signals, but this is only possible on
> the OEM/distro level - i.e. I'm not gonna ship a patched firefox/pidgin/foo
> that listens for Wader's signals in my ppa/buildservice, it ain't gonna
> scale.
>
> It is gonna be a though process, but we need to engage all the interested
> parties on a discussion about how to make applications aware of
> connectivity changes and come up with a DBus interface that several
> applications can provide.
>
> I have already expressed this concerns to Dan Williams, and I think that
> @asac thinks something similar.
>
> What do you guys think?
>
> > The only way you can make intelligent decisions about the network state
> > on the machine is to make those decisions with *all* the necessary
> > information, and that means letting NetworkManager control all your
> > network connections.
> >
> > There are situations in which NM is not appropriate at this time, and
> > those are mostly situations where the primary network connection cannot
> > be controlled by NM for some reason.  Thankfully, there are not too many
> > of those.  Network-mounted-/usr is one of those cases, as are cases
> > where the root device is network-mounted, or where the interface cannot
> > be touched after exiting the initrd.  For now, I'd suggest using the
> > static config scripts.
> >
> > A bullet-point on my feature list is to handle this case specifically
> > for wired non-802.1x connections, because all other types require too
> > much state to just be taken over post-initrd.
> >
> > Dan
> >
> > _______________________________________________
> > NetworkManager-list mailing list
> > NetworkManager-list gnome org
> > http://mail.gnome.org/mailman/listinfo/networkmanager-list