NFD

What I'm observing is that the sample app face is not destructed when I press Ctrl-C. It is only destructed when the app is started for the second time. Another observation is that running another app that connects to NFD's unix socket does not cause the first app's face to be destroyed... I'm a little puzzled.

@Yanbiao. We need to update RIB manager's logic to not issue the assert and ensure that the processing is correct.

I have more input on this issue. I tracked down the problem to having root identity configured on my machine.

To complete the scenario in this bug report, run

ndnsec-keygen / | ndnsec-install-cert -

The problem seem to be entirely inside the Automatic Prefix Propagation module. Based on logs, face is being properly destroyed when Ctrl-C is pressed. Here is what I see in the log:

• after app started

1450334272.471824 INFO: [UnixStreamTransport] [id=0,local=unix:///private/tmp/nfd.sock,remote=fd://31] Creating transport
1450334272.471950 INFO: [FaceTable] Added face id=261 remote=fd://31 local=unix:///private/tmp/nfd.sock
1450334272.477663 INFO: [RibManager] Adding route /hello/world nexthop=261 origin=0 cost=0
1450334272.483901 INFO: [AutoPrefixPropagator] no hub connected to propagate /

• after Ctrl-C pressed

1450334275.311978 INFO: [Transport] [id=261,local=unix:///private/tmp/nfd.sock,remote=fd://31] setState UP -> FAILED
1450334275.312506 INFO: [Transport] [id=261,local=unix:///private/tmp/nfd.sock,remote=fd://31] setState FAILED -> CLOSED
1450334275.317282 INFO: [FaceTable] Removed face id=261 remote=fd://31 local=unix:///private/tmp/nfd.sock (LpFace failed)
1450334275.318667 INFO: [AutoPrefixPropagator] should be kept for another RIB entry: /localhost/nfd/rib

• after app started again

1450334312.483872 INFO: [UnixStreamTransport] [id=0,local=unix:///private/tmp/nfd.sock,remote=fd://31] Creating transport
1450334312.484001 INFO: [FaceTable] Added face id=262 remote=fd://31 local=unix:///private/tmp/nfd.sock
1450334312.489580 INFO: [RibManager] Adding route /hello/world nexthop=262 origin=0 cost=0
Assertion failed: (!entryIt->second.isNew()), function afterInsertRibEntry, file ../rib/auto-prefix-propagator.cpp, line 179.
Abort trap: 6

I think the automatic prefix propagation record is incorrectly kept for /localhost/nfd/rib prefix. Or something related to this prefix.

Reply to note-4:

Is this a problem originated from the design, or is it the implementation inconsistent with the design?

If there's a design problem, the state transition table in devguide should be updated as well.

I think it's just a implementation issue. According to the design, it indeed will happen that a state goes into NEW but does not become PROPAGATING at once.

The assertion failure occurs in AutoPrefixPropagator::afterInsertRibEntry.

This function is invoked when a RIB entry (not route) is inserted, which means one of the following:

• prefix == LINK_LOCAL_NFD_PREFIX branch: "hub connect" event for all existing propagated entries
• LOCAL_REGISTRATION_PREFIX.isPrefixOf(prefix) or !propagateParameters.isValid branch: no event because the prefix shouldn't be propagated
• entryIt != m_propagatedEntries.end() branch: no event because propagateParameters.parameters.getName() refers to an existing propagated entries created by another RIB entry which has the same prefix propagation parameters
• the last case: "rib insert" event on a new propagated entry

Based on this analysis, I agree that this is an implementation problem, and the assertion should be deleted.