Peter Emanuel | 7 Jul 00:33 2016

Propagating a default gateway OLSRv2

I am working on a project that wants to use OLSR to extend the network to villages in emerging economies. It combines very low cost Raspberry PI’s running Linux using OLSR to build out a network backbone and Android devices that join the network to  run Android apps. The Android app that uses OLSR to achieve this was originally using Version 1 of the protocol. For many good reasons, Version 2 is desired. When using version 1, HNA was utilized for a particular node to alert other nodes that it could use this node to route packets to the Internet. A device that has the WiFi connected to the OLSR adhoc network and has a hardwired Ethernet to the internet is a candidate for this. A phone with a 3G or 4G cellular connection is also such a candidate.

 

·         I have Olsrd2 ported to Android and it is running inside an App on the Android devices

·         I am using olsrd2_static as it just makes it simpler (at least at this juncture)

·         I am using fixed IP addresses on the WiFi for now

o   I do really want to have the devices generate their own IP’s as this is a cool version 2 enhancement but haven’t gotten that to work yet. Later!

 

The problem is best explained using a simple 2 node network example.

192.168.18.5 is a gateway device. It’s hardwired address on eth0 is 192.168.1.115 and its default gateway to the Internet is the router at 192.168.1.1

There is 1 other Android node on the test network – 192.168.18.106

The gateway route on both devices looks like the following:

 

Ip route on gateway

 

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.115
192.168.18.0/24 dev wlan0  proto kernel  scope link  src 192.168.18.5

192.168.18.106 via 192.168.18.106 dev wlan0  proto 100 src 192.168.18.5 metric 2 onlink

 

Ip route on Android device 192.168.18.106


192.168.18.0/24 dev wlan0 proto kernel scope link src 192.168.18.106

192.168.18.5 via 192.168.18.5 dev wlan0  proto 100 src 192.168.18.106 metric 2 onlink

 

When using HNA on OLSRDv1 with an entry in the conf file like

 

Hna4

{

# Internet gateway

0.0.0.0  0.0.0.0

}

 

a default route on the Android device is added automatically

 

default via 192.168.18.5 dev wlan0 metric 2 onlink

 

It’s complete gateway now (using olsrv1) is

 

default via 192.168.18.5 dev wlan0 metric 2 onlink

192.168.18.0/24 dev wlan0 proto kernel scope link src 192.168.18.106

192.168.18.5 via 192.168.18.5 dev wlan0  proto 100 src 192.168.18.106 metric 2 onlink

 

Now the Android device can access the Internet by routing packets through the gateway.

 

However, I am not able to replicate the same behavior on OLSRDv2. I have tried using the lan_import plugin but am a little clueless on how to propagate the default gateway in version 2 from the gateway devices to it’s edge devices.

 

Can someone please help me set up my gateway device properly so the Android devices can see the Internet?

 

Here is the olsrd2_static –schema output:

 

List of section types:
(use this command with the types as parameter for more information)
    domain (named, default name)
    ff_dat_metric (unnamed)
    global (unnamed)
    http (unnamed): Settings for the http interface
    interface (named)
    lan_import (named)
    log (unnamed)
    mesh (unnamed)
    neighbor_probing (unnamed)

    nhdp (unnamed)

    nl80211_listener (unnamed)
    olsrv2 (unnamed)
    telnet (unnamed): Settings for the telnet interface

And olsrd2_static –version output

 

OLSRd2 version 0.11.1
Git commit: v0.11.1-0-g35a1f94
Visit http://www.olsr.org
Static plugin: auto_111

Static plugin: cfg_compact
Static plugin: class
Static plugin: clock
Static plugin: duplicate_set
Static plugin: ff_dat_metric
Static plugin: http
Static plugin: lan_import
Static plugin: layer2
Static plugin: layer2info
Static plugin: link_config
Static plugin: neighbor_probing
Static plugin: netjsoninfo
Static plugin: nhdp
Static plugin: nhdpinfo

Static plugin: nl80211_listener
Static plugin: olsrv2
Static plugin: olsrv2info
Static plugin: os_clock
Static plugin: os_fd
Static plugin: os_interface
Static plugin: os_routing
Static plugin: os_system
Static plugin: packet_socket
Static plugin: rfc5444
Static plugin: socket
Static plugin: stream_socket
Static plugin: systeminfo
Static plugin: telnet
Static plugin: timer
Static plugin: viewer

 

Thanks for any help forthcoming.

 

Peter Emanuel

 

 

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Gabriel | 4 Jul 21:50 2016

Re: olsrv2 remoteconfig plugin


On 04/07/2016 17:47, Henning Rogge wrote:
> Hi,
> 
> I pushed some fixes for handling of default parameters in named config
> sections...
> 
> could you try again with the latest master branch?
> 

Now it works, Thanks!

Gabriel

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Gabriel | 2 Jul 01:16 2016

olsrv2 remoteconfig plugin

Hi, I'm using the remoteconfig plugin in my GSoc Project "Poprouting".

I tried to set the values of the timers manually using the telnet commands:

config set interface.h_timer=20
config set olsrv2.tc_timer=20
config commit

I set a high time (20s) to check if the messages were actually flowing
out at that speed, but when i checked with wireshark i saw that they're
flowing very fast, and even if i change the timers to 2s nothing
changes. I used this filter to see just the packets going out my olsr2:
ipv6.src eq <localipv6> && ipv6.dst eq ff02::6d

I tryed then to fetch the config infos using the config get command, and
the values are ok.

Am I missing something or the plugin isn't working?

This is my config file:

[global]
      plugin remotecontrol

[olsrv2]
      originator    -0.0.0.0/0
      originator    -::1/128
      originator    default_accept

[log]
        stderr false
        file /var/log/olsrd2.log
        info all
[interface]
        bindto        -0.0.0.0/0
        bindto        -::1/128
        bindto        default_accept
[telnet]
	bindto	10.150.13.149
	allowed session 10

[remotecontrol]
	acl	default_accept

[interface=wlan0]
[interface=lo]

Thanks, Gabriel

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge | 7 Jun 11:18 2016
Picon

Bugfix release v0.12.1

Hi...

it is annoying, but I expected it (I replaced a major subsystem in 0.12.0).

Here is an IMPORTANT bugfix release for 0.12.0... you should upgrade
if you plan to use 0.12.x

Henning

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Gabriel | 25 May 11:53 2016

OONF telnet plugin

Hi, I'm trying to connect to the oonf's telnet plugin using a posix
socket. This is my code:

sd = create_socket(address, 2009);
char *req = "/netjsoninfo graph";
int sent =send(sd,req,strlen(req),0);
if(!receive_data_olsr2(sd, &buffer)){
	return 0;
}

My problem is that 'recv' inside receive_data_olsr2 hangs
because I' not receiving anything from the telnet plugin.

Analyzing the connection of 'nc' with wireshark I discovered that telnet
plugin answer back only after a "FIN" flag.

Am I doing something wrong in my code? Is there a way to send the FIN
flag without closing the socket?

Thanks, Gabriel

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Bastian Bittorf | 19 May 15:49 2016
Gravatar

olsrd1 / broken: LinkQualityMult default

Greetings to all,

back from Battlemesh v9 i recognized something odd
while debugging a flapping route with olsrd1:

the relevant section is:

Interface "eth0.2"
{
        LinkQualityMult default 0.4
        Ip4Broadcast 255.255.255.255
        HelloInterval 3.0
        HelloValidityTime 125.0
        TcInterval 2.0
        TcValidityTime 500.0
        MidInterval 25.0
        MidValidityTime 500.0
        HnaInterval 10.0
        HnaValidityTime 125.0
}

so this is a perfect wired link and i'am using the metric 'etxff_eth'.
so with a default of 0.4 every link should in theory go to 40% which is
around 2.500 but is does not. When setting a specific IP, it works.
(e.g. LinkQualityMult $IP 0.4):

root <at> box:~ wget -qO - http://127.0.0.1:2006/lin | grep $WANADR
Local IP        Remote IP       Hyst.   LQ      NLQ     Cost
10.63.93.189    10.63.60.253    0.000   1.000   1.000   1.000
10.63.93.189    10.63.34.225    0.000   1.000   1.000   1.000
10.63.93.189    10.63.49.225    0.000   1.000   1.000   1.000

it's not old and runs with OpenWrt r49276 (sorry, not on LEDE yet)
pre-0.9.1-git_f851f12-hash_a3636978d19797e7d895256c8cc6c575

any idea what i'am doing wrong?

