From shijunxiao at email.arizona.edu Fri Jan 1 03:03:15 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 1 Jan 2016 04:03:15 -0700 Subject: [Nfd-dev] NFD-Windows In-Reply-To: References: Message-ID: Dear folks In this 2016's first post, I'd like to introduce NFD-Windows, Windows builds of NDN software. This project started during NDNcomm2015 hackathon, but I hit some roadblock back then due to ongoing face refactoring. Now NFD 0.4.0 has been released with face refactoring completed, and I'm able to successfully build and run NFD on Windows. NFD-Windows currently offers the following programs: ndnsec nfd nfdc nfd-status ndnpeek ndnpoke ndnping ndnpingserver ndn-dissect infoedit. Head over to https://yoursunny.com/p/NFD-Windows/ for download link and more details. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From salvatore.signorello at uni.lu Tue Jan 5 04:26:40 2016 From: salvatore.signorello at uni.lu (Salvatore Signorello) Date: Tue, 5 Jan 2016 13:26:40 +0100 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy Message-ID: <568BB680.8030309@uni.lu> 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 From shijunxiao at email.arizona.edu Tue Jan 5 04:35:01 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 5 Jan 2016 05:35:01 -0700 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: <568BB680.8030309@uni.lu> References: <568BB680.8030309@uni.lu> Message-ID: 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 You can point the transport to the TCP port or Unix socket listener of your next stage, and use existing NDN programs. 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" 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 > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Jan 5 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 5 Jan 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20160105 Message-ID: <201601051500.u05F02Cc031402@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From salvatore.signorello at uni.lu Tue Jan 5 08:25:09 2016 From: salvatore.signorello at uni.lu (Salvatore Signorello) Date: Tue, 5 Jan 2016 17:25:09 +0100 Subject: [Nfd-dev] additional data between ethernet header and ndn header In-Reply-To: References: <566F4494.8070607@uni.lu> <6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu> <566F4829.70207@uni.lu> Message-ID: <568BEE65.8070201@uni.lu> Hi Junxiao, sorry to come back to you on this thing again, I know that I should simply update my software which is outdated. Now I see a Data packet generated by ndnpoke (some software versions and OS listed in the previous mail) that contains the following: 50:fd:01:83:51:08:00:00:00:00:00:00:00:00:54:fd:01:75:06:fd:01:71:07:22 which, according to your previous hypothesis, could be decoded like: 50 fd // NdnlpData 01 83 // ???? 51 08 // NdnlpSequence 00 00 00 00 00 00 00 00 54 fd // NdnlpPayload 01 75 // again ???? 06 fd // Data 01 71 // ibid 07 22 // name In addition, as you can see the 'fd' length value is never decremented...this sound a bit weird. Any idea? Best, Salvatore On 12/15/2015 04:37 PM, Junxiao Shi wrote: > Hi Salvatore > > The payload of the first packet in the pcap > is 50:37:51:08:00:00:00:00:00:00:00:11:54:2b:05:29:07:21:08:10:70:34:73:6f:66:74:77:61:72:65:73:77:69:74:63:68:08:0d:73:61:79:68:65:6c:6c:6f:77:6f:72:6c:64:0a:04:10:f2:e0:8f. > This appears to be NDNLPv1-TLV > protocol, > and can be interpreted as: > > 50 37 // NdnlpData > 51 08 // NdnlpSequence > 00 00 00 00 00 00 00 11 > 54 2b // NdnlpPayload > 05 29 // Interest > 07 21 // Name > 08 10 // NameComponent > 70 34 73 6f 66 74 77 61 72 65 73 77 69 74 63 68 > 08 0d // NameComponent > 73 61 79 68 65 6c 6c 6f 77 6f 72 6c 64 > 0a 04 // Nonce > 10 f2 e0 8f > > Neither ndndump nor NDN dissector for Wireshark supports NDNLPv1-TLV. > In latest NFD, NDNLPv1-TLV is deprecated and replaced by NDNLPv2 > , which will > be supported by NDN dissector for Wireshark in #3197 > . > > Yours, Junxiao > > On Mon, Dec 14, 2015 at 3:52 PM, Salvatore Signorello > > wrote: > > Hi Alex, > > the pcap is in attach. I'm not using the latest version of the > software tools and daemon, so if you either don't see the issue or > are not able to reproduce it. I'll likely update the ndn software > suite before asking you for more support. > > Thanks, > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jan 5 08:30:13 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 5 Jan 2016 09:30:13 -0700 Subject: [Nfd-dev] additional data between ethernet header and ndn header In-Reply-To: <568BEE65.8070201@uni.lu> References: <566F4494.8070607@uni.lu> <6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu> <566F4829.70207@uni.lu> <568BEE65.8070201@uni.lu> Message-ID: <568bef92.0406430a.a1c6a.ffff85ac@mx.google.com> Hi Salvatore Your decoding is wrong. FD indicates the TLV-LENGTH field has 3 octets. See http://named-data.net/doc/ndn-tlv/tlv.html#variable-size-encoding-for-type-t-and-length-l Yours, Junxiao From: Salvatore Signorello Sent: Tuesday, January 5, 2016 09:25 To: Junxiao Shi Cc: Alex Afanasyev; Subject: Re: [Nfd-dev] additional data between ethernet header and ndn header Hi Junxiao, sorry to come back to you on this thing again, I know that I should simply update my software which is outdated. Now I see a Data packet generated by ndnpoke (some software versions and OS listed in the previous mail) that contains the following: 50:fd:01:83:51:08:00:00:00:00:00:00:00:00:54:fd:01:75:06:fd:01:71:07:22 which, according to your previous hypothesis, could be decoded like: 50 fd ??? // NdnlpData ??? 01 83 ??? // ???? ??? 51 08 ??? // NdnlpSequence ??? ? 00 00 00 00 00 00 00 00 ??? 54 fd ??? // NdnlpPayload ??? 01 75 ??? // again ???? ??? ??? 06 fd??? // Data ??? ??? ??? 01 71 // ibid ??? ??? ??? 07 22 // name In addition, as you can see the 'fd' length value is never decremented...this sound a bit weird. Any idea? Best, Salvatore -------------- next part -------------- An HTML attachment was scrubbed... URL: From salvatore.signorello at uni.lu Tue Jan 5 08:38:12 2016 From: salvatore.signorello at uni.lu (Salvatore Signorello) Date: Tue, 5 Jan 2016 17:38:12 +0100 Subject: [Nfd-dev] additional data between ethernet header and ndn header In-Reply-To: <568bef92.0406430a.a1c6a.ffff85ac@mx.google.com> References: <566F4494.8070607@uni.lu> <6ADF6759-EA2A-4F10-98B0-CC8D8A1CC882@cs.ucla.edu> <566F4829.70207@uni.lu> <568BEE65.8070201@uni.lu> <568bef92.0406430a.a1c6a.ffff85ac@mx.google.com> Message-ID: <568BF174.6070407@uni.lu> Thank you for spotting this, Junxiao, it was obvious. Sorry 50 fd 01 83 // NdnlpData 51 08 // NdnlpSequence 00 00 00 00 00 00 00 00 54 fd 01 75 // NdnlpPayload 06 fd 01 71 // Data 07 22 // name Best, Salvatore On 01/05/2016 05:30 PM, Junxiao Shi wrote: > > Hi Salvatore > > Your decoding is wrong. FD indicates the TLV-LENGTH field has 3 > octets. See > http://named-data.net/doc/ndn-tlv/tlv.html#variable-size-encoding-for-type-t-and-length-l > > Yours, Junxiao > > > *From: *Salvatore Signorello > *Sent: *Tuesday, January 5, 2016 09:25 > *To: *Junxiao Shi > *Cc: *Alex Afanasyev ; > > *Subject: *Re: [Nfd-dev] additional data between ethernet header and > ndn header > > Hi Junxiao, > > sorry to come back to you on this thing again, I know that I should > simply update my software which is outdated. > > Now I see a Data packet generated by ndnpoke (some software versions > and OS listed in the previous mail) that contains the following: > > 50:fd:01:83:51:08:00:00:00:00:00:00:00:00:54:fd:01:75:06:fd:01:71:07:22 > > which, according to your previous hypothesis, could be decoded like: > > 50 fd // NdnlpData > 01 83 // ???? > 51 08 // NdnlpSequence > 00 00 00 00 00 00 00 00 > 54 fd // NdnlpPayload > 01 75 // again ???? > 06 fd // Data > 01 71 // ibid > 07 22 // name > > In addition, as you can see the 'fd' length value is never > decremented...this sound a bit weird. Any idea? > > Best, > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From salvatore.signorello at uni.lu Wed Jan 6 00:40:22 2016 From: salvatore.signorello at uni.lu (Salvatore Signorello) Date: Wed, 6 Jan 2016 09:40:22 +0100 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: References: <568BB680.8030309@uni.lu> Message-ID: <568CD2F6.6040402@uni.lu> 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" > > 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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Jan 6 03:37:31 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 6 Jan 2016 04:37:31 -0700 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: <568CD2F6.6040402@uni.lu> References: <568BB680.8030309@uni.lu> <568CD2F6.6040402@uni.lu> Message-ID: 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" 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" > 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 >> 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 Luxembourghttp://wwwen.uni.lu/snt/people/salvatore_signorello > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From salvatore.signorello at uni.lu Wed Jan 6 04:52:12 2016 From: salvatore.signorello at uni.lu (Salvatore Signorello) Date: Wed, 6 Jan 2016 13:52:12 +0100 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: References: <568BB680.8030309@uni.lu> <568CD2F6.6040402@uni.lu> Message-ID: <568D0DFC.7060600@uni.lu> 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" > > 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" >> > > 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 >> 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: From harsh0233 at gmail.com Wed Jan 6 03:51:32 2016 From: harsh0233 at gmail.com (harshit singh) Date: Wed, 6 Jan 2016 17:21:32 +0530 Subject: [Nfd-dev] nfd-android Message-ID: can someone show the working of nfd-android ( communication between two android phones) regards Harshit Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Jan 6 08:32:03 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 6 Jan 2016 09:32:03 -0700 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: <568D0DFC.7060600@uni.lu> References: <568BB680.8030309@uni.lu> <568CD2F6.6040402@uni.lu> <568D0DFC.7060600@uni.lu> Message-ID: <568d4183.c72a620a.95ae0.16db@mx.google.com> 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. 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 Sent: Wednesday, January 6, 2016 05:52 To: Junxiao Shi Cc: 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" 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Wed Jan 6 08:34:23 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 6 Jan 2016 09:34:23 -0700 Subject: [Nfd-dev] nfd-android In-Reply-To: References: Message-ID: <568d420f.c640620a.a997.ffffdb1d@mx.google.com> Dear folks I?m also interested. I hope we can have an NDN seminar on this topic. Is there an APK download link? Yours, Junxiao From: harshit singh Sent: Wednesday, January 6, 2016 08:31 To: nfd-dev at lists.cs.ucla.edu Subject: [Nfd-dev] nfd-android can someone show the working of nfd-android ( communication between two android phones) regards Harshit Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdpa at st-andrews.ac.uk Wed Jan 6 11:14:44 2016 From: pdpa at st-andrews.ac.uk (Percy Perez Aruni) Date: Wed, 6 Jan 2016 19:14:44 +0000 Subject: [Nfd-dev] nfd-android In-Reply-To: <568d420f.c640620a.a997.ffffdb1d@mx.google.com> References: <568d420f.c640620a.a997.ffffdb1d@mx.google.com> Message-ID: Hi Hi guys You probably know this, but just in case. Last time, Alex pointed me to the below NFD forwarder link. https://github.com/named-data-mobile/NFD-android But also he pointed me to some examples from UCLA students that are listed below. Those are useful to develop simple Android apps. https://github.com/sumitgouthaman/NDNWhiteboard https://github.com/dchimeraan/ndn-hangman https://github.com/ohnonoho/photoSharing And yes, it would be nice to have a seminar on this. Enjoy.! Cheers Percy On 6 January 2016 at 16:34, Junxiao Shi wrote: > Dear folks > > > > I?m also interested. I hope we can have an NDN seminar on this topic. > > Is there an APK download link? > > > > Yours, Junxiao > > > > > > > > > *From: *harshit singh > *Sent: *Wednesday, January 6, 2016 08:31 > *To: *nfd-dev at lists.cs.ucla.edu > *Subject: *[Nfd-dev] nfd-android > > > > can someone show the working of nfd-android ( communication between two > android phones) > > > > regards > > Harshit Singh > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Wed Jan 6 17:51:09 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Wed, 6 Jan 2016 17:51:09 -0800 Subject: [Nfd-dev] nfd-android In-Reply-To: References: <568d420f.c640620a.a997.ffffdb1d@mx.google.com> Message-ID: <35672C7F-4EF1-4E74-AE81-C986FF4D8119@cs.ucla.edu> Thanks Percy. I have just finished publishing the pre-built APK files to Google Play. To start using it, please use this link https://play.google.com/apps/testing/net.named_data.nfd to opt-in for alpha testing and proceed to download the app. -- Alex PS Since I just upload the APKs, it will take a few hours for it to be published. If you see message that "the app is not compatible with your device", try in a few hours. NFD should work with most of the android devices. > On Jan 6, 2016, at 11:14 AM, Percy Perez Aruni wrote: > > Hi Hi guys > > You probably know this, but just in case. Last time, Alex pointed me to the below NFD forwarder link. > > https://github.com/named-data-mobile/NFD-android > > But also he pointed me to some examples from UCLA students that are listed below. Those are useful to develop simple Android apps. > > https://github.com/sumitgouthaman/NDNWhiteboard > https://github.com/dchimeraan/ndn-hangman > https://github.com/ohnonoho/photoSharing > > And yes, it would be nice to have a seminar on this. > Enjoy.! > > Cheers > Percy > > > > On 6 January 2016 at 16:34, Junxiao Shi > wrote: > Dear folks > > > > I?m also interested. I hope we can have an NDN seminar on this topic. > > Is there an APK download link? > > > > Yours, Junxiao > > > > > > > > > From: harshit singh > Sent: Wednesday, January 6, 2016 08:31 > To: nfd-dev at lists.cs.ucla.edu > Subject: [Nfd-dev] nfd-android > > > > can someone show the working of nfd-android ( communication between two android phones) > > > > regards > > Harshit Singh > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From salvatore.signorello at uni.lu Thu Jan 7 02:00:07 2016 From: salvatore.signorello at uni.lu (Salvatore Signorello) Date: Thu, 7 Jan 2016 11:00:07 +0100 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: <568d4183.c72a620a.95ae0.16db@mx.google.com> References: <568BB680.8030309@uni.lu> <568CD2F6.6040402@uni.lu> <568D0DFC.7060600@uni.lu> <568d4183.c72a620a.95ae0.16db@mx.google.com> Message-ID: <568E3727.8060805@uni.lu> 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 > . > > 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 > *Sent: *Wednesday, January 6, 2016 05:52 > *To: *Junxiao Shi > *Cc: * > *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" > > > 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: From salvatore.signorello at uni.lu Thu Jan 7 04:18:49 2016 From: salvatore.signorello at uni.lu (Salvatore Signorello) Date: Thu, 7 Jan 2016 13:18:49 +0100 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: <568E3727.8060805@uni.lu> References: <568BB680.8030309@uni.lu> <568CD2F6.6040402@uni.lu> <568D0DFC.7060600@uni.lu> <568d4183.c72a620a.95ae0.16db@mx.google.com> <568E3727.8060805@uni.lu> Message-ID: <568E57A9.8040905@uni.lu> ndnpoke is still serving the Interest issued by ndnpeek. I think that the reason is that both daemons register all the existing network interfaces at boot, so a face for veth1 is created and linked for each daemon. When nfd1 forwards to the program thanks to the rule set by nfdc the Interest goes through veth1, so both nfd2 and my program get the Interest packet. Even if I unregister that face from nfd2 using nfdc (btw, how to manipulate nfd2's FIB using nfdc? the client.conf trick seems to not work with this utility and nfdc always modifies nfd1's FIB), the daemon after a while rescans a list of interfaces it holds and registers it back again. What could I do to stop such behavior? Is there any configuration related to such thing? Best, Salvatore On 01/07/2016 11:00 AM, Salvatore Signorello wrote: > 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 >> . >> >> 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 >> *Sent: *Wednesday, January 6, 2016 05:52 >> *To: *Junxiao Shi >> *Cc: * >> *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" >> > > 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 > > > _______________________________________________ > Nfd-dev mailing list > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Jan 7 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 7 Jan 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20160107 Message-ID: <201601071500.u07F02Ib021089@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Fri Jan 8 04:20:03 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Fri, 8 Jan 2016 05:20:03 -0700 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: <568E57A9.8040905@uni.lu> References: <568BB680.8030309@uni.lu> <568CD2F6.6040402@uni.lu> <568D0DFC.7060600@uni.lu> <568d4183.c72a620a.95ae0.16db@mx.google.com> <568E3727.8060805@uni.lu> <568E57A9.8040905@uni.lu> Message-ID: <568fa973.970f620a.468c8.ffffa11c@mx.google.com> Hi Salvatore The configuration option you are looking for is ?multicast face blacklist?. This is currently unimplemented; watch #1712 for progress. Yours, Junxiao From: Salvatore Signorello Sent: Thursday, January 7, 2016 05:18 To: Junxiao Shi Cc: Subject: Re: [Nfd-dev] generatation of NDN-like packets with Scapy ndnpoke is still serving the Interest issued by ndnpeek. I think that the reason is that both daemons register all the existing network interfaces at boot, so a face for veth1 is created and linked for each daemon. When nfd1 forwards to the program thanks to the rule set by nfdc the Interest goes through veth1, so both nfd2 and my program get the Interest packet. Even if I unregister that face from nfd2 using nfdc (btw, how to manipulate nfd2's FIB using nfdc? the client.conf trick seems to not work with this utility and nfdc always modifies nfd1's FIB), the daemon after a while rescans a list of interfaces it holds and registers it back again. What could I do to stop such behavior? Is there any configuration related to such thing? Best, Salvatore -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsh0233 at gmail.com Mon Jan 11 01:56:18 2016 From: harsh0233 at gmail.com (harshit singh) Date: Mon, 11 Jan 2016 15:26:18 +0530 Subject: [Nfd-dev] nfd-android Message-ID: Hello How to develop own testbed for nfd-android. regards Harshit Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: From salvatore.signorello at uni.lu Mon Jan 11 08:22:48 2016 From: salvatore.signorello at uni.lu (Salvatore Signorello) Date: Mon, 11 Jan 2016 17:22:48 +0100 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: <568fa973.970f620a.468c8.ffffa11c@mx.google.com> References: <568BB680.8030309@uni.lu> <568CD2F6.6040402@uni.lu> <568D0DFC.7060600@uni.lu> <568d4183.c72a620a.95ae0.16db@mx.google.com> <568E3727.8060805@uni.lu> <568E57A9.8040905@uni.lu> <568fa973.970f620a.468c8.ffffa11c@mx.google.com> Message-ID: <5693D6D8.7010705@uni.lu> Hi Junxiao, pretty interesting configuration option, this will add yet more value to the next daemon release. In the meantime, could you please point me to the place(source code files) where the automatic registration of the NICs is managed? If you knew it, this would save me some time and I would really appreciate your direction. Thanks once more, best, Salvatore On 01/08/2016 01:20 PM, Junxiao Shi wrote: > > Hi Salvatore > > The configuration option you are looking for is ?multicast face > blacklist?. > > This is currently unimplemented; watch #1712 > for progress. > > Yours, Junxiao > > > *From: *Salvatore Signorello > *Sent: *Thursday, January 7, 2016 05:18 > *To: *Junxiao Shi > *Cc: * > *Subject: *Re: [Nfd-dev] generatation of NDN-like packets with Scapy > > ndnpoke is still serving the Interest issued by ndnpeek. I think that > the reason is that both daemons register all the existing network > interfaces at boot, so a face for veth1 is created and linked for each > daemon. When nfd1 forwards to the program thanks to the rule set by > nfdc the Interest goes through veth1, so both nfd2 and my program get > the Interest packet. > > Even if I unregister that face from nfd2 using nfdc (btw, how to > manipulate nfd2's FIB using nfdc? the client.conf trick seems to not > work with this utility and nfdc always modifies nfd1's FIB), the > daemon after a while rescans a list of interfaces it holds and > registers it back again. What could I do to stop such behavior? Is > there any configuration related to such thing? > > Best, > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Mon Jan 11 09:24:26 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Mon, 11 Jan 2016 09:24:26 -0800 Subject: [Nfd-dev] generatation of NDN-like packets with Scapy In-Reply-To: <5693D6D8.7010705@uni.lu> References: <568BB680.8030309@uni.lu> <568CD2F6.6040402@uni.lu> <568D0DFC.7060600@uni.lu> <568d4183.c72a620a.95ae0.16db@mx.google.com> <568E3727.8060805@uni.lu> <568E57A9.8040905@uni.lu> <568fa973.970f620a.468c8.ffffa11c@mx.google.com> <5693D6D8.7010705@uni.lu> Message-ID: <66BA37F2-168E-48C4-870D-856891EBF043@cs.ucla.edu> Hi Salvatore, Check daemon/mgmt/face-manager.cpp around line 735. There is dependency on nicList populated on line 420. For how it is populated, you can check core/network-interface.cpp -- Alex > On Jan 11, 2016, at 8:22 AM, Salvatore Signorello wrote: > > Hi Junxiao, > > pretty interesting configuration option, this will add yet more value to the next daemon release. > In the meantime, could you please point me to the place(source code files) where the automatic registration of the NICs is managed? If you knew it, this would save me some time and I would really appreciate your direction. > > Thanks once more, > best, > Salvatore > > > > On 01/08/2016 01:20 PM, Junxiao Shi wrote: >> Hi Salvatore >> >> The configuration option you are looking for is ?multicast face blacklist?. >> This is currently unimplemented; watch #1712 for progress. >> >> Yours, Junxiao >> >> From: Salvatore Signorello >> Sent: Thursday, January 7, 2016 05:18 >> To: Junxiao Shi >> Cc: >> Subject: Re: [Nfd-dev] generatation of NDN-like packets with Scapy >> >> ndnpoke is still serving the Interest issued by ndnpeek. I think that the reason is that both daemons register all the existing network interfaces at boot, so a face for veth1 is created and linked for each daemon. When nfd1 forwards to the program thanks to the rule set by nfdc the Interest goes through veth1, so both nfd2 and my program get the Interest packet. >> >> Even if I unregister that face from nfd2 using nfdc (btw, how to manipulate nfd2's FIB using nfdc? the client.conf trick seems to not work with this utility and nfdc always modifies nfd1's FIB), the daemon after a while rescans a list of interfaces it holds and registers it back again. What could I do to stop such behavior? Is there any configuration related to such thing? >> >> Best, >> 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 > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nfd-call-notification at mail1.yoursunny.com Tue Jan 12 07:30:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 12 Jan 2016 08:30:02 -0700 Subject: [Nfd-dev] NFD call 20160112 Message-ID: <201601121530.u0CFU2V6032716@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.edu Tue Jan 12 19:54:16 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Tue, 12 Jan 2016 20:54:16 -0700 Subject: [Nfd-dev] Fwd: NFD unexpected behavior on OS X 10.11.2 In-Reply-To: <36E62342-3624-4669-A7EA-845D344CF7F3@gmail.com> References: <36E62342-3624-4669-A7EA-845D344CF7F3@gmail.com> Message-ID: ---------- Forwarded message ---------- From: "Spyridon ?Spyros? Mastorakis" Date: Jan 12, 2016 20:50 Subject: NFD unexpected behavior on OS X 10.11.2 To: "Junxiao Shi" Cc: Hi Junxiao, I hope that you are doing well. I cloned the latest version of ndn-cxx and NFD. I configured and installed both in the regular way as we always do (./waf configure, ./waf, sudo ./waf install). However, when I am trying to start NFD, I get the following message: Dudes-MacBook-Pro:NFD Spyros$ nfd-start ERROR: TPM locator supplied does not match TPM locator in PIB: tpm-file: != tpm-osxkeychain: Dudes-MacBook-Pro:NFD Spyros$ libc++abi.dylib: terminating with uncaught exception of type boost::exception_detail::clone_impl >: TPM locator supplied does not match TPM locator in PIB: tpm-file: != tpm-osxkeychain: and at this point NFD crashes. Am I doing anything wrong somewhere? Thank you, Spyros -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.ricci at uniroma2.it Wed Jan 13 02:30:17 2016 From: bruno.ricci at uniroma2.it (Bruno Ricci) Date: Wed, 13 Jan 2016 11:30:17 +0100 Subject: [Nfd-dev] Maximum FIB size Message-ID: <56962739.5020303@uniroma2.it> Hi, we're trying to do some experiments about FIB scaling, using NFD out of git (commit da3ba964301a43f15e6b87c3d585713068252ae6). We ran some tests adding random FIB entries, but after adding about 1000 entries (not a constant threshold, the number varies but is always above 1000) NFD crashes. The question then is: is there a maximum number of entries in the FIB? Best regards Bruno -- ---------------------------------------------------------------------- Bruno Ricci, Ph.D. Post-doc Researcher CNIT - Consorzio Nazionale Interuniversitario per le Telecomunicazioni Department of Electronic Engineering, University of Rome "Tor Vergata" Website: http://netgroup.uniroma2.it/bruno-ricci/ Tel.: +39 06 7259 7445 From shijunxiao at email.arizona.edu Wed Jan 13 04:14:59 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 13 Jan 2016 05:14:59 -0700 Subject: [Nfd-dev] Redmine/ndn-tlv/issues Message-ID: Dear folks I notice the issue tracker for NDN specs Redmine site is inaccessible: http://redmine.named-data.net/projects/ndn-tlv/issues It works fine last year. Yours, Junxiao -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Wed Jan 13 06:18:22 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Wed, 13 Jan 2016 15:18:22 +0100 Subject: [Nfd-dev] Redmine/ndn-tlv/issues In-Reply-To: References: Message-ID: > On Jan 13, 2016, at 1:14 PM, Junxiao Shi wrote: > > Dear folks > > I notice the issue tracker for NDN specs Redmine site is inaccessible: > http://redmine.named-data.net/projects/ndn-tlv/issues > It works fine last year. > Fixed. I think I have accidentally changed settings for the project, disabling the issue tracking. -- Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From susmit at cs.colostate.edu Wed Jan 13 10:32:07 2016 From: susmit at cs.colostate.edu (Susmit) Date: Wed, 13 Jan 2016 11:32:07 -0700 Subject: [Nfd-dev] Maximum FIB size In-Reply-To: <56962739.5020303@uniroma2.it> References: <56962739.5020303@uniroma2.it> Message-ID: Hi, I tried this on a test machine and could not reproduce it. I could add more than 3000 routes without NFD crashing. Some additional information would be helpful, e.g., how you are adding routes, how long they are, if you are getting any error messages etc. Thanks. On Wed, Jan 13, 2016 at 3:30 AM, Bruno Ricci wrote: > Hi, > > we're trying to do some experiments about FIB scaling, using NFD out of git > (commit da3ba964301a43f15e6b87c3d585713068252ae6). > > We ran some tests adding random FIB entries, but after adding about 1000 > entries (not a constant threshold, the number varies but is always above > 1000) NFD crashes. > > The question then is: is there a maximum number of entries in the FIB? > > Best regards > > Bruno > -- > ---------------------------------------------------------------------- > Bruno Ricci, Ph.D. > Post-doc Researcher > CNIT - Consorzio Nazionale Interuniversitario per le Telecomunicazioni > Department of Electronic Engineering, University of Rome "Tor Vergata" > Website: http://netgroup.uniroma2.it/bruno-ricci/ > Tel.: +39 06 7259 7445 > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -- Regards, Susmit ==================================== http://www.cs.colostate.edu/~susmit ==================================== From shijunxiao at email.arizona.edu Wed Jan 13 10:39:17 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 13 Jan 2016 11:39:17 -0700 Subject: [Nfd-dev] Maximum FIB size In-Reply-To: <56962739.5020303@uniroma2.it> References: <56962739.5020303@uniroma2.it> Message-ID: Hi Bruno Are you using the same app to register all the routes, or are you using 1000 distinct apps? If the latter, this crash could be caused by large number of faces, not FIB. Can you provide a GDB trace for the crash? You'll need a debug build of ndn-cxx and NFD, run NFD within GDB, and type `bt full` (not just `bt`) when crash happens. Yours, Junxiao On Jan 13, 2016 03:30, "Bruno Ricci" wrote: > Hi, > > we're trying to do some experiments about FIB scaling, using NFD out of > git (commit da3ba964301a43f15e6b87c3d585713068252ae6). > > We ran some tests adding random FIB entries, but after adding about 1000 > entries (not a constant threshold, the number varies but is always above > 1000) NFD crashes. > > The question then is: is there a maximum number of entries in the FIB? > > Best regards > > Bruno > -- > ---------------------------------------------------------------------- > Bruno Ricci, Ph.D. > Post-doc Researcher > CNIT - Consorzio Nazionale Interuniversitario per le Telecomunicazioni > Department of Electronic Engineering, University of Rome "Tor Vergata" > Website: http://netgroup.uniroma2.it/bruno-ricci/ > Tel.: +39 06 7259 7445 > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hyuan at wustl.edu Wed Jan 13 10:58:15 2016 From: hyuan at wustl.edu (Haowei Yuan) Date: Wed, 13 Jan 2016 10:58:15 -0800 Subject: [Nfd-dev] Maximum FIB size In-Reply-To: <0f3869ef2fc54290af11a7cf36abe5c9@CY1PR02MB1706.namprd02.prod.outlook.com> References: <56962739.5020303@uniroma2.it> <0f3869ef2fc54290af11a7cf36abe5c9@CY1PR02MB1706.namprd02.prod.outlook.com> Message-ID: Just to add some information about the FIB. We don't have a limit on the FIB size. The underlying hash table data structure will double its size if the load factor is higher than 50%. As Susmit and Junxiao mentioned, some more information to reproduce the problem would be helpful. Haowei On Wed, Jan 13, 2016 at 10:39 AM, Junxiao Shi wrote: > Hi Bruno > > Are you using the same app to register all the routes, or are you using 1000 > distinct apps? > If the latter, this crash could be caused by large number of faces, not FIB. > > Can you provide a GDB trace for the crash? > You'll need a debug build of ndn-cxx and NFD, run NFD within GDB, and type > `bt full` (not just `bt`) when crash happens. > > Yours, Junxiao > > On Jan 13, 2016 03:30, "Bruno Ricci" wrote: >> >> Hi, >> >> we're trying to do some experiments about FIB scaling, using NFD out of >> git (commit da3ba964301a43f15e6b87c3d585713068252ae6). >> >> We ran some tests adding random FIB entries, but after adding about 1000 >> entries (not a constant threshold, the number varies but is always above >> 1000) NFD crashes. >> >> The question then is: is there a maximum number of entries in the FIB? >> >> Best regards >> >> Bruno >> -- >> ---------------------------------------------------------------------- >> Bruno Ricci, Ph.D. >> Post-doc Researcher >> CNIT - Consorzio Nazionale Interuniversitario per le Telecomunicazioni >> Department of Electronic Engineering, University of Rome "Tor Vergata" >> Website: http://netgroup.uniroma2.it/bruno-ricci/ >> Tel.: +39 06 7259 7445 >> _______________________________________________ >> Nfd-dev mailing list >> Nfd-dev at lists.cs.ucla.edu >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From bruno.ricci at uniroma2.it Wed Jan 13 14:29:17 2016 From: bruno.ricci at uniroma2.it (Bruno Ricci) Date: Wed, 13 Jan 2016 23:29:17 +0100 Subject: [Nfd-dev] Maximum FIB size In-Reply-To: References: <56962739.5020303@uniroma2.it> <0f3869ef2fc54290af11a7cf36abe5c9@CY1PR02MB1706.namprd02.prod.outlook.com> Message-ID: <5696CFBD.3030508@uniroma2.it> Hi guys, first of all, thank you for your answers. All we did was run a bash script that calls nfdc register. All routes are random string of 16 chars, and are set towards a random IP address using UDP. As simple as (pseudocode) for i in 1..100000 do ip=random(3.3.3.3) name=random(16) nfdc register ndn:/$name udp://$ip sleep 1 done This runs fine without errors (at least with the default debug level), until NFD silently crashes. As Junxiao pointed out, maybe the problem relies on the number of faces, and not on the FIB size (I honestly haven't thought about that, thanks for pointing that out). I will try tomorrow morning at work to re run the script reducing the faces number, and to run NFD inside gdb. I will keep you posted, thanks again. Bruno On 13/01/2016 19:58, Haowei Yuan wrote: > Just to add some information about the FIB. We don't have a limit on > the FIB size. The underlying hash table data structure will double its > size if the load factor is higher than 50%. > > As Susmit and Junxiao mentioned, some more information to reproduce > the problem would be helpful. > > Haowei > > > On Wed, Jan 13, 2016 at 10:39 AM, Junxiao Shi > wrote: >> Hi Bruno >> >> Are you using the same app to register all the routes, or are you using 1000 >> distinct apps? >> If the latter, this crash could be caused by large number of faces, not FIB. >> >> Can you provide a GDB trace for the crash? >> You'll need a debug build of ndn-cxx and NFD, run NFD within GDB, and type >> `bt full` (not just `bt`) when crash happens. >> >> Yours, Junxiao >> >> On Jan 13, 2016 03:30, "Bruno Ricci" wrote: >>> >>> Hi, >>> >>> we're trying to do some experiments about FIB scaling, using NFD out of >>> git (commit da3ba964301a43f15e6b87c3d585713068252ae6). >>> >>> We ran some tests adding random FIB entries, but after adding about 1000 >>> entries (not a constant threshold, the number varies but is always above >>> 1000) NFD crashes. >>> >>> The question then is: is there a maximum number of entries in the FIB? >>> >>> Best regards >>> >>> Bruno >>> -- >>> ---------------------------------------------------------------------- >>> Bruno Ricci, Ph.D. >>> Post-doc Researcher >>> CNIT - Consorzio Nazionale Interuniversitario per le Telecomunicazioni >>> Department of Electronic Engineering, University of Rome "Tor Vergata" >>> Website: http://netgroup.uniroma2.it/bruno-ricci/ >>> Tel.: +39 06 7259 7445 >>> _______________________________________________ >>> Nfd-dev mailing list >>> Nfd-dev at lists.cs.ucla.edu >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev -- ---------------------------------------------------------------------- Bruno Ricci, Ph.D. Post-doc Researcher CNIT - Consorzio Nazionale Interuniversitario per le Telecomunicazioni Department of Electronic Engineering, University of Rome "Tor Vergata" Website: http://netgroup.uniroma2.it/bruno-ricci/ Tel.: +39 06 7259 7445 From shijunxiao at email.arizona.edu Wed Jan 13 15:37:22 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 13 Jan 2016 16:37:22 -0700 Subject: [Nfd-dev] Fwd: Client Control Strategy using Best Route Strategy v1 In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Vince Lehman (vslehman) Date: Wed, Jan 13, 2016 at 4:27 PM Subject: Client Control Strategy using Best Route Strategy v1 To: Junxiao Shi Hi Junxiao, I noticed that the Client Control Strategy is using Best Route Strategy version 1 instead of version 2. Is there any reason for this? I am experiencing an issue with the Client Control Strategy when a local app sends an Interest with a NextHopFaceId tag set to the Content Store?s FaceID (254). No match is found in the Content Store, and the Interest is left pending. When a remote Interest arrives for the same name while the previous Interest is pending, the Interest is dropped by the Best Route Strategy. When I have ClientControlStrategy inherit from BestRouteStrategy2, this issue seems to be resolved. I?ve attached some slides which illustrate the issue I am experiencing. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ClientControlStrategyWithBestRouteV1.pdf Type: application/pdf Size: 188496 bytes Desc: not available URL: From shijunxiao at email.arizona.edu Wed Jan 13 15:37:52 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Wed, 13 Jan 2016 16:37:52 -0700 Subject: [Nfd-dev] Client Control Strategy using Best Route Strategy v1 In-Reply-To: References: Message-ID: Hi Vince client-control strategy is designed to be used on the consumer side only, because NextHopFaceId can be specified only from local apps. When an Interest from a non-local face is processed by client-control strategy, the behavior is undefined. It's an implementation choice to inherit from best-route v1, the simplest possible strategy. If inheriting from best-route v4 works better in your experiment, you may do so. I don't intend to make any changes on client-control strategy. Eventually it will be deprecated as part of #2000, and NextHopFaceId should always be honored regardless of strategy (see NDNLPv2 spec "implementation note"). Yours, Junxiao On Wed, Jan 13, 2016 at 4:27 PM, Vince Lehman (vslehman) < vslehman at memphis.edu> wrote: > Hi Junxiao, > > I noticed that the Client Control Strategy is using Best Route Strategy > version 1 instead of version 2. Is there any reason for this? > > I am experiencing an issue with the Client Control Strategy when a local > app sends an Interest with a NextHopFaceId tag set to the Content Store?s > FaceID (254). No match is found in the Content Store, and the Interest is > left pending. When a remote Interest arrives for the same name while the > previous Interest is pending, the Interest is dropped by the Best Route > Strategy. When I have ClientControlStrategy inherit from > BestRouteStrategy2, this issue seems to be resolved. > > I?ve attached some slides which illustrate the issue I am experiencing. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide.pesavento at lip6.fr Wed Jan 13 16:22:48 2016 From: davide.pesavento at lip6.fr (Davide Pesavento) Date: Thu, 14 Jan 2016 01:22:48 +0100 Subject: [Nfd-dev] Maximum FIB size In-Reply-To: <5696CFBD.3030508@uniroma2.it> References: <56962739.5020303@uniroma2.it> <0f3869ef2fc54290af11a7cf36abe5c9@CY1PR02MB1706.namprd02.prod.outlook.com> <5696CFBD.3030508@uniroma2.it> Message-ID: On Wed, Jan 13, 2016 at 11:29 PM, Bruno Ricci wrote: > Hi guys, > > first of all, thank you for your answers. > > All we did was run a bash script that calls nfdc register. All routes are > random string of 16 chars, and are set towards a random IP address using > UDP. As simple as (pseudocode) > > for i in 1..100000 > do > ip=random(3.3.3.3) > name=random(16) > nfdc register ndn:/$name udp://$ip > sleep 1 > done > > This runs fine without errors (at least with the default debug level), until > NFD silently crashes. As Junxiao pointed out, maybe the problem relies on > the number of faces, and not on the FIB size (I honestly haven't thought > about that, thanks for pointing that out). I will try tomorrow morning at > work to re run the script reducing the faces number, and to run NFD inside > gdb. > > I will keep you posted, thanks again. > > Bruno > Hi Bruno, I'm pretty sure you went well over the maximum number of open file descriptors allowed by the system, e.g. it's normally set to 1024 on ubuntu linux. This happens because for every prefix you register, you're also implicitly creating a new face. And each face needs a socket, which means an open file descriptor. So basically you're trying to open 100k fds... (or a bit less if some of the generated IPs are duplicates). HTH! Ciao, Davide From bruno.ricci at uniroma2.it Thu Jan 14 03:36:04 2016 From: bruno.ricci at uniroma2.it (Bruno Ricci) Date: Thu, 14 Jan 2016 12:36:04 +0100 Subject: [Nfd-dev] Maximum FIB size In-Reply-To: References: <56962739.5020303@uniroma2.it> <0f3869ef2fc54290af11a7cf36abe5c9@CY1PR02MB1706.namprd02.prod.outlook.com> <5696CFBD.3030508@uniroma2.it> Message-ID: <56978824.7010204@uniroma2.it> Dear all I ran some tests using the same script I used, but always using the same IP address, and I successfully managed to add 10000 FIB entries. Looks like the number of faces (and thus, I think, the file descriptor limit) was indeed the problem. I still cannot figure out why the problem didn't happen always at the same point, but at least now I am aware of what the problem might be. Thank you all for the help. Best regards Bruno On 14/01/2016 01:22, Davide Pesavento wrote: > On Wed, Jan 13, 2016 at 11:29 PM, Bruno Ricci wrote: >> Hi guys, >> >> first of all, thank you for your answers. >> >> All we did was run a bash script that calls nfdc register. All routes are >> random string of 16 chars, and are set towards a random IP address using >> UDP. As simple as (pseudocode) >> >> for i in 1..100000 >> do >> ip=random(3.3.3.3) >> name=random(16) >> nfdc register ndn:/$name udp://$ip >> sleep 1 >> done >> >> This runs fine without errors (at least with the default debug level), until >> NFD silently crashes. As Junxiao pointed out, maybe the problem relies on >> the number of faces, and not on the FIB size (I honestly haven't thought >> about that, thanks for pointing that out). I will try tomorrow morning at >> work to re run the script reducing the faces number, and to run NFD inside >> gdb. >> >> I will keep you posted, thanks again. >> >> Bruno >> > > Hi Bruno, > > I'm pretty sure you went well over the maximum number of open file > descriptors allowed by the system, e.g. it's normally set to 1024 on > ubuntu linux. This happens because for every prefix you register, > you're also implicitly creating a new face. And each face needs a > socket, which means an open file descriptor. So basically you're > trying to open 100k fds... (or a bit less if some of the generated IPs > are duplicates). > > HTH! > > Ciao, > Davide > -- ---------------------------------------------------------------------- Bruno Ricci, Ph.D. Post-doc Researcher CNIT - Consorzio Nazionale Interuniversitario per le Telecomunicazioni Department of Electronic Engineering, University of Rome "Tor Vergata" Website: http://netgroup.uniroma2.it/bruno-ricci/ Tel.: +39 06 7259 7445 From nfd-call-notification at mail1.yoursunny.com Thu Jan 14 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 14 Jan 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20160114 Message-ID: <201601141500.u0EF02LV006405@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Jan 19 07:00:04 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 19 Jan 2016 08:00:04 -0700 Subject: [Nfd-dev] NFD call 20160119 Message-ID: <201601191500.u0JF04gW009172@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Jan 21 07:00:03 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 21 Jan 2016 08:00:03 -0700 Subject: [Nfd-dev] NFD call 20160121 Message-ID: <201601211500.u0LF03EE009205@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From mjs at cisco.com Thu Jan 21 07:11:12 2016 From: mjs at cisco.com (Mark Stapp) Date: Thu, 21 Jan 2016 10:11:12 -0500 Subject: [Nfd-dev] NFD call 20160121 In-Reply-To: <201601211500.u0LF03EE009205@lectura.cs.arizona.edu> References: <201601211500.u0LF03EE009205@lectura.cs.arizona.edu> Message-ID: <56A0F510.1060407@cisco.com> I've just noticed that the redmine links in this series of emails redirect through google - through their tracker network, I'm guessing. Is there a reason you're doing that - do you actually use tracking information of some kind about our use of your redmine server? Thanks, Mark On 1/21/16 10:00 AM, NFD call notification wrote: > Dear folks > > This is a reminder of the upcoming NFD call using Bluejeans > https://bluejeans.com/760263096. The current call time is every > Tuesday/Thursday 13:00-14:00 Pacific Time. The current agenda includes > the following issues: > > ------------------------------------------------------------------------ > > NFD 0.5 feature planning > http://redmine.named-data.net/issues/3400 > > > > http://redmine.named-data.net/issues/3333#note-2 > > > > Interest digest > > scheduled: 20160121 > > need: Alex > > Status report on devguide updates > http://redmine.named-data.net/issues/3395 > > > > http://redmine.named-data.net/issues/3396 > > > http://redmine.named-data.net/issues/3397 > > > http://redmine.named-data.net/issues/3390 > > > http://redmine.named-data.net/issues/3392 > > > http://redmine.named-data.net/issues/3391 > > > > http://redmine.named-data.net/issues/3389 > > > http://redmine.named-data.net/issues/3393 > > > > Status update on PIT lookup algorithm update > > http://redmine.named-data.net/issues/3363 > > > > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > From aa at CS.UCLA.EDU Thu Jan 21 11:05:15 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Thu, 21 Jan 2016 11:05:15 -0800 Subject: [Nfd-dev] NFD call 20160121 In-Reply-To: <56A0F510.1060407@cisco.com> References: <201601211500.u0LF03EE009205@lectura.cs.arizona.edu> <56A0F510.1060407@cisco.com> Message-ID: <64E0B8A4-C0D1-4336-A6E8-A5F7508BF31E@cs.ucla.edu> Hi Mark, It is not intentional and there is no specific reason for doing this. It is just an artifact of the script we wrote that converts the google docs (place we collect issues for the call) to the announcement email. Will try to fix this issue. --- Alex > On Jan 21, 2016, at 7:11 AM, Mark Stapp wrote: > > I've just noticed that the redmine links in this series of emails redirect through google - through their tracker network, I'm guessing. Is there a reason you're doing that - do you actually use tracking information of some kind about our use of your redmine server? > > Thanks, > Mark > > On 1/21/16 10:00 AM, NFD call notification wrote: >> Dear folks >> >> This is a reminder of the upcoming NFD call using Bluejeans >> https://bluejeans.com/760263096. The current call time is every >> Tuesday/Thursday 13:00-14:00 Pacific Time. The current agenda includes >> the following issues: >> >> ------------------------------------------------------------------------ >> >> NFD 0.5 feature planning >> http://redmine.named-data.net/issues/3400 >> >> >> >> http://redmine.named-data.net/issues/3333#note-2 >> >> >> >> Interest digest >> >> scheduled: 20160121 >> >> need: Alex >> >> Status report on devguide updates >> http://redmine.named-data.net/issues/3395 >> >> >> >> http://redmine.named-data.net/issues/3396 >> >> >> http://redmine.named-data.net/issues/3397 >> >> >> http://redmine.named-data.net/issues/3390 >> >> >> http://redmine.named-data.net/issues/3392 >> >> >> http://redmine.named-data.net/issues/3391 >> >> >> >> http://redmine.named-data.net/issues/3389 >> >> >> http://redmine.named-data.net/issues/3393 >> >> >> >> Status update on PIT lookup algorithm update >> >> http://redmine.named-data.net/issues/3363 >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From yudiandreanp at live.com Thu Jan 21 19:13:32 2016 From: yudiandreanp at live.com (Yudi Andrean) Date: Fri, 22 Jan 2016 10:13:32 +0700 Subject: [Nfd-dev] NFD error when configuring FIB Message-ID: Just installed NFD from ppa on a linux 14.04 machine and I got this error while doing the nfdc configuration (tried sudo-ed it before) ERROR: error while connecting to the forwarder (Connection refused) Any help?---Yudi A. Phanama -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Fri Jan 22 12:29:32 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Fri, 22 Jan 2016 12:29:32 -0800 Subject: [Nfd-dev] NFD error when configuring FIB In-Reply-To: References: Message-ID: Did you have any errors during the installation process? The error you are seeing simply means that nfd process hasn't started, though it should after you have installed 'nfd' package. Can you check the logs /var/log/upstart/nfd.log and see if there are any errors there. --- Alex > On Jan 21, 2016, at 7:13 PM, Yudi Andrean wrote: > > Just installed NFD from ppa on a linux 14.04 machine and I got this error while doing the nfdc configuration (tried sudo-ed it before) > > ERROR: error while connecting to the forwarder (Connection refused) > > Any help? > --- > Yudi A. Phanama -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jdd at wustl.EDU Sat Jan 23 07:10:26 2016 From: jdd at wustl.EDU (Dehart, John) Date: Sat, 23 Jan 2016 15:10:26 +0000 Subject: [Nfd-dev] NFD error when configuring FIB In-Reply-To: References: Message-ID: <061B05EF-96F8-476B-B2A3-33A415B35E1A@wustl.edu> Yudi, Along the lines of what Alex said, I have seen this error often when I try to do the nfdc command right after starting nfd. I assumed it was just a timing problem in my scripts and that I needed to give nfd more time to get started. John > On Jan 22, 2016, at 2:29 PM, Alex Afanasyev wrote: > > Did you have any errors during the installation process? > > The error you are seeing simply means that nfd process hasn't started, though it should after you have installed 'nfd' package. Can you check the logs /var/log/upstart/nfd.log and see if there are any errors there. > > --- > Alex > >> On Jan 21, 2016, at 7:13 PM, Yudi Andrean wrote: >> >> Just installed NFD from ppa on a linux 14.04 machine and I got this error while doing the nfdc configuration (tried sudo-ed it before) >> >> ERROR: error while connecting to the forwarder (Connection refused) >> >> Any help? >> --- >> Yudi A. Phanama > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev From yudiandreanp at live.com Sat Jan 23 21:39:45 2016 From: yudiandreanp at live.com (Yudi Andrean) Date: Sun, 24 Jan 2016 12:39:45 +0700 Subject: [Nfd-dev] NFD error when configuring FIB In-Reply-To: <061B05EF-96F8-476B-B2A3-33A415B35E1A@wustl.edu> References: , , <061B05EF-96F8-476B-B2A3-33A415B35E1A@wustl.edu> Message-ID: I triggered the error again twice, here are the information from the log. From the 2 errors, we got 2 FATAL information there. I tried cat-ing the file manually, it needed me to sudo it to work (with the cat bash). 1453613293.855971 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment1453613293.855988 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard1453613293.856023 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard1453613293.856174 INFO: [InternalForwarderTransport] [id=0,local=null://,remote=null://] Creating transport1453613293.856209 INFO: [FaceTable] Added face id=255 remote=null:// local=null://1453613293.859131 INFO: [InternalForwarderTransport] [id=0,local=contentstore://,remote=contentstore://] Creating transport1453613293.859170 INFO: [FaceTable] Added face id=254 remote=contentstore:// local=contentstore://1453613293.861440 INFO: [PrivilegeHelper] dropped to effective uid=65534 gid=655341453613293.861688 INFO: [UnixStreamTransport] [id=0,local=unix:///run/nfd.sock,remote=fd://23] Creating transport1453613293.861732 INFO: [FaceTable] Added face id=259 remote=fd://23 local=unix:///run/nfd.sock1453613293.862099 FATAL: [NFD] FileStore: error opening file for reading: /var/lib/ndn/nfd/.ndn/ndnsec-tpm-file/OWVrLPad6DKRYDA7LObOjA7e0Tgd2N35csRDBcVhbjE=.pri1453613293.863104 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section1453613293.863388 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section1453613293.863428 INFO: [RibManager] Listening on: /localhost/nfd/rib1453613293.864904 FATAL: [NFD] FileStore: error opening file for reading: /var/lib/ndn/nfd/.ndn/ndnsec-tpm-file/OWVrLPad6DKRYDA7LObOjA7e0Tgd2N35csRDBcVhbjE=.pri It is weird, as the FileStore error still persist even if I sudo-ed the nfdc command (nfd-status command also yield the same error). ---Yudi > From: jdd at wustl.edu > To: aa at CS.UCLA.EDU > CC: yudiandreanp at live.com; nfd-dev at lists.cs.ucla.edu > Subject: Re: [Nfd-dev] NFD error when configuring FIB > Date: Sat, 23 Jan 2016 15:10:26 +0000 > > > Yudi, > > Along the lines of what Alex said, I have seen this error often when I try to do the nfdc command > right after starting nfd. I assumed it was just a timing problem in my scripts and that I needed > to give nfd more time to get started. > > John > > > On Jan 22, 2016, at 2:29 PM, Alex Afanasyev wrote: > > > > Did you have any errors during the installation process? > > > > The error you are seeing simply means that nfd process hasn't started, though it should after you have installed 'nfd' package. Can you check the logs /var/log/upstart/nfd.log and see if there are any errors there. > > > > --- > > Alex > > > >> On Jan 21, 2016, at 7:13 PM, Yudi Andrean wrote: > >> > >> Just installed NFD from ppa on a linux 14.04 machine and I got this error while doing the nfdc configuration (tried sudo-ed it before) > >> > >> ERROR: error while connecting to the forwarder (Connection refused) > >> > >> Any help? > >> --- > >> Yudi A. Phanama > > > > _______________________________________________ > > Nfd-dev mailing list > > Nfd-dev at lists.cs.ucla.edu > > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bigcatlei at gmail.com Mon Jan 25 14:12:09 2016 From: bigcatlei at gmail.com (Liu Lei) Date: Mon, 25 Jan 2016 14:12:09 -0800 Subject: [Nfd-dev] Using NDN Chunk for video file transfer Message-ID: Hi, I just noticed that a new NDN tool (NDN Chunks) is available online since a couple of days ago. https://github.com/named-data/ndn-tools/tree/master/tools/chunks I am just wondering if we can use this tool for video file transfer (i.e. producer publishes a video, and the consumer gets the video via NFD and plays it locally)? Thanks, Best regards, Lei -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at CS.UCLA.EDU Mon Jan 25 14:26:41 2016 From: aa at CS.UCLA.EDU (Alex Afanasyev) Date: Mon, 25 Jan 2016 14:26:41 -0800 Subject: [Nfd-dev] Using NDN Chunk for video file transfer In-Reply-To: References: Message-ID: <3D86561B-0569-41AD-9DBF-C0A9FEB707D1@cs.ucla.edu> Hi Lei, This tool was designed primarily to publish and retrieve finite ("static") files and not really for publishing and retrieving streams. For video, you may want to check NDN-RTC project (https://github.com/remap/ndnrtc ) and ndncon app that uses NDN-RTC (https://github.com/remap/ndncon ). There is also next-ndnvideo (https://github.com/iliamo/video-prototype ) project that you may be interested to take a look. --- Alex > On Jan 25, 2016, at 2:12 PM, Liu Lei wrote: > > Hi, > > I just noticed that a new NDN tool (NDN Chunks) is available online since a couple of days ago. > https://github.com/named-data/ndn-tools/tree/master/tools/chunks > > I am just wondering if we can use this tool for video file transfer (i.e. producer publishes a video, and the consumer gets the video via NFD and plays it locally)? > > Thanks, > Best regards, > > Lei -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From shijunxiao at email.arizona.edu Mon Jan 25 15:51:58 2016 From: shijunxiao at email.arizona.edu (Junxiao Shi) Date: Mon, 25 Jan 2016 16:51:58 -0700 Subject: [Nfd-dev] Using NDN Chunk for video file transfer In-Reply-To: References: Message-ID: Hi Liu I'd say, chunks is good for video file *transfer*, but as Alex said it's not for streaming. If you have a pre-generated video file, you can certainly publish it with ndnputchunks, and retrieve it with ndncatchunks piped into a video player. Yours, Junxiao On Mon, Jan 25, 2016 at 3:12 PM, Liu Lei wrote: > Hi, > > I just noticed that a new NDN tool (NDN Chunks) is available online since > a couple of days ago. > https://github.com/named-data/ndn-tools/tree/master/tools/chunks > > I am just wondering if we can use this tool for video file transfer (i.e. > producer publishes a video, and the consumer gets the video via NFD and > plays it locally)? > > Thanks, > Best regards, > > Lei > > > _______________________________________________ > Nfd-dev mailing list > Nfd-dev at lists.cs.ucla.edu > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Tue Jan 26 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Tue, 26 Jan 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20160126 Message-ID: <201601261500.u0QF029p006347@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: From shijunxiao at email.arizona.EDU Wed Jan 27 11:53:03 2016 From: shijunxiao at email.arizona.EDU (Junxiao Shi) Date: Wed, 27 Jan 2016 12:53:03 -0700 Subject: [Nfd-dev] NFD read out IP header fields In-Reply-To: <56A91D60.3090705@cs.arizona.edu> References: <56A91D60.3090705@cs.arizona.edu> Message-ID: Hi Klaus In NFD 0.4.0, IP header is unavailable to strategy. In order to properly implement this feature, you may look at: 1. In UnicastUdpTransport or TcpTransport, obtain ECN flags from the socket (which is managed by Boost.Asio). 2. In Transport::Packet struct, add a field to store the ECN flag, so it becomes available to the LinkService. 3. In LinkService, copy the above field into a packet Tag (look at ndn-cxx tag.hpp). 4. Then, forwarding and strategy can inspect ECN flag by reading the tag. In ndnSIM 2.1, all faces are directly over Ethernet, not over IP. So ECN flags aren't applicable to ndnSIM. #2371 will add IP overlay simulation to ndnSIM. After that, the procedure mentioned above can be applied to bring ECN flags into forwarding. Yours, Junxiao On Wed, Jan 27, 2016 at 12:41 PM, Klaus Schneider wrote: > Hi Junxiao, Alex, > > is there a way to read out IP header fields inside NFD? > > More specifically, I want to check the ECN flags inside the > afterReceiveInterest() and beforeSatisfyInterest() methods of the > forwarding strategy. > > I'm not asking for a feature extension, just some ideas for a quick and > dirty hack that I can do myself. > > It would be good if it also worked in ndnSIM. > > Best regards, > Klaus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nfd-call-notification at mail1.yoursunny.com Thu Jan 28 07:00:02 2016 From: nfd-call-notification at mail1.yoursunny.com (NFD call notification) Date: Thu, 28 Jan 2016 08:00:02 -0700 Subject: [Nfd-dev] NFD call 20160128 Message-ID: <201601281500.u0SF023Y030860@lectura.cs.arizona.edu> An HTML attachment was scrubbed... URL: