Bug #1399
closed
nfdc failed to add nexthop
0%
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.
Updated by Alex Afanasyev about 10 years ago
- Project changed from 14 to NFD
- Category set to Management
- Priority changed from Normal to High
- Target version set to v0.1
Updated by Alex Afanasyev about 10 years ago
Junxiao, is this a part of #1397 and you will handle or somebody else can fix this?
Updated by Anonymous about 10 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?
Updated by Alex Afanasyev about 10 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...
Updated by
Updated by Anonymous about 10 years ago
Is the resolution goal for this bug to add control parameter default values?
Updated by Alex Afanasyev about 10 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.
Updated by Anonymous about 10 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...)
Updated by Alex Afanasyev about 10 years ago
All bugs are features and only some are in progress :-D
Updated by Anonymous about 10 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.
Updated by Alex Afanasyev about 10 years ago
IMHO, the response should contain all active values, including all the applied defaults.
Updated by Junxiao Shi about 10 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.
Updated by Anonymous about 10 years ago
- Status changed from Code review to Closed