can the user control what his wireless does ?

[Mikus Grinbergs]

I do not have a clear idea of what the user can actually manipulate 
regarding his XO's radio.  If I have difficulty - so may others. 
[There is the "general purpose" 'radio', and the "special purpose" 
mesh - yet controlling the 'radio' has an impact on the mesh !]


For power management, it makes sense "to turn the radio off" when on 
an airplane, or when the owner is not using the XO's connectivity, 
and further does not want his XO available as a "wireless relay". 
The Control Panel's 'Network panel' allows controlling this.

Note:  The Control Panel also has a 'Power panel' "extreme" setting 
that disables the radio (to conserve battery life).  Why does OLPC 
need two ways of letting the user "turn the radio off"?  [I presume 
the 'Power panel' setting takes precedence.]


My principal hurdle to understanding "control of wireless" comes 
from the 'radio' having two user-visible interfaces for wireless 
connections - one internally called 'eth' that is used to connect 
with an 'Access Point', and one internally  called 'msh' that is 
used to connect with the 'olpc-mesh'.

  -  I believe the intent was that ultimately these two interfaces 
could be separately controlled.  However, though there are two 
interfaces, most of the writeups I've seen only describe 
"controlling the radio" as a unit.  It is not obvious (if separate 
control were implemented) where separate "control handles" would be.

  -  Somewhere (Neighborhood in 8.2, Frame in 9.1) there exists an 
icon representing the mesh.  This icon is used to connect to, and 
disconnect from, a channel on the 'olpc-mesh'.  But it appears to me 
that even when the user is not using a mesh channel, the XO has been 
described as capable of being a "wireless relay" between other XOs. 
  What if the user wanted to de-activate *everything* related to the 
mesh capability, but without turning off the radio -- is that a 
control that should eventually be implemented ?

  -  If the 'radio' detects the signal of an 'Access Point', an icon 
for that 'Access Point' would appear in Neighborhood.  That icon is 
used to connect to, and disconnect from, that 'Access Point'.  What 
if the user wanted his XO to *not* show 'Access Points' (i.e., to 
de-activate *everything* not related to the mesh capability, but 
leaving the radio activated) -- is that a control that should 
eventually be implemented ?


The current implementation has been described as "if an 'Access 
Point' is connected, the 'olpc-mesh' cannot be" (and vice versa). 
Presumably this means that if the 'olpc-mesh' icon is clicked, that 
de-activates an 'Access Point' connection;  if an 'Access Point' 
icon is clicked, that de-activates any other connection.  This 
certainly controls whether the other 'radio' interface is being used 
for a connection -- but it appears NOT to control what else the XO's 
wireless 'radio' might be doing.  For instance - even if a mesh 
channel is connected, doesn't the 'radio' still look for signals 
from other stations ?  My conclusion is that, except for turning his 
'radio' completely off, there exist wireless functions that the user 
currently has no control over.


--------

My uncertainty is compounded by the parallel existence of other 
considerations:

  -  I do not have a "School Server", so I do not know if making a 
connection to it (or 'Registering the XO') is any different 
depending on whether that server is accessed via an external 
IP-address (i.e., through an 'Access Point' [the 'Access Point' 
might even be provided by that "School Server" itself]), or via a 
mesh-defined IP-address (i.e., directly over a local 'olpc-mesh' 
channel).

  -  The Control Panel's 'Network panel' allows specification of a 
"Collaboration Server" name.  If the IP-address of that server is 
accessible to this XO, the system at that address will be used for 
messaging, etc.  [My understanding is that if this XO registers with 
a "School Server", that server will supply a name to *replace* the 
user's "Collaboration Server" specification.]

  -  I presume that when the XO 'Registers', it stores the 
applicable "School Server" name (i.e., this is not something the 
user can control, except by selecting where to register).


Struggling with what is implemented, and what is not,  mikus