headers
Benjamin Henrion | 7 Jan 2008 18:30

olsr cpu stress with openvz?

Hi,

I was thinking that the token system inside OpenVZ could help to
simulate low CPU machines:

http://forum.swsoft.com/showthread.php?threadid=38066

I am trying to have an OpenVZ kernel running on top on Qemu, but
creating a working hd.img is a pain.

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-4148403

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
Permalink | Reply | 0 comments |
headers
Giuseppe Marocchio | 7 Jan 2008 22:55

Olsr quagga pluing problem


Hello,
i'ive now trying to redistrubute Olsr router into OSPF whith quagga.
i've compiled olsr 0.5.4 whit quagga plugin  "to connect" quagga and
olsrd unfortunatly when i enable  the plugin olsr doesn't get/put the
route with the olsr cloud.

any question, why in quagga is possible redistribute olsr routers in
ospf and bgp and no in rip?

plugin  is loaded successfully.
this is my olsrd conf:

DebugLevel 0
IpVersion 4
AllowNoInt yes
Pollrate 0.1
TcRedundancy 2
MprCoverage 7
LinkQualityFishEye 1
LinkQualityWinSize 100
LinkQualityDijkstraLimit 0 5.0
LinkQualityLevel 2
UseHysteresis no

#Hna4 {
#    0.0.0.0      0.0.0.0
#}

LoadPlugin "olsrd_quagga.so.0.2.2"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Victor | 8 Jan 2008 21:48
Picon
Favicon

how to install olsrd secure plugin

Hi,

 

I’m trying to install the olsrd secure plugin on a Linksys WRT54GL running on Freifunk (actually have Kamikaze as well) and I’m a bit stuck. Is there a howto somewhere? I’ve looked around and haven’t found one though there are lots of people talking about how they have it working. If there isn’t a howto somewhere, I’d be happy to write one up and post it since I need to show other people how to do it once I get it working.

 

At the moment I’ve got the plugin installed (doing the usual ipkg install ) and I’ve also configured the /etc/olsrd.conf file accordingly. I;ve checked that the key file is there and valid and I;ve installed the openssl library. So what now?

 

Any help will be greatly appreciated,

Thanks

Victor

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
Permalink | Reply | 2 comments |
headers
Henning Rogge | 8 Jan 2008 07:26
Picon
Favicon

Re: how to install olsrd secure plugin

Am Dienstag 08 Januar 2008 21:48:08 schrieb Victor:
> Hi,
>
> I'm trying to install the olsrd secure plugin on a Linksys WRT54GL running
> on Freifunk (actually have Kamikaze as well) and I'm a bit stuck. Is there
> a howto somewhere? I've looked around and haven't found one though there
> are lots of people talking about how they have it working. If there isn't a
> howto somewhere, I'd be happy to write one up and post it since I need to
> show other people how to do it once I get it working.
>
> At the moment I've got the plugin installed (doing the usual ipkg install )
> and I've also configured the /etc/olsrd.conf file accordingly. I;ve checked
> that the key file is there and valid and I;ve installed the openssl
> library. So what now?

Do you have something like this in your olsrd.conf (especially the version 
number of the plugin is important, the README is out of date...) ?

LoadPlugin "olsrd_secure.so.0.5"
{
    PlParam     "Keyfile"   "./olsrd_secure_key.conf"
}

In addition to this you need a keyfile exactly 128 Bit (16 bytes) long 
distributed on all nodes.

These two things were enough (for my setup) to get the "secure" plugin 
running. (I write "secure" because all the authentification of this plugin is 
done by a symmetric key, so it does not provide much more security that a 
good WPA2 encryption on your net unless you share the WLAN with other persons 
who must not send olsr routing messages).

Henning

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
Permalink | Reply | 0 comments |
headers
fdb | 8 Jan 2008 09:08
Picon
Favicon

Re: how to install olsrd secure plugin

Hi Victor,

On Freifunk firmware, olsrd.conf is automatically generated from NVRAM
parameters, so every reboot changes in olsrd.conf are lost.

Yuo shoul insert your customization in /etc/local.olsrd.conf.

Bye.

