Project

General

Profile

Actions

Bug #1399

closed

nfdc failed to add nexthop

Added by Yi Huang almost 11 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
Management
Target version:
Start date:
03/24/2014
Due date:
% Done:

0%

Estimated time:

Description

ndn-cpp-dev commit bc19b37cfcf93172dbe012fa8baa1daa055ded58

NFD commit ba7490517d1f4e9b699d7398788db03e1ffaeacc

Steps to reproduce:

  1. Change config file at "~/.ndn/client.conf" to use "nfd=0.1"
  2. Start NFD (sudo env NFD_LOG=all nfd)
  3. Add new face with nfdc (nfdc create udp4://10.0.0.1)
  4. Run nfd-status to get the face id (nfd-status)

    faceid=4 uri=udp4://10.0.0.1:6363 counters={in={0i 0d} out={0i 0d}}

  5. Add nexthop with nfdc (nfdc add-nexthop /example 4)

nfdc output:

ltr120@traffic-gen-vm2:~$ nfdc add-nexthop /example 4
ERROR: error while receiving data from socket (End of file)

Related NFD log (last four lines):

DEBUG: [InternalFace] found Interest filter for /localhost/nfd/fib (previous match)
DEBUG: [FibManager] Options parsed OK
INFO: [FibManager] command result: processing verb: add-nexthop
nfd: /usr/local/include/ndn-cpp-dev/management/nfd-control-parameters.hpp:186: uint64_t ndn::nfd::ControlParameters::getCost() const: Assertion `m_hasCost' failed.
Actions #1

Updated by Alex Afanasyev almost 11 years ago

  • Project changed from 14 to NFD
  • Category set to Management
  • Priority changed from Normal to High
  • Target version set to v0.1
Actions #2

Updated by Alex Afanasyev almost 11 years ago

Junxiao, is this a part of #1397 and you will handle or somebody else can fix this?

Actions #3

Updated by Anonymous almost 11 years ago

If it's a problem with NFD management, then I can take it (I'm doing the #1397 NFD-side).

I suspect this assert is begin tripped by an NFD logging statement at the beginning of the FibManager::addNextHop that invokes ControlParameters::getCost. Can you confirm that nfdc is setting/transmitting the cost correctly?

Actions #4

Updated by Alex Afanasyev almost 11 years ago

This is related to ControlParameters. We used to have default values for all missing parameters encoded as part of the data structure. With ControlParameters one needs to check if parameter is set prior to using it and if it is not set, use module-specific default value...

Actions #5

Updated by Yi Huang almost 11 years ago

  • Tracker changed from Task to Bug
Actions #6

Updated by Anonymous almost 11 years ago

Is the resolution goal for this bug to add control parameter default values?

Actions #7

Updated by Alex Afanasyev almost 11 years ago

I believe the only "correct" way would be to process default values in the manager. Only manager reliable knows what the correct default values are. Setting "default" values to the data structure in the library is wrong, since values are optional and it should be perfectly fine to omit them.

Actions #8

Updated by Anonymous almost 11 years ago

  • Assignee set to Anonymous

I completely agree. It's just a little strange to have a bug for something that's a feature in progress. I'll take this one.

(Maybe all bugs are just features in progress...)

Actions #9

Updated by Alex Afanasyev almost 11 years ago

All bugs are features and only some are in progress :-D

Actions #10

Updated by Anonymous almost 11 years ago

The control response specification defines the response's body as: "... <body> is the ControlParameters passed into this command for all successful responses, ..."

If the command does not explicitly specify a cost, the fib manager will default 0. In general, if a parameter field is optional (such as cost), should the response's body contain the field set to the default value or just echo the exact control parameters received?

I'm assuming it should state the used default value (kind of similar to using 0 for the FaceID), but clarification would be appreciated.

Actions #11

Updated by Alex Afanasyev almost 11 years ago

IMHO, the response should contain all active values, including all the applied defaults.

Actions #12

Updated by Junxiao Shi almost 11 years ago

I'm updating FibMgmt to reply fib/add-nexthop and fib/remove-nexthop with effective FaceId and Cost.

Also, fib/remove-nexthop is considered successful if FIB entry doesn't exist.

Actions #13

Updated by Anonymous almost 11 years ago

  • Status changed from New to Code review
Actions #14

Updated by Anonymous over 10 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF