OLSR LQ Defaults

Andreas, Thomas et al.,

yesterday evening I have some smalltalk with elektra about olsrd settings 
for more routing stabiltity. Because there are several devices currently 
running that Freifunk Firmware, I want to socialize about changed default 
settings prior to a mass deploy with the next FFF update. Currently, we use 
these defaults (a bit slower than the settings proposed with the source 
package to save CPU power with a more static not moving nodes setup):

Pollrate                0.5
TcRedundancy            2
MprCoverage             3
LinkQualityWinSize      18
LinkQualityLevel 2
UseHysteresis no
Interface "ethX"
{
        HelloInterval           5.0
        HelloValidityTime       90.0
        TcInterval              15.0
        TcValidityTime          90.0
        MidInterval             15.0
        MidValidityTime         90.0
        HnaInterval             15.0
        HnaValidityTime         90.0
}

Elektra points out, that it would be more stable with olsrd-0.4.10 if 
TcInterval is shorter than the HelloInterval. This may overcome the "routing 
loop problem" encountered occasionally because topology info is spreaded 

Re: OLSR LQ Defaults

Sven-Ola, everybody,

Sounds good to me. IMO it's very cool that we get some defaults
based on rather long-term real-life usage 
If nobody objects to this these will be the LQ defaults for
0.4.10.

(We're very interested in this sort of feedback before the
release!)

- Andreas

> Andreas, Thomas et al.,
>
> yesterday evening I have some smalltalk with elektra about olsrd settings
> for more routing stabiltity. Because there are several devices currently
> running that Freifunk Firmware, I want to socialize about changed default
> settings prior to a mass deploy with the next FFF update. Currently, we
> use
> these defaults (a bit slower than the settings proposed with the source
> package to save CPU power with a more static not moving nodes setup):
>
> Pollrate                0.5
> TcRedundancy            2
> MprCoverage             3
> LinkQualityWinSize      18
> LinkQualityLevel 2
> UseHysteresis no
> Interface "ethX"
> {

[PATCH] Improvements in dot_draw plugin

The attached patch removes lots of duplicated stuff by adding a
ipc_send_str() function.
Furtehr a few typos are corrected and a function and several variables
were made "static".
It is against 0.4.9.

The open questions are:
- Do you actually appreciate such patches?
  And in that format?
- There severe problems there also: The use of sprintf() is dangerous
  since the function doesn't know how long the buffer.
  The obvious fix is to replace it (unconditionally) with the - now
  common on glibc systems - snprintf() (which I could do). The question
  is if non-Linux-OSes have a problem with such a fix.
  I'm also not a friend of strcpy()/strcat() for the same reason.
  And BTW strncpy()/strncat() have the problem that they do not
  guarantee a terminating \0 character in the string.
- Do you want more such "cleanup" patches?
  And can they be done so that *BSD and Win* do not suffer from
  Linux-isms I'm probably introducing?

	Bernd
--

-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [PATCH] Improvements in dot_draw plugin

Hi Bernd,

Thanks, patches are always appreciated 
But if you can make them against the current CVS version you'll make
life easier for everybody and you make sure you're not fixing something
that is already fixed.

Regarding the sprintf issue I agree that it is bad, but in this code the
string arguments passed to the %s format is always the result for the
olsr_ip_to_string fuction which I regard to be a "controlled" result.
In the core olsrd code there is (AFAIK) no use of potentially dangerous
string functions, but in plugins such as this I don't think this is a
big problem. But if you'd like to clean it up in a platform independent
way, feel free to do so 

- andreas

Bernd Petrovitsch wrote:
> The attached patch removes lots of duplicated stuff by adding a
> ipc_send_str() function.
> Furtehr a few typos are corrected and a function and several variables
> were made "static".
> It is against 0.4.9.
> 
> The open questions are:
> - Do you actually appreciate such patches?
>   And in that format?
> - There severe problems there also: The use of sprintf() is dangerous
>   since the function doesn't know how long the buffer.
>   The obvious fix is to replace it (unconditionally) with the - now

snprintf(), ...

Hi Bernd,

[Bernd suggested to use snprintf() et al. instead of sprintf(), strcat(),
...]

On Win32 olsrd uses msvcrt.dll, which ships with Windows, as its C
library. I've just checked and the version on my system (XP Service Pack
2) has snprintf(), strncpy(), and strncat(). However, I am not sure since
which Windows version these functions exist inside msvcrt.dll. So maybe
we'd break compatibility with earlier Windows versions by using them. But
then again, there should BSD-licensed source code available somewhere for
them, which we could include with olsrd for platforms that do not support
them natively.

