Project

General

Profile

Actions

Bug #2274

closed

ERROR: (Block::get) Requested a non-existed type [7] from Block

Added by Andrew Brown over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Management
Target version:
Start date:
12/04/2014
Due date:
% Done:

0%

Estimated time:

Description

When trying to add routes to the RIB with 'nfdc register /test/route 256', nfdc always returns 'ERROR: (Block::get) Requested a non-existed type [7] from Block'. 256 in this case was the multicast face 'udp4://224.0.23.170:56363' but the same thing happens with all other faces.

Curious, I turned on all logging and tried 'echo "Hello World" | ndn-tlv-poke -w 30000 /hello/world' which returned the same error as above. I looked through the log files (attached) but did not see anything that would indicate why the error was happening. I also looked at the context of the ndn-cxx code throwing the exception (https://github.com/named-data/ndn-cxx/blob/master/src/encoding/block.cpp#L397) but I'm still not clear on why it is being thrown.

I am running NFD on Ubuntu 14.04. Any help is appreciated.


Files

nfd.log (965 KB) nfd.log Andrew Brown, 12/04/2014 02:21 PM

Related issues 1 (0 open1 closed)

Related to ndn-cxx - Bug #2278: Unintuitive error reporting by SecPublicInfo (SecPublicInfoSqlite3)ClosedYingdi Yu12/05/2014

Actions
Actions #1

Updated by Junxiao Shi over 9 years ago

  • Assignee set to Chengyu Fan
Actions #2

Updated by Junxiao Shi over 9 years ago

  • Target version changed from v0.2 to v0.3
Actions #3

Updated by Alex Afanasyev over 9 years ago

I'm not able to reproduce this problem on OSX.

I have feeling that this is related to certificates. Can you delete ~/.ndn/ndnsec-public-info.db and ~/.ndn/ndnsec-tpm-file and then generate self-signed certificate

ndnsec-keygen /some/name | ndnsec-install-cert -
Actions #4

Updated by Andrew Brown over 9 years ago

Alex, thanks for the advice. Just deleting the keys and SQLite DB did the trick. Is there some way to catch that error at a higher level to output a more meaningful error message?

Actions #5

Updated by Alex Afanasyev over 9 years ago

  • Assignee deleted (Chengyu Fan)

I agree. We do need a more meaningful message. I'll create another task for that.

Actions #6

Updated by Alex Afanasyev over 9 years ago

  • Related to Bug #2278: Unintuitive error reporting by SecPublicInfo (SecPublicInfoSqlite3) added
Actions #7

Updated by Andrew Brown over 9 years ago

I would close this issue but I don't have permissions to.

Actions #8

Updated by Alex Afanasyev over 9 years ago

  • Status changed from New to Resolved
Actions #9

Updated by Junxiao Shi over 9 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF