Hi, I would assume that you don't monitor the bug as you didn't answer the questions on irc. So here the part of the IRC communication which needs comments/answers from your side. <T_X> dbeberman-away: hmm, weird. could be a batman specific bug. the first thing I'd have in mind to narrow things down would be to try changing that line: http://git.open-mesh.org/?p=batman- adv.git;a=blob;f=send.c;h=33779278f1b2bfe49155bb9dfadc421305c0c8d7;hb=refs/heads/master#l485 <T_X> from skb_clone to skb_copy <T_X> from looking at the kernel code it seems like skb_clone() is only copying the skb-header, but not the skb-headroom (which we are modifying in send_skb_packet() ) --> jn_ (~jonathan(a)dslb-084-060-236-250.pools.arcor-ip.net) has joined #batman <ecsv_> T_X: and that is a problem.... why? <ecsv_> i don't see which crc is the problem <T_X> ecsv_: you mean it should not be a problem because we for clones we are writing the exact same data in the headroom again? <ecsv_> we should... but yes, it might be a good idea to implement it differently and to test it with skb_copy <ecsv_> it didn't checked the bug report... just assumed that you guessed :) <ecsv_> but still don't see what happened to which crc <ecsv_> we only modify stuff which is related to us.... and not to the encapsulated data <ecsv_> but maybe he meant the ethernet header/wifi stuff before the batman-adv header <ecsv_> but why does he see them? <ecsv_> and why are udp broadcasts fragmented? <ecsv_> we should only have fragmentation for unicast <T_X> ecsv_: I think he's talking about the wifi fragmentation <T_X> not the fragmentation in batman <ecsv_> dbeberman-away: and the only reason why we reject mails on the list is either that you are a known spammer or that you try to send html mails <ecsv_> did you get a reply? <T_X> and I suppose he's doing the sniffing on another interface in monitor mode <T_X> ah, and missed that the "my_skb_head_push()" is in fact making the headroom of the (cloned) skb writeable Kind regards, Sven