Bug #1399
closed
nfdc failed to add nexthop
Added by Yi Huang over 10 years ago.
Updated over 10 years ago.
Description
ndn-cpp-dev commit bc19b37cfcf93172dbe012fa8baa1daa055ded58
NFD commit ba7490517d1f4e9b699d7398788db03e1ffaeacc
Steps to reproduce:
- Change config file at "
~/.ndn/client.conf" to use "nfd=0.1"
- Start NFD (
sudo env NFD_LOG=all nfd)
- Add new face with nfdc (
nfdc create udp4://10.0.0.1)
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}}
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.
- Project changed from 14 to NFD
- Category set to Management
- Priority changed from Normal to High
- Target version set to v0.1
Junxiao, is this a part of #1397 and you will handle or somebody else can fix this?
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?
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...
- Tracker changed from Task to Bug
Is the resolution goal for this bug to add control parameter default values?
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.
- 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...)
All bugs are features and only some are in progress :-D
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.
IMHO, the response should contain all active values, including all the applied defaults.
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.
- Status changed from New to Code review
- Status changed from Code review to Closed
Also available in: Atom
PDF
Updated by 
Updated by Anonymous 
Updated by 
Updated by