Open-Mesh » batman-adv

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260821094813.201800-1-sw%40simonwunderlich.de?part=6

Discovered by: opus-5 · Missed by: gpt-5-6-sol, sashiko-gemini · Confirmed by: gpt-5-6-sol
This is a pre-existing issue and not caused by this patch, but while the
priority handling is being looked at: should the multicast forwarding path
also set skb->priority?

At this commit batadv_skb_set_priority() is only called from three places:

>   batadv_interface_tx()        mesh-interface.c, offset 0
>   batadv_route_unicast_packet() routing.c, offset hdr_len
>   batadv_recv_bcast_packet()   routing.c, offset sizeof(struct batadv_bcast_packet)
> 

net/batman-adv/multicast_forw.c has no call at all, and
batadv_recv_mcast_packet() in net/batman-adv/routing.c re-forwards the
packet without deriving the priority:

>     mcast_packet = (struct batadv_mcast_packet *)skb->data;
>     if (!batadv_skb_decrement_ttl(skb))
>         goto free_skb;
> 
>     tvlv_buff = (unsigned char *)(skb->data + hdr_size);
>     tvlv_buff_len = ntohs(mcast_packet->tvlv_len);
>     ...
>     ret = batadv_tvlv_containers_process(bat_priv, BATADV_MCAST, NULL, skb,
>                          tvlv_buff, tvlv_buff_len);
> 

whereas the equivalent BATADV_BCAST re-broadcast path in
batadv_recv_bcast_packet() does:

>     batadv_skb_set_priority(skb, sizeof(struct batadv_bcast_packet));
> 
>     /* rebroadcast packet */
>     ret = batadv_forw_bcast_packet(bat_priv, skb, 0, false);
> 

On a forwarding node the offset for the mcast path would be
sizeof(struct batadv_mcast_packet) + ntohs(mcast_packet->tvlv_len). Is the
omission intentional, or do forwarded BATADV_MCAST frames leave the node
with the received skb->priority (typically 0) rather than the value in the
256..263 range that batadv_skb_set_priority() documents for the outgoing
wifi hard interface? The driver-side queue selection effect was not traced
end to end here, so this is only an observation about the difference
between the two forwarding paths.