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)

Conrad Lara | 10 Nov 18:56 2014
Picon
Picon

Re: Problem with compile olsrd on SDK AirmaxOS

It was Waldek with the compile issue for IPV6_V6ONLY 

My setup compiled clean with just the the first patch removing the reference to IPV6_TCLASS (which I
actually did weeks ago)

Explains why I didn't see the IPV6_V6ONLY issue however as 7.09 has 2.4.34 for the kernel base.

As I suggested, I recommend a policy decision on minimum supported versions (kernel, GCC, etc) and
anything outside those specs is "unsupported" vs polluting the code base with lines that no one is
maintaining.  This is why I never brought the issue forward when I hit it as I figured it was probably old
enough not to be a worry.

I've already hit my share of issue in olsrd related to code rot, more lines of code isn't always a good thing.

Sent from my iPhone

> On Nov 10, 2014, at 5:58 AM, Ferry Huberts <mailings <at> hupie.com> wrote:
> 
>  <at> Conrad:
> 
> This means that the only thing you have to do is to upgrade your kernel to at least 2.4.21 and you can use IPV6_V6ONLY
> 
> 
>> On 10/11/14 14:56, Ferry Huberts wrote:
>> 
>> 
>>> On 10/11/14 14:03, Henning Rogge wrote:
>>> The patches look reasonable, they should not be a problem with the
>>> current kernels.
>>> 
(Continue reading)

Henning Rogge | 10 Nov 14:15 2014
Picon

Re: Problem with compile olsrd on SDK AirmaxOS

On Mon, Nov 10, 2014 at 1:56 PM, Waldek SPdwaONG <sp2ong <at> gmail.com> wrote:
> Hi,
>
> One big problem for old devices UBNT like NS2 (not NS Mx models) where we
> use AirMAX OS SDK which have kernel 2.4.x and if we want to use latest olsr
> we have problem with compile (but after apply patch now OK).
> I have try use OpenWRT Attitude Adjustment on NS2 but is is not enough space
> to load olsrd with plugins

I think that depends on the amount of features you built into your router.

> and  it is very slow WEB interface compare to original AirMAX OS.

I am not sure that should be a big concern... how often do you use the
web interface of your router? Compared to the lack of a few years of
updates for your kernel and userspace tools.

> One way with NS2 NS5 etc UBNT is use Backfire 10.03.1
> but WEB interface is slowly to compare AirMAX OS for this reason we can only
> use AirMAX SDK with kernel 2.4 or Backfire OpenWRT.

I don't think I agree with this reasoning... but you should be aware
that support for your software platform of choice is somewhere between
"bad" and "not existing" in the future.

Henning Rogge

--

-- 
Olsr-dev mailing list
Olsr-dev <at> lists.olsr.org
(Continue reading)

Henning Rogge | 10 Nov 14:03 2014
Picon

Re: Problem with compile olsrd on SDK AirmaxOS

The patches look reasonable, they should not be a problem with the
current kernels.

Ferry, do you see a problem with these changes?

Hennig

On Mon, Nov 10, 2014 at 1:56 PM, Waldek SPdwaONG <sp2ong <at> gmail.com> wrote:
> Hi,
>
> One big problem for old devices UBNT like NS2 (not NS Mx models) where we
> use AirMAX OS SDK which have kernel 2.4.x and if we want to use latest olsr
> we have problem with compile (but after apply patch now OK).
> I have try use OpenWRT Attitude Adjustment on NS2 but is is not enough space
> to load olsrd with plugins and  it is very slow WEB interface compare to
> original AirMAX OS. One way with NS2 NS5 etc UBNT is use Backfire 10.03.1
> but WEB interface is slowly to compare AirMAX OS for this reason we can only
> use AirMAX SDK with kernel 2.4 or Backfire OpenWRT.
> This patch is necessary for unix/iface.c
> and lib/txtinfo/src/olsrd_txtinfo.c, lib/jsoninfo/src/olsrd_jsoninfo.c to
> problem with "IPV6_V6ONLY"
>
> I have apply (it is work but I am not sure that iti is correct place):
>
> #if defined linux
>     if (jsoninfo_ipv6_only && olsr_cnf->ip_version == AF_INET6) {
> #ifdef IPV6_V6ONLY
>       if (setsockopt(ipc_socket, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&yes,
> sizeof(yes)) < 0) {
>         perror("IPV6_V6ONLY failed");
(Continue reading)

Conrad Lara | 10 Nov 12:23 2014
Picon
Picon

Re: Problem with compile olsrd on SDK AirmaxOS

Ultimately I'm a fan of a published   minimum system requirements.

I don't have an opinion on what kernel level is supported, but whatever it is any code coming in should be
required to run on the minimum supported version.

This applies equally to OLSRD and OLSRD2.  Only way to do that is to set a policy (again haven't seen one
published in any readme)

This also equally applies to any code that may be BSD based, MAC based, etc.

After that it's a different subject of do you bother to accept code for older versions. I would generally say
not to as at that point your adding extra code for an unsupported system base and it's that persons
responsibility who's compiling for an unsupported install base to make it work.

Sent from my iPhone

> On Nov 10, 2014, at 2:55 AM, Ferry Huberts <mailings <at> hupie.com> wrote:
> 
> I can say that I have zero interest in supporting 2.4 kernels.
> Personally I don't even care about 2.6 but I can see that there are people out there using it.
> 
> AFAIC any 2.4 maintenance has to be done by someone else.
> And any patches to that purpose must be non-invasive and well documented :-)
> 
> 
> I'm in the process of adding the last big piece to olsrd v1; the missing piece of the multi-smart-gateway functionality.
> After that olsrd will go into maintenance mode.
> 
> New development should (probably) be done on olsrd v2.
> 
(Continue reading)


Gmane