[Nfd-dev] [EXT]Re: Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today

Zhiyi Zhang zhiyi at cs.ucla.edu
Fri Feb 5 11:42:15 PST 2021


On Fri, Feb 5, 2021 at 1:26 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> I can see that the NFD on suns was last restarted at 2021-02-05 03:05:02
> UTC, which explains the "end of file" message.
>
> "request time out" likely came from ndn::nfd::Controller for failing to
> register prefixes, because NFD-RIB is not yet ready.
> I think you need to add some delay (a RestartSec directive) in the systemd
> unit.
> Also, it's missing BindsTo=nfd.service , unless you are leaving it off
> because you are using user systemd rather than system-wide systemd.
>
>
>
> Anyway, I've tested the service.
> CA profile retrieval is working now.
>
> However, the NewResponse packet is encoded incorrectly - it contains an
> unrecognized TLV element of critical type 0x9B.
> Packet capture is attached.
>
> I can see that the offending line is here:
>
> https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L91
> The protocol doesn't have a Status field in this packet:
>
> https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-0.3/0d11d48d9ebee022eee71dee14f1342e0905a620#232-packet-format
>

I remembered we have this status field in the original doc. I guess it was
removed in later edits.
Anyway, do you think we should have this field in the NEW Data packet to
indicate the current status?


>
> Your decoding function is not implementing TLV evolvability correctly.
>
> https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L102
> If it encounters an unrecognized or out-of-order field of a critical
> TLV-TYPE. However, the current decoding function would erroneously accept
> any unrecognized or out-of-order fields of critical TLV-TYPEs.
> All new NDN software is expected to properly implement TLV evolvability.
> Please see ndn::Interest type in ndn-cxx for an example.
>

Okay. BTW, should there be some helper functions from NDN libraries to help
with this?
I feel it's not very developer-friendly considering the alternatives like
JSON.
Compared with forwarder development, maybe we should relax this requirement
for application development?

Best,
Zhiyi


>
> Please reply when you have fixed the NewResponse bug, so I can re-test.
>

> Yours, Junxiao
>
> On Thu, Feb 4, 2021, 23:53 Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:
>
>> *External Email*
>> It seems the network on the Suns is not stable and the service reports
>> the following error several times:
>>
>> ```
>> Feb 05 03:05:01 suns.cs.ucla.edu ndncert-ca-server[6005]: terminate
>> called after throwing an instance of
>> 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<
>> *ndn::Transport::Error*> >'
>> Feb 05 03:05:01 suns.cs.ucla.edu ndncert-ca-server[6005]:   what():  *error
>> while receiving data from socket (End of file)*
>> ...
>> Feb 05 03:05:12 suns.cs.ucla.edu ndncert-ca-server[16981]: *ERROR:
>> request timed out*
>> ```
>>
>> I restarted the service.
>>
>> Best,
>> Zhiyi
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20210205/dd13f469/attachment.html>


More information about the Nfd-dev mailing list