[Nfd-dev] generatation of NDN-like packets with Scapy

Thu Jan 7 02:00:07 PST 2016

Thanks Junxiao, this could be the option that I'm looking for. I've 
given it a try and it seems to work.
There a couple of fixes that I report here for sake of completeness, 
just in case someone else would like to replicate this set-up.

1) According to the diagram you drew, ndnpoke should connect to 
nfd2.sock and ndnpeek to nfd1.sock and not vice versa as you wrote.
2) I changed the syntax of the URI in client.conf according to what I 
read on the nfd log, so I used strings like 
"transport=unix:///run/nfda.sock" into my client.conf files. I guess you 
may get the right syntax looking at the nfd log when it starts up and 
registers all the faces. Otherwise ndnpoke either did not register 
itself to the right daemon or crashed throwing malformed URI exceptions. 
Anyway, we should keep in mind that I'm not using the latest version of 
the daemon and the tools, so the syntax could have slightly changed.

I did a quick trial and the ndn-apps communicated with the right daemons 
and the software behind the veth2 received first Interest and then Data 
packets. Now I'm looking at the daemons' logs to be sure that the 
packets went through the right path.

Best,
Salvatore

On 01/06/2016 05:32 PM, Junxiao Shi wrote:
>
> Hi Salvatore
>
> How about running two NFD instances?
>
> ndnpeek    ndnpoke
>
>    |          |
>
> NFD1       NFD2
>
>    |          |
>
> veth1      veth2
>
>    |          |
>
>    your program
>
> You can have two NFD instances running on the same host by specifying 
> different nfd.conf files on “--config” parameter. Each nfd.conf should 
> have distinct Unix socket path and port numbers. If you need to edit 
> nfd.conf in a script, check out infoedit 
> <https://github.com/NDN-Routing/infoedit>.
>
> Then, have ndnpeek and ndnpoke connect to different NFD instances by 
> specifying different client.conf, like:
>
> mkdir -p /tmp/ndnpoke-home/.ndn
>
> echo transport=unix:/var/run/nfd1.sock > 
> /tmp/ndnpoke-home/.ndn/client.conf
>
> HOME=/tmp/ndnpoke-home ndnpoke /A
>
> mkdir -p /tmp/ndnpeek-home/.ndn
>
> echo transport=unix:/var/run/nfd2.sock > 
> /tmp/ndnpeek-home/.ndn/client.conf
>
> HOME=/tmp/ndnpeek-home ndnpeek /A
>
> Yours, Junxiao
>
>
> *From: *Salvatore Signorello <mailto:salvatore.signorello at uni.lu>
> *Sent: *Wednesday, January 6, 2016 05:52
> *To: *Junxiao Shi <mailto:shijunxiao at email.arizona.edu>
> *Cc: *<nfd-dev at lists.cs.ucla.edu> <mailto:nfd-dev at lists.cs.ucla.edu>
> *Subject: *Re: [Nfd-dev] generatation of NDN-like packets with Scapy
>
> Hi Junxiao,
>
> 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?
>
>
> Best,
> Salvatore
>
>     On Jan 6, 2016 01:40, "Salvatore Signorello"
>     <salvatore.signorello at uni.lu <mailto:salvatore.signorello at uni.lu>>
>     wrote:
>
>         Hi Junxiao,
>
>         thanks for your prompt feedback, below follows a short
>         description of my quick&dirty "set-up" and then few more
>         comments in-line:
>
>         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)
>         -----------------------
>         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.
>
>         Why am I doing this? I need two applications, one consumer and
>         one producer, like ndnpeek and ndnpoke that generate ndn packets.
>
>         The problems that I would like to avoid are the following:
>         - 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.
>         - ndnpeek and ndnpoke cannot be started simultaneously,
>         otherwise ndnpoke will provide the Data to ndnpeek in one step
>         - 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
>                 "prefixA/content ---- facex(local to ndnpeek),
>         facey(to veth2)"
>             and it should choose only facey
>
>         Quick and dirty workaround
>         -----------------------------------------
>         By now I simulate the scenario above in the following way:
>         1. Starting nfd and registering prefixA to veth1 with the nfdc cmd
>         2. Issuing an Interest for prefixA/content with ndnpeek
>         3. The Interest is correctly forwarded to my software through
>         veth1 where I hold it for a while
>         4. After ndnpeek timeout, I unregister prefixA from nfd
>         5. Starting ndnpoke for prefixA/content with a long waiting time
>         6. Unpausing my software that forwards the original Interest
>         to nfd through veth2
>         7. nfd forwards it to ndnpoke and I get the data back from veth2
>         8. holding again the Data
>         9. register prefixA again like done in 2
>         10. issuing a new Interest with ndnpeek
>         11. unpausing the Data to forwarded it back first to nfd and
>         then to ndnpeek
>
>         Crazy, isn't it?
>

-- 
Salvatore Signorello
PhD student @ SecanLab

Interdisciplinary Centre for Security, Reliability and Trust
SnT, University of Luxembourg
http://wwwen.uni.lu/snt/people/salvatore_signorello

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160107/7d07d7c7/attachment.html>