On 05/02/14 20:52, Daniel wrote:

Hi!

Is there a way how I can prevent a local DHCP-server from replying to non-gw_mode-client's DHCP requests?

No. Batman-adv can only act as "DHCP facilitator" but does not act as a firewall. I assume you have read the documentation about gateway mode at this link:

http://www.open-mesh.org/projects/batman-adv/wiki/Gateways

The situation is that we got a central DHCP server on the mesh which should be used by all nodes which do not have gw_mode set. In my understanding, setting gw_mode to 'server' on another local DHCP server should prevent that DHCP server from receiving (and thus replying to) requests from clients with gw_mode set to 'off',

No, it does not work like that. As I said before batman-adv acts like a facilitator if the GW feature is enabled (server and client) but if it is off then DHCP packets are delivered to the entire network like any normal broadcast packet. I think this is explained in the doc too.

however, it seems like the local gw_mode==server node occasionally

replies to gw_mode==off clients (seems like the usual more-than-one-dhcp-server-on-a-subnet race condition)

Correct, because the broadcast packet reaches this node eventually.

I'm aware that this could probably be solved using ebtables, however, due to the high performance impact and ugliness of ebtables, I'd prefer another way to fix it.

ebtables is not the only solution, iptables can be used to filter any IP packet as well (which I guess is what you have in your network). For more details about how to use this tool I'd suggest you to read its doc directly (about kernel and userspace usage).

Am I getting something wrong regarding the intended behavior of gw_mode==server?

I think I explained this right above :)

If needed, I can write a patch to implement that functionality and have a gw_mode==exclusive_server or something like that in case the current behavior is actually intentional.

This is not an easy task to address because you have to understand from which node the packet is coming from and with the current infrastructure this is not easy: consider that a client might be moving from node to node.

In conclusion I think that any possible implementation would add quite some complexity that is absolutely not wanted given that there are other tools in Linux which can properly address the situation.

Cheers,