Bug #2334

[NRD] error while connecting to the forwarder

Added by Anche Kuo almost 7 years ago. Updated almost 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


When the "transport" field in configuration file "client.conf" is changed to value other than
{tcp|udp}:// 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"
; 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


----> 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.



Updated by Anche Kuo almost 7 years ago

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?


Updated by Junxiao Shi almost 7 years ago

  • 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.


Updated by Junxiao Shi almost 7 years ago

  • 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://


Updated by Anche Kuo almost 7 years ago

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?


Updated by Junxiao Shi almost 7 years ago

The trick is to give NRD the regular client.conf, and give apps a modified client.conf.

One procedure to achieve this is:

  1. modify the global client.conf
  2. add a new UNIX user, and copy an unmodified client.conf to its $HOME/.ndn directory
  3. start NFD and NRD in the UNIX user created in step 2
  4. run other app in the usual user account

Updated by Anche Kuo almost 7 years ago


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:

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