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-
<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
I'm trying to extend the Exporter of OpenMesh to put another float
stored at each Vertex to an off or obj file. But the Tutorial on your
website dosn't make it clear i think.
Do I have to extend the the BaseExporter by a Iterator for my float
virtual PVertexIter const_myFloat_begin() = 0;
virtual PVertexIter const_myFloat_end() = 0;
Where do i have to add the code to get these iterators called?
Is there anything else to add?
Thanks in advance
The broadcast flood protection should be reset to its original value
if the primary interface could not be retrieved.
Signed-off-by: Marek Lindner <lindner_marek(a)yahoo.de>
send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/send.c b/send.c
index 76daa46..3377927 100644
@@ -421,7 +421,7 @@ int add_bcast_packet_to_list(struct bat_priv *bat_priv, struct sk_buff *skb)
primary_if = primary_if_get_selected(bat_priv);
- goto out;
+ goto out_and_inc;
forw_packet = kmalloc(sizeof(struct forw_packet), GFP_ATOMIC);
I would like tp propose following corrections for net-next-2.6/2.6.40.
Both are bug fixes. The first one fixes the regression introduced by
"batman-adv: Make bat_priv->primary_if an rcu protected pointer" which
prevented that the attached net_devices could be destroyed because the
references to them were incorrectly counted.
The second one is a bug which may "filled" the broadcast queue when at
the same time primary_if got changed and a broadcast was initiated. The
queue counter were never reduced because there were no actual packets
attached to the the queue.
The following changes since commit 27aea2128ec09924dfe08e97739b2bf8b15c8619:
batman-adv: remove duplicate code from function is_bidirectional_neigh() (2011-05-08 16:10:42 +0200)
are available in the git repository at:
Marek Lindner (1):
batman-adv: reset broadcast flood protection on error
Sven Eckelmann (1):
batman-adv: Add missing hardif_free_ref in forw_packet_free
net/batman-adv/aggregation.c | 14 +++++++++++---
net/batman-adv/send.c | 19 ++++++++++++++++---
2 files changed, 27 insertions(+), 6 deletions(-)
I found a bug playing with my interfaces while bat0 was active.
The bug is described here: http://www.open-mesh.org/issues/148
The steps to reproduce it are reported too.
In a few words, when trying to unregister a device by unloading its module,
the modprobe hangs and in the dmesg I can see this message:
unregister_netdevice: waiting for wlan0 to become free. Usage count = 1
I tried to do some tests and what I observed is that
hard_iface->refcount doesn't reach 0. This means that
hard_iface_free_rcu() is never invoked and dev_put() too.
I hope the information are enough..
..each of us alone is worth nothing..
Ernesto "Che" Guevara
We must prevent that IPPROTO_UDP gets redefined using compat.h.
Otherwise the build will fail when including things like net/addrconf.h
Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
compat.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/compat.c b/compat.c
index 70de376..586898f 100644
@@ -1,3 +1,4 @@