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 <[EMAIL PROTECTED]> wrote: > On Thu, 2008-01-17 at 13:30 -0500, Michail Bletsas wrote: > > Hal Murray <[EMAIL PROTECTED]> 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@lists.laptop.org > http://lists.laptop.org/listinfo/devel >
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel