using ncclient results in netopeer-server segfault

57 views
Skip to first unread message

vivek atreya

unread,
Mar 25, 2015, 12:06:17 AM3/25/15
to neto...@googlegroups.com
What steps will reproduce the problem?
1. Use ncclient and try edit config
2. netopeer-server segfaults
3. The same request works correctly when using netopeer-cli

Crash Data:
netopeer-server[2355]: segfault at 2c ip b67a6d50 sp bfa9f200 error 4 in libaugeas.so.0.18.0[b67a0000+56000]

This might have something to do with the xml namespaces.

1. The same request from netopeer-cli works correctly.
The request as sent by netopeer-cli

<?xml version="1.0" encoding="UTF-8"?>#012<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="7">#012  <edit-config>#012    <target>#012      <running/>#012    </target>#012    <config>#012      <system xmlns="urn:avaya:params:xml:ns:yang:ona100">#012        <status>#012          <device-status>green</device-status>#012        </status>#012      </system>#012    </config>#012  </edit-config>#012</rpc>

2. The request sent by ncclient. This causes the crash

 <?xml version="1.0" encoding="UTF-8"?>#012<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:ns1="urn:avaya:params:xml:ns:yang:ona100" message-id="urn:uuid:c9d007ea-d29c-11e4-87b8-080027ba1a92">#012  <nc:edit-config>#012    <nc:target>#012      <nc:candidate/>#012    </nc:target>#012    <config>#012      <ns1:system>#012        <ns1:status>#012          <ns1:device-status>green</ns1:device-status>#012        </ns1:status>#012      </ns1:system>#012    </config>#012  </nc:edit-config>#012</nc:rpc>


Warm Regards,
Vivek



Michal Vasko

unread,
Mar 26, 2015, 4:43:42 AM3/26/15
to neto...@googlegroups.com
Hi Vivek,

for one, based on the place of the crash, I believe there must be a problem in your transAPI module, since neither netopeer nor libnetconf use libaugeas. Namespaces seems fine even in the ncclient RPC, but the target datastore is different. The strange thing is the message-id used by ncclient, although I don't think it should cause any problems. Another weird thing is that it modifies the candidate datastore, which should not trigger any callbacks, but simply change the candidate datastore. Still, I don't think I can help you, because there is not a way for me to reproduce your problem.

Regards,
Michal
Reply all
Reply to author
Forward
0 new messages