Project

General

Profile

Actions

Bug #1378

closed

nfd-status: Incorrect processing of received Fib and Face entries

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

Status:
Closed
Priority:
Normal
Category:
Tools
Target version:
Start date:
03/20/2014
Due date:
% Done:

100%

Estimated time:

Description

FibEntry::wireEncode is missing Name field.


Steps to reproduce:

  1. run nfd (sudo env NFD_LOG=all nfd)
  2. create a tunnel using nfdc (NFD=1 nfdc create udp4://10.0.0.10)
  3. add nexthop record to the tunnel using ufdc (NFD=1 nfdc add-nexthop /example <faceid from previous step>)
  4. 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
    
Actions #1

Updated by Anonymous over 10 years ago

  • Assignee set to Anonymous
Actions #2

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.

Actions #3

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)
Actions #4

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.

Actions #5

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)}
Actions #6

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...

Actions #7

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)}
Actions #8

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)

Actions #9

Updated by Alex Afanasyev over 10 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 0 to 100
Actions #10

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
Actions #11

Updated by Alex Afanasyev over 10 years ago

  • Category set to Tools
  • Target version set to v0.1
Actions #12

Updated by Alex Afanasyev over 10 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF