Re: wlan interface (was: first play with new XO 1.5 machines)
I mean the clock in the 802.11 MAC sublayer. This defines the basis of the timing synchronization function (TSF) which is a core part of 802.11. Without synchronized clocks, nodes cannot communicate. I talked with one of the 802.11 experts I know. He's quite sure that there should be no problem on Atheros hardware at least. He has no problem transmitting arbitrary packets at arbitrary times and no problem receiving packets either. is that you get just one channel at a time. ... The TSF stuff looks like an optimization that you don't really need, except perhaps when sending to a receiver that stops listening at certain times. Lame hardware misses out, no surprise. It's for power saving. When 802.11 is used with an access point, the access point can be asked to buffer up frames for battery powered stations, and send an indication in its periodic beacons. The station wakes up for each beacon and can sleep the rest of the time. In addition, 802.11e provides more power-save modes (APSD). See this paper: http://www.redpinesignals.com/VoWiFi-Implementation-with-Single-Stream-802-11n.pdf I don't think that XO-1 WiFi chips ever did any power saving. Don't know about XO-1.5. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wlan interface (was: first play with new XO 1.5 machines)
On Fri, Oct 30, 2009 at 8:45 PM, John Gilmore g...@toad.com wrote: I talked with one of the 802.11 experts I know. He's quite sure that there should be no problem on Atheros hardware at least. He has no problem transmitting arbitrary packets at arbitrary times and no problem receiving packets either. Now I've talked to 5 experts, including one who was involved in the standardization efforts. They all agree that it should be possible, but all expect driver problems. Firmware can ruin things. The recommended setup is an Atheros chipset with the madwifi drivers. You generally need to get the firmware into promiscuous (sniffer) mode, which is not always documented. You'd be essentially doing VAP (virtual access point) stuff; so VAP is the capability to look for. Marvell generally doesn't support promiscuous mode, but the XO firmware did get that feature added at one point. I don't know if it's still there in the thinmac firmware and the XO 1.5 firmware, but at least the classic XO setup could do it. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wlan interface (was: first play with new XO 1.5 machines)
2009/10/26 Albert Cahalan acaha...@gmail.com: The issue is that A and B are both hosting their own networks, they are both beacon masters, spewing beacons based off their own clocks. How is this any different than the mesh situation? Exactly how the XO-1 mesh functions on this level is frustratingly unknown, but when I did a couple of simple observations once before, the clocks appear to synchronize with the neighbours. Which clock? Do you mean one for the individual bits, or one for packet-level time division? I mean the clock in the 802.11 MAC sublayer. This defines the basis of the timing synchronization function (TSF) which is a core part of 802.11. Without synchronized clocks, nodes cannot communicate. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wlan interface (was: first play with new XO 1.5 machines)
On Thu, Oct 29, 2009 at 12:17 PM, Daniel Drake d...@laptop.org wrote: 2009/10/26 Albert Cahalan acaha...@gmail.com: The issue is that A and B are both hosting their own networks, they are both beacon masters, spewing beacons based off their own clocks. How is this any different than the mesh situation? Exactly how the XO-1 mesh functions on this level is frustratingly unknown, but when I did a couple of simple observations once before, the clocks appear to synchronize with the neighbours. Which clock? Do you mean one for the individual bits, or one for packet-level time division? I mean the clock in the 802.11 MAC sublayer. This defines the basis of the timing synchronization function (TSF) which is a core part of 802.11. Without synchronized clocks, nodes cannot communicate. I talked with one of the 802.11 experts I know. He's quite sure that there should be no problem on Atheros hardware at least. He has no problem transmitting arbitrary packets at arbitrary times and no problem receiving packets either. The only limit is that you get just one channel at a time. I'll check with a couple of the other experts I know. The TSF stuff looks like an optimization that you don't really need, except perhaps when sending to a receiver that stops listening at certain times. Lame hardware misses out, no surprise. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wlan interface (was: first play with new XO 1.5 machines)
On Fri, Oct 23, 2009 at 7:09 AM, Daniel Drake d...@laptop.org wrote: 2009/10/23 Albert Cahalan acaha...@gmail.com: Thus, properly done, the XO labled C might have either of: a. wlan0 to reach A, and wlan1 to reach B (same hardware) b. wlan0, from which wlan0_0 and wlan0_1 are instantiated It can't do this, unless it has 2 independent clocks in the wifi hardware. I do not know of any hardware that does this. The issue is that A and B are both hosting their own networks, they are both beacon masters, spewing beacons based off their own clocks. How is this any different than the mesh situation? C can either talk with A, by finding the beacons, adjusting its own clock to match. (at this point, any frames coming from B will be heard as noise) or it can adjust to B's clock, in order to speak to it (and everyone else who's synchronized to B). At this point, frames coming from A are just noise. Which clock? Do you mean one for the individual bits, or one for packet-level time division? AFAIK, a clock for individual bits is not something you'd keep. The preamble should take care of that. A packet-level clock shouldn't cause the heard as noise issue. If you can't deal with multiple beacon masters spewing beacons based off their own clocks, then mesh should be impossible. BTW, this goes beyond ad-hoc and mesh. I might want to serve as 3 access points and be a client to 7 others. That should work, subject only to channel and interference troubles. (hardware X can do 1 channel in each band, hardware Y only does 1 channel total, and hardware Z can do 2 degraded channels in 1 band) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
wlan interface (was: first play with new XO 1.5 machines)
Daniel Drake writes: Another laptop C comes along A C -- B This laptop can see both of these independent laptops (each having its independent network). It can join one or the other. It cannot join both. Hence this XO can only communicate with A or B, but not both (even though the range is OK), and presenting this choice in the UI would be nasty. This is the result of Linux kernel stupidity. It is thus fixable, at least with soft-mac firmware. We're treating wireless network hardware like wired network hardware, but it's really not the same thing. Ignoring VLAN issues and such, a wired network goes to one other place. A wireless network can go many places at once. Right now, you get one device named something like wlan0. You modify parameters to move this one device about. The proper model is that you instantiate a new instance of the device. A single wlan0 device for the hardware is no good. The wlan0 device could... a. exist only as an icky compatibility hack b. not exist c. be one of many instantiations of the hardware d. be only used for raw 802.11-layer packet injection and sniffing e. be only used for instantiating wireless lan devices Thus, properly done, the XO labled C might have either of: a. wlan0 to reach A, and wlan1 to reach B (same hardware) b. wlan0, from which wlan0_0 and wlan0_1 are instantiated ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wlan interface (was: first play with new XO 1.5 machines)
On Fri, Oct 23, 2009 at 04:54:31PM +0545, Daniel Drake wrote: C can either talk with A, by finding the beacons, adjusting its own clock to match. (at this point, any frames coming from B will be heard as noise) or it can adjust to B's clock, in order to speak to it (and everyone else who's synchronized to B). At this point, frames coming from A are just noise. Aside ... in larger and different radio networks, this problem is addressed by using some form of timing other than one station beaconing. This isn't an option for us here. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wlan interface (was: first play with new XO 1.5 machines)
On Friday 23 October 2009 09:09:31 am Daniel Drake wrote: 2009/10/23 Albert Cahalan acaha...@gmail.com: Thus, properly done, the XO labled C might have either of: a. wlan0 to reach A, and wlan1 to reach B (same hardware) b. wlan0, from which wlan0_0 and wlan0_1 are instantiated It can't do this, unless it has 2 independent clocks in the wifi hardware. I do not know of any hardware that does this. The issue is that A and B are both hosting their own networks, they are both beacon masters, spewing beacons based off their own clocks. C can either talk with A, by finding the beacons, adjusting its own clock to match. (at this point, any frames coming from B will be heard as noise) or it can adjust to B's clock, in order to speak to it (and everyone else who's synchronized to B). At this point, frames coming from A are just noise. I agree. The radio and association limitations in wifi are not so easy to abstract away. A drop in replacement to 802.11s that might be worth looking at is batman- adv[0]. It does proactive routing (in the spirit of Cerebro) at layer 2. [0] http://www.open-mesh.org/wiki/batman-adv Daniel -- -Andrés ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
