[Olsr-dev] LinkQualityMult problems in 0.5.6-r5

[Mitar]

Hi!

On Sun, Sep 13, 2009 at 11:17 AM, Henning Rogge <(spam-protected)> wrote:
> Wow, that looks nice. :)
> I think that's the first time I see such a image generator.

Yes, we went one step further (in our opinion) from web based
interfaces on each node and made a central administration web
interface for all nodes. So it is easier to monitor and admin nodes
(and push network wide modifications and configurations).

Also there are live stats for each node. For example we have a solar
powered node for which you can monitor solar panel and battery status
through it:

http://nodes.wlan-lj.net/nodes/node/10.14.128.161

So we got completely rid of any interface on nodes as it is not
necessary anymore as you do not change anything on a node anymore. You
just change configuration on a server, build a new image and flash the
node. (And you get all new changes to underlying firmware as a bonus.)
Currently you still have to do manually this last step but in next
version we will probably also allow pushing/flashing new configuration
automatically. (When we check how stable this will be.)

So now setting up a new node is really fast. You just register new
node (where you specify router type, location and so on and other
thing get preset automatically), generate an image and flash it. And
this is it. Plug&Mesh. :-)

>> But I have done some testing and I think that in our setup having the
>> same IP on multiple interfaces is not a problem because they are
>> interfaces of different physical mediums which are separated by their
>> nature and we just have to keep them separate. Because we do not
>> bridge all connections on a VPN server (but run OLSR there) nodes
>> cannot directly see each other at the same time over VPN server and
>> WiFi. So LQ calculations stay correct.

Can you please confirm (or reject) this?

> The current patch is a step towards a "linklocal-interface" OLSR network, but
> I remember (now) there were some problems why we did not made the full step in
> 0.5.6. If you deploy the patch in a mixed setup (some with sourceip, some
> without them), you cannot kill the MID messages because this will break legacy
> support. If you have a pure sourceip-patch, you could (I think) just set the
> TTL of the MIDs to 2, that would be enough.

Yes, currently we are still in a stage where we could decide for this
(and deploy with sourceip patch everywhere). Later on it will be much
harder. So this is why I would like to clear this out now. :-)

But where do you set this "global" IP when using this patch? Does it
add new configuration options when you enable it when compiling? What
happens if one of interfaces go down? Does it switch "global" IP then?
Or it is an idea that each interface have two IPs assigned: its unique
link-local address and the same "global" IP address? link-local
address is used for OLSR broadcasts (and OLSR identification),
"global" is used for unicast routing?


Mitar