Antwort: Re: Question concerning batman-adv bug #173 "Mesh packets on bat0"
Commit Message
On Wednesday, February 18, 2015 13:28:27 Andreas Pape wrote:
> 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).
It is very possible that the supplied patches have side effects. Right now, I
am trying to figure out which part of the code introduced with 2013.2.0 causes
the malfunction. I prepared some more patches which deactivate more code, most
notably rtnl code added with 2013.2.0. Please give it a try and let me know
how it goes.
>
> 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.
At this point the mesh is working to your expectation ? Can you transport
payload across the mesh ? If so, this is a deviation from #173 - wouldn't you
agree ?
> 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?
Yes, batman-adv continues to use the mac addresses of the interfaces you
configure.
Cheers,
Marek
Comments
>At this point the mesh is working to your expectation ? Can you transport
>payload across the mesh ? If so, this is a deviation from #173 - wouldn't
you
>agree ?
Before adding bat0 to the bridge br0 I can communicate via the mesh
interface. I configured ip addresses for the bat0 interfaces on my devices
and the ping worked without problems. But I understood from #173 that
pinging was possible in that case, too. I'm referring to #173 because I
can see the ogm messages received via wlan also at the bat0 interface,
which was not the case in 2013.1.0 and earlier - if I remember my tests
correctly...
In the meantime I found out that not only batman-adv stops receiving the
ogm messages at ath0 but also the wpa_supplicant does not receive EAPOL
frames any more as soon as bat0 is attached to the bridge br0 if I try to
use WPA with the mesh interface (wpa_supplicant -i ath0). But I can see
the EAPOL frames at the bridge interface br0 (via batctl td br0). Strange.
I'll come back to you as soon as I have tested your latest patches.
Thanks for your support,
Andreas
Hi Marek,
good news: the sum of the three patches you sent solved the problem as far
as I have tested yet. Now bat0 works in combination with the bridge and
also ethernet traffic is bridged into the mini-mesh setup I use correctly.
Furthermore there are no ogm messages visible anymore at bat0 (with the
command batctl td bat0).
Do you see a chance to add these changes to the compatibility code for
older kernels (I guess for kernels < 2.6.39)?
Thanks for the excellent help,
Andreas
On Wednesday, February 18, 2015 16:22:18 Andreas Pape wrote:
> good news: the sum of the three patches you sent solved the problem as far
> as I have tested yet. Now bat0 works in combination with the bridge and
> also ethernet traffic is bridged into the mini-mesh setup I use correctly.
> Furthermore there are no ogm messages visible anymore at bat0 (with the
> command batctl td bat0).
>
> Do you see a chance to add these changes to the compatibility code for
> older kernels (I guess for kernels < 2.6.39)?
Sounds like we are on a good path! Glad to hear that!
Ultimately, we want to fix the problem and support the older kernels correctly.
We still don't know what exactly created the problem. Can you try the patches
one-by-one and let me know if a single also fixes the compat issue ? The first
patch you already tried - remains patch 2 and 3.
Cheers,
Marek
Hi Marek,
I reverted the changes step by step starting with patch
0002-remove-netdev_calls.patch, as patch 1 did not help and patch 3
containes in compat.h and soft-interface.c, I tried out myself earlier
today.
The essential call is in patch 2 as assumed. As soon as I add the
netdev_master_upper_dev_link call again to the compilable code, the
problem starts to occur (mesh doesn't work as soon as bat0 is added to the
bridge, ogm packets can be seen at bat0). It seems that this call behaves
in older kernels different compared to newer ones.
I haven't tried to add all the other excluded parts again except for the
netdev_master_upper_dev_link call. If you are interested I can test this
tomorrow, too.
Regards,
Andreas
From 05f48d1e40e55097ac960dc2a8a50d594cf967a8 Mon Sep 17 00:00:00 2001
From: Marek Lindner <mareklindner@neomailbox.ch>
Date: Wed, 18 Feb 2015 21:44:02 +0800
Subject: [PATCH 3/3] remove ndo workarounds
---
compat.h | 14 --------------
soft-interface.c | 2 --
2 files changed, 16 deletions(-)
@@ -191,20 +191,6 @@ static inline int batadv_param_set_copystring(const char *val,
#define kstrtoul strict_strtoul
#define kstrtol strict_strtol
-/* Hack for removing ndo_add/del_slave at the end of net_device_ops.
- * This is somewhat ugly because it requires that ndo_validate_addr
- * is at the end of this struct in soft-interface.c.
- */
-#define ndo_validate_addr \
- ndo_validate_addr = eth_validate_addr, \
-}; \
-static const struct { \
- void *ndo_validate_addr; \
- void *ndo_add_slave; \
- void *ndo_del_slave; \
-} __attribute__((unused)) __useless_ops1 = { \
- .ndo_validate_addr
-
#define ndo_del_slave ndo_init
#define ndo_init(x, y) ndo_init - master->netdev_ops->ndo_init - EBUSY
@@ -874,8 +874,6 @@ static const struct net_device_ops batadv_netdev_ops = {
.ndo_set_rx_mode = batadv_interface_set_rx_mode,
.ndo_start_xmit = batadv_interface_tx,
.ndo_validate_addr = eth_validate_addr,
- .ndo_add_slave = batadv_softif_slave_add,
- .ndo_del_slave = batadv_softif_slave_del,
};
/**
--
2.1.4