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 --]
next 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.