Victor ha scritto:
> Hi,
> 
>  
> 
> I’m trying to install the olsrd secure plugin on a Linksys WRT54GL
> running on Freifunk (actually have Kamikaze as well) and I’m a bit
> stuck. Is there a howto somewhere? I’ve looked around and haven’t found
> one though there are lots of people talking about how they have it
> working. If there isn’t a howto somewhere, I’d be happy to write one up
> and post it since I need to show other people how to do it once I get it
> working.
> 
>  
> 
> At the moment I’ve got the plugin installed (doing the usual ipkg
> install ) and I’ve also configured the /etc/olsrd.conf file accordingly.
> I;ve checked that the key file is there and valid and I;ve installed the
> openssl library. So what now?
> 
>  
> 
> Any help will be greatly appreciated,
> 
> Thanks
> 
> Victor
> 

-- 
FabioBD

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
Permalink | Reply | 0 comments |
headers
Victor | 10 Jan 2008 06:35
Picon
Favicon

Re: how to install olsrd secure plugin

Hi Henning, Fabio

Yeh this is the contents of my conf file in kamikazi

DebugLevel              0
IpVersion               4
AllowNoInt              yes
Pollrate                0.1
TcRedundancy            2
MprCoverage             7
LinkQualityFishEye      1
LinkQualityWinSize      100
LinkQualityDijkstraLimit 0 5.0

Hna4 
{
	192.168.69.100 255.255.255.0
}

LoadPlugin "olsrd_dyn_gw.so.0.4"
{
}

LoadPlugin "olsrd_secure.so.0.5"
{
	PlParam  "keyfile" "/etc/olsrd.d/olsrd_secure_key"
}

LoadPlugin "olsrd_httpinfo.so.0.1"
{
        PlParam "port"  "8080"
        PlParam "Host"  "192.168.69.1"
        PlParam "Net" "192.168.69.0 255.255.255.0"
}
IpcConnect
{
        MaxConnections  1
        Host            127.0.0.1
        Net 192.168.1.0 255.255.255.0
}
LinkQualityLevel 2
UseHysteresis no
Interface "eth1" 
{
        HelloInterval           5.0
        HelloValidityTime       90.0
        TcInterval              2.0
        TcValidityTime          270.0
        MidInterval             15.0
        MidValidityTime         90.0
        HnaInterval             15.0
        HnaValidityTime         90.0
}

________________________________________________

And the keyfile is 16 bytes long.

Infact on some further investigation of the kamikaze version I realised that
the nodes were sending out packets OLSR packets of type 10 (Ie hello is 1,
TC is 2 etc)? Is that it? But the thing was that the message size was only
36 bytes long and if you subtract the 12 byte olsr message header, the
packet is too small to the be signature message which is 28 bytes.
Also, the other problem is the none of the nodes were connecting to each
other. Might try reinstalling from everything from scratch if there is
nothing else that can be suggested as I;ve messed around with the nvram a
lot!

On that note of reinstalling from scratch. Can someone let me know what I
need to do in order to get the olsrd working on Freifunk? The nodes I had
before was programmed by someone else.

This is what I;ve done so far:

1: Erased all nvram
2: tftp'd a fresh copy of freifunk 1.4.5
3: Reconfigured all the nvram and confirmed that the freifunk mesh was
working and connects
4: ipkg install olsrd

Can someone tell me now what? After installing olsrd it stopped sending out
olsr control messages. I haven't touched any of the config files so if
someone could just paste theirs I could help myself.

Thanks a lot for the help
Victor

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
Permalink | Reply | 2 comments |
headers
Henning Rogge | 9 Jan 2008 08:14
Picon
Favicon

Re: how to install olsrd secure plugin

Am Donnerstag 10 Januar 2008 06:35:58 schrieb Victor:
> Hi Henning, Fabio
>
> Yeh this is the contents of my conf file in kamikazi
.....

looks fine at first look

> Infact on some further investigation of the kamikaze version I realised
> that the nodes were sending out packets OLSR packets of type 10 (Ie hello
> is 1, TC is 2 etc)? Is that it?
The olsr-secure plugin use four new messages:
type 10: (must be last message of an olsr package)
  encrypted signature and timestamp of a package
type 11:
  authentification, step 1
type 12:
  authentification, step 2
type 13:
  authentification, step 3

> But the thing was that the message size was  
> only 36 bytes long and if you subtract the 12 byte olsr message header, the
> packet is too small to the be signature message which is 28 bytes.
36 bytes sounds really to short.

4 bytes for package header
12 bytes for message header of signature
24 bytes for the flags, timestamp and the signature itself
( I think the time_t is a 4 byte value)

