YumaPro SDK provides mechanisms to debug problems with the yangcli-pro client and netconfd-pro server.


yangcli-pro and netconfd-pro can both output debugging information to the terminal and to log files. The level of detail in the debugging information can specified with config file and command line parameters.


Server


An example of producing a log file from the server:


netconfd-pro --log=~/LOGS/netconfd-pro-test.log --log-level=debug4 --access-control=off



Client


An example of producing a log file from the client:


yangcli-pro --log=~/LOGS/yangcli-pro-test.log --log-level=debug4



NOTE: 

  1. The server or client has to be able to create the file so in the above examples the ~/LOGS directory must exist
  2. If a log file with the same name already exists, using --log with the same file name will overwrite the existing one
  3. Use a log file name that is descriptive of the issue you are experiencing. For instance in the examples above netconfd-pro-test.log or yangcli-pro-test.log are the log filenames. For your issue change to something like:   <your_company_name>_netconfd-pro_<issue_with_xyz>.log
  4. In the above example, response output from the server will not be displayed in yangcli-pro it is all redirected to the log file. If you want to see the output as well as have it contained in the log file use the additional parameter: --log-mirroring as show in the example below


yangcli-pro --log=~/LOGS/yangcli-pro-test.log --log-mirroring --log-level=debug4




Log file details


For more details on creating log files, appending to an existing log file and specifying the level of detail see:

 Overview of error logging


For additional debugging parameters see: What CLI parameters are useful for debugging?



Creating a bug report


When creating a bug report you should send information to [email protected] or submit it directly to our ticketing system at https://yumaworks.freshdesk.com/


Include the following information:

  1. A description of the problem you are experiencing
  2. A description of the steps to reproduce the problem (see below)
  3. The YumaPro SDK version
  4. Include one or both of the log files described above with log-level=debug4 (depending on the issue)
  5. Which operating system, version and CPU architecture you are using
  6. Which tool is the problem? client, server, compiler, code generation, etc.
  7. All YANG modules that are being used
  8. netconfd-pro.conf file being used
  9. Any additional data relevant to the problem such as workarounds (see below)


You can save time by using YumaPro's <get-support-save> command to collect most of the information required for YumaWorks' Technical Support Staff to expedite resolving your issue. The information includes:

  • bundles
  • capabilities
  • configuration data
  • datastores
  • modules
  • server name and version
  • sessions
  • SILs
  • server system


The <get-support-save> command is available while yangcli-pro is connected to the netconfd-pro server. Run the command in the example below which send the output to an xml file:


fred@srv1> @~/LOGS/example-bug.xml = get-support-save


Once the file is created attach it to the FreshDesk support ticket by selecting "Add note" and then select the paper clip icon in the bottom left of the note. Browse to the location of the support-save file and select it. Write some helpful text in the note such as the steps to recreate the problem and then add the note to the ticket.



Describing the steps to recreate the issue should be something like:


I start the server with:
    netconfd-pro --log-level=debug4 --param1 --param2 --module=xyz.yang  --log=bug-output.log

Then I start yangcli:
    yanggcli-pro user@srv1> 
    connect server=srv1 user=fred password=pw1

The connect sequence was normal. The I entered the command:
    fred@srv1> command1 param1=xyz param2=abc

So far so good, but when I enter
    fred@srv1> command2 param3=klm 

the server does <explain the symptom of issue>



Other attachments to the ticket should include a log-file with a description in the note which "message-id" in the log file where the issue(s) occur. For yangcli or other client the "message-id" should be in the <rpc> and <rpc-reply> elements. For example, in the section below the "message-id" is 3 for this <rpc-reply>:


<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="3"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2017-10-04T00:51:19Z" ncx:etag="57332"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>

Describe any workarounds that can be used to avoid the issue such as:


If I call command2 before command1 the issue doesn't occur.


See the article: What are the different states for tickets in the Technical Support System? for the different types and statuses for tickets.