[B.A.T.M.A.N.] batman-adv bug 149: odd broadcast behavior -- generated CRC errors

[B.A.T.M.A.N.] batman-adv bug 149: odd broadcast behavior -- generated CRC errors

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 2051 bytes --]

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@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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] batman-adv bug 149: odd broadcast behavior -- generated CRC errors

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 1342 bytes --]

Sven Eckelmann wrote:
> 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.
[...]

Just talked to Marek and we both are a little bit irritated by following part 
of your first "mail":

> > Further, if the UDP packet is large enough to fragment into 2 packets, a
> > total of 6 packets are  broacast, with only the very last packet being
> > broadcast without error.

We don't know what fragmentation you are talking here. batman-adv doesn't 
fragment the broadcast packet, wifi shall not fragment the broadcast packet:

"only mpdus with a unicast receiver address shall be fragmented. 
broadcast/multicast frames shall not be fragmented even if their length 
exceeds dot11FragmentationThreshold" - ieee802.11-2007 page 255

So the only fragmentation seems to be the IP(v6) fragmentation - and this 
would mean that batman-adv only sees two independent packets which it 
rebroadcasts complete independent - therefore it doesn't make any sense that 
only the last of 6 packets isn't destroyed by the resend mechanism.

Could you please exactly tell us on which layer and which situation you 
experienced what behaviour and how you did your measurements.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]