Hi Chun-Yeow, In my case I have reduced the inactive timeout in the code to 60 secs. (net/mac80211/mesh.h) The default is 1800 secs (30min). I don't want inactive nodes to linger that long.
In your case you reboot Node 2 while it is out of range (of Node 1) and then increase the power. It's similar in both cases the plink on one node (Node 1) stays in ESTAB state and the other (Node 2) stays in LISTEN state. Node 1 in the ESTAB state will stay unless it gets a close request from Node 2. It never happens, both nodes sit tight without sending anything. It will remain like that until the lifetime (authentication) expires (default is 3600 secs) or if you manually force a re-authentication while in range. In an open mesh the node in LISTEN state (Node 2) would issue "sndOpen" cmds. If Node 2 does not get an answer "sndCNF"(confirmation) after 3 retries, it will send "sndClose". Node 1 in ESTAB state would then go back a LISTEN state and the peering goes through. In a secured mesh the peering process can get stuck because it gets triggered by the authentication. --Fabrice On 12/16/2011 10:41 AM, Yeoh Chun-Yeow wrote: > Hi, Fabrice > > > 3 - Node 1 goes to LISTEN state and stays there, Node 2 remains in > ESTAB state > I only observed this if I reboot Node 2, set tx power to 0 and bring > up authsae daemon. In such a case, even after set tx power to 30 for > Node 2, "iw mesh0 station dump" in Node 2 will always indicate Node 1 > in LISTEN state. But after a period of time, the link is established back. > > I have tried to reproduce the problem that you mentioned. But seems > that mesh path link is able to establish back between node 1 and node 2. > > Regards, > Chun-Yeow > > _______________________________________________ Devel mailing list [email protected] http://open80211s.com/mailman/listinfo/devel
