<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Junxiao,<br>
<br>
thanks again, but I forgot to tell that changing that piece of
software is not worth doing (long and complex process), I must use
it as it is. This brings us back to my original dilemma of writing
an application that sends ndn packets to specific network interfaces
or simply writing a module for a packet generator? How difficult
would be to do the former?<br>
<br>
<br>
Best,<br>
Salvatore<br>
<br>
<div class="moz-cite-prefix">On 01/06/2016 12:37 PM, Junxiao Shi
wrote:<br>
</div>
<blockquote
cite="mid:CAOFH+OZHyvp0wmfr=pcFfMEWLV6X9UppeJahqNCoXjtfFTOcTg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p dir="ltr">Hi Salvatore</p>
<p dir="ltr">You can have "your software" listen on a separate
Unix socket, and let ndnpeek connect to it directly without
going through NFD. "your software" processes the Interest and
forwards to veth0 without going through NFD.<br>
</p>
</blockquote>
<blockquote
cite="mid:CAOFH+OZHyvp0wmfr=pcFfMEWLV6X9UppeJahqNCoXjtfFTOcTg@mail.gmail.com"
type="cite">
<p dir="ltr">ndnpoke still goes through NFD, so you don't need to
edit out the code that does prefix registration.</p>
<p dir="ltr">This requires two different client.conf used by
ndnpeek and ndnpoke, which can be achieved by setting different
HOME environ when starting those two programs.</p>
<p dir="ltr">Yours, Junxiao</p>
<div class="gmail_quote">On Jan 6, 2016 01:40, "Salvatore
Signorello" <<a moz-do-not-send="true"
href="mailto:salvatore.signorello@uni.lu">salvatore.signorello@uni.lu</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi Junxiao,<br>
<br>
thanks for your prompt feedback, below follows a short
description of my quick&dirty "set-up" and then few more
comments in-line:<br>
<br>
Scenario in mind (caveat: I don't know if it makes sense,
but that's what I need; so if you think of an alternative,
as I guess you already did according to your previous
suggestion, please feel free of throwing away what follows
and propose sth else)<br>
-----------------------<br>
On the same machine where nfd is running, I use the ndnpeedk
to generate an Interest with prefixA. My nfd has a rule that
forwards Interests with prefixA out to a specific veth1. On
that veth1 I have some software running that processes the
Interest and then forwards the same Interest back to the nfd
through a different interface, veth2. In the meantime I've
started a local producer (ndnpoke -w) for that content that
correctly receives the Interest(the 2nd one received on veth
and not the 1st one issued by ndnpeek) and answers back with
the Data. The nfd forwards the data back to veth2, the
software processes it and then forwards it to nfd through
veth1. Nfd forwards the data back to ndnpeek.<br>
<br>
Why am I doing this? I need two applications, one consumer
and one producer, like ndnpeek and ndnpoke that generate ndn
packets. <br>
<br>
The problems that I would like to avoid are the following:<br>
- the pit record for the Interest issued by ndnpeek risks
to drop the Interest received on veth2 [SOLVED] I change
the nonce when I process the Interest for the 2nd time.<br>
- ndnpeek and ndnpoke cannot be started simultaneously,
otherwise ndnpoke will provide the Data to ndnpeek in one
step<br>
- if the 1st Interest creates a PIT record, how to avoid
that nfd will use it when receiving Data from ndnpoke? The
daemon will have a PIT record like the following<br>
"prefixA/content ---- facex(local to ndnpeek),
facey(to veth2)"<br>
and it should choose only facey<br>
<br>
Quick and dirty workaround<br>
-----------------------------------------<br>
By now I simulate the scenario above in the following way:<br>
1. Starting nfd and registering prefixA to veth1 with the
nfdc cmd<br>
2. Issuing an Interest for prefixA/content with ndnpeek<br>
3. The Interest is correctly forwarded to my software
through veth1 where I hold it for a while<br>
4. After ndnpeek timeout, I unregister prefixA from nfd<br>
5. Starting ndnpoke for prefixA/content with a long waiting
time <br>
6. Unpausing my software that forwards the original Interest
to nfd through veth2<br>
7. nfd forwards it to ndnpoke and I get the data back from
veth2<br>
8. holding again the Data<br>
9. register prefixA again like done in 2<br>
10. issuing a new Interest with ndnpeek<br>
11. unpausing the Data to forwarded it back first to nfd and
then to ndnpeek<br>
<br>
Crazy, isn't it?<br>
<br>
<div>On 01/05/2016 01:35 PM, Junxiao Shi wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Hi Salvatore</p>
<p dir="ltr">I'll offer a different idea to solve your
problem: pretend to be NDN forwarder.</p>
<p dir="ltr">NDN programs recognizes
$HOME/.ndn/client.conf, and connects to the NDN
forwarder specified in "transport" option. <a
moz-do-not-send="true"
href="http://named-data.net/doc/ndn-cxx/current/manpages/ndn-client.conf.html"
target="_blank"><a class="moz-txt-link-freetext" href="http://named-data.net/doc/ndn-cxx/current/manpages/ndn-client.conf.html">http://named-data.net/doc/ndn-cxx/current/manpages/ndn-client.conf.html</a></a><br>
</p>
</blockquote>
<br>
Cool, I didn't know about this config option. I guess this
does mean that the local apps use TCP instead of Unix socket
as transport connection towards the local forwarder. Have I
got it right?
<blockquote type="cite">
<p dir="ltr"> You can point the transport to the TCP port
or Unix socket listener of your next stage, and use
existing NDN programs.<br>
</p>
</blockquote>
My other stage is a veth. Does it make any difference with
what you're thinking of? After reading this one, I'm not
sure that I've got the previous sentence well. Could you
please elaborate a little bit according to the scenario I've
described. <br>
<blockquote type="cite">
<p dir="ltr">Consumer programs should with just fine.<br>
Producer programs need small modifications: bypass
prefix registration step.<br>
</p>
</blockquote>
<blockquote type="cite">
<p dir="ltr">Yours, Junxiao</p>
<div class="gmail_quote">On Jan 5, 2016 05:27, "Salvatore
Signorello" <<a moz-do-not-send="true"
href="mailto:salvatore.signorello@uni.lu"
target="_blank">salvatore.signorello@uni.lu</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
all,<br>
<br>
I would like to generate some NDN packets that are not
processed in a first stage by the NFD daemon, so I
guess that I cannot use ready-made things like
ndnpeek/pook/ping/etc.<br>
<br>
Has anyone already implemented an NDN module for a
packet generator like Scapy? If so, or if there exists
other ways to do that, could you please point me to
the right resources?<br>
<br>
Do I really need to write a module for a packet
generator? I mean: does the ndn-repo have anything
else that may fit the purpose?<br>
<br>
Any help would be really appreciated,<br>
Salvatore<br>
<br>
-- <br>
Salvatore Signorello<br>
PhD student @ SecanLab<br>
<br>
Interdisciplinary Centre for Security, Reliability and
Trust<br>
SnT, University of Luxembourg<br>
<a moz-do-not-send="true"
href="http://wwwen.uni.lu/snt/people/salvatore_signorello"
rel="noreferrer" target="_blank">http://wwwen.uni.lu/snt/people/salvatore_signorello</a><br>
<br>
_______________________________________________<br>
Nfd-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Nfd-dev@lists.cs.ucla.edu"
target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
<a moz-do-not-send="true"
href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev"
rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
</blockquote>
</div>
</blockquote>
<br>
<pre cols="72">--
Salvatore Signorello
PhD student @ SecanLab
Interdisciplinary Centre for Security, Reliability and Trust
SnT, University of Luxembourg
<a moz-do-not-send="true" href="http://wwwen.uni.lu/snt/people/salvatore_signorello" target="_blank">http://wwwen.uni.lu/snt/people/salvatore_signorello</a></pre>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Salvatore Signorello
PhD student @ SecanLab
Interdisciplinary Centre for Security, Reliability and Trust
SnT, University of Luxembourg
<a class="moz-txt-link-freetext" href="http://wwwen.uni.lu/snt/people/salvatore_signorello">http://wwwen.uni.lu/snt/people/salvatore_signorello</a></pre>
</body>
</html>