Re: [B.A.T.M.A.N.] question regarding gateway_mode server

[Antonio Quartulli <antonio@meshcoding.com>]

[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]

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,


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]