NFD

Disagree. The proper solution of the root cause is letting every node have a different command prefix for prefix registrations, as described in #3142 and #3143.

Oh, I don't disagree with fixing the root issues, but given that there has been no progress in 4 years, I don't expect them to be resolved any time soon. In the meantime, we should clearly communicate to our users that the two settings are mutually incompatible.

Hi,for error message, which part do you want it to add in nfd.conf.sample.in,on both localhop_security part and auto_prefix_propagate part?

You can add a note about the incompatibility in nfd.conf.sample.in, in both sections, but that's not the main goal of this task. The "error message" mentioned in the description must be raised by NFD at runtime, if the config is incorrect. That means throwing a ConfigFile::Error exception. There are plenty of similar cases in the codebase, for instance take a look at daemon/face/*-factory.cpp.

Thanks for that example，I am thinking the config file is related with rib/service.cpp，and there is a ApplyConfig function，if the section has localhop_security already，and in next loop，it has auto_prefix_propagate，should this situation be incorrect for throwing exception？

Is ApplyConfig function in rib/service.cpp a right place to add code ?

Wenkai Zheng wrote:

Is ApplyConfig function in rib/service.cpp a right place to add code ?

I think you are targeting at the correct file. But it seems more likely that the function you should work on is Service::checkConfig. E.g. if in a loop you see CFG_LOCALHOP_SECURITY and in another loop you see CFG_PREFIX_PROPAGATE, you need to throw an error.

A basic question: what is the problem when both localhop_security and auto_prefix_propagate are enabled?

My understanding is there are only two combinations:

1. localhost + auto_prefix_propagate: prefix registrations on NFD are propagated to the connected gateway router
2. localhop: NFD expects prefix registrations from apps running on remote machines.

Why can't localhop work with auto_prefix_propagte? I must misunderstand something here.

Thanks in advance.

Davide Pesavento wrote:

Apparently NFD-Android enables both these sections in the default config. Anyone knows why?

This was done in commit:449a431db2d67d98bb7d6aaad35696fdd26ed0ca to "fix" self-learning, with the disclaimer that this is a temporary solution and be replaced with the proper
trust management inside NDN android app later.

Ah thanks, I remember now. It shouldn't be a problem then. Self-learning is switching to its own validator instead of abusing the localhop validator. So NFD-Android can simply disable localhop_security again when it gets updated to the new NFD (and enable prefix_announcement_validation for self-learning).