Hi,

I do not understand what the transmission quality in OGMs is for. From my reading of the RFC draft, route selection is done based on the number of OGMs received for a specific destination within a sliding window of sequence numbers. I did catch a comment in the source code about transmission quality it being used for bidirectional link detection, but there I couldn't find a mention of transmission quality in the draft RFC.

the RFC describes BATMAN III which is outdated since quite a while. In the field you will find BATMAN IV that eliminates numerous problems.

A comprehensive documentation can be found here: http://gitorious.org/batman-adv-doc

Meanwhile we are working on mark V: http://www.open-mesh.org/wiki/2009-12-18-batman-v-outlook

I don't know what is being used for the extra 8 bytes of batman data. I guess the originator and receiver portions of the packet are now 6 byte MAC addresses rather than 4 byte IP addresses. However, this does not account for extra 8 bytes used for BATMAN-ADV.

Please check the dissectors Sven mentionned or use batctl or read the IV-PDF to get an overview about the protocol changes.

In the future, it seems like BATMAN-ADV will get the majority of the developer attention. Other than not having to asign IP addresses, which does seem pretty cool, I am finding it hard to see 'major' advantages of one versus another.

Just to name a few: * protocol independence (IPv4, IPv6, IPX, whatever) * you can run DHCP over your mesh to autoconfig non-mesh clients * roaming for the non-mesh clients * full control over the mesh traffic which enables you to do: bonding / forward error correction / etc * multicast support

This advantage also seems to be slightly offset because it now becomes harder to get gateway information. Is this right?

The gateway problem has been resolved in the trunk (check the mail archives if you are interested in details).

Does working at the data link layer make it easier to extract, neighbour SNR's or bit rates from the wireless driver? What about power control? I'm just throwing ideas around here (I haven't thought this through) but could you have a power save mode whereby if the device is battery powered and has

...

8 neighbours, then slowly reduce the transmission power until neighbours

is < 4 or mains powered batman neighbours is <2.

Extracting the bitrates from the drivers is completely unrelated to the layer the mesh runs on. Whether it will bring advantages to have those information remains yet to be seen.

You don't want to run any kind of mesh on a battery driven device. Even if your mesh protocol saved all the power it could, the wifi power control protocols won't work on adhoc mode. Therefore your device will be drained in no time. Furthermore, you don't need it - with batman-adv you bridge the wifi client into the mesh and get the benefit of the mesh (roaming) plus power saving from the managed network.

Regards, Marek