Project

General

Profile

Actions

Bug #4059

closed

localhop prefix registration "400 failed in validating parameters" at the first time

Added by Junxiao Shi over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
RIB
Target version:
Start date:
04/20/2017
Due date:
% Done:

100%

Estimated time:
3.00 h

Description

When an end host's AutoPrefixPropagation attempts to register a prefix on a testbed router using /localhop/nfd/rib/register command, the command fails with "400 failed in validating parameters" at the first time, but a subsequent retry succeeds.


Files

hobo20170419.pcap (5.75 KB) hobo20170419.pcap Junxiao Shi, 04/20/2017 08:53 AM

Related issues 1 (0 open1 closed)

Related to NFD - Bug #3640: ECDSA key unusable with automatic prefix propagationClosedZhiyi Zhang06/02/2016

Actions
Actions #1

Updated by Junxiao Shi over 7 years ago

  • Related to Bug #3640: ECDSA key unusable with automatic prefix propagation added
Actions #2

Updated by Junxiao Shi over 7 years ago

I captured a Wireshark trace on the router at one incident.

From the attached trace, we can see:

  1. In packet 8, the end host tcp4://128.196.203.35:35306 sends a prefix registration command.
  2. In packet 10, the router sends an Interest to udp4://199.175.53.34:6363 to retrieve the signing certificate.
  3. In packet 11, the certificate is retrieved successfully.
  4. In packet 12, the router returns a 400 error to the end host.
  5. 50 seconds later, in packet 20, the end host sends a new prefix registration command.
  6. In packet 21, the router returns a 200 successful response to the end host.

On another long-running end host, I observe that 400 error occurs once an hour:

sunny@vps3:~$ grep 'fail to propagate' /var/log/ndn/nfd.log | awk '$1>1492664400 {print $1}' | awk 'NR>1{print int($1)-last} {last=int($1)}'
3651
3650
3651
3651
3651
3651
3651
3651
3651

I know of two places where constant "one hour" is used:

I guess the IdentityCertificate FreshnessPeriod is the deciding factor: whenever a certificate retrieval is needed, the registration command fails.

Actions #3

Updated by Junxiao Shi over 7 years ago

  • Estimated time set to 3.00 h

I believe this is a bug in Dispatcher::processControlCommandInterest:

shared_ptr<ControlParameters> parameters;
try {
  parameters = parser(pc);
}
catch (const tlv::Error&) {
  return;
}

AcceptContinuation accept = bind(accepted, _1, prefix, interest, parameters.get());
RejectContinuation reject = bind(rejected, _1, interest);
authorization(prefix, interest, parameters.get(), accept, reject);

If authorization function is asynchronous, the ControlParameters object is deallocated when Dispatcher::processControlCommandInterest returns, and thus parameters.get() passed to accept is a dangling pointer.

Actions #4

Updated by Junxiao Shi over 7 years ago

  • Status changed from New to Code review
  • Assignee set to Junxiao Shi
  • % Done changed from 0 to 100
Actions #5

Updated by Davide Pesavento over 7 years ago

anything else to do here?

Actions #6

Updated by Junxiao Shi over 7 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF