Question concerning batman-adv bug #173 "Mesh packets on bat0"

Message ID 2282256.5kOumjqyC5@voltaire (mailing list archive)
State RFC, archived
Headers

Commit Message

Marek Lindner Feb. 18, 2015, 11:26 a.m. UTC
  On Wednesday, February 18, 2015 08:35:49 Andreas Pape wrote:
> I'm interested if there is any progress concerning the bug entry #173 (
> http://www.open-mesh.org/issues/173). 
> 
> I'm currently observing something similiar on an embedded system running 
> an older kernel 2.6.32.26. Batman-adv versions up to 2013.1.0 work 
> flawlessly out of the box. All newer versions show the phenomenon 
> described in bug #173. 
> In my case I found out, that the batadv_batman_skb_recv function is never 
> called again as soon as I add bat0 to the bridge interface I use. 
> If I use the bat0 interface outside a bridge, everything works fine up to 
> the latest version I tested (which was 2014.4.0) even with the old kernel 
> version. 

Can you please try the attached patch and check whether it makes any 
difference? If the symptoms are the same, please provide step-by-step 
instructions how you create / configure your interfaces.

Thanks,
Marek
  

Comments

Andreas Pape Feb. 18, 2015, 12:28 p.m. UTC | #1
Hi,

I adapted your patch to batman-adv-2014.4.0 without success. I got the 
additional issue that with the patched version of batman-adv I was not 
able to destroy the virtual wireless interface anymore used fot the adhoc 
connection over which I try to use batman-adv (error message was: 
unregister_netdevice: waiting for ath0 to become free). 

With the unpatched 2014.4.0 I did the following test on two of my devices:

1. created a virtual wireless interface ath0 in adhoc mode
2. iwconfig ath0 essid TEST
3. iwconfig ath0 channel 40
4. ifconfig ath0 up
5. batctl if add ath0

After this the two devices connected and I could see the repective 
neighbor via the batctl o command on both devices. So far so good. 
But I can see via batctl td bat0 OGM packets sent with the MAC address of 
the wlan interface of the device itself and also from the neigbour this 
device is connected to via wlan. Is this OK?

6. Generating a bridge interface via brctl addbr br0
7. add bat0 interface to bridge via brctl addif br0 bat0

As soon as I do this, the batadv_batman_skb_recv isn't called anymore 
(I've put a printk at the beginning of that function for debugging). 
Furthermore batctl o shows that the mesh communication starts timing out 
(last seen time for the originator/neighbor exceeds the ogm send interval 
and increases continuously).

The interesting point in this state is, that batctl td bat0 still shows 
the reception of ogm messages from the neighbour and from the own wlan 
interface as mentioned above.

As mentioned I use a kernel version 2.6.32.26 and batman-adv/batctl 
versions up to 2013.1.0 work with the same configuration steps. 

Thanks for the support,
Andreas





Von:    Marek Lindner <mareklindner@neomailbox.ch>
An:     The list for a Better Approach To Mobile Ad-hoc Networking 
<b.a.t.m.a.n@lists.open-mesh.org>, 
Datum:  18.02.2015 12:28
Betreff:        Re: [B.A.T.M.A.N.] Question concerning batman-adv bug #173 
"Mesh   packets on bat0"
Gesendet von:   "B.A.T.M.A.N" <b.a.t.m.a.n-bounces@lists.open-mesh.org>



On Wednesday, February 18, 2015 08:35:49 Andreas Pape wrote:
> I'm interested if there is any progress concerning the bug entry #173 (
> http://www.open-mesh.org/issues/173). 
> 
> I'm currently observing something similiar on an embedded system running 

> an older kernel 2.6.32.26. Batman-adv versions up to 2013.1.0 work 
> flawlessly out of the box. All newer versions show the phenomenon 
> described in bug #173. 
> In my case I found out, that the batadv_batman_skb_recv function is 
never 
> called again as soon as I add bat0 to the bridge interface I use. 
> If I use the bat0 interface outside a bridge, everything works fine up 
to 
> the latest version I tested (which was 2014.4.0) even with the old 
kernel 
> version. 

Can you please try the attached patch and check whether it makes any 
difference? If the symptoms are the same, please provide step-by-step 
instructions how you create / configure your interfaces.

Thanks,
Marek
[Anhang "0001-do-not-call-master-netdev_ops-ndo_init.patch" gelöscht von 
Andreas Pape/Phoenix Contact] [Anhang "signature.asc" gelöscht von Andreas 
Pape/Phoenix Contact]
  

Patch

From 97dd927aca3747e1a054303638011f93373c96bf Mon Sep 17 00:00:00 2001
From: Marek Lindner <mareklindner@neomailbox.ch>
Date: Wed, 18 Feb 2015 19:24:06 +0800
Subject: [PATCH] do not call master->netdev_ops->ndo_init

---
 hard-interface.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hard-interface.c b/hard-interface.c
index fbda6b5..010a403 100644
--- a/hard-interface.c
+++ b/hard-interface.c
@@ -349,7 +349,7 @@  batadv_hardif_deactivate_interface(struct batadv_hard_iface *hard_iface)
  * is free'd and master can correctly change its internal state.
  * Return 0 on success, a negative value representing the error otherwise
  */
-static int batadv_master_del_slave(struct batadv_hard_iface *slave,
+/*tatic int batadv_master_del_slave(struct batadv_hard_iface *slave,
 				   struct net_device *master)
 {
 	int ret;
@@ -362,7 +362,7 @@  static int batadv_master_del_slave(struct batadv_hard_iface *slave,
 		ret = master->netdev_ops->ndo_del_slave(master, slave->net_dev);
 
 	return ret;
-}
+}*/
 
 int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface,
 				   const char *iface_name)
@@ -403,10 +403,10 @@  int batadv_hardif_enable_interface(struct batadv_hard_iface *hard_iface,
 	/* check if the interface is enslaved in another virtual one and
 	 * in that case unlink it first
 	 */
-	master = netdev_master_upper_dev_get(hard_iface->net_dev);
+	/* master = netdev_master_upper_dev_get(hard_iface->net_dev);
 	ret = batadv_master_del_slave(hard_iface, master);
 	if (ret)
-		goto err_dev;
+		goto err_dev; */
 
 	hard_iface->soft_iface = soft_iface;
 	bat_priv = netdev_priv(hard_iface->soft_iface);
-- 
2.1.4