[Olsr-users] multiple domains in olsrv2

nemesis (spam-protected)
Thu Oct 4 15:45:01 CEST 2018

 On Wed, 3 Oct 2018 10:01:02 +0200, Henning Rogge <(spam-protected)> 
> On Wed, Oct 3, 2018 at 9:45 AM Gabriel <(spam-protected)> wrote:
>> So i think we have two problems:
>> 1:
>> the acl should be 'default accept' as you said, otherwise you always
>> have to explicitly allow something.
> This should be easy...
>> 2:
>> the UCI parser in OONF have problems with named sections:
>> I tryied the 4 possibilities w and w\o section name and option name 
>> and
>> OONF doesn't work if you specify the section name without specifyin 
>> an
>> option name.
>> IMHO the option name is redundant and we should only use the section
>> name.
> OONF uses libuci... which does (as far as I know) not support section
> names well... to be specific, it doesn't allow two section of
> different types with the same name. I had to work around this, I 
> don't
> remember any better solution.
> I do NOT want to implement a parser for a configuration format 
> without
> a good specification myself.
> If you have a good suggestion, feel free to post it here. OONF
> implement configuration formats as plugins, so it would be easy to
> implement something different.

 Hi guys,

 permit me to step-in in the conversation.

 I think it's better to avoid using section names to determine software 
 In my understanding the names of UCI section are a kind of ID which is 
 to allow updating specific configuration objects by referring to them 
 via this ID.
 That means we shouldn't use the UCI ID in place of the name config 
 option because that's
 not how that internal feature of UCI is meant to be used.
 Yes it means to have a bit of redundancy if you want the section to 
 have the same name you use,
 for the option name, but it's not a big deal if this redundancy is 
 managed by  an automated system.
 Non automated systems can do without the UCI name entirely.

 That said, Henning, why is the code not working if the section is 
 That doesn't sound like something which is meant to happen and I think 
 it would surely help OLSRd2 if this is avoided.
 I am not using the C bindings to manipulate UCI configurations, I'm 
 only using lua and shell to do that,
 but in my understanding the lua bindings are using the C library under 
 the hood.
 With the lua bindings I am still able to loop over configuration types, 
 even if they do have a name.
 Can we do something similar in this case?
 Could you share the piece of code that deals with this part so we can 
 take a look at it?


More information about the Olsr-users mailing list