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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox