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
(Continue reading)

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
>
(Continue reading)

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
(Continue reading)

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:
(Continue reading)

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:
(Continue reading)

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
Gabriel | 21 Apr 20:47 2016

netjson plugin

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.

Is it just a bug or it has been implemented to contain just the 1-hop links?

Gabriel

--

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

Re: OSLRd2 segmentation fault


On 20/04/2016 20:03, Henning Rogge wrote:
> On Wed, Apr 20, 2016 at 8:01 PM, Gabriel <gabriel <at> autistici.org> wrote:
>> I'm running 0.9.2 on openwrt(ar7xxx) and 0.11.2
>> on debian(MIPS64)
> 
> Please update to 0.11.2 (or 0.11.3) on both systems...
> 
> if you want to use 0.11.3 for OpenWRT you can use my own Routing Feed
> (I expect 0.11.3 to appear in the official one in the next days).
> 
> https://github.com/HRogge/packages
> 
> Henning
> 

I've updated to 0.11.3 on OpenWRT. The Edgerouter is still running 0.11.2

The daemons behave in the same way as before.

This are the last lines of strace on the Openwrt router:

writev(3, [{"20:35:32.694 DEBUG(olsrv2_routin"..., 130}, {NULL, 0}], 2)
= 130
clock_gettime(CLOCK_REALTIME, {1461177332, 700907012}) = 0
munmap(0x77942000, 27)                  = 0
open("/etc/TZ", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC) = 26
fstat64(26, {st_mode=S_IFREG|0644, st_size=27, ...}) = 0
mmap2(NULL, 27, PROT_READ, MAP_SHARED, 26, 0) = 0x77942000
close(26)                               = 0
(Continue reading)

Gabriel | 20 Apr 22:25 2016

Re: OLSRd SegFault


On 20/04/2016 21:49, Ferry Huberts wrote:
> Please give me more info so that I can try to reproduce it.
> 
> How did you compile?
I compiled it locally on the machine, i've tryied a couple of times.
These are the commands i use:

git clone https://github.com/OLSR/olsrd.git
cd olsrd
make
make libs
make install
make install_libs

> How did you run?

/usr/local/sbin/olsrd -f /etc/olsrd/olsrd.conf.netjson

> What do your interface look like (ifconfig)?
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 fdc0:ffee::10:150:25:1/128 scope global
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
master br0 state DOWN
(Continue reading)


Gmane