[Olsr-users] Sticky gateway

[L. Aaron Kaplan]

sorry it took me some time to answer this one.

On Jan 23, 2009, at 1:09 AM, Juliusz Chroboczek wrote:

>> Your example is right in theory, but it's wrong in practice.
>
> I'm not quite sure what to make of this statement.  I've been  
> brought up to
> believe that either theory and practice agree, or the theory is wrong.
>

Well as you know , theories are - well theories - that means  
eventually they do get refuted ;-)
But they can be "true" for some time (until Popper comes along at  
least ;)) )
But as far as I can see you made a good point of course.
I really just wonder, why we have not encountered that problem in  
practice yet.


In the long run you would suggest source routing to the gateways?
Could it be the "fluidness" of constantly changing ETX values that  
prevents this?
Don't know...

>> Our link quality values on a link are never total stable because of  
>> the ETX
>> metric we use. Most times they go up and down by 0.1 or more.
>
> Except on wired networks.  You do use cables and/or tunnels, right?
>
>> But we are talking about both problems (the possibility or routing  
>> loops to
>> the HNA 0 gateway AND the instable routing metrics) and I hope we  
>> will get
>> better solutions for this problems in the next 12 months (much to  
>> do, not
>> enough time to do it ;) ).
>
> I'm looking forward to seeing your solution.
>
> In the meantime, I think it'd be a good idea not to recommend the  
> sticky
> gateway feature for general use.

As said - so far we did not have any problems with it *in practice*.  
In fact it has been quite helpful.

Another thing I want to drop in here: I believe when we have gateway  
selection we should also consider more security.
We are sometimes seeing misconfigured HNA 0/0 gateways. The freifunk  
firmware gets rid of those by a trick, but by default OLSRd would not.
That is just an example of a security problem that needs to be  
addressed.
The bigger the mesh networks become (and olsrd scales pretty nicely  
now for some time CPUwise) the more we will be running into security  
problems.
Any *good* papers recently  on that topic which are worth a look at?  
(emphasis is on good)

a.