All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven@narfation.org>
To: dbeberman@aicas.com
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: [B.A.T.M.A.N.] batman-adv bug 149: odd broadcast behavior -- generated CRC errors
Date: Fri, 20 May 2011 09:55:26 +0200	[thread overview]
Message-ID: <201105200955.27323.sven@narfation.org> (raw)

[-- 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 --]

             reply	other threads:[~2011-05-20  7:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20  7:55 Sven Eckelmann [this message]
2011-05-20  8:37 ` [B.A.T.M.A.N.] batman-adv bug 149: odd broadcast behavior -- generated CRC errors Sven Eckelmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201105200955.27323.sven@narfation.org \
    --to=sven@narfation.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=dbeberman@aicas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.