The current condition actually does NOT consider bonding when the
interface the packet came in from is the soft interface, which is the
opposite of what it should do (and the comment describes). Fix that and
slightly simplify the condition.
Reported-by: Ray Gibson <booray(a)gmail.com>
Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de>
routing.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/routing.c b/routing.c
index 35f76f2..6648f32 100644
@@ -443,11 +443,13 @@ batadv_find_router(struct batadv_priv *bat_priv,
router = batadv_orig_router_get(orig_node, recv_if);
+ if (!router)
+ return router;
/* only consider bonding for recv_if == BATADV_IF_DEFAULT (first hop)
* and if activated.
- if (recv_if == BATADV_IF_DEFAULT || !atomic_read(&bat_priv->bonding) ||
+ if (!(recv_if == BATADV_IF_DEFAULT && atomic_read(&bat_priv->bonding)))
/* bonding: loop through the list of possible routers found
Does anyone knows how we can read data from batman-adv transmission
buffer. before it transmits. Can we change the buffer ?
Any details about the way batman-adv is using the buffer is valuable.
Please update me.
thanx in advance
I'm experiencing some issues where clients connected to a batman node
(through a wired interface) are expiring from the local translation
table after a period of inactivity. I'm guessing this is an
intentional feature to support roaming but I'm wondering if there is a
way to stop this behavior for certain MAC addresses. Some more detail
of my setup:
* I have multiple mesh nodes named pico9, pico17, pico24, pico41, etc...
* Each node is running BATMAN 2014.2.0 attached to a wireless device.
* Each node is also bridging the batman device with its local ethernet device.
* A subset of the nodes are then connected to the same wired backbone,
lets say pico9/17/24 are all on this backbone.
* I have my laptop also connected to the backbone and I am able to
successfully connect to any of the BATMAN nodes (over the wired
backbone or to other nodes via the wireless mesh).
pico41 (not on the backbone) has a wired client connected to it, lets
call it clientA
I can initially connect to clientA from my laptop and it shows up
correctly in pico41's local translation table. However if I do not
continually send data (ping, ssh, etc) between my laptop and clientA,
I see the "last seen" column of pico41's local translation table entry
increase. Eventually, clientA is removed from the table and I am not
able to connect to it (ping or ssh) until I "do something" to trigger
some traffic from clientA onto the mesh network. This is problematic
because it requires either physically accessing clientA (not practical
in our application) or manually ssh'ing into the node running batman
and then connecting to clientA (makes for a challenging use-case)
Is this expiration from the local translation expected?
I've thought of a few hacks (make certain entries in the local
translation table permanent, have a script on clientA which
continually generates traffic) but I'm hoping someone else has thought
about this same problem.
Anyone have any recommendations for a good dual radio mesh node for
batman-adv that won't break the bank? I'm looking at having wired
clients, but two mesh radios to keep throughput high. 802.11n radios
thanks for testing.
Please don't send HTML mails to the mailing list, they will get rejected.
On Monday 13 October 2014 08:26:59 syedmoulana47 wrote:
> I am using batman-adv: 2012.5.0. I tried with version 2014.3.0 also.
> Even without enabling bonding sometimes I can see simultaneous outbound udp
> traffic in both interfaces wlan0 and wlan1.
> I will try with the patch and update.
> Sent from my Xiaomi
> On 11 Oct 2014 03:03, Simon Wunderlich <sw(a)simonwunderlich.de> wrote:
> Hey Syed,
> which version of batman-adv are you using?
> Please note there is a fix for a bonding problem which hasn't been merged
please merge it manually for your tests (assuming you are using a
> recent version)
> Also bonding has nothing to do with fragmentation - the idea of bonding is
> that the packets should not be split, but get sent interleaved over the
> interfaces, e.g.
> * wlan 1 - packet 1
> * wlan 2 - packet 2
> * wlan 1 - packet 3
> * wlan 2 - packet 4
> * etc ...
> To have a real gain from that, the two links must be equally good quality.
> Also deep queues in the driver may cause reordering of packets which will
> upset TCP. The best results I've seen in the past were 50% performance gain
> over a single link, but I didn't try it out in real world scenarios lately.
> On Tuesday 07 October 2014 17:27:50 syed moulana wrote:
> > hi
> > I tested the throughput between point to point mesh nodes using single
> > and 2 radios.
> > 1. Using single radio (ch 5180) the resulting throughput for HT40+
> > TCP max 250mbit/s
> > UDP - max 320mbit/s
> > 2. Using 2 radios with and without batctl bonding enabled (ch 5180 for
> > wlan0, ch 5785 for wlan1), the resulting throughput for HT40+ is same.
> > with batctl bonding and fragmentation enabled I believed I
> > should be getting 50% gain in througput.
> > When I monitor the wlan0 and wlan1 interfaces using batctl tcpdump
> > -p 4 wlanx I can see that iperf data are interleaved.
> > There is no splitting of data frames into 2 wireless interfaces.
> > Please advice
> > Tq
> > Syed