Alternative to Create a new wireless network
simon at schampijer.de
Thu Apr 22 11:17:17 EDT 2010
On 12/08/2009 03:04 AM, Reuben K. Caron wrote:
> Since we've run into problems with creating ad-hocs networks on the XO
> 1.5 (1) (2), I've been thinking about this functionality, the change
> in UI behavior and perhaps the decrease in usability and I don't like
> it. I believe it is clunky to have children create their own
> networks..Who designates who creates the network? Why do I have to
> join that network? Why can't I make my own network and have them join
> me, etc.. All of this is aside from the technical limitations of which
> channel does my network get created on. Does the user specify channels
> 1, 6, or 11 when creating the network, or does the channel randomly
> get set? If randomly set, how do we avoid channel overlaps and
> To ease all of this and maintain a similar UI, what if we:
> -Create three faux "Mesh Channel #" icons in the Network view
> -When the child wants to join a mesh network they will select one of
> the networks
> -Upon selection: the XO will: 1. Scan to see if that ad-hoc network
> already exists and 2. if it does not exist the XO will create the
> network allowing other children to join it.
> The one pitfall of this idea, and I'm not sure how much of an issue
> this would be, is also the pitfall of ad-hoc networks...when the
> initiator of the ad-hoc network leaves the network fails. When the
> network has a respective name it is a bit more obvious when that
> person has left and the reason why the network has failed, this would
> not be the case given the anonymity of a "Mesh Network #." A more long
> term solution to this problem may be for the XO to sense the loss of
> the initiator and recreate the network. In this case, the first XO to
> sense the loss of the network after some period of time would check if
> another XO has already setup the network, if not the XO would create
> the network or join the new one if it already exists.
> Aside from the one pitfall, I think it would be really beneficial to
> maintain the same UI and appearance of functionality. Further
> development in this area may also help us get MPP back, at least at
> the software level.
> Your thoughts?
> (1) http://dev.laptop.org/ticket/9807
> (2) http://dev.sugarlabs.org/ticket/1604
based on the discussion in this thread I have created a first patch
attached to ticket #9845  implementing the three default ad hoc
networks for channel 1, 6 and 11. A screenshot can be found there, too.
There are a few open questions about the general approach I want to name
* Do we agree to have three icons, one for each available channel?
* Naming: do we agree to name the networks 'Mesh Network [channel name]'
even though they are no mesh networks but in order to keep 'backwards
* I do not save the connection to the nm-config file and don't mark them
to autoconnect, so we do not autoconnect when starting Sugar. I think,
as an ad-hoc network is not a persistent configuration this makes sense.
* Should we add an icon for 'mesh-network-connected' to better represent
the mesh network we are currently connected to?
* Connection sharing: So far the connections created are 'link-local'
connections. What is the plan for sharing an internet connection over an
adhoc network? As the XO has only one network device, i guess this is
not a common scenario.
* Remove the 'Create Network' ability of the wireless frame device
palette: As we have the default ad-hoc networks we may not need the
ability to create adhoc networks anymore. It may be more confusing then
of any help, what do others think?
More information about the Devel