bye, bastian

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge | 22 Apr 12:39 2016
Picon

Re: OSLRd2 segmentation fault

Hi,

can you maybe compile an "OONF-GIT" package?

just use the Github repository as a package feed for olsrd2 and you
should get a "make menuconfig" selection named "oonf-olsrd2-git".

This should be an easy way to generate the latest version of the code
(which should contain a fix for at least one buggy path you
discovered).

This "impossible trace" is normally a sign that the executable doesn't
match the one of the build system.

Did you remove/uninstall the old executable before trying to install
the new one?

Henning

On Fri, Apr 22, 2016 at 12:34 PM, Gabriel <gabriel <at> autistici.org> wrote:
> The patch works for Debian Wheezy on MIPS.
>
> I've also tested the patch on openwrt 15.05, and it is not working. The
> olsrd2 daemon is still segfaulting at the same point.
>
> This is the last debug message:
>
> 12:01:19.596 DEBUG(olsrv2_routing) eady gone 589: Initialize route entry
> dst 172.19.186.3 [0.0.0.0/0] with pathcost 16776960
>
> I compiled the package with "-ggdb" flag and then I tried to debug with
> gdb on the router.
>
> When olsrd2 crashes, gdb print this warning thus is impossible to backtrace:
>
> warning: GDB can't find the start of the function at 0x77fc5224.
>
> This is a stack dump just after the segfault:
>
> http://pastebin.com/d6t1AJLv
>
>
> I've also tried the patch I wrote and it works, so I assume that the
> problem is at the same memcpy instruction.
>
> Gabriel
>
>
>
>
>
> On 21/04/2016 07:59, Henning Rogge wrote:
>> On Thu, Apr 21, 2016 at 4:59 AM, Gabriel <gabriel <at> autistici.org> wrote:
>>>> Using gdb I found out that the instruction causing the SEGFAULT was in
>>>> olsrv2_routing.c at line 598:
>>>>
>>>> memcpy(&rtentry->last_originator, last_originator,
>>>> sizeof(*last_originator));
>>>>
>>>> After the the SEGFAULT I printed the variable "last_originator" in gdb
>>>> and it was null.
>>>>
>>>> I
>>
>> Thank you for locating this place.
>>
>>> Sorry, I forgot to explain what I've done:
>>>
>>> I just put an if statement before the instructions to copy the memory
>>> locations only if the src (last_originator) is not null.
>>
>> Hmm... I think I see what happens.
>>
>> For some reason the IPv6 address on the local node is still missing
>> when the other side sends a NHDP message.
>>
>> Could you test the following attached patch? I think this one fixes
>> the original problem.
>>
>> Henning
>>

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Gabriel | 22 Apr 12:34 2016

Re: OSLRd2 segmentation fault


The patch works for Debian Wheezy on MIPS.

I've also tested the patch on openwrt 15.05, and it is not working. The
olsrd2 daemon is still segfaulting at the same point.

This is the last debug message:

12:01:19.596 DEBUG(olsrv2_routing) eady gone 589: Initialize route entry
dst 172.19.186.3 [0.0.0.0/0] with pathcost 16776960

I compiled the package with "-ggdb" flag and then I tried to debug with
gdb on the router.

When olsrd2 crashes, gdb print this warning thus is impossible to backtrace:

warning: GDB can't find the start of the function at 0x77fc5224.

This is a stack dump just after the segfault:

http://pastebin.com/d6t1AJLv

I've also tried the patch I wrote and it works, so I assume that the
problem is at the same memcpy instruction.

Gabriel

On 21/04/2016 07:59, Henning Rogge wrote:
> On Thu, Apr 21, 2016 at 4:59 AM, Gabriel <gabriel <at> autistici.org> wrote:
>>> Using gdb I found out that the instruction causing the SEGFAULT was in
>>> olsrv2_routing.c at line 598:
>>>
>>> memcpy(&rtentry->last_originator, last_originator,
>>> sizeof(*last_originator));
>>>
>>> After the the SEGFAULT I printed the variable "last_originator" in gdb
>>> and it was null.
>>>
>>> I
> 
> Thank you for locating this place.
> 
>> Sorry, I forgot to explain what I've done:
>>
>> I just put an if statement before the instructions to copy the memory
>> locations only if the src (last_originator) is not null.
> 
> Hmm... I think I see what happens.
> 
> For some reason the IPv6 address on the local node is still missing
> when the other side sends a NHDP message.
> 
> Could you test the following attached patch? I think this one fixes
> the original problem.
> 
> Henning
> 

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
nemesis | 21 Apr 23:12 2016
Gravatar

