Re: [PATCH RFC batadv 0/5] batman-adv: allow to specify limits for remote learned objects

["Linus Lüssing" <linus.luessing@c0d3.blue>]

On Sat, May 16, 2026 at 02:35:17PM +0200, Sven Eckelmann wrote:
> There are some concerns that an external entity could spam the batman-adv
> related interfaces with random mac addresses. The batman-adv would use more
> and more resources to safe things like neighbors, originators, TT, ... and
> would at some point run out of resources.
> 
> One idea is to limit the number of entries for each resource type could
> have. Things which might need limits
> 
> * orig_node
> * neigh_node
> * tt_local_entry
> * dat_entry
> * bla_backbone_gw
> * bla_claim
> 
> Things which are limited by other things (maybe)
> 
> * hardif_neigh_node
> * gw_node
> * orig_node_vlan
> * orig_info
> 
> Unknown how to handle overly large tt_global_entries:
> 
> * tt_global_entry

For tt_global_entry I think we are currently bound by MTU size and
the maximum of 16 fragments? So ~2000 entries? Which in an IPv6
enabled network, due to one multicast TT entry for each IPv6 address,
would maybe be ~500 hosts. Which isn't much already when considering
that people bridge larger TP-Link Omada / Ubiquiti UniFi setups into
batman-adv at least at Freifunk.

> This approach is also used for the bridge since commit bdb4dfda3b41 ("net:
> bridge: Track and limit dynamically learned FDB entries"). And it is also
> disabled by default.

I agree that it would make sense to agree on similar approaches
for the Linux bridge and batman-adv.

> For the moment, I just want to demonstrate how this might work with some
> example code. I didn't invest any time to actually check out the other
> items in the list. So, please consider these lists as vague suggestions.

Some more, vague thoughts/ideas on what to do when hitting limits:

We now have this new multicast packet type. And have introduced
these "want_all_*" flags. We could also introduce such flags for
unicast. And have a unicast packet delivered to multiple nodes
via the batman-adv multicast packet type.

We could do more "aggregation" of addresses and more broad,
opportunistic delivery when hitting limits.

This could also be useful if some host (accidentally or not)
was using the same MAC address as another host, maybe. To treat
such a unicast MAC address like a multicast one then.


I also would be interested in aggregating/absorption/handover of other
originator('s flags + TT entries) when a node is only connected
via one other node. So that a neighbor node takesover the
responsibility, to save OGM traffic. We have a lot of such leaf
nodes with a single connection in Freifunk setups and could probably
save 2/3 of the OGM traffic by that. And this could be useful for singular nodes with a
cellular modem, to avoid having constant, costly OGM streams to them, by
transparantly, within batman-adv switching them from a full "originator mode",
to a leightweight "TT client mode" with a few ELP hellos or so.


tl;dr: hop-by-hop auto-aggregations should make it harder for an attacker
to DoS from a single position in the network?

Regards, Linus