[Nfd-dev] generatation of NDN-like packets with Scapy
Salvatore Signorello
salvatore.signorello at uni.lu
Wed Jan 6 04:52:12 PST 2016
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 01/06/2016 12:37 PM, Junxiao Shi wrote:
>
> Hi Salvatore
>
> 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.
>
> ndnpoke still goes through NFD, so you don't need to edit out the code
> that does prefix registration.
>
> 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.
>
> Yours, Junxiao
>
> 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?
>
> On 01/05/2016 01:35 PM, Junxiao Shi wrote:
>>
>> Hi Salvatore
>>
>> I'll offer a different idea to solve your problem: pretend to be
>> NDN forwarder.
>>
>> NDN programs recognizes $HOME/.ndn/client.conf, and connects to
>> the NDN forwarder specified in "transport" option.
>> http://named-data.net/doc/ndn-cxx/current/manpages/ndn-client.conf.html
>>
>
> 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?
>>
>> You can point the transport to the TCP port or Unix socket
>> listener of your next stage, and use existing NDN programs.
>>
> 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.
>>
>> Consumer programs should with just fine.
>> Producer programs need small modifications: bypass prefix
>> registration step.
>>
>> Yours, Junxiao
>>
>> On Jan 5, 2016 05:27, "Salvatore Signorello"
>> <salvatore.signorello at uni.lu
>> <mailto:salvatore.signorello at uni.lu>> wrote:
>>
>> Hi all,
>>
>> 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.
>>
>> 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?
>>
>> 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?
>>
>> Any help would be really appreciated,
>> Salvatore
>>
>> --
>> Salvatore Signorello
>> PhD student @ SecanLab
>>
>> Interdisciplinary Centre for Security, Reliability and Trust
>> SnT, University of Luxembourg
>> http://wwwen.uni.lu/snt/people/salvatore_signorello
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>
> --
> Salvatore Signorello
> PhD student @ SecanLab
>
> Interdisciplinary Centre for Security, Reliability and Trust
> SnT, University of Luxembourg
> http://wwwen.uni.lu/snt/people/salvatore_signorello
>
--
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/20160106/9e1604e2/attachment.html>
More information about the Nfd-dev
mailing list