It is possible that the mac_len is not properly exported because of strange device configuration (this behaviour has been observed when using batman-adv on top of a vlan interface). Therefore it is needed to explicitly recompute it at the very beginning of the rx path.
This is done by appending the recompute function to the skb_share_mac() function, hence the "dirty hack" in the subject. We expect this problem to be fixed in linux 3.8 and above.
Reported-by: Antonio Quartulli ordex@autistici.org Signed-off-by: Simon Wunderlich siwu@hrz.tu-chemnitz.de ---
this is a rewrite of Antonios patch "batman-adv: recompute mac_len at the beginning of the rx path". It is intended to fix the issue for out-of-kernel releases, without hurting the in-kernel code too much. Obviously, this patch won't go upstream into the kernel. --- compat.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
diff --git a/compat.h b/compat.h index 14969e0..dca9685 100644 --- a/compat.h +++ b/compat.h @@ -159,4 +159,19 @@ static inline void eth_hw_addr_random(struct net_device *dev)
#endif /* < KERNEL_VERSION(3, 5, 0) */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 8, 0) + +/* hack for not correctly set mac_len. This may happen for some special + * configurations like batman-adv on VLANs. + * + * This is pretty dirty, but we only use skb_share_check() in main.c right + * before mac_len is checked, and the recomputation shouldn't hurt too much. + */ +#define skb_share_check(skb, b) \ + skb_share_check(skb, b); \ + if (skb) \ + skb_reset_mac_len(skb) + +#endif /* < KERNEL_VERSION(3, 8, 0) */ + #endif /* _NET_BATMAN_ADV_COMPAT_H_ */