diff options
author | Linus Lüssing <linus.luessing@c0d3.blue> | 2023-09-07 03:09:09 +0200 |
---|---|---|
committer | Simon Wunderlich <sw@simonwunderlich.de> | 2023-11-14 08:16:34 +0100 |
commit | 90039133221e33964ccb4a536dad7eb0a372fff7 (patch) | |
tree | f2128719fa18c5f03897e18faf0c40419a58cba1 /drivers/accessibility/Kconfig | |
parent | 07afe1ba288c04280622fa002ed385f1ac0b6fe6 (diff) | |
download | linux-90039133221e33964ccb4a536dad7eb0a372fff7.tar.gz linux-90039133221e33964ccb4a536dad7eb0a372fff7.tar.bz2 linux-90039133221e33964ccb4a536dad7eb0a372fff7.zip |
batman-adv: mcast: implement multicast packet generation
Implement the preparation of a batman-adv multicast packet and use this
under certain conditions.
For one thing this implements the capability to push a complete
batman-adv multicast packet header, including a tracker TVLV with all
originator destinations that have signaled interest in it, onto a given
ethernet frame with an IP multicast packet inside.
For another checks are implemented to determine if encapsulating a
multicast packet in this new batman-adv multicast packet type and using
it is feasible. Those checks are:
1) Have all nodes signaled that they are capable of handling the new
batman-adv multicast packet type?
2) Do all active hard interfaces of all nodes, including us, have an MTU
of at least 1280 bytes?
3) Does a complete multicast packet header with all its destination
addresses fit onto the given multicast packet / ethernet frame and
does not exceed 1280 bytes?
If all checks passed then the new batman-adv multicast packet type will
be used for transmission and distribution. Otherwise we fall back to one or
more batman-adv unicast packet transmissions, if possible. Or if not
possible we will fall back to classic flooding through a batman-adv
broadcast packet.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Diffstat (limited to 'drivers/accessibility/Kconfig')
0 files changed, 0 insertions, 0 deletions