Testing the Wireless driver changes

[Dan Williams]

On Thu, 2008-01-17 at 13:30 -0500, Michail Bletsas wrote:
> Hal Murray <hmurray at megapathdsl.net> wrote on 01/17/2008 12:55:47 PM:
> 
> > 
> > > When it comes to our radio - we *designed it* to start forward frames
> > > soon after you initialize it and keep doing it regardless of what the
> > > host interface does. 
> > 
> > In the context of making the radio safe to use on airplanes...
> > 
> > Does the firmware turn the radio on at boot time?
> > 
> > Does your "initialize" above mean firmware level or OS level?
> > 
> > 
> > 
> Initialize means loading the wireless firmware on the radio's ARM core and 
> start running it.
> 
> If you want to make sure that the radio never transmits a single bit, then 
> preventing that (loading the wireless firmware) is what you need right 
> now. There is explicit  mesh start/stop in the plans (already implemented 
> in the firmware but not in place yet since the driver people didn't like 
> it).

Sigh.  There are two issues that you're not sufficiently separating:

1) Whether the mesh is enabled/disabled at Layer 2.  This has nothing to
do with the ethX device and is a completely orthogonal problem.  (or if
it _does_ have any user-visible interaction with the ethX device that's
a total layering violation, and somebody needs to be taken behind the
woodshed and shot)

2) Whether the radio is on/off at Layer 1.  This affects _both_ the ethX
device and the mshX device.

There are acceptable, upstreamable solutions for both of these problems.

Solution for #1: up/down on the mshX device; if the mshX device is
marked !IFF_UP, the mesh functionality should probably be disabled.  The
8388 can keep the state and forwarding/blinding tables around until
poweroff/reset, but it should simply stop handling any mesh frames at
this point.  This can certainly be implemented with a
CMD_802_11_MESH_CONTROL firmware command _in_the_driver_, but there's no
need for another iwpriv just to achieve the same thing that up/down
already can do.  Then modify NM and system scripts to never down the
mesh device except in correct circumstances.

Solution for #2: already exists with 'iwconfig <iface> txpower off' and
'iwconfig <iface> txpower auto'.

------

The other discussion to have is what should the default radio state be
in.  If the default state is OFF until it's explicitly turned on by
NetworkManager or the user, then:

a) it should be verified that the firmware doesn't turn the radio on
until told to do so
b) it should be verified that the driver doesn't turn the radio on until
the device is brought up (ifconfig eth0 up)
c) it should be verified that nothing in the host OS (startup scripts
like the 'network' service calling ifup or NetworkManager bring the
device up) until the point at which the user has explicit control

Note that this approach would not be conducive to a nice exploratory
out-of-box experience (hence I don't really condone this approach
wholeheartedly) where access points and friends are immediately visible
from the Mesh view, until you explain to 5 year olds what the heck
wireless is and why it's off-by-default in the first place.

People traveling in RF-prohibited environments should be the ones who
bear the burden of turning off the RF, since not too many of the target
audience is going to ever be flying on a plane or driving by a blasting
site.  Plus those people who are flying on planes likely already know
that they _need_ to turn off the wireless component, which isn't likely
to be known by the 5 - 10 year old children in Peru who may never been
near an airplane anyway.

Dan