NDN project issue tracking system: Issueshttps://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232019-11-18T08:56:51ZNDN project issue tracking system
Redmine NFD - Bug #5056 (Closed): Creating permanent face with changed MTU does not work if on-demand fac...https://redmine.named-data.net/issues/50562019-11-18T08:56:51ZJohn DeHartjohn.d.dehart@gmail.com
<p>On the NDN Testbed I have tried to create permanent faces with an MTU of 1450 to turn on NDNLP fragmentation and reassembly. But if the neighbor node has already started sending NDN packets an on-demand face will be created with an MTU of 8800. In this state, the addition of the new permanent face with MTU 1450 does not succeed.</p>
NFD - Bug #4874 (Closed): AsfStrategy Nacks new Interest from neighbor while there exists a Pendi...https://redmine.named-data.net/issues/48742019-03-12T10:56:25ZJohn DeHartjohn.d.dehart@gmail.com
<p>As discussed in this email thread: </p>
<p>[[[https://www.lists.cs.ucla.edu/pipermail/nfd-dev/2019-March/003584.html]]]</p>
<p>While we have a PIT entry for an interest with NextHopFaceId from NLSR to retrieve the cert/KEY for a route update,<br>
there may not currently be a FIB entry for this route yet.<br>
If another neighbor sends an Interest for the same name, AsfStrategy finds no FIB entry and NACKs, for NoRoute,<br>
the neighbor interest and removes the PIT entry.<br>
Then when the data returns for the NLSR interest, there is no PIT entry and the data gets dropped as unsolicited data.</p>
Packaging - Task #4594 (In Progress): systemd service files dependency corrections for nfd and as...https://redmine.named-data.net/issues/45942018-04-26T10:09:53ZJohn DeHartjohn.d.dehart@gmail.com
<p>The systemd service files currently in use for Ubuntu 16.04 do not correctly support stopping and restarting<br>
daemons that are dependent on each other. For example when we do a stop of nfd:</p>
<pre><code>systemctl stop nfd
</code></pre>
<p>nfd and all the dependent daemons should be stopped. Because it is misconfigured, nfd stops and restarts.</p>
<p>Also, when we try to start nfd:</p>
<pre><code>systemctl start nfd
</code></pre>
<p>we would like all the associated daemons to start as well. This does not happen.</p>
<p>To fix this, the nfd.service file should contain this in its Unit section:</p>
<pre><code>Wants=nlsr.service
Wants=nfd-autoreg.service
Wants=nfd-status-http-server.service
Wants=repo-ng.service
Wants=repo-ng2.service
Wants=ndnping.service
Wants=ndn-autoconfig-server.service
</code></pre>
<p>And each service listed above (nlsr, nfd-autoreg, nfd-status-http-server, repo-ng, repo-ng2, ndnping and ndn-autoconfig-server) should contain this in its Unit section:</p>
<pre><code>Requires=nfd.service
After=nfd.service
</code></pre>
<p>Two of the service files should be corrected in the Package system: nfd-status-http-server.service and nfd-autoreg.service.<br>
nfd-status-http-server.service is missing the <code>Requires=nfd.service</code>.<br>
nfd-autoreg.service has <code>Wants=nfd.service</code> which should be replaced with <code>Requires=nfd.service</code>.</p>
<p>nlsr.service, repo-ng.service, ndnping.service and ndn-autoconfig-server.service are all correct.</p>
<p>repo-ng2.service is a second repo-ng that we set up on the Testbed and will need to be taken care of by the Testbed config scripts.</p>
<p>The nfd.service changes should also probably be taken care of by the Testbed config scripts since not alll<br>
Ubuntu users of NFD will want to include all those daemons.</p>
Packaging - Task #3910 (Closed): nfd-status-http-server has no HOME on Ubuntu 16.04https://redmine.named-data.net/issues/39102017-01-04T08:52:09ZJohn DeHartjohn.d.dehart@gmail.com
<p>The /etc/systemd/system/multi-user.target.wants/nfd-status-http-server.service file <br>
has no definition for the HOME environment variable. When it runs on Ubuntu 16.04<br>
it gives this error message in /var/log/syslog:</p>
<p>isan-ndn nfd-status-http-server[7809]: boost::filesystem::create_directory: Read-only file system: "./.ndn"</p>
<p>Adding this line to the [Service] section of the file should fix it:</p>
<p>Environment=HOME=/var/lib/ndn/nfd-status-http-server</p>
NFD - Bug #2626 (New): CS lookup takes long time if Interest Name covers many entrieshttps://redmine.named-data.net/issues/26262015-03-09T08:48:54ZJohn DeHartjohn.d.dehart@gmail.com
<p>We have been noticing odd spikes in ndnping RTTs and have been trying to track down the root cause of it.</p>
<p>I believe I have narrowed it down to an interaction between the ndnping Interests and the Interests we send out to collect data<br>
from nfd for the ndnmap.arl.wustl.edu bandwidth display.</p>
<p>I have some very specific data now on something strange that is happening with nfd.</p>
<p>I include a portion of the combined log files from nfd and an ndndump I was running on the WU Testbed node at the time of such a spike. The ndnping in question has a reference number of: 1744606568<br>
I have modified the log messages to insert “nfd” and “ndndump” to help keep straight which messages<br>
are from which log. Please note that this is all from the WU Testbed node so the times should be <br>
directly comparable.</p>
<p>At time 1425669071.230902, nfd performs a <code>[ContentStore] find /localhost/nfd/faces/list R</code> but it doesn't register <code>[ContentStore] no-match</code> until 1425669071.253650, which is <br>
22.748 ms later. There were NO nfd log messages in between.<br>
During that time, ndndump registers the arrival of 7 new Interests.</p>
<p>From this it would appear that the search of the CS took 22.748 ms.</p>
<pre><code>1425669071.226706 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466
1425669071.226759 nfd DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186
1425669071.227090 nfd DEBUG: [ContentStore] find /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186 L
1425669071.229658 nfd DEBUG: [ContentStore] no-match
1425669071.229736 nfd DEBUG: [AccessStrategy] /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 interestFrom 266 new-interest mi=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173
1425669071.230136 nfd DEBUG: [AccessStrategy] /ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3582782466 interestTo 269 last-nexthop rto=111227
1425669071.230395 nfd DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/wustl/ndnmap/stats/128.196.203.36/72.36.112.82/141.225.11.173/193.147.51.186
1425669071.230794 nfd DEBUG: [Forwarder] onIncomingInterest face=269 interest=/localhost/nfd/faces/list
1425669071.230902 nfd DEBUG: [ContentStore] find /localhost/nfd/faces/list R
1425669071.231738 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197
1425669071.236867 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/arizona/ndnmap/stats/192.172.226.248/129.82.138.48/141.225.11.173/133.9.73.66/128.187.81.12?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2335882350
1425669071.241170 ndndump From: 172.16.21.176, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/wustl/ping/1744606568?ndn.MustBeFresh=1&ndn.Nonce=1744606568
1425669071.241297 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/org/caida/ndnmap/stats/128.195.4.36/202.120.188.176?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2532105913
1425669071.244815 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/ch/unibas/ndnmap/stats/193.147.51.186/162.105.146.26/137.194.54.81?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=3200941563
1425669071.249054 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/cn/edu/pku/ndnmap/stats/202.120.188.176/114.247.165.44?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=338471191
1425669071.253186 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/edu/neu/ndnmap/stats/162.105.146.26?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=763898399
1425669071.253650 nfd DEBUG: [ContentStore] no-match
1425669071.253702 nfd DEBUG: [Forwarder] onOutgoingInterest face=1 interest=/localhost/nfd/faces/list
1425669071.253788 nfd DEBUG: [BestRouteStrategy2] /localhost/nfd/faces/list?ndn.ChildSelector=1&ndn.MustBeFresh=1&ndn.Nonce=2666790337 from=269 newPitEntry-to=1
1425669071.253909 nfd DEBUG: [InternalFace] received Interest: /localhost/nfd/faces/list
1425669071.253986 nfd DEBUG: [InternalFace] found Interest filter for /localhost/nfd/faces (previous match)
1425669071.254052 nfd DEBUG: [FaceManager] command result: processing verb: list
1425669071.257714 nfd DEBUG: [Forwarder] onIncomingData face=1 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00
1425669071.257882 nfd DEBUG: [ContentStore] insert /localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00
1425669071.258040 ndndump From: 128.252.153.28, To: 128.252.153.194, Tunnel Type: UDP, INTEREST: /ndn/it/unipd/ndnmap/stats/72.36.112.82/192.43.193.111/193.147.51.186/161.105.195.18?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=738760142
1425669071.258043 nfd DEBUG: [Forwarder] onIncomingData matching=/localhost/nfd/faces/list
1425669071.258123 nfd DEBUG: [Strategy] beforeSatisfyInterest pitEntry=/localhost/nfd/faces/list inFace=1 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00
1425669071.258333 nfd DEBUG: [Forwarder] onOutgoingData face=269 data=/localhost/nfd/faces/list/%FD%00%00%01K%F0%7F%A1%96/%00%00
1425669071.258514 nfd DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36
1425669071.258815 nfd DEBUG: [ContentStore] find /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36 L
1425669071.261579 nfd DEBUG: [ContentStore] no-match
1425669071.261652 nfd DEBUG: [Forwarder] onOutgoingInterest face=260 interest=/ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36
1425669071.261920 ndndump From: 128.252.153.194, To: 72.36.112.82, Tunnel Type: UDP, INTEREST: /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197
1425669071.261945 nfd DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/ndnmap/stats/192.172.226.248/128.97.98.7/129.82.138.48/162.105.146.26/128.195.4.36?ndn.MustBeFresh=1&ndn.InterestLifetime=700&ndn.Nonce=2821820197 from=266 newPitEntry-to=260
1425669071.262232 nfd DEBUG: [Forwarder] onIncomingInterest face=303 interest=/ndn/edu/wustl/ping/1744606568
</code></pre>
<p>Here are some other examples of CS 'find' operations:</p>
<pre><code>1425669061.723974 DEBUG: [ContentStore] find /localhost/nfd/faces/events R
1425669061.725418 DEBUG: [ContentStore] no-match
1425669105.051430 DEBUG: [ContentStore] find /localhost/nfd/faces/list R
1425669105.074600 DEBUG: [ContentStore] no-match
1425669001.213923 DEBUG: [ContentStore] find /localhost/nfd/status R
1425669001.214097 DEBUG: [ContentStore] no-match
1425669001.222970 DEBUG: [ContentStore] find /localhost/nfd/faces/channels R
1425669001.223182 DEBUG: [ContentStore] no-match
1425669001.639833 DEBUG: [ContentStore] find /localhost/nfd/faces/query/%96%1Cr%1Audp4%3A%2F%2F128.252.153.28%3A6363 R
1425669001.640152 DEBUG: [ContentStore] no-match
1425669105.099019 DEBUG: [ContentStore] find /ndn/it/unipd/ndnmap/stats/72.36.112.82/192.43.193.111/193.147.51.186/161.105.195.18 L
1425669105.101716 DEBUG: [ContentStore] no-match
1425669105.242469 DEBUG: [ContentStore] find /ndn/edu/wustl/ping/1744606602 L
1425669105.242597 DEBUG: [ContentStore] no-match
</code></pre>
<p>Analyzing these times, I get this:</p>
<pre><code> Time Diff find log msg no-match log mst name
0.174045562744 1425669001.213923 1425669001.214097 find /localhost/nfd/status R no-match
0.211954116821 1425669001.222970 1425669001.223182 find /localhost/nfd/faces/channels R no-match
0.319004058838 1425669001.639833 1425669001.640152 find /localhost/nfd/faces/query/%96%1Cr%1Audp4%3A%2F%2F128.252.153.28%3A6363 R no-match
1.44410133362 1425669061.723974 1425669061.725418 find /localhost/nfd/faces/events R no-match
23.1699943542 1425669105.051430 1425669105.074600 find /localhost/nfd/faces/list R no-match
2.6969909668 1425669105.099019 1425669105.101716 find /ndn/it/unipd/ndnmap/stats/72.36.112.82/192.43.193.111/193.147.51.186/161.105.195.18 L no-match
0.128030776978 1425669105.242469 1425669105.242597 find /ndn/edu/wustl/ping/1744606602 L no-match
</code></pre>
<p>So, it appears that the find for <code>/localhost/nfd/faces/list</code> takes a lot longer than<br>
any of the other find operations.</p>
NFD - Bug #2473 (Closed): Inconsistency in UDP face timeoutshttps://redmine.named-data.net/issues/24732015-02-03T11:28:42ZJohn DeHartjohn.d.dehart@gmail.com
<p>The UDP face timeout specified in the nfd config file and the value used don't agree.<br><br>
I have 600 seconds specified in the config file but faces actually expire at 1200 seconds.<br>
The message in the log file says 600 seconds.<br><br>
I don’t have an easy way to check to see if this has been fixed in newer versions.<br>
This is the released version of nfd that we run on the Testbed.<br>
It is not causing any problems, just an inconsistency.</p>
<pre><code>$ grep idle_timeout /etc/ndn/nfd.conf
idle_timeout 600 ; idle time (seconds) before closing a UDP unicast face
$ nfd-status -f | grep 10.0.2.1
faceid=343 remote=udp4://10.0.2.1:6363 local=udp4://10.0.2.2:6363 expires=1112s counters={in={2i 0d 108B} out={192i 2d 18059B}} non-local on-demand point-to-point
ndnops@ndnops:~$ grep 10.0.2.1 /var/log/ndn/nfd.log | grep 343
1422989686.487219 INFO: [FaceTable] Added face id=343 remote=udp4://10.0.2.1:6363 local=udp4://10.0.2.2:6363
1422990886.487276 INFO: [UdpFace] [id:343,uri:udp4://10.0.2.1:6363] Idle for more than 600 seconds, closing
1422990886.487436 INFO: [UdpFace] [id:343,uri:udp4://10.0.2.1:6363] Close tunnel
1422990886.490994 INFO: [FaceTable] Removed face id=343 remote=udp4://10.0.2.1:6363 local=udp4://10.0.2.2:6363
ndnops@ndnops:~$ nfd-status -v
General NFD status:
nfdId=/localhost/daemons/nfd/KEY/ksk-1406409442387/ID-CERT
version=0.2.0-88-gc5173de
startTime=20150203T170240.606000
currentTime=20150203T191649.046000
uptime=8048 seconds
nNameTreeEntries=1113
nFibEntries=65
nPitEntries=865
nMeasurementsEntries=83
nCsEntries=8192
nInInterests=3695849
nOutInterests=962078
nInDatas=56719
nOutDatas=56949
</code></pre> NFD - Bug #2121 (Closed): nfd-status-http-server subprocesses hang with data size over 65536https://redmine.named-data.net/issues/21212014-11-03T12:33:02ZJohn DeHartjohn.d.dehart@gmail.com
<p>nfd-status-http-server.py spawns subprocesses of 'nfd-status -x' to gather<br>
nfd status information. If the size of the data returned from such an<br>
nfd-status is over 65536 the subprocess hangs. I believe this is<br>
a limitation in the subprocess.PIPE mechanism.</p>
<p>There is some discussion of this issue here:<br>
<a href="http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/">http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/</a></p>
<p>This is a rather serious problem as of our Testbed nodes are now limited<br>
in the number of links they can have. For example when I tried to add the WASEDA<br>
node I wanted to add a link from WASEDA to ARIZONA but was unable to because <br>
the ARIZONA node would eventually hang with all the stuck subprocesses caused<br>
by the testbed status page trying to monitor its status.</p>
NFD - Bug #1971 (Closed): NccStrategy: Interest not forwarded if a similar Interest arrives durin...https://redmine.named-data.net/issues/19712014-09-08T11:24:35ZJohn DeHartjohn.d.dehart@gmail.com
<p>Steps to reproduce:</p>
<ol>
<li>send an Interest with MustBeFresh=yes</li>
<li>response a Data with FreshnessPeriod=0ms</li>
<li>within 50ms, retransmit the same Interest with a fresh Nonce</li>
</ol>
<p>Expected: Interest is forwarded to producer<br><br>
Actual: Interest is not forwarded and eventually times out</p>
<p>Root cause:</p>
<ol>
<li>The first Interest creates a PIT entry. NCC strategy knows this PIT entry is new.</li>
<li>When the first Interest is satisfied, in-records and out-record are deleted from the PIT entry; the PIT entry itself is scheduled to be deleted when straggler timer expires (100ms).</li>
<li>The second Interest arrives before straggler time expires, so it finds the same PIT entry. Straggler timer is cancelled.</li>
<li>The second Interest cannot be satisfied by ContentStore because the Data is already stale.</li>
<li>NCC strategy thinks this PIT entry is old via <code>NccStrategy::PitEntryInfo::isNewInterest</code>, so it won't forward the Interest.</li>
</ol>
<hr>
<p>Original report: <strong>nfd-status -f : gets frequent timeout on Testbed nodes</strong></p>
<p>When running nfd-status on Testbed nodes we get frequent results of:</p>
<pre><code>Request timed out
</code></pre>
<p>I've narrowed it down to the face status portion of nfd-status.</p>
<p>I have not been able to get this to happen on my local nfd running on MacOS.</p>
NFD - Task #1729 (Closed): Add byte counters to FaceCountershttps://redmine.named-data.net/issues/17292014-07-02T14:05:16ZJohn DeHartjohn.d.dehart@gmail.com
<p>Add byte count fields to <code>nfd::FaceCounters</code> structure.</p>
<p>Byte count field reflect number of bytes received or sent on link layer.<br>
Those counters include link layer headers imposed by NFD (NDNLP or LocalControlHeader), but exclude headers of underlying protocol (Ethernet or TCP or UDP).<br>
Each counter is 64-bit, and can wrap around after overflowing.</p>