This is probably well understood by the engineers working on the Linux Wireless layer and those on the batman-adv project. I'm just a user trying to figure out what the best use of the protocol is for my application. This is a follow up explanation for the behavior I have been seeing.
I walked through the MAC80211 layer. There are rate control algorithms that are loaded as modules. Currently there seems to be two of them, but more can be registered. Each of these appears to check individually for multicast and broadcast packets. Each broadcast packet uses the lowest basic rate available. The multicast packets use a basic rate from the BSSBasicRateSet that can be user defined. I believe, but have not verified, that batman-adv uses the broadcast address (FF:FF:FF:FF:FF:FF) for broadcast and multicast packets. The MAC80211 layer then uses the lowest basic rate available, which in my case, with a mixed b/g/n is 1 Mbps.
For what I am trying to do, this is a problem. However, I would not call this a problem with batman-adv or MAC80211 in general. I can obviously do a hack for my own uses that looks into the packet in the MAC80211 layer to determine if it is a batman-adv broadcast packet and use a different rate. Maybe I can change batman-adv to use a multicast MAC address and pick up the fixed multicast rate that I can configure in MAC80211. None of this should be a general change for either module.
Also, last time I looked through the batman-adv code, it did not have a multicast implementation from what I could tell. Seemed like multicast was mapped onto a general broadcast approach. Since my application requires all nodes to send to all other nodes in the system (full mesh), it seemed like broadcast was the best solution, and the docs I read said the same thing.
Just thought I'd post a follow up on the broadcast data rate issue in case anybody reads through an archive on this, and wanted to see any resolution to the questions.
Also, I saw a question about whether I had turned on aggregation when I increased the OGM rate from 1000 to 100 msecs. Apologies, but I do not remember. I believe I tried it both ways. I was hoping for a decision to go to a multi-hop route would occur faster with a higher OGM rate, when I was using unicast UDP traffic, and my nodes were moving apart. Instead, I found that the decision to go to multi-hop route appeared to take longer. Could easily have been configuration and user error on my part. I was using the batctl ping with the routing flag to see what the route to look at the behavior.
Regards, David Beberman