> which is impossible todo inside olsr,<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I wonder what you mean by this, because before working on C, I tested<br>
this idea with a bash script(which only included ping, route add and<br>
route del), and my handover-time was less then a second.<br></blockquote><div><br></div><div>no i meant impossible inside the whole mesh</div><div>it is no problem for the master-nodes to do it fast,..</div><div>but its hard to convince the wohle mesh to do the same,..</div>
<div><br></div><div>but in the meantime, i realised that in theory it can be done quite fast, (using tcs (of hypothetic olsrd-nodes) to company the hnas, as tcs can overwrite old, which plain hnas can't)</div><div>so u can force the typical olsrd-mesh within the time one broadcast flooding needs, to forget the old position/gateway of a client and to learn the new,..</div>
<div><br></div><div>so it might be quite easy & fast to get the new topology information, into the mesh</div><div><br></div><div>BUT i still have some doubts that some of the typical configured nodes in the mesh will need up to 10 seconds to recalculate their routes, and therefore boycott this new topology (and the routes based on it) a bit</div>
<div><br></div><div>(but in maybe 1-2 years we will probably have olsrd that can adopt such topology changes really fast, but this requires multiple (already planned) improvements)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
<br>
> (you would need to change every olsrd in your mesh, to learn them to do<br>
> timely synchronised routing changes)<br>
</div>every olsrd with a accesspoint-function. agreed.<br>
I think we can assume that on a handover, the two accesspoints<br>
involved, are (two hop) neighbours on OLSR. </blockquote><div>hmm why can you assume this? </div><div><br></div><div>the client may be on a spot seing two freifunk nodes that can not see each other, and do not share any neighbours aswell</div>
<div><br></div><div>and even if they are, this does not help very much, as the targets the client device wants to exchange data with might lie somewhere far away in the mesh, (but even a node 1 hop away may insist to wait some seconds until it recalculates its routing table, causing a intermittent loop until it does,..)</div>
<div><br></div><div>but too make things clear, it will work in about 80-90% #1 of usecases quite well, and im just continuing to find a solution for close to 100% #2 *G<br></div><div><br></div><div>#1 assuming that the next gateway to internet is quite near, and typical usecase is traffic into the internet</div>
<div><br></div><div>#2 i already have one really ugly method, and one very complex, that will still probably fail (at least with mutliple roaming events)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If i client roams, it is<br>
most important that the old accesspoint has a route pointing towards<br>
the new accesspoint. The rest shouldn't be very important.<br></blockquote><div><br>e.g. expect problems if you want to voip from and to clients/nodes in the mesh (having some hops between)<br></div></div><div><br></div>
<div>Markus<br></div><div><br></div><div>p.s. we can switch to german i think (-;</div>