how to support the augment YANG model based on another augment YANG model

[Adrian Pan]

I would like to support the augment YANG model based on another augment YANG model, we have our private ospf YANG model private-ospf.yang augments the ietf-ospf yang model while ietf-ospf is the augment yang model of ietf-routing.

what I have done?
1)use lnctool to generate the related transapi callback functions with ietf-routing as base model and ietf-ospf and our private-ospf as the augment yang model
2)use ncds_add_model to add the ietf-ospf and private-ospf to the datastore of ietf-routing as below
ncds_add_model("/var/lib/libnetconf/models/ietf...@2014-09-17.yin");
ncds_add_model("/var/lib/libnetconf/models/privat...@2015-02-05.yin");
ncds_add_models_path("/var/lib/libnetconf/models/");
3)configure the objects defined by private-ospf

Problem:
I found the Netconf Server can't parse the configuration for the private-ospf correctly, after the debug I found it because the related xmlDocPtr does not have the private-ospf information.

what's wrong here? Is it the libnetconf limitation or I did it incorrectly?

thanks
Adrian

[Radek Krejčí]

Hi Adrian,

I have a few questions to get more info to be able to help you.

1) are you using netopeer-server or do you have your own NETCONF server implementation?
2) is it possible to share the data-models you are using? It would help to detect possible problems - libnetconf does not support all YANG features (e.g. deviation)
3) what do you mean bythe "related xmlDocPtr"?

Regards,
Radek

Dne 18.3.2015 v 09:22 Adrian Pan napsal(a):

[Radek Krejčí]

Hi Adrian,
I've found and fixed bug in libnetconf, so please pull (master or 0.9.x branch) and check if the fix works for you.

Best regards and thank you for reporting the problem :)

Radek

Dne 18.3.2015 v 13:15 潘自全 napsal(a):

Hi Radek,

The ext_model is not empty, it includes the information of ietf-routing and ietf-ospf. I call ncds_consolidate() after ncds initiation and adding models of ietf-ospf and private ospf model.

The attachments are the ietf-routing and ietf-ospf YANG models and YIN files.

thanks

Adrian

[Radek Krejčí]

yes, the problem should be only in the datastore.c, libnetconf was working with the wrong element when resolving the augment path, But please configrm that it works for you, I was testing only using the lncdatastore tool, so I can be missing some other consequences performed by libnetconf functions (e.g. lncdatastore does not initiate internal datastores, but the nc_init() used by the server usually does this).

Radek

PS: if possible, keep the discussion in the mailing list

Dne 18.3.2015 v 15:44 潘自全 napsal(a):

Hi Radek,

thanks a lot for your quick response and so quick fix, may I confirm that the fix is in the file Datastore.c only?

thanks

Adrian

[潘自全]

Hi Radek,

Today when I do the verification, I think the second augment models have been added to the datastore, but at the same time I met another critical problem before to call transapi_running_changed. The log is attached as below, I am not sure whether it's related with the fix or it's a new problem. When I change it back as below, the 

 Segmentation fault disappear. Could you help to look into this segmentation fault?

thanks

Adrian

/* some augment found, now check it */

free(module_inpath);

module_inpath = (char*) xmlGetNsProp(node, BAD_CAST "module", BAD_CAST "libnetconf");

change back to 

/* some augment found, now check it */

free(module_inpath);

module_inpath = (char*) xmlGetNsProp(path_node, BAD_CAST "module", BAD_CAST "libnetconf");

<?xml version="1.0" encoding="UTF-8"?>

<rpc message-id="102"

     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"

     xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"

     xmlns:ospf="urn:ietf:params:xml:ns:yang:ietf-ospf"

     xmlns:eospf="urn:com:ericsson:yang:ericsson-ospf">

  <edit-config>

    <target>

      <running />

    </target>

    <config>

      <rt:routing>

        <rt:routing-instance>

          <rt:name>ri-local</rt:name>

          <rt:description>routing instance for context local</rt:description>

          <rt:routing-protocols>

            <rt:routing-protocol>

              <rt:type>ospf:ospfv2</rt:type>

              <rt:name>ospf0</rt:name>

              <rt:description>configuration for OSPF based PE-CE route distribution</rt:description>

              <ospf:ospf>

                <ospf:instance>

                  <ospf:routing-instance>ri-local</ospf:routing-instance>

                  <ospf:af>rt:ipv4-unicast</ospf:af>

                  <ospf:area>

                    <ospf:area-id>0.0.0.0</ospf:area-id>

                    <ospf:area-type>ospf:nssa</ospf:area-type>                                

                  </ospf:area>               

                </ospf:instance>                  

              </ospf:ospf>

            </rt:routing-protocol>            

          </rt:routing-protocols>    

        </rt:routing-instance>

      </rt:routing>

    </config>

  </edit-config>

</rpc>

V| Merging the node routing (sw/se/xc/bsd/comp/libnetconf/src/datastore/edit_config.c:2311)

V| Creating the node routing (sw/se/xc/bsd/comp/libnetconf/src/datastore/edit_config.c:1497)

V| Deleting the node routing (sw/se/xc/bsd/comp/libnetconf/src/datastore/edit_config.c:1022)

Segmentation fault (core dumped)

2015-03-18 23:14 GMT+08:00 Adrian Pan <pan...@gmail.com>:

thanks for the confirmation and advice, your support is really highly appreciated.

I will do the verification tomorrow Beijing time, will let you know the result once I have it.

thanks
Adrian

-------- 原始邮件 --------
主题：Re: [libnetconf] how to support the augment YANG model based on another augment YANG model
发件人：Radek Krejčí
收件人：潘自全 ,libnetconf
抄送：

[Radek Krejčí]

Hi Adrian,
I put your modules into the netopeer-server (without any transapi module, just the data models with file datastore) and used the edit-config you posted (on an empty datastore, or do you have some data in your datastore when you are applying the edit-config?) and everything works for me, neither valgrind doesn't see any problem. Did you explore the core dump? Please try to compile libnetconf with configure's --enable-debug option and your server with -g and then run your server with valgrind to get more detailed information.

Regards,
Radek

Dne 19.3.2015 v 09:31 潘自全 napsal(a):

-- 
Radek Krejci
mobile  : +420 732 212 714
office  : +420 234 680 256
e-mail  : rkr...@cesnet.cz
LinkedIn: http://www.linkedin.com/in/radekkrejci

CESNET, Association of Legal Entities
Zikova 4
160 00 Praha 6
Czech Republic

[潘自全]

Hi Radek,

The datastore is empty, I did not explore the core dump.   I am wondering the problem is transapi module related.

thanks

Adrian

[Radek Krejčí]

I'm not sure about it, but I hope that the valgrind output would help. Can you run the server with valgrind and share the output?

Radek

Dne 19.3.2015 v 12:42 潘自全 napsal(a):

[潘自全]

Hi Radek,

Please check the output by valgrind as below.

thanks

Adrian

==2292== 

==2292== Process terminating with default action of signal 11 (SIGSEGV)

==2292==  Access not within mapped region at address 0x18

==2292==    at 0x4E57967: fill_default (in /usr/lib/libnetconf.so.0.0)

==2292==    by 0x4E57CC4: ncdflt_default_values (in /usr/lib/libnetconf.so.0.0)

==2292==    by 0x4E32764: ncds_apply_transapi (in /usr/lib/libnetconf.so.0.0)

==2292==    by 0x4E36309: ncds_apply_rpc (in /usr/lib/libnetconf.so.0.0)

==2292==    by 0x4E366E4: ncds_apply_rpc2all (in /usr/lib/libnetconf.so.0.0)

==2292==    by 0x4019BB: handle_rpc_default_message (in /usr/lib/siara/bin/testserverd)

==2292==    by 0x401D96: handle_rpc_message (in /usr/lib/siara/bin/testserverd)

==2292==    by 0x401E15: run_event_loop (in /usr/lib/siara/bin/testserverd)

==2292==    by 0x402380: main (in /usr/lib/siara/bin/testserverd)

==2292==  If you believe this happened as a result of a stack

==2292==  overflow in your program's main thread (unlikely but

==2292==  possible), you can try to increase the size of the

==2292==  main thread stack using the --main-stacksize= flag.

==2292==  The main thread stack size used in this run was 8388608.

==2292== 

==2292== Events    : Ir

==2292== Collected : 649176894

==2292== 

==2292== I   refs:      649,176,894

Killed

[Radek Krejčí]

This doesn't help much, I need you to compile (and then use) libnetconf with the configure's --enable-debug option. Valgrind then will show the line numbers where it detects the problem.

Radek

Dne 19.3.2015 v 14:20 潘自全 napsal(a):

[潘自全]

Hi Radek,

Find the debug information as below.

thanks

Adrian

==2118== 

==2118== Process terminating with default action of signal 11 (SIGSEGV)

==2118==  Access not within mapped region at address 0x18

==2118==    at 0x4E57AA7: fill_default (with_defaults.c:595)

==2118==    by 0x4E57E04: ncdflt_default_values (with_defaults.c:670)

