Bug #2334
closed
[NRD] error while connecting to the forwarder
Added by Anche Kuo over 9 years ago.
Updated over 9 years ago.
Description
When the "transport" field in configuration file "client.conf" is changed to value other than
{tcp|udp}://127.0.0.1 or unix:///var/run/nfd.sock
then whenever NRD is run it reports the fatal error message
"FATAL: [NRD] error while connecting to the forwarder"
environment on OS X 10.10.1
OSTYPE: darwin14
boost: 1.55.0
steps to reproduce
sudo cp /usr/local/etc/ndn/nfd.conf.sample /usr/local/etc/ndn/nfd.conf
sudo cp /usr/local/etc/ndn/client.conf.sample /usr/local/etc/ndn/client.conf
change the following line in "client.conf"
transport=unix:///var/run/nfd.sock
to
transport=tcp4://172.18.53.106:6363
; another computer with the exact same environment, OS, hardware running up an nfd and nrd successfully
ndnsec-keygen /`whoami` | ndnsec-install-cert -
sudo mkdir -p /usr/local/etc/ndn/keys/
ndnsec-cert-dump -i /`whoami` > default.ndncert
sudo mv default.ndncert /usr/local/etc/ndn/keys/default.ndncert
nfd-start
----> boom! The error occurs
" [NRD] error while connecting to the forwarder"
By the way on my Fedora 20 with boost 1.54.0 there is no such problem.
Files
I am new to this place, and is wondering if this should be a task or a bug?
Since I am not sure if it is a bug or did I mis-operated on some steps?
- Tracker changed from Task to Bug
- Description updated (diff)
- Category set to RIB
- Target version set to v0.3
This shall use Bug tracker, because the software's behavior differs from operator's expectation.
- Description updated (diff)
- Status changed from New to Rejected
This Bug shall be Rejected because NRD is supposed to connect to the local NFD. It's unsupported to connect NRD to a remote NFD.
The client.conf used by NRD must specify either local UNIX socket or local TCP socket (tcp4://127.0.0.1:6363).
So if I want to connect the local consumer to a remote producer, how should I do it?
quote from the client.conf:
; "transport" specifies Face's default transport connection.
; The value is a unix or tcp4 scheme Face URI.
What does this mean?
Because when I am running ndn-cxx example client in my Fedora 20, by changing transport value to tcp://target_IP, it worked!
So it is a bug for Fedora?
The trick is to give NRD the regular client.conf, and give apps a modified client.conf.
One procedure to achieve this is:
- modify the global client.conf
- add a new UNIX user, and copy an unmodified client.conf to its $HOME/.ndn directory
- start NFD and NRD in the UNIX user created in step 2
- run other app in the usual user account
Thanks!!!
It works perfectly! I know why it worked in Fedora now, because in Fedora, when I installed ndn-cxx and NFD by default action, nfd-start would not move. When running nfd-start script, it kept output "nfd command not found" and "nrd command not found." I checked (which nfd and which nrd) that nfd, nrd resides in /usr/local/bin, and /usr/local/bin is in my PATH.
But anyway I found this thread:
http://redmine.named-data.net/projects/nfd/wiki/Install-centos
So I reinstalled NFD with "./waf configure --prefix=/usr --sysconfdir=/etc" configuration.
Now I had to put client.conf and nfd.conf in two different folders. Is this why it works in Fedora even if I use the same user to start nfd and a nan-cxx example consumer? Because client.conf and nfd.conf are in different folders?
Thanks for being so patient on answering my questions :)
And if what happens on my Fedora machine seems strange to you, I can update with more detail with the settings and environments.
Also available in: Atom
PDF
Updated by 
Updated by 