Re: Sugar + OLPC mesh network selection logic
- From: Daniel Drake <dsd laptop org>
- To: Dan Williams <dcbw redhat com>
- Cc: sugar-devel lists sugarlabs org, networkmanager-list gnome org
- Subject: Re: Sugar + OLPC mesh network selection logic
- Date: Mon, 06 Jul 2009 17:27:41 +0100
On Wed, 2009-07-01 at 12:18 -0400, Dan Williams wrote:
> If other APs appear later, it may well trigger the
> schedule_activate_check() which might cause NM to try to connect to that
> new network. To combat that, I'd suggest that the mesh device block the
> wifi device from activating if it already failed by putting it into the
> UNAVAILABLE state or something, but that could be error prone. What I
> think we really want here is the 'device idle' concept that asac and I
> have been talking over for a while.
The same consideration has to apply for when the mesh device disconnects
the eth device, because the user requested a mesh connection. Right now,
NM immediately reactivates eth0 (usually reconnecting to the same
network as before) and "wins."
What is the "device idle" concept? What do you think of an approach
along these lines? This way the mesh device can attach to the
autoconnect-allowed signal on the main device, and influence when it can
and cannot be used for automatic connections.
Daniel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]