Project

General

Profile

Bug #2024

Fetch example works locally, but not across hosts

Added by Felix Rabe over 4 years ago. Updated about 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Start date:
10/03/2014
Due date:
% Done:

0%

Estimated time:

Description

Original description on ndn-lib:

Since last week when JeffT sat down with me in Paris to get ndn-js/tests/node/fetch.js working, I've always only been able to use it locally on the same host as NFD was running, either within VirtualBox or within Docker. Also, on the networks I've been on this week (i.e. outside Paris), plain unmodified fetch.js happily connects (as it looks like to me) to a random host on the testbed.

I do see from the logs of NFD that I actually get a connection from fetch.js (using TCP), but it always times out after that. Running netcat (OpenBSD variant) instead on the same port works as expected (connecting fetch.js dumps some unreadable binary stuff). I'm not too acquainted with tcpdump to make sense of what it tries to tell me.

I've looked at the configuration in /usr/local/etc/ndn/ndn.conf (copied from the sample) and found nothing that should prevent a remote client from connecting, either.


Details for my Vagrant setup as requested by Junxiao (with some additions):

  • Source: https://github.com/named-data-education/ndn-with-vagrant

    Also see http://redmine.named-data.net/issues/2014#note-3

  • Network topology

    OS X host is connected via wifi to a router (interface en0, gateway 192.168.1.1), router is connected to ISP.

    The Vagrant setup (see Vagrantfile) produces a private network (visible as vboxnetN via the host's ifconfig) with the guest at 10.99.99.99 and the host at 10.99.99.1.

    felix-mba:ndn-with-vagrant fr$ netstat -nr
    Routing tables
    
    Internet:
    Destination        Gateway            Flags        Refs      Use   Netif Expire
    default            192.168.1.1        UGSc           29        0     en0
    10.99.99/24        link#16            UC              1        0 vboxnet
    10.99.99.99        8:0:27:1:7e:81     UHLWIi          1       15 vboxnet    717
    ...
    
  • Version of operating system

    Host: OS X 10.9.4

    Guest (Vagrant): Ubuntu 14.04

  • Version of NFD (nfd --version or commit hash)

    0.2.0

  • Version of Boost libraries

    Same as provided by Ubuntu 14.04, i.e. whatever apt-get install nfd installed.

  • Version of ndn-js (commit hash)

    f87eeb941

  • Version of web browser or NodeJS

    node --version reports v0.10.32 on both guest and host.

  • Exact command to reproduce the issue

    On guest (via vagrant ssh):

    nfd status  # => "nfd start/running, process 11861"
    nc -l 6789
    

    OS X host:

    ping -c 3 10.99.99.99  # => connectivity ok
    echo "Hello world" | nc 10.99.99.99 6789  # => shows up in host
    
    git clone https://github.com/named-data/ndn-js.git
    cd ndn-js
    git checkout -b test f87eeb941
    mv ./tests/node/fetch.js{,.bak}
    sed 's/new Face()/new Face({host: "10.99.99.99"})/g' ./tests/node/fetch.js.bak > ./tests/node/fetch.js
    fgrep Face ./tests/node/fetch.js  # verify that change was applied correctly
    node ./tests/node/fetch.js
    
  • Output ("in web browser console or NodeJS console")

    felix-mba:ndn-js fr$ node ./tests/node/fetch.js
    Express name /
    Interest time out.
    Interest name: /
    Quit script now.
    felix-mba:ndn-js fr$ 
    
  • Related lines in NFD log (use DEBUG or TRACE level if possible)

    These are the logs as seen on the guest via tail -F /var/log/ndn/nfd.log

    Default logs:

    1412337273.710671 INFO: [FaceTable] Added face id=264 remote=tcp4://10.99.99.1:62039 local=tcp4://10.99.99.99:6363
    1412337277.715634 INFO: [TcpFace] [id:264,uri:tcp4://10.99.99.1:62039] Connection closed
    1412337277.720362 INFO: [FaceTable] Removed face id=264 remote=tcp4://10.99.99.1:62039 local=tcp4://10.99.99.99:6363
    

    Second attempt with TRACE: http://pastebin.com/RrMxWX5e

History

#1 Updated by Junxiao Shi over 4 years ago

This is related to NFD Bug #1644.

  1. The fetch example is requesting ambiguous Data ndn:/.
  2. ContentStore returns a Data under /localhost.
  3. Forwarding determines it violates ScopeControl and won't send the Data.

#2 Updated by Felix Rabe over 4 years ago

Junxiao, is the following also caused by / related to #1644?

I'm running other examples now, and I observe similar behavior there: test-publish-async-nfd.js, when run locally (on the Ubuntu guest), will start and wait after the following output:

vagrant@vagrant-ubuntu-trusty-64:~/ndn-js/tests/node$ node test-publish-async-nfd.js 
Using { filePath: /var/run/nfd.sock }
Register prefix /testecho

When I modify it on the OS X host and try to run the same code using new Face({host: '10.99.99.99'}), it cannot register the prefix:

felix-mba:ndn-with-vagrant fr$ node ./ndn-js/tests/node/test-publish-async-nfd.js 
Register prefix /testecho
Timeout while requesting the ndndid.  Cannot registerPrefix for /testecho .
Register failed for prefix /testecho
felix-mba:ndn-with-vagrant fr$ fgrep 'new Face' ./ndn-js/tests/node/test-publish-async-nfd.js
  // var face = new Face(new UnixTransport());
  var face = new Face({host: '10.99.99.99'});

#3 Updated by Felix Rabe over 4 years ago

Trace for running test-publish-async-nfd.js remotely on host using TCP: http://pastebin.com/A6MAfqb2

#4 Updated by Junxiao Shi over 4 years ago

note-2 is unrelated to this issue. It's caused by #1848

#5 Updated by Jeff Thompson over 4 years ago

  • Status changed from New to In Progress

Hi Felix. Junxiao was helping with this. Is it still an open issue?

#6 Updated by Felix Rabe over 4 years ago

Yes, I cannot remember any of the examples working across hosts. (Was busy with other things the past few days.)

Registering a prefix between two NFDs seemed fine though.

#7 Updated by Junxiao Shi over 4 years ago

#1644 is rejected. This bug should be rejected as well, because application is requesting ambigious Name.

#8 Updated by Jeff Thompson about 4 years ago

  • Status changed from In Progress to Rejected

Rejected according to note #7.

Also available in: Atom PDF