Alternative to Create a new wireless network

[John Watlington]

On Dec 8, 2009, at 1:04 AM, James Cameron wrote:
> On Mon, Dec 07, 2009 at 09:04:52PM -0500, Reuben K. Caron wrote:
>> If randomly set, how do we avoid channel overlaps and interference.
>
> OpenFirmware has a method to detect channel use and avoid it, and  
> it is
> used in the NANDblaster feature on XO-1.  Avoiding overlaps and
> interference is not difficult to code, but it is unlikely to work as
> well as getting a human to make the decision.  Decisions made by  
> humans
> deliver a cognitive bias in favour of the decision.

More importantly, this breaks reported usage scenarios.   I'm told  
that in
Uruguay (back when they mistakenly had laptops acting like MPPs and
hosing the network with mesh transmissions) they used the ad-hoc meshes
to collaborate.   A teacher would have all students in a class click  
on the
"1", "6", or "11" channel to collaborate.

The ad-hoc channel should not be randomly selected.  It must be 1, 6,  
or 11
to avoid overlaps.  To avoid changing the interface, I would leave all
three shown in the neighborhood view and allow the user to select which
one they want to use.

> On Mon, Dec 07, 2009 at 11:37:03PM -0600, Mikus Grinbergs wrote:
>>> Since we've run into problems with creating ad-hocs networks on the
>>> XO 1.5
>>
>> I believe these tickets deal with the consequences of having long
>> *names* for systems, rather than with whether ad-hoc networks  
>> *can* be
>> created on the XO-1.5.
>
> Agreed.  Apart from those problems I've found no current issues  
> creating
> and operating ad-hoc networks on XO-1.5.  Sharing activities is a
> different matter; #9669.
>
>> To me, having three icons (to save an extra click) needlessly  
>> clutters
>> up Neighborhood View.  I would much prefer having a single icon  
>> (which
>> dynamically shows the number of the channel to which the hardware is
>> tuned at this instant),  together with (while establishing a  
>> connection)
>> a palette to allow the user to explicitly indicate (if he wants  
>> to) the
>> number of the channel on which he wants his XO to be active.
> Agreed.
>
> But I'd also like to see the previous UI restored, even though it  
> won't
> map to XO-1 semantics, nor even interoperate with the XO-1 network.

The lack of interoperability sucks.   A future XO-1 release could  
support
ad-hoc networks without using the mesh packet protocol, and restore
interoperability, with little downside...

wad