Hi, I'm using batman-adv in two different ways. The first is what it is meant for, mesh routing. Apologies if that is not the correct technical term.
The second way I'm using it is to take advantage of broadcasting as a simply floodfill algorithm. All of my nodes transmit to all other nodes on a periodic basis. This is an IPv6 local multicast. I believe this translates to 802.11 MAC FF:FF:FF:FF:FF:FF broadcast address, and everything works.
What I noticed with a network sniffer is that all of the broadcasts were sent with 1 Mbps data rate. For some of my systems, I was able to force the rate to a fixed value: iwconfig wlan0 rate 5.5M for example.
For other systems, the command is accepted but the broadcast rate stays at 1Mbps. The systems that show this are laptops running Intel iwlagn drivers, as well as external USB Linksys (USB600N) devices with Ralink drivers. I tried both the ubuntu kernel 2.6.32-29-generic and also upgraded it to 2.6.39 downloaded directly from kernel.org. I thought that perhaps the ad-hoc fixed rate behavior might not be implemented in the mac80211/cfg80211 in the earlier kernel versions.
I'm running the batman-adv 2011.1.0 release.
What I would really want is some way to flood packets to all of my nodes from all of my nodes on a periodic basis. That is, this is a full mesh connection situation. I would somehow like to still take advantage of higher data rates when nodes are closer to each other. Unfortunately, broadcasts do not have full CSMA/CA, only CSMA, so no feedback to do data rate management (I think).
Does anyone have experience with using the wireless extensions (iwconfig, wpa_supplicant, wpa_cli, etc.), or the newer "iw" commands to get broadcasts to occur at different data rates in ad-hoc mode?
Also: I have tried using unicast packets one for each connected pair and let the batman-adv next-hop routing forward the packets. This does work in a reasonably stable system. The problem is that my nodes have a fairly short data transmit period on the order of 1 second. The nodes are moving around relative to each other also on the order of a few seconds. The routing resolution based on link quality works on the order of 30+ seconds. Thus there can be loss of traffic for a significant period relative to 1 second periods. I did up the OGM rate, 100 msec and even 10 msec just to experiment. This actually seemed to reduce the next-hop decisions, based on the batctl ping results.
From what I can tell reading the algorithms written in the
documentation, all next hop decisions are based on link quality. Link quality using roundtrip metrics of broadcast packets. Broadcast packets are transmitted at 1Mbps in my systems, thus the link quality for 2 nodes at a distance that uses 1 Mbps data rate is the same as the link quality for 2 nodes that could use much higher data rates. Since my objective is to deliver the same packet from each source node to all other nodes, using next-hop routing, I end up with my data rates dropping to the minimum to reach the maximum operational distance nodes, even if there are a bunch of nodes in between.
When I broadcast, the data rate stays constant and as long as a node can hear at least one other node, it gets all the periodic data from all other nodes.
If this makes sense to someone, or I'm missing something obvious, please feel free to clue me in.
My next step is to getting into the transmit control flow in the WLAN device drivers for each piece of hardware and see if I can hard code the transmit data rate for broadcast packets. Usually there is a control header for each transmit frame sent to the hardware/firmware. Finding it, and understanding it without documentation is a challenge I've been hoping to avoid.
Any help would be appreciated. The only help I can offer in return is that I figured out how to change the operating channel on the Broadcom bcm4329 driver for the HTC Desire in ad-hoc mode. There are a couple of minor errors in the wireless extension handling code. Someone might find that useful.
Regards, David Beberman
2011/6/16 David Beberman dbeberman@gmail.com:
Hi, I'm using batman-adv in two different ways. The first is what it is meant for, mesh routing. Apologies if that is not the correct technical term.
The second way I'm using it is to take advantage of broadcasting as a simply floodfill algorithm. All of my nodes transmit to all other nodes on a periodic basis. This is an IPv6 local multicast. I believe this translates to 802.11 MAC FF:FF:FF:FF:FF:FF broadcast address, and everything works.
What I noticed with a network sniffer is that all of the broadcasts were sent with 1 Mbps data rate. For some of my systems, I was able to force the rate to a fixed value: iwconfig wlan0 rate 5.5M for example.
The standard fix the broadcast rate to 1 Mbs for 802.11b and 6 Mbs for 802.11g. Since most of the wireless lan work in mixed mode, the broadcast ends up to be sent at 1Mbs.
For other systems, the command is accepted but the broadcast rate stays at 1Mbps. The systems that show this are laptops running Intel iwlagn drivers, as well as external USB Linksys (USB600N) devices with Ralink drivers. I tried both the ubuntu kernel 2.6.32-29-generic and also upgraded it to 2.6.39 downloaded directly from kernel.org. I thought that perhaps the ad-hoc fixed rate behavior might not be implemented in the mac80211/cfg80211 in the earlier kernel versions.
You can use the command: iw wlan0 set bitrates legacy-2.4 12 18 24 for example to let wlan0 use onbly 12 18 and 24 Mbs, in any case anyhow this applies only to unicast communication.
I'm running the batman-adv 2011.1.0 release.
What I would really want is some way to flood packets to all of my nodes from all of my nodes on a periodic basis. That is, this is a full mesh connection situation. I would somehow like to still take advantage of higher data rates when nodes are closer to each other. Unfortunately, broadcasts do not have full CSMA/CA, only CSMA, so no feedback to do data rate management (I think).
Does anyone have experience with using the wireless extensions (iwconfig, wpa_supplicant, wpa_cli, etc.), or the newer "iw" commands to get broadcasts to occur at different data rates in ad-hoc mode?
I think it is not possible, maybe you can try to hardcode it in the driver code but I don't know if it could work.
Also: I have tried using unicast packets one for each connected pair and let the batman-adv next-hop routing forward the packets. This does work in a reasonably stable system. The problem is that my nodes have a fairly short data transmit period on the order of 1 second. The nodes are moving around relative to each other also on the order of a few seconds. The routing resolution based on link quality works on the order of 30+ seconds. Thus there can be loss of traffic for a significant period relative to 1 second periods. I did up the OGM rate, 100 msec and even 10 msec just to experiment. This actually seemed to reduce the next-hop decisions, based on the batctl ping results. From what I can tell reading the algorithms written in the documentation, all next hop decisions are based on link quality. Link quality using roundtrip metrics of broadcast packets.
The algoritm is not based on RTT but on the number of routing management frame correctly received through the path.
Broadcast packets are transmitted at 1Mbps in my systems, thus the link quality for 2 nodes at a distance that uses 1 Mbps data rate is the same as the link quality for 2 nodes that could use much higher data rates.
This is partially true, it depends on the unicast data rate of the alternative multi-hop path. But if the difference is great (1Mbs vs 54Mbs) you are right.
Since my objective is to deliver the same packet from each source node to all other nodes, using next-hop routing, I end up with my data rates dropping to the minimum to reach the maximum operational distance nodes, even if there are a bunch of nodes in between.
When I broadcast, the data rate stays constant and as long as a node can hear at least one other node, it gets all the periodic data from all other nodes.
The rate of broadcast is constant, it does not depend from BATMAN.
If this makes sense to someone, or I'm missing something obvious, please feel free to clue me in.
My next step is to getting into the transmit control flow in the WLAN device drivers for each piece of hardware and see if I can hard code the transmit data rate for broadcast packets. Usually there is a control header for each transmit frame sent to the hardware/firmware. Finding it, and understanding it without documentation is a challenge I've been hoping to avoid.
Any help would be appreciated. The only help I can offer in return is that I figured out how to change the operating channel on the Broadcom bcm4329 driver for the HTC Desire in ad-hoc mode. There are a couple of minor errors in the wireless extension handling code. Someone might find that useful.
Regards, David Beberman
Someone other surely it is more qualified on this field.
Regards,
Hi!
Am 16.06.2011 00:04, schrieb David Beberman:
The second way I'm using it is to take advantage of broadcasting as a simply floodfill algorithm. All of my nodes transmit to all other nodes on a periodic basis. This is an IPv6 local multicast. I believe this translates to 802.11 MAC FF:FF:FF:FF:FF:FF broadcast address, and everything works.
What I noticed with a network sniffer is that all of the broadcasts were sent with 1 Mbps data rate.
This is the behavior specified in IEEE 802.11 [1], §9.6 (Multirate support): "All frames with multicast and broadcast in the Address 1 field that have a UP of zero shall be transmitted at one of the rates included in the BSSBasicRateSet parameter, regardless of their type or subtype."
The basic rate set seems to often consists only of small rates such as 1 or 2 MBit/s in 11g networks. However, I couldn't find out how to get the basic rates supported by my wifi card or configured in the wireless stack. Does anyone know how to do this?
- Daniel
[1] http://standards.ieee.org/getieee802/download/802.11-2007.pdf
Hi Dan,
So far, with Linux, I have only used the iwconfig and iw tools. For one of the drivers, using iwconfig, I was able to set the data rate, which was used for broadcasts. I could set the data rate to both 802.11b and 802.11g rates. However, the hardware would send a CTS frame and apparently an 802.11g frame with what appears to be corruption giving a CRC error for all 802.11g rates. This only occurred when a node detects the presence of other nodes operating at 802.11b/g, which corresponds to 802.11n coexistence behavior. Not what I was expecting. For other drivers, I was unable to get anything but 1 Mbps broadcasts. As I think this is useful for floodfill types of data traffic requirements, as opposed to unicast or multicast, my next step is to take a look at the Linux MAC80211 layer. This is very much a "corner case" use for mesh networks, but I happen to need it. Still hoping for a simple solution to this.
David
On Thu, Jun 16, 2011 at 5:20 AM, Daniel Seither post@tiwoc.de wrote:
Hi!
Am 16.06.2011 00:04, schrieb David Beberman:
The second way I'm using it is to take advantage of broadcasting as a simply floodfill algorithm. All of my nodes transmit to all other nodes on a periodic basis. This is an IPv6 local multicast. I believe this translates to 802.11 MAC FF:FF:FF:FF:FF:FF broadcast address, and everything works.
What I noticed with a network sniffer is that all of the broadcasts were sent with 1 Mbps data rate.
This is the behavior specified in IEEE 802.11 [1], §9.6 (Multirate support): "All frames with multicast and broadcast in the Address 1 field that have a UP of zero shall be transmitted at one of the rates included in the BSSBasicRateSet parameter, regardless of their type or subtype."
The basic rate set seems to often consists only of small rates such as 1 or 2 MBit/s in 11g networks. However, I couldn't find out how to get the basic rates supported by my wifi card or configured in the wireless stack. Does anyone know how to do this?
- Daniel
[1] http://standards.ieee.org/getieee802/download/802.11-2007.pdf
On Thursday, June 16, 2011 12:04:41 AM David Beberman wrote:
I did up the OGM rate, 100 msec and even 10 msec just to experiment. This actually seemed to reduce the next-hop decisions, based on the batctl ping results.
Did you disable aggregation while using these short intervals ?
My next step is to getting into the transmit control flow in the WLAN device drivers for each piece of hardware and see if I can hard code the transmit data rate for broadcast packets. Usually there is a control header for each transmit frame sent to the hardware/firmware. Finding it, and understanding it without documentation is a challenge I've been hoping to avoid.
The linux wireless list (http://linuxwireless.org/en/developers/MailingLists) might be a more suitable place to discuss this kind of topic.
Regards, Marek
b.a.t.m.a.n@lists.open-mesh.org
-
Daniel Seither -
Daniele Furlan -
David Beberman -
Marek Lindner