Alternative to Create a new wireless network

[Simon Schampijer]

On 12/08/2009 03:04 AM, Reuben K. Caron wrote:
> Daniel,
>
> 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
> interference.
>
> 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?
>
> Regards,
> Reuben
>
>
>
> (1) http://dev.laptop.org/ticket/9807
> (2) http://dev.sugarlabs.org/ticket/1604


Hi everyone,

based on the discussion in this thread I have created a first patch 
attached to ticket #9845 [1] 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 
here:

* 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 
compatibility'?

* 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?

Thanks,
    Simon

[1] http://dev.laptop.org/ticket/9845