Hi there everyone,

> Glad to see that this hack could work, but indeed I am not sure it's the
> best way to solve your problem I hope you can test the changed code longer
> to see if it's stable. 
Nodes are running in a stable way for almost three days now, and under 
constant ping traffic, about 30 incoming packets/sec. I recorded the 
routes that were established, server is currently taring the results for me...

> Maybe (mpath->flags & MESH_PATH_SN_VALID) is not
> the source of the problem. The implementation problem here is below:
> (1)node N first received a PREQ with originator STA A, and the route of A
> in N is updated with the MESH_PATH_SN_VALID=1
> (2)node N secondly received
> a PREQ with tx node STA A(NOW STA A is not orginator!!), and the route of
> A in N is updated with the MESH_PATH_SN_VALID=0
> if step (1) and (2) occur in turn, a PREQ can be retransmitted many times
> until memory of relative nodes empty or TTL of PREQ reaches 0.
> Then the problem you saw happened.

* @MESH_PATH_SN_VALID: the mesh path contains a valid destination sequence 
number

If I understand correctly, the second step invalidates the Route to any node 
that forwards a PREQ?
This doesn't sounds right, so maybe the correct fix would be keeping the route 
as it is:

--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -449,7 +449,6 @@ static u32 hwmp_route_info_get(struct 
ieee80211_sub_if_data *sdata,
 
                if (fresh_info) {
                        mesh_path_assign_nexthop(mpath, sta);
-                       mpath->flags &= ~MESH_PATH_SN_VALID;
                        mpath->metric = last_hop_metric;

After a quick test, this also fixes the problem for me!

> I still did some test with BATMAN and 802.11s, but something bother me
> much: Why BATMAN is much better than 802.11s When the originator and the
> target is several hops  away(in my test 6 or 7 hops), the performance of
> BATMAN is much better than 802.11s.

Define Performance. Do you mean packet loss, bandwidth, latency?
BATMAN, being a proactive protocol, has the advantage of always having a route 
to your destination, but the price to pay is constant background traffic on 
your network, that gets heavier the more nodes you have.

> Do you mind share some test result and the analyze of BATMAN compared with
> 802.11s with me?

As soon as we got all our results verified, I can post some first pieces of 
possibly interesting stuff.
In the long run, we are going to evaluate how attacks can impact mesh 
network performance. We have built attack tools for AODV, BATMAN and 802.11s 
networks, and we started working on building an IDS for those.
As soon as our work is finished I'll make sure that our findings will be made 
public somehow. At least I made sure that our attack tools are GPLed ;)

Greetings
ASPj
_______________________________________________
Devel mailing list
Devel@lists.open80211s.org
http://open80211s.com/mailman/listinfo/devel

Reply via email to