==2118==    by 0x4E3285C: ncds_apply_transapi (datastore.c:5248)

==2118==    by 0x4E36449: ncds_apply_rpc (datastore.c:6304)

==2118==    by 0x4E36824: ncds_apply_rpc2all (datastore.c:6396)

==2118==    by 0x4019BB: handle_rpc_default_message (testserverd.c:294)

==2118==    by 0x401D96: handle_rpc_message (testserverd.c:323)

==2118==    by 0x401E15: run_event_loop (testserverd.c:349)

==2118==    by 0x402380: main (testserverd.c:643)

==2118==  If you believe this happened as a result of a stack

==2118==  overflow in your program's main thread (unlikely but

==2118==  possible), you can try to increase the size of the

==2118==  main thread stack using the --main-stacksize= flag.

==2118==  The main thread stack size used in this run was 8388608.

==2118== 

==2118== Events    : Ir

==2118== Collected : 660584153

==2118== 

==2118== I   refs:      660,584,153

Killed

[Radek Krejčí]

Hi Adrian,
which libnetconf version (branch or git hash) are you using? In current master and 0.9.x branches, line 595 in with_defaults.c is comment. Please pull current HEAD of 0.9.x or master branch and check if you still have the problem you are describing. Probably, we already fixed the problem you are facing.

Regards,
Radek

Dne 20.3.2015 v 07:44 潘自全 napsal(a):

[潘自全]

Hi Radek,

thanks for you quick response, currently we are using 0.9.0, could you help me to confirm that the issue is about below code. (I have problem to access google code currently)

"if (created_local[i]->children == NULL)"

BTW, I have another problem when apply the callback functions to the private-ospf models, the related callback functions for our private-ospf models can't be called while the callbacks for ietf-routing and ietf-ospf models can be called correctly when the netconf server call transapi_running_changed.

thanks

Adrian

[潘自全]

Hi Radek,

I checked the code in 0.9.x (0.9.1) branch, the code should be the same as 0.9.0 for it.  when I modify the code as below, the problem is disappeared.

"if (created_local[i]->children == NULL)"

change to

"if ((created_local[i] != NULL )&& (created_local[i]->children == NULL)) "

could you help me to look into the callback can't be called issue?

thanks

Adrian

[Radek Krejčí]

Hi Adrian,

Dne 20.3.2015 v 09:04 潘自全 napsal(a):

Hi Radek,

thanks for you quick response, currently we are using 0.9.0, could you help me to confirm that the issue is about below code. (I have problem to access google code currently)

"if (created_local[i]->children == NULL)"

I don't know what line causes the issue. I see the last change of with_defaults.c before releasing 0.9.0 version, what exact version (git hash) are you using? Anyway, please update to the current HEAD of 0.9.x or master branch and then check that you still have the problem. Currently, I'm not able to reproduce your issue and this email ping pong consumes much time.

BTW, I have another problem when apply the callback functions to the private-ospf models, the related callback functions for our private-ospf models can't be called while the callbacks for ietf-routing and ietf-ospf models can be called correctly when the netconf server call transapi_running_changed.

please update libnetconf to avoid solving problems that may be already solved.

Radek

[Radek Krejčí]

no Adrian, the code is not the same - why valgrind report the line 595? There is some other change, the line you are fixing is just the line where the problem appears, but it is definitely not the line which causes the problem. Don't just check the code in 0.9.x, but use that branch.

Radek

Dne 20.3.2015 v 09:27 潘自全 napsal(a):

--
You received this message because you are subscribed to the Google Groups "libnetconf" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libnetconf+...@googlegroups.com.
Visit this group at http://groups.google.com/group/libnetconf.
For more options, visit https://groups.google.com/d/optout.

[潘自全]

Hi Radek,

thanks, I am going to use the branch 0.9.x, in order to compile libnetconf successfully in our system, I did a little change in the code which does not affect the code logic.

let's see the result with the branch 0.9.x.

thanks

Adrian

[Michal Vasko]

Hi Adrian,

this issue should now be resolved both in the master and the 0.9.x branch.

Dňa piatok, 20. marca 2015 9:04:10 UTC+1 Adrian Pan napísal(-a):

[潘自全]

Hello Radek,

After the latest version of datastore.c is used with 0.9.0, the callback issue is resolved.

thanks

Adrian

[Radek Krejčí]

Great, thanks to Michal who actually fixed the issue.

Radek


Dne 24.3.2015 v 03:38 潘自全 napsal(a):

[潘自全]

Hi Radek,

Thanks all for your great support!

BR

Adrian