[Mini-NDN] Fw: mini-ndn RTNETLINK error and ndndump question
Ashlesh Gawande (agawande)
agawande at memphis.edu
Thu Oct 6 08:03:27 PDT 2016
Hi all
Just FYI, Mini-NDN does not work with PPAs as of yet. Please use source.
Ashlesh
________________________________
From: Ashlesh Gawande (agawande)
Sent: Tuesday, October 4, 2016 8:46 AM
To: Gaetano Laterza
Subject: Re: [Mini-NDN] mini-ndn RTNETLINK error and ndndump question
>From xterm I think you are connecting to the NFD that is running outside the Mini-NDN nodes. This is because of the bug that xterm does not set $HOME as /tmp/<node-name>. Are you running NFD outside of Mini-NDN?
When you do ps aux | grep nfd it should show you two NFDs, one with config file of a and other with that of b.
But since mininet> a nfd-status does not work I doubt it will show any NFD running.
I have not configured Mini-NDN for use with PPAs - If you install from source it does not require the cert file folder which is giving the FATAL error.
Can you please try to install from source: ndn-cxx, NFD, and NLSR
https://github.com/named-data/ndn-cxx
https://github.com/named-data/NFD
https://github.com/named-data/NLSR
https://github.com/named-data/ndn-tools
(BUT BEFORE THIS MAKE SURE THAT YOU HAVE COMPLETELY REMOVED THE PPA INSTALLS)
Ashlesh
________________________________
From: Gaetano Laterza <g.laterza6 at gmail.com>
Sent: Tuesday, October 4, 2016 2:40:20 AM
To: Ashlesh Gawande (agawande)
Subject: Re: [Mini-NDN] mini-ndn RTNETLINK error and ndndump question
a ping -c 3 1.0.0.2 works, I can normally see packets through tcpdump too.
ndn-cxx:amd64/xenial 0.4.1-ppa1~xenial uptodate
ndn-tools:amd64/xenial 0.3-6-gd230073-ppa1~xenial uptodate
nfd:amd64/xenial 0.4.1-1-g704430c-ppa1~xenial uptodate
I forgot to say that I'm now running
Linux machine 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
About nfd debug logs, I changed my simple.conf file like this:
[nodes]
a: _ nfd-log-level=DEBUG
b: _ nfd-log-level=DEBUG
[links]
a:b
And in /tmp/a/a.log or /tmp/b/b.log I can only see this:
1475565918.612249 INFO: [StrategyChoice] setDefaultStrategy /localhost/nfd/strategy/best-route/%FD%04
1475565918.612484 INFO: [InternalForwarderTransport] [id=0,local=internal://,remote=internal://] Creating transport
1475565918.612507 DEBUG: [InternalClientTransport] connectToForwarder 0x94c8f0
1475565918.612532 INFO: [FaceTable] Added face id=1 remote=internal:// local=internal://
1475565918.613168 DEBUG: [CommandValidator] generated certfile path: /tmp/a/certs/localhost_daemons_nfd.ndncert
1475565918.613187 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1475565918.613196 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1475565918.613206 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1475565918.613274 FATAL: [NFD] Unable to open certificate file /tmp/a/certs/localhost_daemons_nfd.ndncert [from ../daemon/mgmt/command-validator.cpp:208 in void nfd::CommandValidator::onConfig(const ConfigSection&, bool, const string&)]
Ps: I noticed that if I type:
mininet> a nfd-status
ERROR: error while connecting to the forwarder (No such file or directory)
While if I type it on an xterm terminal, it works normally.
And about this:
-------------------------------------------------
One more thing, you say that:
nfdc register /test/pingserver udp4://1.0.0.2:6363<http://1.0.0.2:6363>
FIB and RIB:
FIB:
/localhost/nfd/rib nexthops={faceid=259 (cost=0)}
/test/ndnping nexthops={faceid=262 (cost=0)}
/localhost/nfd nexthops={faceid=1 (cost=0)}
The FIB should show /test/pingserver and not /test/ndnping (same on node b).
I guess you copied some other output for /test/ndnping?
---------------------------------------------------
Yes, a just copied another output cause I was trying several times while writing the mail, sorry for that.
2016-10-04 2:07 GMT+02:00 Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>>:
So ndnpingserver and ndnping connects to local NFD via unix socket.
For example ndnpingserver would connect to NFD via unix socket file. So any packets it receives would first come through a UDP/TCP face to NFD and then delivered to ndnpingserver. So it should show on ndndump.
So changing unix socket would not solve the problem. Your problem is that ndndump does not capture any packet on the interface of 'a' because none are sent!
ndnpingserver and ndnping running on different nodes must communicate via either TCP or UDP - you don't have to set it (If they are running on the same node they will use a unix socket).
So when you say only face 264 (a local unix face so that local application can communicate with local NFD) works that means ndnping sends interest to local NFD, but NFD cannot forward it further (since non-local face 262 has 0 outgoing interest). Can you ping normally:
mininet> a ping -c3 1.0.0.2
and see if that works? If it does not work then problem is with Mininet installation. Can you post the output of the command when you install Mininet (sudo ./util/install.sh -nv)?
If the normal ping works can you post the version of ndn-cxx, NFD, and ndn-tools? Also post the output for
mininet>a ifconfig
and mininet>b ifconfig
And the NFD DEBUG logs.
But from what the problem looks like, face 262 should say:
faceid=262 remote=udp4://1.0.0.2:6363<http://1.0.0.2:6363> local=udp4://1.0.0.1:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
and not:
faceid=262 remote=udp4://1.0.0.2:6363<http://1.0.0.2:6363/> local=udp4://192.168.1.98:6363<http://192.168.1.98:6363/> counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
because this looks like that NFD running on a is not aware that the interface is a-eth0 (1.0.0.1) and not your computer's interface (192.168.1.98).
-------------------------------------------------
One more thing, you say that:
nfdc register /test/pingserver udp4://1.0.0.2:6363<http://1.0.0.2:6363/>
FIB and RIB:
FIB:
/localhost/nfd/rib nexthops={faceid=259 (cost=0)}
/test/ndnping nexthops={faceid=262 (cost=0)}
/localhost/nfd nexthops={faceid=1 (cost=0)}
The FIB should show /test/pingserver and not /test/ndnping (same on node b).
I guess you copied some other output for /test/ndnping?
---------------------------------------------------
Ashlesh
________________________________
From: Gaetano Laterza <g.laterza6 at gmail.com<mailto:g.laterza6 at gmail.com>>
Sent: Monday, October 3, 2016 4:12:34 PM
To: Ashlesh Gawande (agawande)
Subject: Re: [Mini-NDN] mini-ndn RTNETLINK error and ndndump question
Hi Ashlesh,
I'm sorry to bother you again. Last week I did an answer to the mini-ndn mailing list about ndndump issue. I can't see the flow of Interest/Data packets with ndndump cause I noticed that the ping packets were sent through unix stream channel and not through udp4 channel. How can I use udp4 channel? I'll explain in short what I do.
simple.conf:
[nodes]
a: _
b: _
[links]
a:b
So I have node a (1.0.0.1) and node b (1.0.0.2).
On node a:
nfdc register /test/pingserver udp4://1.0.0.2:6363<http://1.0.0.2:6363>
FIB and RIB:
FIB:
/localhost/nfd/rib nexthops={faceid=259 (cost=0)}
/test/ndnping nexthops={faceid=262 (cost=0)}
/localhost/nfd nexthops={faceid=1 (cost=0)}
RIB:
/localhost/nfd/rib route={faceid=259 (origin=0 cost=0 ChildInherit)}
/test/ndnping route={faceid=262 (origin=255 cost=0 ChildInherit)}
face 262:
faceid=262 remote=udp4://1.0.0.2:6363<http://1.0.0.2:6363> local=udp4://192.168.1.98:6363<http://192.168.1.98:6363> counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
On node b:
ndnpingserver /test/pingserver
Now, if I check FIB and RIB again, I see:
FIB:
/localhost/nfd/rib nexthops={faceid=259 (cost=0)}
/test/ndnping nexthops={faceid=262 (cost=0)}
/localhost/nfd nexthops={faceid=1 (cost=0)}
/test/pingserver/ping nexthops={faceid=264 (cost=0)}
RIB:
/localhost/nfd/rib route={faceid=259 (origin=0 cost=0 ChildInherit)}
/test/pingserver/ping route={faceid=264 (origin=0 cost=0 ChildInherit)}
/test/ndnping route={faceid=262 (origin=255 cost=0 ChildInherit)}
with face 264:
faceid=264 remote=fd://29 local=unix:///run/nfd.sock counters={in={1i 0d 430B} out={0i 1d 806B}} local on-demand point-to-point
When I ping from node a with:
ndnping /test/pingserver
Only face 264 works (I can see this from the counters):
faceid=262 remote=udp4://1.0.0.2:6363<http://1.0.0.2:6363> local=udp4://192.168.1.98:6363<http://192.168.1.98:6363> counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
faceid=264 remote=fd://29 local=unix:///run/nfd.sock counters={in={1i 7d 1109B} out={7i 1d 1226B}} local on-demand point-to-point
If I destroy the face with faceid 264, a new face automatically comes up when I send a ping packet.
To avoid the creation of faces on unix stream channel, I tried to comment out unix section in nfd.conf file:
;unix
; {
; path /var/run/nfd.sock ; Unix stream listener path
; }
and I tried to change the transport channel in client.conf file too (default value: "transport=unix:///var/run/nfd.sock").
But in the last case I don't know what proper value I can assign to transport, so if I change it nfd doesn't work anymore (and actually I don't know if it is the right way to solve my problem).
How would you do in my case? If you realize the scenario I described, are you able to send packets through udp4 channel? Am I trying to do anything wrong?
Thank you very much for you help!
Regards,
Gaetano.
2016-09-29 22:02 GMT+02:00 Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>>:
What version of Mininet are you using? They recently fixed the RTNETLINK error on Ubuntu 16.04.
You might want to install from source if you haven't: https://github.com/mininet/mininet
If you did install from source and still got this error, I don't think it should affect in any way since the program does not crash.
I am not sure why ndndump is not working. There is one bug for xterm:
https://redmine.named-data.net/issues/3038
In xterm, can you try export HOME=/tmp/<node-name> before running anything?
That should fix it.
If not, next thing you can try is to paste the following in bin/minindn, line 344:
for host in self.net.hosts:
for intf in host.intfNames():
ndnDumpOutputFile = "dump.%s_%s" % (intf, str(host.intf(intf).IP()))
host.cmd("ndndump -i %s > %s &" % (intf, ndnDumpOutputFile))
Then try to install and run and see in /tmp/<node-name> whether you have dump files that are populated.
Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Gaetano Laterza <g.laterza6 at gmail.com<mailto:g.laterza6 at gmail.com>>
Sent: Thursday, September 29, 2016 11:34:26 AM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [Mini-NDN] mini-ndn RTNETLINK error and ndndump question
Hi all, I'm starting to learn ndn protocol and mini-ndn tool. In particular I'd like to start mini-ndn with a very simple configuration, here the content of my conf file:
$ cat simple.conf
[nodes]
a: _
b: _
[links]
a:b delay=10ms
In short, I'd like to observe the exchange of Interest / Data packets using ndndump.
First of all, I cannot understand an error occurring during links initialization:
$ sudo minindn simple.conf
Parse of simple.conf done.
*** Creating network
*** Adding controller
*** Adding hosts:
a b
*** Adding switches:
*** Adding links:
(10ms delay) *** Error: RTNETLINK answers: No such file or directory
(10ms delay) *** Error: RTNETLINK answers: No such file or directory
(a, b)
*** Configuring hosts
a b
Setup time: 4
*** Starting controller
c0
*** Starting 0 switches
*** Starting CLI:
mininet>
Any idea about the Error: RTNETINK answers: No such file or directory?
Here my system information:
$ uname -a
Linux machine 4.1.33-nrj-desktop-1rosa-x86_64 #1 SMP PREEMPT Sun Sep 18 20:20:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
So, going back to the packets exchange, through xterm I typed on node a:
$ ndnpingserver /a
PING SERVER /a
Always on node a, I ran ndndump:
$ ndndump -i a-eth0
So I ran from node b the command:
$ ndnping /a
PING /a
content from /a: seq=2172173333986410181 time=2.51873 ms
content from /a: seq=2172173333986410182 time=0.411503 ms
content from /a: seq=2172173333986410183 time=0.381647 ms
content from /a: seq=2172173333986410184 time=0.458184 ms
[...]
And on node a I can see:
interest received: seq=2172173333986410181
interest received: seq=2172173333986410182
interest received: seq=2172173333986410183
interest received: seq=2172173333986410184
[...]
But ndndump doesn't show any packet. Why? I also tried with:
$ tcpdump -i a-eth0 -v
But when I stop it, the result is:
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Thank you in advance for your help!
Regards,
Gaetano.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20161006/05678909/attachment.html>
More information about the Mini-NDN
mailing list