-Thomas

Re: snprintf(), ...

On Mon, 2005-11-07 at 10:47 +0100, Thomas Lopatic wrote:
[...]
> [Bernd suggested to use snprintf() et al. instead of sprintf(), strcat(),
> ...]
> 
> On Win32 olsrd uses msvcrt.dll, which ships with Windows, as its C
> library. I've just checked and the version on my system (XP Service Pack
> 2) has snprintf(), strncpy(), and strncat(). However, I am not sure since
> which Windows version these functions exist inside msvcrt.dll. So maybe
> we'd break compatibility with earlier Windows versions by using them. But
> then again, there should BSD-licensed source code available somewhere for
> them, which we could include with olsrd for platforms that do not support
> them natively.

A license compatible to the olsrd license is enough since the simple
integration is "put the source into the tree and add a #define for it".
I have to take a closer look into the Makefile to see what's the
simplest solution.

	Bernd
--

-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: snprintf(), ...

[adding source code for snprintf() to the olsrd source code]

>> But
>> then again, there should BSD-licensed source code available somewhere
>> for
>> them, which we could include with olsrd for platforms that do not
>> support
>> them natively.
>
> A license compatible to the olsrd license is enough since the simple
> integration is "put the source into the tree and add a #define for it".
> I have to take a closer look into the Makefile to see what's the
> simplest solution.

Wait a second... Is this really the case? Would we (or other people) be
allowed to distribute binary-only versions for, for example, Windows if we
used a GPLed implementation of snprintf() in olsrd?

Hmmm. Maybe we should simply use OpenBSD's implementation. We'd then
probably have the world's safest snprintf() in olsrd.  And it would
come with a BSD license.

-Thomas

Re: snprintf(), ...

On Mon, 2005-11-07 at 11:06 +0100, Thomas Lopatic wrote:
> [adding source code for snprintf() to the olsrd source code]
[...]
> > A license compatible to the olsrd license is enough since the simple
> > integration is "put the source into the tree and add a #define for it".
> > I have to take a closer look into the Makefile to see what's the
> > simplest solution.
> 
> Wait a second... Is this really the case? Would we (or other people) be
> allowed to distribute binary-only versions for, for example, Windows if we
> used a GPLed implementation of snprintf() in olsrd?

Probably no. What does the license.txt actually mean? BSD-like?

And it is actually an interesting question: Am I forced to provide the
source code if the only GPL source is in a separate .c and .h file but
actually the code is not present in the compiled (and handed out) output
because the program links aginst a (system-)library which provides the
desired function(ality).

> Hmmm. Maybe we should simply use OpenBSD's implementation. We'd then
> probably have the world's safest snprintf() in olsrd.  And it would

Yes, we all know about the bugs in (OpenBSDs original) openssh years
ago

> come with a BSD license.

I don't care *which* one (as long as I don't have to write one).

Re: [PATCH] Improvements in dot_draw plugin

On Mon, 2005-11-07 at 07:14 +0100, Andreas Tønnesen wrote:
[...]
> Thanks, patches are always appreciated 
> But if you can make them against the current CVS version you'll make
> life easier for everybody and you make sure you're not fixing something
> that is already fixed.

ACK. And I (tried to) apply to former patch. A similar one against
current cvs is attached.

> Regarding the sprintf issue I agree that it is bad, but in this code the
> string arguments passed to the %s format is always the result for the
> olsr_ip_to_string fuction which I regard to be a "controlled" result.

Yes, of course I don't want to imply that anything is seriously broken
*now* (please insert definition of "seriously broken" here.
It is just to be sure that no (hidden) bug is introduced if e.g. some of
the controlled functions (like inet_ntoa()) is replaced at sometime in
the future with not-so-controlled functions (or even worse that parts of
these strings comes from the config-file or command line).
And I don't think that one (especially not me) checks *all* callers of a
function if such a change is made just to check that some buffer is
large enough after the change.

> In the core olsrd code there is (AFAIK) no use of potentially dangerous
> string functions, but in plugins such as this I don't think this is a

I will explain the potential weakness with the patches (even if they are
quite pathological cases).
And gcc (especially gcc-4.0x) has also a lot of nice warnings to find

[PATCH] add .cvsignore files

against current cvs. To be applied with
----  snip  ----
cd olsrd-current && patch <olsrd-cvsignore.patch
----  snip  ----

	Bernd
--

-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

_______________________________________________
olsr-dev mailing list
olsr-dev <at> olsr.org
https://www.olsr.org/mailman/listinfo/olsr-dev