Ferry Huberts | 23 Mar 15:02 2015

Re: [Olsr-users] OLSR 0.6.8 on OpenWrt with ipv6 and kernel 3.18.x


On 23/03/15 14:58, Russell Senior wrote:
> But, the config is identical, except for the kerrnel version (3.14 vs
> 3.18).  Or am I misunderstanding your suggestion.

I mean to also setup networking the same.
So if other nodes have no bridge, then first remove it.
Try with the kernel version of other nodes.
First make stuff the same, then start changing things

>
> On Mon, Mar 23, 2015 at 4:21 AM, Ferry Huberts <mailings <at> hupie.com> wrote:
>> ok, I read the thread.
>>
>> Sadly, no clue comes to mind.
>> I'd start with making your new node 'identical' in config to an existing
>> node and see if you still have the problem.
>> If not, then bisect towards the config you have now to see when it breaks.
>>
>>
>>
>> On 23/03/15 08:47, Russell Senior wrote:
>>>>>>>>
>>>>>>>> "Ferry" == Ferry Huberts <mailings <at> hupie.com> writes:
>>>
>>>
>>> Ferry> On 23/03/15 08:18, Russell Senior wrote:
>>>>>
>>>>>
>>> Ferry> I am skiing now so I didn't read the full thread.  Might be
(Continue reading)

Philipp Borgers | 13 Mar 00:18 2015
Picon
Picon

accidental push to olsr master

Hi,

while hacking on the olsrd code base with a friend we accidental pushed our
changes to the olsrd.org git repository [1]. We reverted our change to the
master and pushed the revert as well.

The fact that we can push to the upstream repository confused us quite a bit.

Sorry for the inconvenience.

Kind Regards
Philipp and Sebastian

[1] http://olsr.org/git/?p=olsrd.git;a=summary
--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge | 21 Feb 10:59 2015
Picon

OLSR.org Network Framework v0.7.0 released

Hi,

I tagged the version 0.7.0 of the Olsr.org Network Framework (which
includes olsrd2).

There have been quite a few important changes and fixes:

- better CMake makefile which makes it easy to compile and install
only parts of OONF
- Support for multiple application targets (olsrd2, dlep,
minimal-oonf) in the makefile
- Hysteresis mechanism for DAT routing metric for better stability

and lots and lots of fixed bugs we found during testing on our
Institutes Mesh Network.

As always you can find the new release in the repository, it is tagged
"v0.7.0" with a GPG signature.
http://olsr.org/git/?p=oonf.git;a=summary

See also here for a lot of documentation about OONF and olsrd2:
http://www.olsr.org/mediawiki/index.php/OLSR.org_Network_Framework

Henning Rogge

--

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

(Continue reading)

Saverio Proto | 15 Feb 21:19 2015
Picon

tcpdump olsr_print CVE-2014-8767

Hello there,

http://www.gentoo.org/security/en/glsa/glsa-201502-05.xml

anyone here contributed to write the olsr parser in tcpdump ?

The olsr_print function function contains an integer underflow error
(CVE-2014-8767)

dont worry, the bug is in tcpdump, not in olsrd, but if someone here
has a patch, now it is time to merge it upstream to the tcpdump people
:)

Saverio

--

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

Conrad Lara | 5 Jan 22:55 2015
Picon
Picon

Re: PlParam "IP.ADDR" "another-name.mesh"

To me on quick glance appears to be an intentional function of init_olsr_plugin() in plugin_loader.c

It checks if the entry->plugin_paramaters[i].name[0] value is == 0 and then specifically passes the key
name (in this case an IP address) as an ADDON value to the registers function.  

It's appears to act as way to register a catch all function. Internally the key name isn't zero it actually is
the IP address for the key name

This method in nameservice.c was changed when went to the "new plugin interface" around 2005 before then it
was an "if key is else if key is else if key is else assume it's an IP address hostname pairs.

Sent from my iPhone

> On Jan 5, 2015, at 12:51 PM, Henning Rogge <hrogge <at> gmail.com> wrote:
> 
>> On Mon, Jan 5, 2015 at 8:30 PM, Joe Ayers <joe <at> ayerscasa.com> wrote:
>> True to the DNA of Ham Radio, we've been known to use metal rain gutters and
>> coat hangers for antennas.   If it's effective and works until something
>> better is available  ... :) .
> 
> I am surprised it works at all... the "zero length key" is most likely
> some unintended behavior of the configuration parser of olsrd1.
> 
> But I have to admit that I am not surprised that something like this
> exists in olsrd1... *G*
> 
> Henning Rogge
> 
> -- 
> Olsr-dev mailing list
(Continue reading)

Conrad Lara | 3 Jan 11:33 2015
Picon
Picon

Re: PlParam "IP.ADDR" "another-name.mesh"

Is this a Commotion only change that it doesn't accept it? or something that just recently was pulled out? 
Quick glancing the code it looks like it still should work to me.

I am using this feature on my network (0.6.7) from OLSR.org with BBHN patch sets that don't touch
nameservice) without issue.

