Bug #1378
closednfd-status: Incorrect processing of received Fib and Face entries
100%
Description
FibEntry::wireEncode
is missing Name field.
Steps to reproduce:
- run nfd (
sudo env NFD_LOG=all nfd
) - create a tunnel using nfdc (
NFD=1 nfdc create udp4://10.0.0.10
) - add nexthop record to the tunnel using ufdc (
NFD=1 nfdc add-nexthop /example <faceid from previous step>
) run
nfd-status -b
to show FIB status.ltr120@traffic-gen-vm1:~$ NFD=1 nfd-status -b FIB: /localhost/nfd nexthops={faceid=1 (cost=0)} ltr120@traffic-gen-vm1:~$ NFD=1 nfdc create udp4://10.0.0.10 Face creation succeeded: ForwardingEntry(FaceID: 4, Uri: udp4://10.0.0.10) ltr120@traffic-gen-vm1:~$ NFD=1 nfdc add-nexthop /example 4 Nexthop insertion succeeded: ForwardingEntry(Prefix: /example, FaceID: 4, Cost: 0, Strategy: /, ) ltr120@traffic-gen-vm1:~$ NFD=1 nfd-status -b FIB: Expected NextHopRecords, but Block is of a different type: #128
Updated by Junxiao Shi over 10 years ago
- Description updated (diff)
Irrelevant logs are deleted.
@Yi: logs are usually unnecessary, because they can be obtained by following the steps. If you need to include logs, paste only relevant lines, and/or attach logs as a file.
Use correct Markdown syntax for code and console output: indent four spaces (or indent eight spaces if inside a list). Don’t use <pre> tag, because snippet inside is still processed by Markdown.
Updated by Junxiao Shi over 10 years ago
- Project changed from NFD to ndn-cxx
- Subject changed from FIB not updated correctly after 'nfdc add-nexthop' to FibEntry encode/decode is incorrect
- Description updated (diff)
- Target version deleted (
v0.1)
Updated by Anonymous over 10 years ago
I don't think is a problem of a missing name field the wire encode. I call the name "prefix", and it's corresponding member variable (m_prefix) is indeed added.
I'm playing around with the nfd-status tool itself and I think that's where the problem lies. In afterFetchFibEnumerationInfo() (~ line 206, I have some debugging additions), the code uses a Block constructor with its length verification disabled. Enabling length verification results in the constructor failing due to a mismatch of the buffer length (49 bytes) with the TLV length (19 bytes). My understanding of this constructor is that it's trying to convert the entire result buffer into a single block. Is that correct?
The result is successfully parsed if I use the Block(uint8_t*, max size) constructor instead and nfd-status runs without issue.
Updated by Anonymous over 10 years ago
Here's the output. I think there's a different, but related, problem:
$ NFD=1 nfdc create udp4://10.0.0.10
Face creation succeeded: ForwardingEntry(FaceID: 3, Uri: udp4://10.0.0.10)
$ NFD=1 nfdc add-nexthop /example 3
Nexthop insertion succeeded: ForwardingEntry(Prefix: /example, FaceID: 3, Cost: 0, Strategy: /, )
$ NFD=1 nfd-status -b
FIB:
/example nexthops={faceid=3 (cost=0)}
/example nexthops={faceid=3 (cost=0)}
/example nexthops={faceid=3 (cost=0)}
Updated by Alex Afanasyev over 10 years ago
Steve DiBenedetto wrote:
I don't think is a problem of a missing name field the wire encode. I call the name "prefix", and it's corresponding member variable (m_prefix) is indeed added.
I'm playing around with the nfd-status tool itself and I think that's where the problem lies. In afterFetchFibEnumerationInfo() (~ line 206, I have some debugging additions), the code uses a Block constructor with its length verification disabled. Enabling length verification results in the constructor failing due to a mismatch of the buffer length (49 bytes) with the TLV length (19 bytes). My understanding of this constructor is that it's trying to convert the entire result buffer into a single block. Is that correct?
The result is successfully parsed if I use the Block(uint8_t*, max size) constructor instead and nfd-status runs without issue.
I'll check nfd-status. The constructor must use the current version (this one is thread-safe). There could be more bugs in this constructor...
Updated by Anonymous over 10 years ago
Corrected my debugging use of the Block(uint8_t*, max size) constructor and I now get (what I think is) the correct output:
FIB:
/example nexthops={faceid=3 (cost=0)}
/localhost/nfd nexthops={faceid=1 (cost=0)}
Updated by Alex Afanasyev over 10 years ago
- Status changed from New to In Progress
- Assignee changed from Anonymous to Alex Afanasyev
Ok. There are a couple of bugs in nfd-status (used wrong versions of Block constructor). Will push the fix to gerrit (the fix would require new changes in ndn-cpp-dev library)
Updated by Alex Afanasyev over 10 years ago
- Status changed from In Progress to Code review
- % Done changed from 0 to 100
Updated by Alex Afanasyev over 10 years ago
- Project changed from ndn-cxx to NFD
- Subject changed from FibEntry encode/decode is incorrect to nfd-status: Incorrect processing of received Fib and Face entries
Updated by Alex Afanasyev over 10 years ago
- Category set to Tools
- Target version set to v0.1
Updated by Alex Afanasyev over 10 years ago
- Status changed from Code review to Closed