Hi* You are splitting up the VLANs and I did not quite get the reason. In the
document you state the number of OGMs will be decreased. Whether it decreases
or not heavily depends on the network attached to these VLANs. How does the
topology look like ? May be I overlooked that section ?

Well, I didn't mention it, but the reason for splitting the lan ports into VLANs is an approach for using bat-adv on boxes in a partially wired environment (indoor installations with some ethernet wires). So, yepp, you're right, it depends on the network topology. In my case I am using some of the LAN connections to link the boxes among each other. So I think, it's a good approach to seperate the lan ports and to let bat-adv bridge the frames. Correct me, if it's wrong.

* The vis-advanced daemon is not necessary here because the kernel module has
the server built-in. All you need to do is activating a server (echo "server"
> /proc/net/batman-adv/vis) which allows you to retrieve the information via
cat /proc/net/batman-adv/vis. The vis-advanced daemon goes together with
batman-adv-userspace which is the user space implementation of the layer 2
approach. Its a bit confusing - we have to think about how to clean it up ..

Yepp, you're right. I've documented the vis stuff beeing not sure if it's working this way on layer 2. Simon answered all of my questions so now it's time for me to write down the bat-adv-kernel way ;-) He gave me some very interesting hints to collect the data from outside the mesh like polling /proc/net/batman-adv/vis. I think it's a good challenge for me for this weekend to set up a nice solution to collect the data on a central box outside the mesh and visualize it. I have some experiences with JSON, so Iwould use it as exchange format. Well, patching s3d to accept MAC- instead of IP-addresses seems to be a nice solution too.

Regards,
Chris