Hi David, Currently max_peer_links are first come first serve. An algorithm for maintaining best n peer links would be desirable.
Thanks, Thomas On Wed, Jan 18, 2012 at 10:39 AM, David Fulgham <[email protected]> wrote: > Quick confirmation regarding mesh_max_peer_links. > > If I set this to an arbitrary value say 4. will this limit the number of > peer links on anything other than first come first serve? i.e. will my 4 > peer links be my best 4 links by quality, speed, etc. Or will they just be > the first 4 links that it happens to recv beacons for? If the latter is the > case this might not be good, as my nodes often have multiple peer links > established well below what is usable (ie. -90dBm and lower) > > >> > > David Fulgham > > On Tue, Jan 17, 2012 at 10:42 PM, Yeoh Chun-Yeow <[email protected]> > wrote: >> >> Hi, David >> >> This patch prevents your fixed nodes forwarding the traffic via mobile >> nodes, such as: >> >> fixed node ---> mesh node 1 ---> mesh node 2 >> fixed node 1 ---> mesh node ---> fixed node 2 >> >> when you set "iw mesh0 set mesh_param mesh_forwarding 0" in your mobile >> nodes. But you mobile nodes still can create many plinks with the >> neighboring nodes as long as it can reach them via single-hop. >> >> My purpose of this patch is to save power in the smart devices or mobile >> phones that would like to join the mesh network but not to participate in >> forwarding the traffic, creating a selfish node :(. >> >> As Thomas pointed out before, set mesh_max_peer_links to 1 with iw, could >> ensure only one plink is established for your mobile nodes. >> >> Perhaps, you can combine these two and give it a try. See whether it helps >> . >> >> Thanks >> >> Regards, >> Chun-Yeow >> >> >> On Wed, Jan 18, 2012 at 3:51 AM, David Fulgham <[email protected]> >> wrote: >>> >>> I've was playing with mobile nodes a while ago (i.e. a mesh node in a >>> couple cars, driving through our network of 28 fixed outdoor nodes.) and I >>> noticed that the fixed nodes would often establish peer links with the >>> mobile nodes, and forward multi-hop traffic through them. This would >>> disrupt the regular established fixed node behavior and cause timeouts >>> and/or increased latency when the mobile node moved in and out of range. >>> Not to mention the extra management traffic this caused. >>> >>> I'm hoping that this feature would be useful in this situation, i.e. >>> disabling mesh_forwarding on the mobile nodes would keep the fixed nodes >>> from trying to forward traffic through these mobile nodes in the vehicles. >>> >>> Let me know your thoughts. >>> >>> David Fulgham >>> > > > _______________________________________________ > Devel mailing list > [email protected] > http://open80211s.com/mailman/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://open80211s.com/mailman/listinfo/devel
