[PATCH batadv 0/2] batman-adv: fix broadcast/multicast "hw csum failure"

Sven Eckelmann <[email protected]> Wed, 10 Jun 2026 14:56:02 +0200
Newsgroups org.open-mesh.lists.batman
Message-ID <[email protected]>
Yesterday, I wanted to test the pending fixes for the next release on the
Freifunk Vogtland server. It was noticed that there was a

    bat-rc: hw csum failure
    skb len=96 headroom=304 headlen=96 tailroom=1328
    mac=(290,14) mac_len=14 net=(304,40) trans=344
    shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
    csum(0xfffffb8a start=64394 offset=65535 ip_summed=2 complete_sw=0 valid=1 level=0)
    hash(0x0 sw=0 l4=0) proto=0x86dd pkttype=2 iif=32
    priority=0x100 mark=0x0 alloc_cpu=1 vlan_all=0x0
    encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)
    dev name=bat-rc feat=0x0000000000004200

during the start of the server. The shown packet (removed here) was just a
simple broadcast packet. A quick check of the logs showed that this problem
was already present before the fixes. The most likely culprit was a
modification of the packets before the local delivery path was received
(see commit 798174b15153 ("batman-adv: fix packet checksum in receive
path") for a better explanation). The steps are

* actually make sure that broadcast packet is unshared before trying to
  write to it
* unchecksum area before modying it and afterwards rechecksum it

This is tested successfully on our servers without any new Oops. And the AI
overlords only complained (until now) about an unrelated [1] TTL
modification.

[1] https://www.open-mesh.org/issues/442

Signed-off-by: Sven Eckelmann <[email protected]>
---
Sven Eckelmann (2):
      batman-adv: ensure bcast is writable before modifying TTL
      batman-adv: fix (m|b)cast csum after decrementing TTL

 net/batman-adv/routing.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 62 insertions(+), 2 deletions(-)
---
base-commit: 385b248dd4e46c4ce022adeb1b13e547d1954901
change-id: 20260610-ip_checksum-4969d31241b5

Best regards,
--  
Sven Eckelmann <[email protected]>