Bug #1378
closed
  
nfd-status: Incorrect processing of received Fib and Face entries
 
        
        Added by Yi Huang over 11 years ago.
        Updated over 11 years ago.
        
  
  
  
  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 -bto 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
 
 
 
 
  
  
    
    
    
    
       - Assignee set to Anonymous
 
   
  
  
    
    
    
    
       - 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.
 
   
  
  
    
    
    
    
       - 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)
 
   
  
  
    
    
    
    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.
 
   
  
  
    
    
    
    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)}
 
   
  
  
    
    
    
    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...
 
   
  
  
    
    
    
    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)}
 
   
  
  
    
    
    
    
       - 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)
 
   
  
  
    
    
    
    
       - Status changed from In Progress to Code review
- % Done changed from 0 to 100
 
   
  
  
    
    
    
    
       - 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
 
   
  
  
    
    
    
    
       - Category set to Tools
- Target version set to v0.1
 
   
  
  
    
    
    
    
       - Status changed from Code review to Closed
 
   
  
 
  
  
 
Also available in:  Atom
  PDF