Re: Fwd: Re: netjson plugin

 Hi everyone,

 thank you all for bringing this up, by reading your discussion I 
 understood that the RFC is not crystal clear and needs to be improved.

 the goal of NetworkGraph is to represent a Network Topology for 
 visualization and monitoring purposes but the initial definition did not 
 allow distance vector protocols to return their partial graph using 
 NetworkGraph, so we changed the definition to allow this (so we could 
 write a generic collector, which we did). Too bad now the definition is 
 vague and can lead to misunderstandings.

 I believe in this case it's appropiate (and surely more useful) for the 
 olsrd1 implementation to return the graph of entire network.

 The discussion about local vs full topology started already a few 
 months ago and I opened an issue on github in order to avoid forgetting 
 the various proposals, see here:
 https://github.com/interop-dev/netjson/issues/25

 I did not have the time to work on that specific issue because I was 
 more focused on writing the RFC draft and write some implementations 
 (rough consensus and running code), netdiff was one of the first 
 implementations of which Gabriel is one of the core contributors. 
 Gabriel also proposed the creation of NetworkGraph and the addition of 
 the "local_addresses" attribute, he knows quite well the matter.

 In the following example, you can see an API that implements NetJSON 
 NetworkGraph, returing the output of the OLSRd1 ninux network in 
 Florence:
 http://ninux-graph.netjson.org/api/topology/643c4577-cef2-4b5e-b8a4-c29756b10748/

 The generated graph can be viewed at this URL:
 http://ninux-graph.netjson.org/topology/643c4577-cef2-4b5e-b8a4-c29756b10748/

 Ferry did send me a sample of the new plugin output, but I did not 
 understand it was intentionally limited to local links, my bad.

 I hope this clears the misunderstanding and I promise to improve the 
 spec and work on issue #25.
 If you have suggestions and alternative proposals please let me know.

 I will also meet Ferry, Henning and everyone interested in improving 
 NetJSON at the battlmesh v9 in Porto (1-7 May 2016).

 Best
 Federico Capoano

 PS: Lara is spot on :-)

 On Thu, 21 Apr 2016 22:47:17 +0200, Gabriel <gabriel <at> autistici.org> 
 wrote:
