Testing the Wireless driver changes

[Ricardo Carrano]

I apologize if I am over simplifying:

- mesh stop was considered when we had compatibility issues with lazy-wds
routers. We addressed this, right? Do we still need this feature? Michail?
- For airplane mode or relatives, we need to shut up radio (any traffic).

On Jan 17, 2008 5:05 PM, Dan Williams <dcbw at redhat.com> wrote:

> 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
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080117/191521fe/attachment.html>