[OLSR-users] Rescue access

[Sven-Ola Tuecke]

Hi,

several network if with same subnet? Yes: you need to limit the netmask for 
some of the in order to have access. Routes are sorted by "narrow netmask 
before wider netmask" - thats why the default route comes last. Example:

wlan0: 10.1.2.3/8 (thats ad-hoc-omni)
wlan1: 10.10.8.1/24 (thats the speed uplink, directed)
eth0: 10.255.255.253/30 (thats a p2p link to neighbour box)

This scenario will sort with prio: first check eth0, then check wlan1 then 
check wlan0 and at last do the default gw.

(Remember: OLSR will set host routes, so routes via eth0 will functioning 
regardless of netmask)

Complicated? Never trust an 0.x routing daemon. To be on the secure side, 
its better to have a way to contact without hostroutes. And: You may also 
read and dig the policy routing possiblities (seveal routing tables in the 
background)...

Happy hacking!
Sven-Ola

""Ignacio García Pérez"" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
>> consider to setup and run the ssh daemon/client on any box in the
>> path. Then you are able to ssh-hop from box to box without olsr
>> routes.
>
> It's not that easy in my setup. I have several network interfaces in each
> node, and all are in the same subnet. If per-node routes are not properly
> setup, the default route will route all reply packets to one interface. If
> you try to connect from a node via one of the other interfaces, your 
> packets
> will arrive, but the replies will go out through the wrong interface, 
> making
> communication impossible.
>
>> Your setup is
>> much too compicated to really function in the field.
>
> Um.... why?... I though it was just the opposite (it is SO simple it 
> should
> work in all scenarios). My only concern is that misuse can bring the whole
> net to its knees.
>
> Wait, now that I think about it, I was thinking about telnet-like access,
> that is, interactive. If you try to transfer a file via this mechanism the
> network will be probably overflowed.
>
> To solve that, one possibility would be the following scheme:
>
> 1- Use the "simple flood" mechanism only initially in a ping-pong scheme 
> to
> learn a valid path to the node we want to reach.
>
> 2- Use a second type of packet, which is not flooded but contains the full
> path embedded in the header. Nodes will pass the packets along the 
> specified
> route.
>
> Problem here is that if the daemon wants to be transparent to programs
> (which is what I intended by using the tun driver):
>
> - A path needs to be discovered when we get a packet from tun0 for a node
> for which we do not already have a calculated path.
>
> - When do we "forget" that path?. We cannot make it permanent, because 
> what
> would happen if the topology changes?. Of course we could be analyzing TCP
> packets and forget the path when no TCP connection is alive, but that is 
> way
> too much work, and anyway that would not work for UDP packets.
>
> Another possibility is that each node periodically floods the net with a
> "HELLO" packet. This packet would contain a path in the header, and before
> rebroadcasting it, each node would add itself to the path. When those
> packets arrive to each node, it can directly learn the path to the origin
> from it.
>
> I don't like this approach. It is fairly simple (though not as much as the
> initial proposal), but would generate traffic in the network, and this is
> definitely a no-no. The "rescue" scheme must be as unobstrusive as 
> possible.
>
> The more I think about it the more I believe the simplest, initial 
> approach
> is the best. Will definitely not work (or even temporarily kill the 
> network)
> if used simply to transfer a file, but is more than enough for manual
> interactive telnet, which is indeed all I need to get into a node and
> bootstrap a rescue process (maybe set up some routes manually, kill olsrd
> and launch the previous version, whatever...).
>
> Nacho.
>
>
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users