NDN project issue tracking system: Issueshttps://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232018-04-10T12:59:46ZNDN project issue tracking system
Redmine jndn - Bug #4575 (Closed): fail to register prefix with NFD-android using NDN-DOT-NET libraryhttps://redmine.named-data.net/issues/45752018-04-10T12:59:46ZYanbiao Lilybmath2009@gmail.com
<p>we were trying to register a prefix from the APP (built on top of NDN-NOT-NET) to NFD-Android, but it failed.<br>
But it succeeded to register the same prefix with a remote NFD.</p>
<p>Finally, we figured out that the reason why it fails with NFD-Andorid is: the command Interest is always started from /localhop/nfd and NFD-Andorid does not enable /localhop handler by default.<br>
We created a TCP connection (using 127.0.0.1 as the address) between the APP and NFD-andorid, it should hit, after checking isLocal(), the branch which adopts /localhost/nfd prefix but it didn't.</p>
<p>Is there any issue with the isLocal() check?</p>
ICE-AR Prototype - Task #4494 (New): explore the use of RxAdnroidBLE for beaconinghttps://redmine.named-data.net/issues/44942018-02-08T09:54:36ZYanbiao Lilybmath2009@gmail.com
<p>this task requires to explore how to use RxAdnroidBLE for beaconing on android</p>
ICE-AR Prototype - Task #4493 (New): BLE agent for NFD-androidhttps://redmine.named-data.net/issues/44932018-02-08T09:47:46ZYanbiao Lilybmath2009@gmail.com
<p>This task requires to develop an agent that<br>
1/ maintains a TCP connection to NFD-android; communicates with NFD-andorid through this TCP connection<br>
2/ invokes BLE library on android to discover/monitor and communicate with beacons</p>
ICE-AR Prototype - Task #4491 (New): sample client for bluetooth beaconinghttps://redmine.named-data.net/issues/44912018-02-05T17:14:33ZYanbiao Lilybmath2009@gmail.com
<p>This task requires to write a sample client for the bluetooth beaconing design:<br>
1/ Must be written in C# on android, can work with Unity;<br>
2/ Should be built upon NDN-DOT-NET, and talks with NFD-android via Interest/Data exchanges;<br>
3/ minimized required features:<br>
A. can register prefix(es) to NFD-android;<br>
B. can setup notification callbacks and register notification stream to NFD-andorid</p>
ICE-AR Prototype - Task #4461 (New): Design and configure three-site testbedhttps://redmine.named-data.net/issues/44612018-01-11T21:06:16ZYanbiao Lilybmath2009@gmail.com
<p>1/ REMAP, UCLA CS, NMSU<br>
2/ with one edge node, two mobiles, and a few beacons each<br>
3/ mobility support<br>
4/ namespace design</p>
<p>will split into separate issues after clarify requirements</p>
ICE-AR Prototype - Task #4460 (New): Design, then implement and deploy acceleration-as-a-service ...https://redmine.named-data.net/issues/44602018-01-11T21:04:04ZYanbiao Lilybmath2009@gmail.comICE-AR Prototype - Task #4459 (New): Implement and deploy authentication and access control using...https://redmine.named-data.net/issues/44592018-01-11T21:03:51ZYanbiao Lilybmath2009@gmail.com
<p>1/ this task first requires a good understanding on NMSU design (will provide some links later)<br>
2/ this task includes both implementation and deployment; the targets are mobile client, edge service and content publisher</p>
ICE-AR Prototype - Task #4458 (New): Incorporate bluetooth beacon reading into NFD-andoridhttps://redmine.named-data.net/issues/44582018-01-11T20:56:54ZYanbiao Lilybmath2009@gmail.com
<p>This project should design and develop a bluetooth communication module for NFD-andorid</p>
<p>Minimum requirements:<br>
1) provision RFduino or other BTLE beacons with an NDN names from a utility program easily<br>
2) when the mobile moves into proximity of a beacon, provide a notification with the name to the prototype app while the beacon is visible (And probably, for how long and with what signal strength, etc.).<br>
3) API calls: entry/exit notifications plus polling capability to check if the beacon is still around (or the list of nearby beacons with a given signal strength).</p>
ICE-AR Prototype - Task #4457 (New): develop repo-sync for content publishing and retrievalhttps://redmine.named-data.net/issues/44572018-01-11T20:54:43ZYanbiao Lilybmath2009@gmail.com
<p>1/ start from the repo-ng (after cleanup)<br>
2/ use a revised VectorSync (scale to large number of namespaces)</p>
<p>repo-ng code: <a href="https://github.com/named-data/repo-ng">https://github.com/named-data/repo-ng</a><br>
VectorSync ICN paper: <a href="https://conferences.sigcomm.org/acm-icn/2017/proceedings/icn17-1002.pdf">https://conferences.sigcomm.org/acm-icn/2017/proceedings/icn17-1002.pdf</a></p>
ICE-AR Prototype - Task #4456 (Closed): clean up the existing repo-ng codehttps://redmine.named-data.net/issues/44562018-01-11T20:48:30ZYanbiao Lilybmath2009@gmail.com
<p>1/ remove all the code for selector support<br>
2/ remove this "in-memory" requirement of the index table, to remove the repo size limitation. </p>
<p>code: <a href="https://github.com/named-data/repo-ng">https://github.com/named-data/repo-ng</a></p>
NFD-android - Feature #4367 (Rejected): what should AutoPropagator do if there is no proper ident...https://redmine.named-data.net/issues/43672017-10-30T14:39:38ZYanbiao Lilybmath2009@gmail.com
<p>When a prefix (/ndn/ucla/alice/test/app1) is registered in the local RIB, NFD will select an Identity from its key-chain that covers the locally registered prefix to propagate and to sign the propagation command.<br>
If there is not such an Identity, nothing will be propagated out according current design.</p>
<p>On the android platform, each App has its own key-chain which is inaccessible to the NFD.<br>
So, when an App registers a prefix, NFD always can not find a proper identity for propagation.</p>
<p>Given that the original intention of propagation is to aggregate and announce reachability to local Apps, what shall we do in the above case.<br>
Possible options:<br>
1/ Do not propagate anything since NFD can not find a proper identity (i.e. a delegated namespace) covers locally registered prefixes.<br>
2/Just propagate the locally registered prefix and use NFD's default key to sign.<br>
3/ Let Apps to install their identity certificate into NFD's key-chain</p>
NFD - Feature #3211 (Closed): Redesign of remote prefix registrationhttps://redmine.named-data.net/issues/32112015-09-17T17:24:40ZYanbiao Lilybmath2009@gmail.com
<ol>
<li><p>rename Remote Registration to Automatic Prefix Propagation.<br><br>
REASON: the term "Remote" may confuse others, while "Automatic Propagation" impresses what this feature works.</p></li>
<li><p>eliminate two interfaces: registerPrefix / uregisterPrefix.<br><br>
REASON: registration and unregistration processes are triggered by corresponding signals of Rib automatically, their entrances should not be exposed.</p></li>
<li><p>select the shortest available identity to register remotely, rather than the longest one.<br><br>
REASON: to reduce the number of registered entries.<br><br>
NOTE: no registration flag will be inherited from local RIB entries. The default setting (i.e, CHILD INHERIT) takes effect.</p></li>
<li><p>introduce a resendRegCommand method shared by refreshing, retrying or redoing (after hub connect) registrations and improve the mechanism.<br><br>
REASON1: refreshing, retrying, redoing registrations all require to resend the registration commands.<br><br>
REASON2: before resending commands, there may be new identities inserted or existing identities erased. This scenario was not covered before.</p></li>
<li><p>introduce a RemoteRegisteredEntry class and a state machine to maintain registered entries.</p></li>
<li><p>maintain potential registered entries when there is no connectivity (fix <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: Remote prefix registration: prefix is not registered if app starts before HUB connection (Closed)" href="https://redmine.named-data.net/issues/2413">#2413</a>)</p></li>
<li><p>correct the action when registration succeeds but the registered entry does not exist.</p></li>
<li><p>adopt an exponential back-off strategy as the retry policy after registration fails, instead of performing limited number of retries.</p></li>
<li><p>cover the case when unregistration succeeds but an entry with the same name exists.</p></li>
<li><p>redesign the test suite.</p></li>
</ol>
NFD - Bug #2757 (Closed): Gateway RIB crashes after remote unregistrationhttps://redmine.named-data.net/issues/27572015-04-17T08:00:02ZYanbiao Lilybmath2009@gmail.com
<p>When the RIB manager on a gateway processes a remote unregistration command from a laptop, nfd process on the gateway crashes after sending a successful response.</p>
<p>Environment: two machines, A works as the laptop while B works as the gateway.</p>
<p>Steps to reproduce:</p>
<ol>
<li>run nfd on A with <code>rib.remote-register</code> enabled, and set the log level to INFO</li>
<li>generate an identity /Z/A on A and install its cert.</li>
<li>run nfd on B with <code>rib.localhop-security</code> enabled, configure the trust anchor as type any.</li>
<li>run <code>nfdc register /localhop/nfd udp4://<ip_address_of_B></code> on A to gain connectivity to B.</li>
<li>run <code>ndnpingserver ndn:/Z/A/H</code> on A to register prefix /Z/A/H/ping locally. Confirm that /Z/A is successfully registered to B's rib (run <code>nfd-status -r</code> on B).</li>
<li>stop ndnpingserver on A. Confirm that /Z/A/H/ping is unregistered from A's rib and there is not any other entries on A's rib starts with prefix /Z/A. So that /Z/A will be unregistered from B's rib.</li>
</ol>
<p>Actual: A's nfd can receive the response of successfully unregistration of /Z/A from B. B's nfd has exited unexpectedly.<br><br>
Expected: B's nfd does not crash.</p>
NFD - Bug #2407 (Duplicate): Local certificate is not publishedhttps://redmine.named-data.net/issues/24072015-01-23T10:17:25ZYanbiao Lilybmath2009@gmail.com
<p>After a proper trust model is configured in localhop_security for remote registration, the remote hub needs to fetch the certificate from the requester to verify the signature. But it fails with error "can not fetch cert". </p>
<p>According to the traffic captured by ndndump, the remote hub sent out the interest for certificate, but the requester didn't answer it.</p>
<p>A temporary solution: </p>
<p>Before sending out remote registration command, just put the data of certificate of the key that signs this command on the face. Thus, the certificate will be cached in CS to answer the interest of certificate.</p>
NFD - Bug #2312 (Closed): CHILD_INHERIT does not work when run nfdc registerhttps://redmine.named-data.net/issues/23122014-12-19T12:18:22ZYanbiao Lilybmath2009@gmail.com
<p>A route with prefix <code>/localhop/nfd/rib</code> is already exists. (<code>/localhop/nfd/rib nexthops={faceid=259 (cost=0)}</code>)</p>
<p>After register a prefix <code>/localhop/nfd</code> (using <code>nfdc register</code>), a new route is generated (<code>/localhop/nfd nexthops={faceid=262 (cost=0)}</code>), in which <code>CHILD_INHERIT</code> is default set.</p>
<p>However, the previous route doesn't inherit the face of the second route.</p>
<p>here follows the full screenshot:</p>
<pre><code>LiYanBiaos-MacBook-Pro:NFD lybmath$ nfd-start
LiYanBiaos-MacBook-Pro:NFD lybmath$ nfd-status -b
FIB:
/localhost/nfd nexthops={faceid=1 (cost=0)}
/localhop/nfd/rib nexthops={faceid=259 (cost=0)}
/localhost/nfd/rib nexthops={faceid=259 (cost=0)}
LiYanBiaos-MacBook-Pro:NFD lybmath$ nfdc register /localhop/nfd udp://spurs.cs.ucla.edu
Successful in name registration: ControlParameters(Name: /localhop/nfd, FaceId: 262, Origin: 255, Cost: 0, Flags: 1, )
LiYanBiaos-MacBook-Pro:NFD lybmath$ nfd-status -b
FIB:
/localhost/nfd nexthops={faceid=1 (cost=0)}
/localhop/nfd/rib nexthops={faceid=259 (cost=0)}
/localhop/nfd nexthops={faceid=262 (cost=0)}
/localhost/nfd/rib nexthops={faceid=259 (cost=0)}
LiYanBiaos-MacBook-Pro:NFD lybmath$
</code></pre>