but why should olsrd try to send out an empty package ?
do you have a hexdump of the package ?

Henning

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
Permalink | Reply | 1 comment |
headers
Victor | 11 Jan 2008 06:33
Picon
Favicon

Re: how to install olsrd secure plugin

I don't have a hex dump but heres a byte dump :P

0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Packet Length         |    Packet Sequence Number     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |     Vtime     |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                            MESSAGE                            :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |     Vtime     |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                            MESSAGE                            :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 */

0 56 198 226  >> Packet header (56 bytes)
201 106 0 16  >> 201 = ETXHELLO & 16=Message Size
104 3 69 1  >> IP address of node as 104.3.69.1
1 0 184 100 
0 0 70 3  >> Message
10 0 0 36  >> Start of type 10 packet (36 bytes)
104 3 69 1  >> Originator address
1 0 184 101 >> TTL, hopcount, message sequence no
1 2 0 0 >> Scheme, Algorithms, Reserverd (2bytes)
56 109 69 208 >> Time Stamp

Everything from here on should be the  signature but I
Thought that the signature was 160 bits ie 20 bytes. That is from the solsr
paper on the olsr.org website so it could be old etc
	
60 91 172 115  
18 56 250 59 
14 44 52 161 
130 163 133 101

Hmm so things look right, I think...now gotta get two nodes to connect and
work...Will try that over the next few days.

Thanx

-----Original Message-----
From: Henning Rogge [mailto:rogge <at> fgan.de] 
Sent: Wednesday, January 09, 2008 6:14 PM
To: olsr-users <at> lists.olsr.org
Cc: Victor
Subject: Re: [Olsr-users] how to install olsrd secure plugin

Am Donnerstag 10 Januar 2008 06:35:58 schrieb Victor:
> Hi Henning, Fabio
>
> Yeh this is the contents of my conf file in kamikazi
....

looks fine at first look

> Infact on some further investigation of the kamikaze version I realised
> that the nodes were sending out packets OLSR packets of type 10 (Ie hello
> is 1, TC is 2 etc)? Is that it?
The olsr-secure plugin use four new messages:
type 10: (must be last message of an olsr package)
  encrypted signature and timestamp of a package
type 11:
  authentification, step 1
type 12:
  authentification, step 2
type 13:
  authentification, step 3

> But the thing was that the message size was  
> only 36 bytes long and if you subtract the 12 byte olsr message header,
the
> packet is too small to the be signature message which is 28 bytes.
36 bytes sounds really to short.

4 bytes for package header
12 bytes for message header of signature
24 bytes for the flags, timestamp and the signature itself
( I think the time_t is a 4 byte value)

but why should olsrd try to send out an empty package ?
do you have a hexdump of the package ?

Henning

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
Permalink | Reply | 0 comments |
headers
David Murray | 17 Jan 2008 10:31
Picon
Picon

Routing problems with multiple interfaces

Hi,

I am getting a few routing problems in my experimental network. I have 
four nodes each equipped with two wireless cards. Each node has two 
links (see diagram). These links are A-C, A-D , B-D and B-C (see 
diagram) and each link is running on a different frequency. The 
frequencies discovered are dynamically found which means that upon boot 
time, there is the potential for ath0 on node D to be initially 
connected to node A but then later switched to connect with node B.

The network appears to work, routing tables get filled and look 
perfectly sane et cetera. However, there is a problem that certain 
nodes cannot ping other nodes. To try to understand the problems I have 
written scripts to take snapshots of the routing table and 
simultaneously record ping results.

- Node A can ping one interface on C and one interface on node D and 
nothing on B
- Node B can ping every interface on node C and D but cannot ping any 
interface on node A
-Node C can ping every interface on A and B but cannot ping any 
interface on  node D
- Node C can ping every interface.

Diagram:

A            B
| \        / |
|   \    /   |
|     \/     |
|    /  \    |
|  /      \  |
|/          \|
C            D

I am a little confused by this problem as the routing tables look fine 
and the routing protocol seems to be exchanging packets fine however 
there are problems with pings. I am thinking that this could be an arp 
issue but when I look at the arp table, each node looks consistently 
the same each with only one arp entry for each wireless interface.

Does anyone have any suggestions at to where the problem might lie or 
how I could further define the problem? has anyone else has much 
experience with olsr and two wireless cards?

Thank you for your time

Dave

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
Permalink | Reply | 1 comment |
headers
David Murray | 18 Jan 2008 08:35
Picon
Picon

