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).

<br><br><div class="gmail_quote">On Jan 17, 2008 5:05 PM, Dan Williams <<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="Ih2E3d">On Thu, 2008-01-17 at 13:30 -0500, Michail Bletsas wrote:<br>> Hal Murray <<a href="mailto:hmurray@megapathdsl.net">hmurray@megapathdsl.net</a>> wrote on 01/17/2008 12:55:47 PM:<br>><br>> >

<br>> > > When it comes to our radio - we *designed it* to start forward frames<br>> > > soon after you initialize it and keep doing it regardless of what the<br>> > > host interface does.<br>> >

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

<br>> ><br>> ><br>> ><br>> Initialize means loading the wireless firmware on the radio's ARM core and<br>> start running it.<br>><br>> If you want to make sure that the radio never transmits a single bit, then

<br>> preventing that (loading the wireless firmware) is what you need right<br>> now. There is explicit  mesh start/stop in the plans (already implemented<br>> in the firmware but not in place yet since the driver people didn't like

<br>> it).<br><br></div>Sigh.  There are two issues that you're not sufficiently separating:<br><br>1) Whether the mesh is enabled/disabled at Layer 2.  This has nothing to<br>do with the ethX device and is a completely orthogonal problem.  (or if

<br>it _does_ have any user-visible interaction with the ethX device that's<br>a total layering violation, and somebody needs to be taken behind the<br>woodshed and shot)<br><br>2) Whether the radio is on/off at Layer 1.  This affects _both_ the ethX

<br>device and the mshX device.<br><br>There are acceptable, upstreamable solutions for both of these problems.<br><br>Solution for #1: up/down on the mshX device; if the mshX device is<br>marked !IFF_UP, the mesh functionality should probably be disabled.  The

<br>8388 can keep the state and forwarding/blinding tables around until<br>poweroff/reset, but it should simply stop handling any mesh frames at<br>this point.  This can certainly be implemented with a<br>CMD_802_11_MESH_CONTROL firmware command _in_the_driver_, but there's no

<br>need for another iwpriv just to achieve the same thing that up/down<br>already can do.  Then modify NM and system scripts to never down the<br>mesh device except in correct circumstances.<br><br>Solution for #2: already exists with 'iwconfig <iface> txpower off' and

<br>'iwconfig <iface> txpower auto'.<br><br>------<br><br>The other discussion to have is what should the default radio state be<br>in.  If the default state is OFF until it's explicitly turned on by<br>

NetworkManager or the user, then:<br><br>a) it should be verified that the firmware doesn't turn the radio on<br>until told to do so<br>b) it should be verified that the driver doesn't turn the radio on until<br>the device is brought up (ifconfig eth0 up)

<br>c) it should be verified that nothing in the host OS (startup scripts<br>like the 'network' service calling ifup or NetworkManager bring the<br>device up) until the point at which the user has explicit control

<br><br>Note that this approach would not be conducive to a nice exploratory<br>out-of-box experience (hence I don't really condone this approach<br>wholeheartedly) where access points and friends are immediately visible

<br>from the Mesh view, until you explain to 5 year olds what the heck<br>wireless is and why it's off-by-default in the first place.<br><br>People traveling in RF-prohibited environments should be the ones who<br>bear the burden of turning off the RF, since not too many of the target

<br>audience is going to ever be flying on a plane or driving by a blasting<br>site.  Plus those people who are flying on planes likely already know<br>that they _need_ to turn off the wireless component, which isn't likely

<br>to be known by the 5 - 10 year old children in Peru who may never been<br>near an airplane anyway.<br><font color="#888888"><br>Dan<br></font><div><div></div><div class="Wj3C7c"><br><br>_______________________________________________

<br>Devel mailing list<br><a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br><a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br></div></div></blockquote>

</div><br>