> Could you give us your opinion on this?
>
>
> Thanks,  Gabriel
> ---------- Messaggio inoltrato ----------
> Da: Conrad Lara <ipstealer <at> cox.net>
> Data: 21 apr 2016 22:23
> Oggetto: Re: [Olsr-dev] netjson plugin
> A: Ferry Huberts <mailings <at> hupie.com>
> Cc: Gabriel <gabriel <at> autistici.org>,olsr-dev <at> lists.olsr.org
>
>> I'm not an expert on netjson,   did I miss a line that says "known" 
>> links are local only on my quick read? If not doesn't OLSR "know" 
>> about all the links because of the OLSR packet forwarding?(dot_draw 
>> determines this already somehow to draw it's graphs)
>>
>> Just because one isn't directly connected to the link doesn't mean 
>> (unless RFC says so) that you don't know about it.  The RFC calls for 
>> a source and  destination id for the link mapping. That could easily 
>> handle showing the remote node. If the source was just the same node 
>> why would the protocol call for a source node ID definition when's 
>> just a destination would tell you everything you need because the link 
>> could only be local? It also doesn't state that the source id must be 
>> the presenting node.
>>
>> A quick google already showers at least one test sample file that 
>> shows this in action as part of the system test for netdiff 
>> https://github.com/ninuxorg/netdiff/blob/master/tests/static/netjson-3-links.json 
>> that it shows more then one source for the links to display (this is 
>> by no means a RFC proof of course as its not from the official source 
>> but makes me think this deserves more in depth discussion)
>>
>>
>> Sent from my iPhone
>>
>> > On Apr 21, 2016, at 12:48 PM, Ferry Huberts <mailings <at> hupie.com> 
>> wrote:
>> >
>> >
>> >
>> >> On 21/04/16 20:47, Gabriel wrote:
>> >> Hi, I've finally managed to get the netjson plugin working.
>> >>
>> >> I noticed that the "links" section contains just the 1-hop links.
>> >> The NetworkGraph should be a representation of the whole network 
>> as
>> >> edges and nodes.
>> >
>> > Incorrect, the RFC says:
>> >
>> >> Definition: a list of nodes and links known by a node.
>> >
>> > See http://netjson.org/rfc.html#rfc.section.4
>> >
>> >
>> > If you want the whole network, you must query all nodes and 
>> combine the info.
>> >
>> >
>> >>
>> >> Is it just a bug or it has been implemented to contain just the 
>> 1-hop links?
>> >>
>> >>
>> >> Gabriel
>> >
>> > --
>> > Ferry Huberts
>> >
>> > --
>> > Olsr-dev mailing list
>> > Olsr-dev <at> lists.olsr.org
>> > https://lists.olsr.org/mailman/listinfo/olsr-dev
>>

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Conrad Lara | 21 Apr 22:23 2016
Picon
Picon

Re: netjson plugin

I'm not an expert on netjson,   did I miss a line that says "known" links are local only on my quick read? If not
doesn't OLSR "know" about all the links because of the OLSR packet forwarding?(dot_draw determines this
already somehow to draw it's graphs)

Just because one isn't directly connected to the link doesn't mean (unless RFC says so) that you don't know
about it.  The RFC calls for a source and  destination id for the link mapping. That could easily handle
showing the remote node. If the source was just the same node why would the protocol call for a source node ID
definition when's just a destination would tell you everything you need because the link could only be
local? It also doesn't state that the source id must be the presenting node.

A quick google already showers at least one test sample file that shows this in action as part of the system
test for netdiff
https://github.com/ninuxorg/netdiff/blob/master/tests/static/netjson-3-links.json that it
shows more then one source for the links to display (this is by no means a RFC proof of course as its not from
the official source but makes me think this deserves more in depth discussion)

Sent from my iPhone

> On Apr 21, 2016, at 12:48 PM, Ferry Huberts <mailings <at> hupie.com> wrote:
> 
> 
> 
>> On 21/04/16 20:47, Gabriel wrote:
>> Hi, I've finally managed to get the netjson plugin working.
>> 
>> I noticed that the "links" section contains just the 1-hop links.
>> The NetworkGraph should be a representation of the whole network as
>> edges and nodes.
> 
> Incorrect, the RFC says:
> 
>> Definition: a list of nodes and links known by a node.
> 
> See http://netjson.org/rfc.html#rfc.section.4
> 
> 
> If you want the whole network, you must query all nodes and combine the info.
> 
> 
>> 
>> Is it just a bug or it has been implemented to contain just the 1-hop links?
>> 
>> 
>> Gabriel
> 
> -- 
> Ferry Huberts
> 
> -- 
> Olsr-dev mailing list
> Olsr-dev <at> lists.olsr.org
> https://lists.olsr.org/mailman/listinfo/olsr-dev

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Gabriel | 21 Apr 20:51 2016

OONF compilation fails on Debian

Hi, I'm using OONF on Debian Wheezy. If i try to compile it using "make
all" the process terminate with this error:

[ 57%] Built target oonf_static_layer2
[ 57%] Building C object
src-plugins/subsystems/CMakeFiles/oonf_static_os_tunnel.dir/os_linux/os_tunnel_linux.c.o
/opt/OONF/src-plugins/subsystems/os_linux/os_tunnel_linux.c: In function
'_handle_ipv6_tunnel':
/opt/OONF/src-plugins/subsystems/os_linux/os_tunnel_linux.c:222:24:
error: storage size of 'p' isn't known
/opt/OONF/src-plugins/subsystems/os_linux/os_tunnel_linux.c:222:24:
error: unused variable 'p' [-Werror=unused-variable]
cc1: all warnings being treated as errors
make[2]: ***
[src-plugins/subsystems/CMakeFiles/oonf_static_os_tunnel.dir/os_linux/os_tunnel_linux.c.o]
Error 1
make[1]: ***
[src-plugins/subsystems/CMakeFiles/oonf_static_os_tunnel.dir/all] Error 2
make: *** [all] Error 2

I managed to get olsrd2 compiling the target "olsrd2_static"

thanks, Gabriel

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev

Gmane