Re: Routing problems with multiple interfaces

Hi,

I now have much more defined idea of my problem/olsr bug. This problem 
is only likely to affect a very small number of users who are using 
multiple interfaces and changing channels of interfaces while running 
olsr. The diagram below shows the setup with four nodes - A, B, C and D 
each with two interfaces Ath0 and Ath1. Also shown are the IP addresses 
of each node and the frequency of each link.

       Ath1 10.173.56.237             Ath1 10.121.39.119
                     |    5.825Ghz     |
                    A-------------------B
Ath0 10.173.54.111 -|                   |- Ath0 10.121.42.92
                    |                   |
                    |                   |
             5.32Ghz|                   |5.26Ghz
                    |                   |
                    |                   |
  Ath0 10.87.21.61 -|                   |- Ath0 10.78.114.25
                    C-------------------D
                     |     5.785Ghz    |
             Ath1 10.16.34.192        Ath1 10.86.251.86

Now, because these channels are (initially) dynamically assigned, 
different interfaces could previously have had links with different 
nodes. From my experience, Olsr has been very quick and reliable at 
cutting out old/stale routes and installing newly discovered routes 
(which might have occurred because of a complete channel change.

However, while Olsr seems to be fine, it is my understanding that the 
OLSR and its routing table are used to instruct the Kernel IP routing 
table of the various routes. The contents of the Kernel IP routing 
table are then used in decisions such as which interface to broadcast 
ARP/RARP and build the ARP table.

When using multiple interfaces in the way that I have, It seems that 
sometimes, old/stale routes are not removed from the kernel routing 
table. The details of each node (A,B,C and D) are shown below. The node 
that is of interest is node D. If you look at the kernel IP routing 
table for node D you will see two routing entries each of the following 
IP addresses: 10.121.42.92, 10.121.39.119 and 10.16.34.192. This error 
in the kernel routing table also has a follow on error because ARP on 
node D is now sending out ARP requests for 10.121.39.119 on the wrong 
interface (see Node D's ARP table). This problem is causing 
connectivity problems between different nodes (some pings are 
unsuccessful).

Is this a possible bug in OLSR or is it something that I should be 
accommodating for in what I am doing (eg check and manually delete 
duplicate kernel routes and hope that OLSR rebuilds them).

Thanks

Dave

---------------------------------------------------------------------------

##########
# Node A #
##########

Interface Stats
---------------
ath0 freq:5.32 IP - 10.173.54.111
ath1 freq:5.825 IP - 10.173.56.237

Ping Test - Ping every other IP address
---------------------------------------
10.87.21.61 is alive
10.16.34.192 is alive
10.121.42.92 is alive
10.121.39.119 is alive
10.78.114.25 is alive
10.86.251.86 is alive

OLSR Routing output
-------------------
<SNIP: Links, Neighbors, Topology, HNA>
Table: MID
IP      Aliases
10.121.39.119   10.121.42.92
10.86.251.86    10.78.114.25
10.87.21.61     10.16.34.192

Table: Routes
Destination     Gateway Metric  ETX     Interface
10.78.114.25/32 10.121.39.119   2       2.000   ath1
10.87.21.61/32  10.87.21.61     1       1.091   ath0
10.86.251.86/32 10.121.39.119   2       2.000   ath1
10.121.42.92/32 10.121.39.119   1       1.000   ath1
10.121.39.119/32        10.121.39.119   1       1.000   ath1
10.16.34.192/32 10.87.21.61     1       1.091   ath0

Kernel IP routing table
-----------------------
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.121.42.92    10.121.39.119   255.255.255.255 UGH   2      0        0 ath1
10.121.39.119   *               255.255.255.255 UH    1      0        0 ath1
10.78.114.25    10.121.39.119   255.255.255.255 UGH   2      0        0 ath1
10.16.34.192    10.87.21.61     255.255.255.255 UGH   2      0        0 ath0
10.86.251.86    10.121.39.119   255.255.255.255 UGH   2      0        0 ath1
10.87.21.61     *               255.255.255.255 UH    1      0        0 ath0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
10.0.0.0        *               255.0.0.0       U     0      0        0 ath1
10.0.0.0        *               255.0.0.0       U     0      0        0 ath0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

ARP Table
---------
Address                  HWtype  HWaddress           Flags Mask         
    Iface
10.121.39.119            ether   00:12:17:79:27:77   C                  
    ath1
10.87.21.61              ether   00:0B:6B:57:15:3D   C                  
    ath0
192.168.1.100            ether   00:1B:24:03:EF:B6   C                  
    eth0
192.168.1.100            ether   00:1B:24:03:EF:B6   C                  
    eth0

---------------------------------------------------------------------------

##########
# Node B #
##########

Interface Stats
---------------
ath0 freq:5.26 - 10.121.42.92
ath1 freq:5.825 - 10.121.39.119

Ping Test - Ping every other IP address
---------------------------------------
ICMP Host Unreachable from 10.78.114.25 for ICMP Echo sent to 10.87.21.61
ICMP Host Unreachable from 10.78.114.25 for ICMP Echo sent to 10.87.21.61
ICMP Host Unreachable from 10.78.114.25 for ICMP Echo sent to 10.87.21.61
10.173.54.111 is alive
10.173.56.237 is alive
10.78.114.25 is alive
10.86.251.86 is alive
10.16.34.192 is alive
10.87.21.61 is unreachable

OLSR Routing output
-------------------
<SNIP: Links, Neighbors, Topology, HNA>
Table: MID
IP      Aliases
10.86.251.86    10.78.114.25
10.87.21.61     10.16.34.192
10.173.54.111   10.173.56.237

Table: Routes
Destination     Gateway Metric  ETX     Interface
10.78.114.25/32 10.78.114.25    1       1.000   ath0
10.87.21.61/32  10.78.114.25    2       2.000   ath0
10.86.251.86/32 10.78.114.25    1       1.000   ath0
10.173.54.111/32        10.173.56.237   1       1.000   ath1
10.16.34.192/32 10.78.114.25    2       2.000   ath0
10.173.56.237/32        10.173.56.237   1       1.000   ath1

Kernel IP routing table
-----------------------
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.173.56.237   *               255.255.255.255 UH    1      0        0 ath1
10.173.54.111   10.173.56.237   255.255.255.255 UGH   2      0        0 ath1
10.78.114.25    *               255.255.255.255 UH    1      0        0 ath0
10.16.34.192    10.78.114.25    255.255.255.255 UGH   2      0        0 ath0
10.87.21.61     10.78.114.25    255.255.255.255 UGH   2      0        0 ath0
10.86.251.86    10.78.114.25    255.255.255.255 UGH   2      0        0 ath0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
10.0.0.0        *               255.0.0.0       U     0      0        0 ath1
10.0.0.0        *               255.0.0.0       U     0      0        0 ath0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

ARP Table
---------
Address                  HWtype  HWaddress           Flags Mask         
    Iface
192.168.1.1              ether   00:12:17:9E:AE:40   C                  
    eth0
10.78.114.25             ether   00:0B:6B:4E:72:19   C                  
    ath0
10.173.56.237            ether   00:40:96:AD:38:ED   C                  
    ath1
192.168.1.100            ether   00:1B:24:03:EF:B6   C                  
    eth0

---------------------------------------------------------------------------

##########
# Node C #
##########

Interface Stats
---------------
ath0 freq:5.32 IP - 10.87.21.61
ath1 freq:5.785 IP - 10.16.34.192

Ping Test - Ping every other IP address
---------------------------------------
ICMP Host Unreachable from 10.86.251.86 for ICMP Echo sent to 10.121.39.119
ICMP Host Unreachable from 10.86.251.86 for ICMP Echo sent to 10.121.39.119
ICMP Host Unreachable from 10.86.251.86 for ICMP Echo sent to 10.121.39.119
10.173.54.111 is alive
10.173.56.237 is alive
10.121.42.92 is alive
10.78.114.25 is alive
10.86.251.86 is alive
10.121.39.119 is unreachable

OLSR Routing output
-------------------
<SNIP: Links, Neighbors, Topology, HNA>
Table: MID
IP      Aliases
10.121.39.119   10.121.42.92
10.86.251.86    10.78.114.25
10.173.54.111   10.173.56.237

Table: Routes
Destination     Gateway Metric  ETX     Interface
10.78.114.25/32 10.86.251.86    1       1.000   ath1
10.86.251.86/32 10.86.251.86    1       1.000   ath1
10.121.42.92/32 10.86.251.86    2       2.000   ath1
10.173.54.111/32        10.173.54.111   1       1.000   ath0
10.121.39.119/32        10.86.251.86    2       2.000   ath1
10.173.56.237/32        10.173.54.111   1       1.000   ath0

Kernel IP routing table
-----------------------
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.173.56.237   10.173.54.111   255.255.255.255 UGH   2      0        0 ath0
10.121.42.92    10.86.251.86    255.255.255.255 UGH   2      0        0 ath1
10.173.54.111   *               255.255.255.255 UH    1      0        0 ath0
10.121.39.119   10.86.251.86    255.255.255.255 UGH   2      0        0 ath1
10.78.114.25    10.86.251.86    255.255.255.255 UGH   2      0        0 ath1
10.86.251.86    *               255.255.255.255 UH    1      0        0 ath1
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
10.0.0.0        *               255.0.0.0       U     0      0        0 ath0
10.0.0.0        *               255.0.0.0       U     0      0        0 ath1
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

ARP Table
---------
Address                  HWtype  HWaddress           Flags Mask         
    Iface
192.168.1.1              ether   00:12:17:9E:AE:40   C                  
    eth0
192.168.1.100            ether   00:1B:24:03:EF:B6   C                  
    eth0
10.173.54.111            ether   00:40:96:AD:36:6F   C                  
    ath0
10.86.251.86             ether   00:0B:6B:56:FB:56   C                  
    ath1

---------------------------------------------------------------------------

##########
# Node D #
##########

Interface Stats
---------------
ath0 freq:5.26 IP - 10.78.114.25
ath1 freq:5.785 IP - 10.86.251.86

Ping Test - Ping every other IP address
---------------------------------------
ICMP Host Unreachable from 10.86.251.86 for ICMP Echo sent to 10.121.39.119
ICMP Host Unreachable from 10.86.251.86 for ICMP Echo sent to 10.87.21.61
ICMP Host Unreachable from 10.86.251.86 for ICMP Echo sent to 10.121.39.119
10.173.54.111 is alive
10.173.56.237 is alive
10.16.34.192 is alive
10.121.42.92 is alive
10.87.21.61 is unreachable
10.121.39.119 is unreachable

OLSR Routing output
-------------------
<SNIP: Links, Neighbors, Topology, HNA>
Table: MID
IP      Aliases
10.121.39.119   10.121.42.92
10.87.21.61     10.16.34.192
10.173.54.111   10.173.56.237

Table: Routes
Destination     Gateway Metric  ETX     Interface
10.87.21.61/32  10.16.34.192    1       1.000   ath1
10.121.42.92/32 10.121.42.92    1       1.000   ath0
10.173.54.111/32        10.16.34.192    2       2.000   ath1
10.121.39.119/32        10.121.42.92    1       1.000   ath0
10.16.34.192/32 10.16.34.192    1       1.000   ath1
10.173.56.237/32        10.16.34.192    2       2.000   ath1

Kernel IP routing table
-----------------------
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.173.56.237   10.16.34.192    255.255.255.255 UGH   2      0        0 ath1
10.173.54.111   10.16.34.192    255.255.255.255 UGH   2      0        0 ath1
10.121.42.92    *               255.255.255.255 UH    1      0        0 ath0
10.121.42.92    10.121.39.119   255.255.255.255 UGH   2      0        0 ath1
10.121.39.119   *               255.255.255.255 UH    1      0        0 ath1
10.121.39.119   10.121.42.92    255.255.255.255 UGH   2      0        0 ath0
10.16.34.192    *               255.255.255.255 UH    1      0        0 ath1
10.16.34.192    10.121.39.119   255.255.255.255 UGH   2      0        0 ath1
10.87.21.61     10.121.39.119   255.255.255.255 UGH   2      0        0 ath1
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
10.0.0.0        *               255.0.0.0       U     0      0        0 ath1
10.0.0.0        *               255.0.0.0       U     0      0        0 ath0
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

ARP Table
---------
Address                  HWtype  HWaddress           Flags Mask         
    Iface
192.168.1.1              ether   00:12:17:9E:AE:40   C                  
    eth0
10.16.34.192             ether   00:15:6D:10:22:C0   C                  
    ath1
10.121.42.92             ether   00:12:17:79:2A:5C   C                  
    ath0
192.168.1.100            ether   00:1B:24:03:EF:B6   C                  
    eth0
10.121.39.119                    (incomplete)                           
    ath1

--

-- 
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
Permalink | Reply | 0 comments |

Gmane