This is the exception to the normal rule of having a setting name value pair in that it uses the IP address is
where the parameter name normally is and the value is the hostname.

Make sure you are using a properly formatted IP address. Also the IP used has to be in your local list of OLSR
listens addresses OR your HNA announcement range otherwise it will be thrown out as invalid.

Sent from my iPhone

> On Jan 3, 2015, at 1:24 AM, Ferry Huberts <mailings <at> hupie.com> wrote:
> 
> 
> 
>> On 02/01/15 16:50, Giuseppe De Marco wrote:
>> Hi all,
>> 
>> last night I saw that the parameter
>> 
>> PlParam "10.87.x.y" "another-hostname.mesh"
> 
> 
> There is no such parameter, see https://github.com/opentechinstitute/olsrd/blob/commotion/lib/nameservice/src/nameservice.c#L256
> 
> The format is
> 
(Continue reading)

Giuseppe De Marco | 2 Jan 16:50 2015
Picon

PlParam "IP.ADDR" "another-name.mesh"

Hi all,

last night I saw that the parameter

PlParam "10.87.x.y" "another-hostname.mesh"

doesn't work.
Reading the

https://github.com/opentechinstitute/olsrd/blob/commotion/lib/nameservice/src/nameservice.c

in line 227 and then in line 435 I saw that this parameter were not
parsed at all.
Is there any possibility to have this feature fully working in the
next months or should we - in my local mesh community- develop it by
hand ?

If we have to implement this by hand could someone describe us some
hints and suggestions about the code design to speed up the
integration of theese little bunch of code ?

Thank you all,
olsrd is awesome,
Giuseppe

--

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

(Continue reading)

Henning Rogge | 28 Dec 12:57 2014
Picon

Re: Bug #48

On Sat, Dec 27, 2014 at 10:59 PM, André Gaul <andre <at> gaul.io> wrote:
> Am 27.12.2014 um 09:20 schrieb Henning Rogge:
>> Looking forward the hear about the results.
>
> unfortunately, this does not resolve the memory leak. I just reproduced
> the issue on openwrt trunk with your patch. I simply added a wifi-iface
> with station mode and an ssid that doesn't exist (so the interface
> doesn't come up):
>
> config wifi-iface
>         option device   radio1
>         option network  wireless1
>         option mode     sta
>         option ssid     doesntexist
>         option encryption none
>
> Adding this interface to the olsrd6 config then again results in the
> memory leak and the messages
>
> Sat Dec 27 21:08:09 2014 daemon.info olsrd[1682]: Adding interface wlan1
> Sat Dec 27 21:08:09 2014 daemon.err olsrd[1682]: bind: Cannot assign
> requested address
>
> are logged roughly every second.
>
>> No, I will be not at the CCC...
>
> Too bad! Maybe you have another idea about solving this issue?

I cannot use valgrind on openwrt (and I don't have wireless hardware
(Continue reading)

Henning Rogge | 27 Dec 09:20 2014
Picon

Re: Bug #48

On Sat, Dec 27, 2014 at 2:15 AM, André Gaul <andre <at> gaul.io> wrote:
> Hey Henning!
>
> Am 23.12.2014 um 15:54 schrieb Henning Rogge:
>> after reading your new bug report (and looking for a moment at some
>> insanity in the code), could you maybe test the following patch?
>
> thx for the patch, we're going to test it in the next days.

Looking forward the hear about the results.

> btw, are you also participating at 31c3? I'll be mostly hanging around
> at the freifunk assembly. :)

No, I will be not at the CCC...

Henning Rogge

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Henning Rogge | 23 Dec 15:54 2014
Picon

Bug #48

Hi,

after reading your new bug report (and looking for a moment at some
insanity in the code), could you maybe test the following patch?

Henning
Attachment (olsrd.patch): text/x-patch, 2354 bytes
--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
https://lists.olsr.org/mailman/listinfo/olsr-dev
Ferry Huberts | 13 Nov 23:14 2014

Re: [OLSRd 0000047]: memory leak on one remote end of point to point link

Taking the bug onto the dev mailing list...

You are running an olsrd with a git sha that is not in our tree...
We can't reasonably support that since we don't know what you are running.

Having said that, we need to at least see the olsrd config file.
Also, smart gateway is complaining about kmod_ipip so it appears you 
turned it on?

On 13/11/14 23:05, Mantis Bug Tracker wrote:
>
> The following issue has been SUBMITTED.
> ======================================================================
> http://olsr.org/bugs/view.php?id=47
> ======================================================================
> Reported By:                valentt
> Assigned To:
> ======================================================================
> Project:                    OLSRd
> Issue ID:                   47
> Category:                   Core
> Reproducibility:            always
> Severity:                   major
> Priority:                   normal
> Status:                     new
> ======================================================================
> Date Submitted:             2014-11-13 23:05 CET
> Last Modified:              2014-11-13 23:05 CET
> ======================================================================
> Summary:                    memory leak on one remote end of point to point link
(Continue reading)


Gmane