Hi there
> 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...
Nice work!!
> * @MESH_PATH_SN_VALID: the mesh path contains a valid destination sequence
> number
It really mens this,but indeed I think it's like a lock for modification of
sequence number.
If MESH_PATH_SN_VALID==1, sequence number can be modified
If MESH_PATH_SN_VALID==0, sequence number can not be modified
In fact ,I have not found any other function of MESH_PATH_SN_VALID besides the
lock scheme
What do you think?
>If I understand correctly, the second step invalidates the Route to any node
>that forwards a PREQ?
In my opinion the second step invalidates the sequence number but not the route,
the route can still be active.
> 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!
Great! This can also fix that problem. But pay attention to MESH_PATH_SN_VALID,
if you fix the problem like this, MESH_PATH_SN_VALID cannot be modified to 0 at
any place in the code(See Kernel 3.0),
Do you think MESH_PATH_SN_VALID is still useful or not in this situation?
I think maybe it is not useful anymore.
> 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.
Yes, what i am concerning is packets loss and latency. In my test, the packets
loss
of BATMAN is 4 or 5 times better than that of 802.11s, so is latency. I used
Wireshark to
capture packets and found out that PREQs may loss between two nodes when ping
succeed.
This is very weird and I do not know why....
Have you found this ?
> 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 ;)
Very good!
Good luck ! I am looking forwarding to it!
Cheers
You Bo
_______________________________________________
Devel mailing list
Devel@lists.open80211s.org
http://open80211s.com/mailman/listinfo/devel
