Bug #2334
closed
[NRD] error while connecting to the forwarder
Added by Anche Kuo almost 10 years ago.
Updated almost 10 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 